Michael StJohns | 30 Jul 23:30 2014


Hi -

Slightly different topic from before.

The signature over the finished messages is TLS-PRF(HASH (handshake 

My question - assuming the HASH and TLS-PRF both use SHA256 - what is 
the security strength of that signature function?

I note that back in the archive that Marsh Ray from Microsoft took a 
swing at this 
(https://www.ietf.org/mail-archive/web/tls/current/msg10584.html) and 
concluded it wasn't an issue, but he was looking at it from the 
viewpoint of recovery of the HMAC key, but I'm not sure this is the 
worst case viewpoint.

As I read the guidance, HMAC-SHA256 is 256 bit secure, but SHA256 is 
only 128 bit secure with respect to signatures.

If that's the case, is the handshake finished message signature security 
any stronger than the signature strength of the hash function?  E.g. 128 
bits for a SHA256 hash?

Note that I'm not having a discussion about whether or not 128 bits is 
sufficient, but whether or not SHA256 as the summary hash function 
represents the weakest part of the cipher suite for suites with bit 
strengths above 128 bits.

(Continue reading)

Martin Thomson | 30 Jul 22:58 2014

Key derivation processes

We've had a bit of discussion thus far about the role of the PRF and
its form.  I think that having a map that describes what material goes
where might help understanding the process.

Here's how I think we should try to structure the flow of keying material:

The handshake determines the PMS.  That's not any different from TLS 1.2.

>From the PMS, we derive a set of other keys and material derived from
those keys.  How that material is subsequently protected can vary
depending on the requirements around its usage.

   - A client read/server write encryption key

   - A client read/server write IV

   - A client write/server read encryption key

   - A client write/server read IV

   - Input for calculating the Finished message

   - A TLS extractor [RFC5705] primitive to be used in place of the MS

   - A TLS unique [RFC5929] value

   - A resumption key that is used as input to the PMS of a resumed connection

Then the PMS is discarded.

(Continue reading)

Michael StJohns | 30 Jul 16:56 2014

Premaster/Master convention

Given that TLS1.3 only does KeyAgreement, is there still any reason for 
the premaster -> master_secret derivation step?  We do (KA)->premaster 
and then premaster -> master and then master->(session keys).   We could 
probably do (KA)->master->(session keys) where the master secret is now 
the KA shared secret rather than premaster.

1) Is there any security reason for retaining the extra step given there 
is no longer a KeyTransport mechanism in TLS1.3?
2) Are there other *good* - non-security - reasons for retaining the 
extra step?

Salz, Rich | 30 Jul 03:57 2014

SNI and ALPN -- which firsr?

Is there a fixed order for processing a hello that has both ALPN and SNI?

For example, if you do ALPN first, then the SNI might end up “pointing to” a client with weaker ciphers than, say HTTP/2 allows.

On the other hand, I can see the case that the SNI is protocol-specific, so you should do ALPN first.


Thoughts?  Is this something we need to specify?  Or give general advice for the processing order of extzensions?



Principal Security Engineer

Akamai Technologies, Cambridge MA

IM: rsalz <at> jabber.me Twitter: RichSalz


TLS mailing list
TLS <at> ietf.org
Sean Turner | 29 Jul 14:48 2014

WGLC: draft-ietf-tls-cached-info

This is the working group last call for draft-ietf-tls-cached-info:
Please send comments on this draft to the TLS list before August 19, 2014.

Dave Garrett | 28 Jul 22:24 2014

PRF in 1.3


Issue #26 notes complication with the usage of a negotiable PRF. The
current suggestion mentioned was to consider removing PRF
negotiation in favor of SHA-256, calling it "good enough" until the next
protocol version. I agree that this is quite possibly the case, however
I would like to suggest future proofing things a bit. Old versions of TLS
used the strategy of dual hash algorithms "to ensure that
non-catastrophic flaws in one algorithm will not break the overall
protocol" [RFC4346 F.1.5]. TLS 1.1 used MD5+SHA1. For TLS 1.3, I
would like to suggest SHA2-256+SHA3-256 or similar for consideration.
Picking a single combo allows the removal of negotiation, fixing any issues
that causes, provides a simpler spec for this feature, and allows both the
current standard and new SHA functions to be used without having to
rely 100% on either. Adoption rates of new TLS versions are less than
ideal, so future proofing in manners like this that don't add a fantastic
amount of additional complexity seems like an idea worth consideration.

- Dave
Salz, Rich | 28 Jul 18:09 2014

Author change

I think we should instruct Eric to remove Tim as an editor and add him to the Contributors section as co-author of TLS 1.1 and TLS 1.2


I am sure modesty prevents Eric from doing this himself. J



Principal Security Engineer

Akamai Technologies, Cambridge, MA

IM: rsalz <at> jabber.me; Twitter: RichSalz


TLS mailing list
TLS <at> ietf.org
Watson Ladd | 26 Jul 19:58 2014

Unwarrented change to point formats

Dear all,
Curve25519 was a draft. Curve25519 came back with good reviews from
the CFRG. End of story? No: the TLS WG leadership has decided to ask
for the choice of curves, on nebulous criteria, ignoring existing
drafts, on the basis that the curves must be applicable "IETF wide".

I don't see the reason for this, especially given that OpenSSH has
implemented and deployed Curve25519 and Ed25519, complete with
Montgomery form on the wire.  Arguing that we need twisted Edwards
point formats everywhere for consistency with existing libraries
ignores what has already been deployed and widely adopted.

Watson Ladd
Joseph Salowey (jsalowey | 25 Jul 19:37 2014

Encryption of TLS 1.3 content type

At the interim meeting on July 20, 2014 there was general consensus to support the encryption of TLS 1.3
content type.  The favored approach was to remove the content type and version from the TLS record layer
header and add the content type to the encrypted data.   The proposal is to update the draft to document this
approach and try to run some tests to see if this causes much grief with middle boxes.  If you object to this
proposal please respond to the list by Friday, August 01, 2014.  
Martin Thomson | 24 Jul 20:21 2014

shibboleth and the nonce

(No, that's not a proposed prog-synth-death-polka band name.)

The arguments around the way that explicit/implicit nonces interact
with certification were, I thought, already exhausted.  So I'd like to
see if some points can be clarified:

As far as I am aware, there are no concrete concerns about implicit
nonces from a straight-up security perspective.  Is that right?

If the concerns are solely around the certification of crypto modules,
then we need more information to be able to make a rational decision

If the static inputs are keys, and the per-record inputs are nonce +
ad + plaintext, I see no problem.

The previous response to suggestions that the nonce was a required
input was to have a counter produce the nonce input, with a matching
counter and validation in the module.

The new information yesterday was that David McGrew suggested that the
nonce needed to be arbitrary.  In that case, do we actually need the
input to be validated?  Does the certification process check that the
module produces different output for different nonces by starting
separate module instances with the same values for all other inputs
(keys, ad, and plaintext) then varying the input nonces?

I'm sure that there are other concerns, but it's hard for me to make
an assessment based on the information made available thus far.
internet-drafts | 23 Jul 00:12 2014

I-D Action: draft-ietf-tls-negotiated-ff-dhe-00.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-00.txt
	Pages           : 19
	Date            : 2014-07-22

   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:

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: