Joseph Salowey | 24 Apr 19:10 2015

Consensus for AEAD IV

The general consensus on the list seems to prefer to derive "IV" and use it to make the AEAD nonce less predictable. Most folks seemed to be OK with this approach.    In Dallas, there was significant support for using the derived "IV" as a per session XOR mask for the counter.  If you have objections to this approach please respond on the list by May 1, 2015 . 


TLS mailing list
TLS <at>
Russ Housley | 17 Apr 20:59 2015

HSM-friendly Key Computation

Section 6.3 of draft-ietf-tls-tls13-05 describes the key calculation from the current master secret
(MS).  First a key block is computed:

      key_block = PRF(MS,
                      "key expansion",
                      SecurityParameters.server_random +

Then, the key block is divided into keys and IVs:


If one wants to implement the cryptographic functions in a Hardware Security Module (HSM), this structure
is far from ideal.  In general I would expect the client_write_key and server_write_key to stay inside the
protected boundary of the HSM, but the client_write_IV and server_write_IV do not need this protection. 
Both of these coming from the same key_block makes this separation very difficult to implement.

Can we get these values from different invocations of the PRF?  I'd like to see one invocation for values that
are expected to remain secret and a separate invocation for values that do not need to remain secret.

IETF Secretariat | 16 Apr 21:05 2015

ID Tracker State Update Notice: <draft-ietf-tls-negotiated-ff-dhe-08.txt>

IANA review state changed to IANA OK - Actions Needed
ID Tracker URL:
Amanda Baber via RT | 16 Apr 20:11 2015

[IANA #817122] Last Call: <draft-ietf-tls-negotiated-ff-dhe-08.txt> (Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for TLS) to Proposed Standard


IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-tls-negotiated-ff-dhe-08. Please see below and report any inaccuracies
as soon as possible.

IANA's reviewer has the following comments:

IANA understands that, upon approval of this document, there is a single action that IANA must complete.

In the EC Named Curve Registry in the Transport Layer Security (TLS) Parameters registry at

A note will be added to the registry indicating that values from 256-511 (inclusive) are set aside for
"Finite Field Diffie-Hellman groups," and that all other entries in the registry are "Elliptic curve
groups." This document will be listed as an additional reference for the registry itself. 

In addition, the four highest codepoints in the Finite Field Diffie-Hellman group range (508-511,
inclusive) will be marked "Reserved for Private Use."

Finally, five new registration will be added the registry (along with the PRIVATE USE restriction) as follows:

| Value | Description | DTLS-OK | Reference |
| 256 | ffdhe2048 | Y | [ RFC-to-be ] |
| 257 | ffdhe3072 | Y | [ RFC-to-be ] |
| 258 | ffdhe4096 | Y | [ RFC-to-be ] |
| 259 | ffdhe6144 | Y | [ RFC-to-be ] |
| 260 | ffdhe8192 | Y | [ RFC-to-be ] |
| 508-511 (inclusive) | Reserved for Private Use | - | [ RFC-to-be ]  |

Note:  The actions requested in this document will not be completed until the document has been approved for
publication as an RFC. This message is only to confirm what actions will be performed.   


Amanda Baber
IANA Request Specialist


On Sat Apr 04 02:08:03 2015, iesg-secretary <at> wrote:
> The IESG has received a request from the Transport Layer Security WG
> (tls) to consider the following document:
> - 'Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for TLS'
>   <draft-ietf-tls-negotiated-ff-dhe-08.txt> as Proposed Standard
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> ietf <at> mailing lists by 2015-04-17. Exceptionally, comments may be
> sent to iesg <at> instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
> Abstract
>    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 using a
>    section of the TLS "EC Named Curve Registry" to establish common
>    finite-field DH parameters with known structure and a mechanism for
>    peers to negotiate support for these groups.
> The file can be obtained via
> IESG discussion can be tracked via
> No IPR declarations have been submitted directly on this I-D.
Thijs van Dijk | 16 Apr 18:07 2015

Request for clarification: "in the same flight"

Dear all,

I'm working on a hobby implementation of TLS1.3 as a way of vetting the spec draft, and I ran into an issue with sending the ClientKeyShare.

The handshake spec (7.2) says it should be sent "in the same flight" as the ClientHello message, without specifying the correct encapsulation method. Maybe it's just me, but this phrase could be interpreted as either the following:

TCP packet
 \- TLSPlaintext  (content_type 22)
     |- Handshake (msg_type 1)
     |   \- ClientHello
     \- Handshake (msg_type 5)
         \- ClientKeyShare


TCP packet
 |  TLSPlaintext  (content_type 22)
 |   \- Handshake (msg_type 1)
 |       \- ClientHello
 \- TLSPlaintext  (content_type 22)
     \- Handshake (msg_type 5)
         \- ClientKeyShare

If I were to venture a guess, I'd say the two are equivalent, but it's also conceivable that some implementations require any TLSPlaintext to contain exactly one child struct. (Source: mine does; I'm trying to figure out if that's a bug or not.)

I think that if we have a preference for either one, the spec should reflect that. If not, it may be wise to explicitly declare both options to be correct.



(I have also opened a Github issue to this effect: )

TLS mailing list
TLS <at>
Radia Perlman | 16 Apr 07:53 2015

Secdir review of draft-ietf-tls-session-hash-04

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG. These
comments were written primarily for the benefit of the security area
directors. Document editors and WG chairs should treat these comments just
like any other last call comments.

This document proposes an extension and a small computation change to TLS to
mitigate the "triple handshake" (and perhaps other related
yet-to-be-discovered) vulnerabilities in TLS. For details of the attack,
see: Bhargavan, K., Delignat-Lavaud, A., Fournet, C., Pironti, A., and P.
Strub, "Triple Handshakes and Cookie Cutters: Breaking and Fixing
Authentication over TLS", IEEE Symposium on Security and Privacy
(Oakland'14) , 2014.

In my judgement, the proposed change does a fine job of addressing the
vulnerability. I assume this has gotten lots of other eyes as well.

I hope that someone has tested the major server implementations of TLS to
assure that they follow the spec and will ignore the new unrecognized
extension if a client presents it. The TLS spec clearly says that they MUST
do so, but there has been a history of hacks done by implementers to get
around bugs in legacy implementations. If there are a significant number of
implementations that get this wrong, it would be worth considering
implementing the extension in some different way (e.g. as an additional
proposed cipher-suite).

This vulnerability is subtle and would not affect the security of most uses
of TLS, though evaluating whether it does or does not in any particular case
is difficult so it makes sense to implement this change universally over
time. This spec, however, takes a hard line in the trade-off between
security and interoperability that I believe needs to be carefully
considered. In particular, I believe lots of implementers will *not* follow
this spec in implementing the feature in order to get greater
interoperability with deployed systems.

In particular, section 5.2 paragraph 4 & 5 say:

"If the server receives a ClientHello without the extension, it SHOULD abort
the handshake. If it chooses to continue, then it MUST NOT include the
extension in the ServerHello."

"If a client receives a ServerHello without the extension, it SHOULD abort
the handshake."

Implementations that follow these SHOULDs will not interoperate with any
existing implementation of TLS, making a phased deployment of the new
software impossible. I believe it would be preferable to say that
implementations of TLS SHOULD be configurable to reject peers that do not
implement the extension so that improved security at the expense of
interoperability can be enabled after a critical mass of deployments exist.

In section 5.3, there is similar language to disable session resumption when
the extension is not present. While this may be more acceptable because it
will not break interoperability, it *will* cause a significant performance
degradation in some important scenarios. I would again recommend that it be
a configuration parameter so that no one will refuse to deploy this change
because of performance concerns.

Section 5.4 also mandates breaking behavior (and here it is a MUST) in
scenarios where there is most likely to be a triple handshake vulnerability.
Given that there are cases with no such vulnerability and given that people
will be reluctant to deploy software that turns a subtle security
vulnerability into non-interoperability, I believe this should be a matter
of configuration.

Section 5.4 paragraph 4 seems to be undermining earlier requirements, saying
that it MAY be safe (to break rules stated earlier). Taking this to heart, I
would propose that the "MUST abort" clauses in sections 5.2 and 5.3 be
softened to at least allow - and perhaps recommend - implementations to
support this scenario.



In section 6.2, it is claimed that the security of TLS depends on the hash
function used being collision resistant, use of MD5 and SHA1 is NOT
RECOMMENDED. That would rule out use of TLS 1.0 and TLS 1.1. While a worthy
goal, I don't believe this enhancement makes migration away from TLS 1.0 and
TLS 1.1 any more urgent. I also don't believe that TLS depends on the hash
function being collision resistant (but only that it is second preimage

P9: "each other identity" -> "each other's identities"
P10: "that where hence" -> "that were hence"
P11: "server/ Hence," -> "server. Hence,
TLS mailing list
TLS <at>
Peter Gutmann | 15 Apr 17:38 2015

Re: AD review of draft-ietf-tls-negotiated-ff-dhe-08

Santiago Zanella <szanella <at>> writes:

>That does not follow from what I said. The 8.7% group is the 4th most common,
>the top 3 have also 1024-bit moduli.

Yeah, that was the puzzling bit, so just out of curiosity what were the other
1024-bit groups if they weren't the RFC 2409 one?

IETF Secretariat | 15 Apr 00:56 2015

ID Tracker State Update Notice: <draft-ietf-tls-session-hash-04.txt>

IESG state changed to Waiting for Writeup::Revised I-D Needed from Waiting for Writeup
ID Tracker URL:
Santiago Zanella | 15 Apr 16:18 2015

Re: AD review of draft-ietf-tls-negotiated-ff-dhe-08

Some hard data that can be of interest.

A current full IPv4 survey of groups used for FFDHE shows that the
2048-bit MODP group from RFC3526 is the 5th most common (and the most
common with a modulus longer than 1024 bits): roughly 7.8% of over 10M
hosts use it. For comparison, 8.7% use IKE 1024-bit MODP group. The
other MODP groups in RFC3526 are used only marginally.

So, there is a significant number of hosts using IKE 2048-bit MODP
group, which is as strong as the weakest group in the draft.

That said, I fully agree with the reasons given in the draft for not
naming any existing groups*, but lack of common use should not be one of them.


IETF Secretariat | 14 Apr 00:06 2015

ID Tracker State Update Notice: <draft-ietf-tls-session-hash-04.txt>

IANA review state changed to IANA OK - Actions Needed
ID Tracker URL:
Martin Rex | 13 Apr 23:18 2015

TLS ALPN (rfc7301), no reserved seperator char and why is 0 no banned

I have only recently looked at the TLS extension ALPN spec (RFC7301)
and it seems that there currently is no reserved character for the
ALPN ID registry that could be used as seperator character if one
wanted to facilitate the admin/user UI and tracing/logging.

While I don't allowing UTF8, I would have really appreciated
reserving at least one character (or octet value) for the obvious
purpose of printing all currently offered protocols in a single line.

I'm also puzzled why the octet value 0 was not banned from the
ALPN ID either.  That seems like calling for trouble.