Subject: [TLS] I-D Action: draft-ietf-tls-session-hash-04.txt

From: [email-masked]
Date: Mon, 09 Mar 2015 12:56:29 -0700

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-04.txt
	Pages           : 14
	Date            : 2015-03-09

Abstract:
   The Transport Layer Security (TLS) master secret is not
   cryptographically bound to important session parameters such as the
   server certificate.  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:
https://datatracker.ietf.org/doc/draft-ietf-tls-session-hash/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-tls-session-hash-04

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-tls-session-hash-04

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:
ftp://ftp.ietf.org/internet-drafts/

---

From: Peter Dettman <[email-masked]>
Date: Tue, 10 Mar 2015 21:44:41 +0700

Hi,

I've mentioned this a while back, but I am still curious what is the 
reasoning to require the ServerHello in an abbreviated (accepted 
resumption) handshake to include the extended_master_secret extension? 
(see section 5.3, last bullet point).

Searching the list for relevant comments, I found these:

     Myself (Aug 26): don't send the extension

     Yoav Nir (Nov 24): I would go for the less meaningless bytes option.
     Adam Langley (Nov 24): let's say that the server SHOULD NOT echo it

     Eric Rescorla (Jan 16): The server MUST NOT echo it?
     Martin Thompson (Jan 16): I think that I'd prefer to have the 
server echo the extension in this case too.
     Eric Rescorla (Jan 16): I could live with this as well.

So, a bob each way, but there wasn't much in the way of discussion as to 
why (at least on-list).

The only extension I am aware of that is normally required in the 
ServerHello of an abbreviated handshake is renegotiation_info (RFC 
5746). There is justification for doing so, since "secure_renegotiation" 
is a connection-specific flag, not a session parameter.

I don't really see any special justification for it in the case of 
extended_master_secret. If a client tries to resume a (EMS) session, and 
includes the extension in ClientHello as required, and the server 
resumes, then what's missing that is fixed by requiring the ServerHello 
extension as well?

Also, why SHOULD resumption of an (EMS) session fail if the client 
doesn't include the extension? Section 5.3, second list item:

       If the new ClientHello does not contain the
       "extended_master_secret" extension, the server SHOULD fall back to
       a full handshake by sending a ServerHello that rejects the offered
       session but continues with a full handshake.  If it continues with
       an abbreviated handshake the considerations in Section 5.4 apply.

So the server SHOULD pick the (all else being equal) less-secure, 
more-expensive of the two options the client proposed?

There are of course precedents for similar requirements, e.g. that the 
offered cipher_suites/compression_methods must contain the 
session-selected values in order for a session to be resumable, but 
again, there's a justification for that: the client can't resume the 
session if it doesn't support the algorithms needed to "run" it. That 
doesn't seem applicable to extended_master_secret.

Regards,
Pete Dettman

On 10/03/2015 2:56 am, [email-masked] wrote:
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Karthikeyan Bhargavan <[email-masked]>
Date: Tue, 10 Mar 2015 16:52:57 +0100

These are good points. We went back and forth over when editing the text.

I would have been happy to say that if the original session uses an extended_master_secret,
then neither the ClientHello nor the ServerHello need to use the extension.

However, some might feel that it is bizarre for a client or server that originally
proposed the extension to not use the extension during resumption.
Which is why I left it at SHOULD (to be, as you note, consistent with
other resumption requirements like using the same cipher suite.)

I’ll let others weigh in on this choice. See and comment also on
the related last paragraph of 5.4.

On 10 Mar 2015, at 15:44, Peter Dettman <[email-masked]> wrote:

> Hi,
> 
> I've mentioned this a while back, but I am still curious what is the reasoning to require the ServerHello in an abbreviated (accepted resumption) handshake to include the extended_master_secret extension? (see section 5.3, last bullet point).
> 
>    Martin Thompson (Jan 16): I think that I'd prefer to have the server echo the extension in this case too.
> So, a bob each way, but there wasn't much in the way of discussion as to why (at least on-list).
> 
> The only extension I am aware of that is normally required in the ServerHello of an abbreviated handshake is renegotiation_info (RFC 5746). There is justification for doing so, since "secure_renegotiation" is a connection-specific flag, not a session parameter.
> 
> I don't really see any special justification for it in the case of extended_master_secret. If a client tries to resume a (EMS) session, and includes the extension in ClientHello as required, and the server resumes, then what's missing that is fixed by requiring the ServerHello extension as well?
> 
> Also, why SHOULD resumption of an (EMS) session fail if the client doesn't include the extension? Section 5.3, second list item:
> 
> So the server SHOULD pick the (all else being equal) less-secure, more-expensive of the two options the client proposed?
> 
> There are of course precedents for similar requirements, e.g. that the offered cipher_suites/compression_methods must contain the session-selected values in order for a session to be resumable, but again, there's a justification for that: the client can't resume the session if it doesn't support the algorithms needed to "run" it. That doesn't seem applicable to extended_master_secret.
> 
> Regards,
> Pete Dettman
>

---

From: Henrik Grubbström <[email-masked]>
Date: Tue, 10 Mar 2015 17:43:16 +0100

On Tue, Mar 10, 2015 at 3:44 PM, Peter Dettman
<[email-masked]> wrote:
> reasoning to require the ServerHello in an abbreviated (accepted resumption)
> handshake to include the extended_master_secret extension? (see section 5.3,
> last bullet point).
[...]
> Also, why SHOULD resumption of an (EMS) session fail if the client doesn't
> include the extension? Section 5.3, second list item:

Because it is best practice to send the same extensions in an
attempted resumption ClientHello as in a normal ClientHello. Consider
the case where the server doesn't remember the session id.

FYI: My server-side implementation of TLS performs the same extension
handling and protocol selection for resumption attempts as for normal
ClientHellos, and then validates that the resulting session parameters
are equivalent with the cached session before actually deciding to
resume the session.

-- 
Henrik Grubbström                                       [email-masked]
Roxen Internet Software AB                              [email-masked]