Jim Schaad | 2 Sep 01:18 2014

Master Secret Computation

This message applies to both the 1.3 TLS document and to the session hash

I have not ever implemented TLS, so I have been spending some time reading
the documents to try and figure out how things are going to work.  Based on
mail see, I have assumed that 1.3 is going to adopt the extended hash
computation for the master secret and have created my table based on this.
(If this is not the case then I think it needs to be argued.)

As part of putting together the attacked picture, I read a number of
different TLS documents which are not part of the core spec.  It is possible
that some of these are no longer needed and should be ruled out as possible
extensions to the TLS 1.3 document, but would be relevant to the extension
for the 1.2 (and prior) documents.

Notes on the picture that I have included:

Items tagged with [1] are sent only in the event that the server does not
want to have a client certificate.
Items tagged with [2] are sent only in the event that the a) there is a
client certificate or b) the new session ticket extension is being used.
Items tagged with [3] are sent in the event that a restart is made because
of a mismatch of key agree groups.

I am not clear if the use of the Supplemental Data extension means that the
server Finish message cannot be sent before receiving the response from the
The new session ticket extension requires that the client finish message be
validated before it can be sent to the client, thus it falls into the [2]
(Continue reading)

Jim Schaad | 2 Sep 00:21 2014

Clarifictions for failure to agree on key sizes during hello

I am trying to figure out how this works and I find myself confused and not able to make headway.


My view of the messages looks like the following:

(Yes I know that I have shortened the cipher suite strings and have defined a new extension for ECDH parameters that I do not believe exists yet.)



                Cipher_suites = <TLS_DHE_RSA, TLS_DHE_DSS, TLS_ECDHE_RSA, TLS_ECDHE_ECDSS>

                NegotiatedDHParams=<ffdhe2432, ffdhe4096>

                NegotiatedECDHParams=<P-256, P-521>

                ClientKeyExchange=<(dhe, ffdhe2432), (ecdh, P-256)>



                                                                                                Cipher_suite = ??????

                                                                                                NegotiatedDHParams = <ffdhe4096>

                                                                                                NegotiatedECHDParams = <P-521>



                Copy above with a different ClientKeyExchange extension.



I don’t know what is going to be placed in the Cipher_suite field so that the client can say – who there is a mismatch in the keys that I passed in, but I should not expect to see a ServerkeyExchange message (which I might not like).


Putting a cipher suite means that the client must check for an overlap between the negotiated params extension for that suite to check for an overlap between what the server returns and what it put into the client key exchange record.


Putting a cipher suite means that the client might get locked into doing DH in this case, when it would prefer doing ECDH for P-521 to doing  DH t 4096.


It was not clear to me from the document, but I think it is correct, that the way this is handled is to use the negotiated params extensions to declare what sizes I support, even if I did not send keys of that size to start with. 


Putting a value into the cipher_suite field that is not in the client hello list seems to be a bad idea, unless there is a specific value that says I did not like the set of client keys you gave me to start with.  Since this is not defined I assume that it is not there.  (as an example putting TLS_DH_anon_* would be a disaster in the making.)




TLS mailing list
TLS <at> ietf.org
Ralph Holz | 1 Sep 16:58 2014

NULL cipher to become a MUST NOT in UTA BCP

Dear list,

I would like to notify the list of a feature in the draft for Best
Practices "Recommendations for Secure Use of TLS and DTLS"


=> "Implementations MUST NOT negotiate the NULL cipher suites"

This may lead to implementations dropping NULL (or making it hard to

There used to be one reasonable use case for NULL that I am personally
aware of: grid traffic between large computing centres. Our group did
see such high-speed, high-volume traffic on our network monitors when we
did SSL/TLS/X.509 analyses - that was 3 years ago.

My contacts at grid centres tell me that NULL encryption was useful then
as the data was public anyway and good integrity was all that was
needed. I am told by one centre at least there is no real need for NULL
any more. In fact, the agreement seems to be that that cipher should be
eliminated now.

My personal take as one of the authors of the BCP is that the UTA WG
should process UNLESS someone has a use case that is relevant on the
same scale, or thinks the above statement does not hold in general.

In that case, please bring your use case to the attention of the UTA or
directly to the authors (i.e. Yaron Sheffer, yaronf.ietf <at> gmail.com, or
me). We would like to keep any discussion focused.



Ralph Holz
I8 - Network Architectures and Services
Technische Universit√§t M√ľnchen
Phone +
PGP: A805 D19C E23E 6BBB E0C4  86DC 520E 0C83 69B0 03EF

TLS mailing list
TLS <at> ietf.org
Sean Turner | 27 Aug 23:11 2014

TLS interim planning fall 2014

We would like to get input on the preferred dates and locations of an interim TLS meeting.  The dates on offer are:

October 1-2
October 2-3

in either Dublin or Paris


October 20-21
October 21-22

in London, Dublin, or Paris.

Please fill out the following doodle poll to indicate your preferences by the end of Friday September 29th:



Nikos Mavrogiannopoulos | 27 Aug 13:59 2014

a TLS server cannot be used in a use-case that requires privilege separation

While trying to implement the privilege separation paradigm in various
TLS servers, I've come to a limitation of the TLS protocol. Unlike SSH,
a TLS server cannot use privilege separation to perform authentication
of the client.

That is if we have:
----------------  -------------
|authentication|  | TLS server|
|  server      |  |           |
----------------  -------------

there is no way for the authentication server to authenticate a user
connecting to the TLS server, without having the authentication server
perform the whole TLS handshake. The latter of course defeats the
purpose of privilege separation.

Why is that? The reason is that unlike ServerKeyExchange the client's
CertificateVerify message is defined as:
      struct {
           digitally-signed struct {
               opaque handshake_messages[handshake_messages_length];
      } CertificateVerify;

meaning that the signature covers all the exchanged messages, and has no
field that can be set by the authentication server directly. Note that
in ServerKeyExchange the authentication server could have set a part or
the whole server_random[] and he could have used that as a proof that
the signature is on the current session. There can be very expensive
work-arounds, but are of significant complexity for the authentication
server, that again defeat the purpose of privilege separation.

I believe it is a nice goal to set for a future revision of TLS, to have
the CertificateVerify message modified to have the same properties as
the ServerKeyExchange message. That is, to have an additional fixed
field that is set by the server.

Daniel Migault | 27 Aug 13:11 2014

IV generation


draft-stjohns-tls-tls13-crypto-infra-00 [1] provides TLS crypto construction. I found the document interesting and well written, so thank you for doing so.

However, I have a question related to the IV  generation, and I would be happy to get some feed backs. In section 4.4 it recommends to generate the IV as follows:

 iv_data = PRDG ("clientAndServerIV", context,
                   2* SecurityParameters.fixed_iv_length * 8);

   Then, iv_data is partitioned as follows:


I am considering assymetric connectivity where one peer sends all the data, whereas the other only receives. (In my use case I use IPsec.)

In this case, this scheme seems to present the following drawbacks:
    1) It seems unnecessary to generate the receivers' IVs.
    2) More over it seems like a potential attack vector for memory/CPU exhaustion. If I suppose IVs are used in the order they are generated, then the receiver uses rIV[1], while the sender uses sIV[1]...., sIV[N]. If the receiver is likely to use rIV2 at the end of the download, then the sender needs to keep the values of r[IV[2], ..., rIV[N], or to re-compute them when used by the receiver.
    3) rIV and sIV may be seen as to distinct function, and thus use different keys.

As a result, it seems preferable to use something like 1) generating a server_iv_key and a client_iv_key 2) using that key to generate client_iv and server_iv separately.
## this would be a key derive from the master for example
key_iv_client_server = KDF( key_iv, "clientAndServerIV", context, 2 * SecurityParameters.fixed_iv_length * 8)

## the iv key is used to derive the two subkeys
key_iv_client = key_iv_client_server[:SecurityParameters.fixed_iv_length]
key_iv_server = key_iv_client_server[SecurityParameters.fixed_iv_length:]
client_iv = KDF(key_iv_client, "clientIV", context,

SecurityParameters.fixed_iv_length * 8)

server_iv = KDF(key_iv_server, "clientIV", context,

SecurityParameters.fixed_iv_length * 8)

This would be an alternative, but maybe it might be easier to use PRDG instead of KDF and using key_iv_client (resp. key_iv_client) as context. Both keys may also directly derived from the master.

[1] http://trac.tools.ietf.org/id/draft-stjohns-tls-tls13-crypto-infra-00.txt

Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58
TLS mailing list
TLS <at> ietf.org
internet-drafts | 27 Aug 09:27 2014

I-D Action: draft-ietf-tls-negotiated-ff-dhe-01.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Transport Layer Security Working Group of the IETF.

        Title           : Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for TLS
        Author          : Daniel Kahn Gillmor
	Filename        : draft-ietf-tls-negotiated-ff-dhe-01.txt
	Pages           : 22
	Date            : 2014-08-27

   Traditional finite-field-based Diffie-Hellman (DH) key exchange
   during the TLS handshake suffers from a number of security,
   interoperability, and efficiency shortcomings.  These shortcomings
   arise from lack of clarity about which DH group parameters TLS
   servers should offer and clients should accept.  This document offers
   a solution to these shortcomings for compatible peers by establishing
   a registry of DH parameters with known structure and a mechanism for
   peers to indicate support for these groups.

The IETF datatracker status page for this draft is:

There's also a htmlized version available at:

A diff from the previous version is available at:

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
Eric Rescorla | 26 Aug 18:56 2014

Should we allow GMT in ServerRandom?


Per WG consensus, we have removed the GMT field from ClientRandom
and ServerRandom but we still have the following text in TLS 1.3:

   Note: Versions of TLS prior to TLS 1.3 used the top 32 bits of
   the Random value to encode the time since the UNIX epoch. TLS 1.3
   Server implementations MAY opt to include the time in their
   Server.random values in order to accomodate clients which use
   that field for time synchronization.

There's no obvious way for a client to know if this is true or not and
people have suggested removing this text entirely see, for instance:

Does anyone want to argue in favor of retaining this?


TLS mailing list
TLS <at> ietf.org
Eric Rescorla | 26 Aug 18:34 2014

Pull request: Remove length from AEAD Ciphers

Per discussion in Toronto. Fixes:

Target merge date: 8/28.

Please comment here or on github if you see issues.


TLS mailing list
TLS <at> ietf.org
Nigel Smart | 23 Aug 22:22 2014

Re: Simplifying the proof

On 23/08/2014 20:00, tls-request <at> ietf.org wrote:
> If we want key confirmation, we should send a key confirmation
> value outside the record layer encryption to solve this.

Not quite true. If the key confirmation is sent un-encrypted one still
has a problem as the BR key agreement security definition will not
apply.   So it depends what you mean by "secure".  The correct
definition should be to have a combined "KA+secure channel"
definition it would appear. There has been multiple work on this
over the last couple of years; much in relation to TLS.

Watson Ladd | 22 Aug 21:39 2014

Simplifying the proof

Dear all,
While we now have a multi thousand line computer checkable proof of
the correctness of the handshake with certain extensions, this is
suboptimal in many respects. It's a pain to check, and interaction
with extensions is even more painful, which means that extending it to
all of TLS 1.3 is going to be even more painful.

How can we fix this? Everything goes fine, up until the master-secret
gets use to derive keys, and then the Finished message is sent. The
reason this isn't good is that we want the keys the record layer uses
to be independent of what an attacker saw in the handshake and they
aren't because of the Finished message coming after the Change Cipher
Spec. If we want key confirmation, we should send a key confirmation
value outside the record layer encryption to solve this. We should
also work on defining security properties we want new features to have
and work backwards, instead of going back from a design to determine
the security it actually provides.

Watson Ladd