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
(Continue reading)

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.


Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58
TLS mailing list
TLS <at>
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

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>
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>
Nigel Smart | 23 Aug 22:22 2014

Re: Simplifying the proof

On 23/08/2014 20:00, tls-request <at> 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
internet-drafts | 22 Aug 15:47 2014

I-D Action: draft-ietf-tls-session-hash-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           : Transport Layer Security (TLS) Session Hash and Extended Master Secret Extension
        Authors         : Karthikeyan Bhargavan
                          Antoine Delignat-Lavaud
                          Alfredo Pironti
                          Adam Langley
                          Marsh Ray
	Filename        : draft-ietf-tls-session-hash-01.txt
	Pages           : 8
	Date            : 2014-08-22

   The Transport Layer Security (TLS) master secret is not
   cryptographically bound to important session parameters such as the
   client and server identities.  Consequently, it is possible for an
   active attacker to set up two sessions, one with a client and another
   with a server, such that the master secrets on the two sessions are
   the same.  Thereafter, any mechanism that relies on the master secret
   for authentication, including session resumption, becomes vulnerable
   to a man-in-the-middle attack, where the attacker can simply forward
   messages back and forth between the client and server.  This
   specification defines a TLS extension that contextually binds the
   master secret to a log of the full handshake that computes it, thus
   preventing such attacks.

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

Internet-Drafts are also available by anonymous FTP at:
Joseph Salowey (jsalowey | 21 Aug 07:06 2014

Early code-point assignment for draft-ietf-tls-session-hash

We have a request for early code point assignment for the extended_master_secret extension in
draft-ietf-tls-session-hash.  I've asked the authors to update the draft with an IANA section including
the details.  If anyone has a concern with early code point assignment for this draft, please respond to the
list by September 3, 2014.  


Ilari Liusvaara | 20 Aug 18:45 2014

Problems with TLS 1.3 handshake protocol

Here is listing of some problems with proposed TLS 1.3 handshake
protocol (of various severity), and some proposals how to solve those.

1) Is ClientKeyExchange coming?

Because the handshake protocol uses transcripts, it requires that both
sides always know who will transmit next, which impiles knowing when
peer's flight has ended.

This goes badly with ClientKeyExchange. It is optional, and there is
no marker for end of flight. As consequence, the first flight can
end with either ClientHello or ClientKeyExchange.

Proposal: Stick those first flight key exchange messages inside

2) Duplicate ClientHello:

If the client misses all its guesses about Key Exchange, the current
spec has it restart from ClientHello.

This seems very dangerous. This kind of repetion is a good source of
bugs. Bugs that one absolutely does not want in any security-sensitive

Proposal: Have client send remedial key exchange message (containing
one key) if needed.

3) Duplicate master secrets:

The handshake does not hash exchange keys into master secret, and as
such is vulernable to duplicated master secrets.

This leads to THS and other vulernabilities.

Yes, those could also be addressed with validating keys, but some
implementations will just omit that and be vulernable.

The proposed THS fix does actually work here (it says to cut off
transcript as soon as all exchange keys are sent, which is enough).

In (EC)DHE, certificates do not contain exchange keys. 

But having to use that extension in TLS 1.3 would be sad (the TLS
1.3 key exchange should not be vulernable to THS&co no matter what).

Proposal: Hash the transcript up to where server's ChangeCipherSpec
appears and make the master secret depend upon that (this is
equivalent to what proposed THS fix would do).

That is: ClientHello, ServerHello, ServerKeyExchange (if present)
and ClientKeyExchange (if present).

4) Problems with PSK:

PSK has specific key exchange format, and the PSK spec has something
called identity_hint (which requires protocol on top to specify what
it means).

If there is no identity_hint, the client could send its identity
in ClientHello.

Otherwise this needs extra RTT.

Proposal: Does this need to be supported (some very constrained
devices seem to use PSK)? 

If yes:
- Client can send PSK identity in ClientHello. In this case, both
  ClientKeyExchange and ServerKeyExchange are absent.
- If no PSK identity in ClientHello, server sends identity hint in
  ServerKeyExchange (forced present) and client sends PSK identity
  in ClientKeyExchange.

5) Problems with DHE_PSK:

DHE_PSK has different specific format for KeyExchange messages.

The problems here are mostly similar to PSK, but there is
additional one: The identity is not DH algorithm specific, but
shared among all algorithms.

Proposal: Does this need to be supported?

If yes:
- Client can send PSK identity in ClientHello. DH key exchange
  proceeds as usual.
- No PSK identity in ClientHello, server sends indentity hint in
  ServerKeyExchange and client sends PSK identity and possibly key
  in ClientKeyExchange.

6) Problems with SRP:

SRP in general needs ServerKeyExchange before ClientKeyExchange.
Now, if client is able to guess the exchange group, the order
of those two can be inverted.

Also, the key exchange messages have their own format.

Some additional issues:
- The key shares are relatively large (multiplicative group!)
- The key shares are relatively slow to generate (ditto)
- The usual SRP groups do not match named groups.

There is no straightforward way to make ECC SRP.

Also, SRP is seemingly pretty much unused in context of TLS.

Proposal: Does this need to be supported?

If yes, just force remedial ClientKeyExchange (2RTT) with
SRP-specific ServerKeyExchange/ClientKeyExchange format.


RSA_PSK is another (non-PFS) variant of PSK. Does not seem to be of
much use.

Proposal: Not supported at all.

8) 0RTT issues:

Due to how applications work, failed 0RTT must smoothly fall back.
Losing the connection is not acceptable.

Losing the initial data is acceptable (client TLS stack can retransmit
it, presumably is not large).

And because duplicate ClientHello seems like asking for trouble, it
follows that 0RTT handshake should be like 1RTT, except for extra
encrypted data.

Also, because of difficulties in FS with 0RTT, one should still do
full rekey of the connection.

Proposal: Have optional extension for early encrypted data in
ClientHello. The server can accept or refuse it (signaling that in
ServerHello). Either way, the exchange otherwise proceeds normally.

If server refuses, client retransmits the data after it completes
the handshake.

9) Issue #71:
Traditionally TLS has split between DH and ECDH. But there is no
technical reason for that outside of arbitrary groups (which seem
like bad idea).

Also, if the spaces are unified, it would be useful to allow some
group to use special formats. Would make easier to support some
more special DH functions (e.g. Curve25519).

Also, one could make the group space 2 bytes, with 0-255 mapping 
to draft-dkg groups.

This runs into issues with ciphersuite names (since there would be
no difference between _ECDHE_ and _DHE_).

But then, TLS seems to get into similar trouble (but with signatures)
already via signature_algorithms extension (which is defined in
base TLS 1.2 document).

Proposal: ?

10) Editorial:

In section "Client Authentication and Key Exchange Messages", there is:
- Seemingly duplicate struct ClientKeyExchange (looks like old version)
- Seemingly unused struct PreMasterSecret (looks RSA-related)
- Seemingly transitively unused struct ClientDiffieHellmanPublic
- Seemingly transitively unused enum PublicValueEncoding.

Proposal: Remove those.