Subject: [TLS] UPDATED Last Call: <draft-ietf-tls-tls13-24.txt> (The Transport Layer Security (TLS) Protocol Version 1.3) to Proposed Standard

From: The IESG <[email-masked]>
Date: Fri, 16 Feb 2018 09:06:41 -0800

The IESG has received a request from the Transport Layer Security WG (tls) to
consider the following document: - 'The Transport Layer Security (TLS)
Protocol Version 1.3'
  <draft-ietf-tls-tls13-24.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
[email-masked] mailing lists by 2018-03-02. Exceptionally, comments may be
sent to [email-masked] instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract

   This document specifies version 1.3 of the Transport Layer Security
   (TLS) protocol.  TLS allows client/server applications to communicate
   over the Internet in a way that is designed to prevent eavesdropping,
   tampering, and message forgery.

The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/ballot/

The following IPR Declarations may be related to this I-D:

   https://datatracker.ietf.org/ipr/2900/

The document contains these normative downward references.
See RFC 3967 for additional information: 
    rfc8017: PKCS #1: RSA Cryptography Specifications Version 2.2 (Informational - IETF stream)
rfc6962: Certificate Transparency (Experimental - IETF stream)
rfc6979: Deterministic Usage of the Digital Signature Algorithm (DSA)
and Elliptic Curve Digital Signature Algorithm (ECDSA) (informational
- Independent Stream)
rfc7539: ChaCha20 and Poly1305 for IETF Protocols (Informational - IRTF stream)
rfc7748: Elliptic Curves for Security (Informational - IRTF stream)
rfc8017: PKCS #1: RSA Cryptography Specifications Version 2.2 (Informational - IETF stream)
rfc8032: Edwards-Curve Digital Signature Algorithm (EdDSA) (Informational - IRTF stream)

---

From: Sean Turner <[email-masked]>
Date: Fri, 16 Feb 2018 12:21:34 -0500

The difference here is that this LC includes all of the downrefs according to the process described in [0].  Including the downward references to non-stardards track RFCs will ensure we’re not delayed due to process issues.  Most of these are as a result of how we publish algorithm drafts, i.e., from the CFRG through through the IRTF stream, and none are a surprise.

spt

[0] https://tools.ietf.org/html/bcp97

> On Feb 16, 2018, at 12:06, The IESG <[email-masked]> wrote:
> 
>

---

From: Hubert Kario <[email-masked]>
Date: Wed, 21 Feb 2018 12:46:30 +0100

On Friday, 16 February 2018 18:06:41 CET The IESG wrote:
> The IESG has received a request from the Transport Layer Security WG (tls)
> to consider the following document: - 'The Transport Layer Security (TLS)
> Protocol Version 1.3'

Section 4.1.2 currently states that the only changes allowed to the second 
ClientHello message (in HelloRetryRequest case) are:
 - replacing key_share
 - removing early_data
 - adding cookie
 - updating pre_shared_key
 - adding, removing or changing padding

What about extensions undefined now? What if in the future we have another 
extension like the PSK extension that needs to be updated for the second 
ClientHello?

Do we accept that the above list is set in stone and will never change (except 
for new protocol versions), requiring all future extensions to also require 
the same extension payload for first and second ClientHello?

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 21 Feb 2018 08:10:59 -0600

> the same extension payload for first and second ClientHello?

It seems to me that such a hypothetical future extension could include a
signaling value in the HRR to indicate that the server understands the
new extension, and the semantics of the extension defined such that when
the server understands the extension the client may change its value
between ClientHello1 and ClientHello2.

This might be slightly inefficient if the extension's information flow
is only from client to server, but I think it would be a compatible way
to allow an extension value to change after HRR.

-Ben

---

From: Hubert Kario <[email-masked]>
Date: Wed, 21 Feb 2018 15:13:27 +0100

>   <draft-ietf-tls-tls13-24.txt> as Proposed Standard

The current draft states that if the server recognises an identity but is 
unable to verify corresponding binder, it "MUST abort the handshake"
at the same time, they "SHOULD select as single PSK and validate solely the 
binder that corresponds to that PSK"
(Page 60, draft-ietf-tls-tls13-24).

That allows for trivial enumeration of externally established identities - the 
attacker just needs to send to the server a list of identity guesses, with 
random data as binders, if the server recognises any identity it will abort 
connection, if it doesn't, it will continue to a non-PSK handshake.

Behaviour like this is generally considered a vulnerability:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2003-0190
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5229

I was wondering if the document shouldn't recommend ignoring any and all 
identities for which binders do not verify to prevent this kind of attack.
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 21 Feb 2018 06:20:24 -0800

> to allow an extension value to change after HRR.

Yes. Also, there's not really any good reason to change an extension that
is not
mentioned in HRR.

-Ekr

> -Ben
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 21 Feb 2018 06:21:58 -0800

> unable to verify corresponding binder, it "MUST abort the handshake"

Which text are you referring to here?

-Ekr

---

From: Hubert Kario <[email-masked]>
Date: Wed, 21 Feb 2018 15:26:42 +0100

On Wednesday, 21 February 2018 15:21:58 CET Eric Rescorla wrote:
> > > The IESG has received a request from the Transport Layer Security WG
> > 
> > (tls)
> > 

Section 4.2.11:

   Prior to accepting PSK key establishment, the server MUST validate
   the corresponding binder value (see Section 4.2.11.2 below).  If this
   value is not present or does not validate, the server MUST abort the
   handshake.  Servers SHOULD NOT attempt to validate multiple binders;
   rather they SHOULD select a single PSK and validate solely the binder
   that corresponds to that PSK.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 21 Feb 2018 06:31:33 -0800

i think your general point is sound here, but I'll nitpick the statement
that
"if the server recognises an identity but is unable to verify corresponding
binder".

1. The server only picks one identity so you if you send A, B, and C and you
get an abort, you don't know if it recognized one or all.
2. The server can *recognize* the identity but ignore it (say it's a ticket
that's
too old)

With that said, I think it would probably be safe to say you must ignore an
identity
where the binder doesn't validate, but I'd like to hear from cryptographers
on this
one.

Thanks,
-Ekr

On Wed, Feb 21, 2018 at 6:26 AM, Hubert Kario <[email-masked]> wrote:

> > > That allows for trivial enumeration of externally established
> identities -
> > > the

---

From: Martin Thomson <[email-masked]>
Date: Thu, 22 Feb 2018 10:22:35 +1100

I think that the current behavior is fine, but we might add text to
suggest that identities be self-authenticating to avoid this sort of
enumeration.  Note that in common practice, this sort of enumeration
would be over an infeasibly large space, it's only where identities
are more easily enumerable that it becomes an issue (e.g., "ted" as an
identity, rather than a self-encrypted session ticket)

---

From: Tony Putman <[email-masked]>
Date: Thu, 22 Feb 2018 09:18:44 +0000

For externally established PSKs (especially for IoT devices) the identity can be as simple as a serial number, easily enumerated. I think it would be a mistake to place requirements on the structure of the identity to resolve this (if it needs resolving); IMHO treating the situation in the same way as one which does not include a valid PSK is better. But I agree with Eric that we should hear from cryptographers on this.
-- Tony

-----Original Message-----
From: TLS [mailto:[email-masked]] On Behalf Of Martin Thomson
Sent: 21 February 2018 23:23
To: Eric Rescorla
Cc: [email-masked]; <[email-masked]>; IETF discussion list
Subject: Re: [TLS] external PSK identity enumeration Re: UPDATED Last Call: <draft-ietf-tls-tls13-24.txt> (The Transport Layer Security (TLS) Protocol Version 1.3) to Proposed Standard

Dyson Technology Limited, company number 01959090, Tetbury Hill, Malmesbury, SN16 0RP, UK.
This message is intended solely for the addressee and may contain confidential information. If you have received this message in error, please immediately and permanently delete it, and do not use, copy or disclose the information contained in this message or in any attachment.
Dyson may monitor email traffic data and content for security & training.

---

From: Hubert Kario <[email-masked]>
Date: Thu, 22 Feb 2018 11:49:33 +0100

> identity, rather than a self-encrypted session ticket)

that's why the subject is saying "external PSK", and those can be as simple as 
"ted", "admin", "mary"...

yes, session tickets ("resumption PSK") SHOULD be self-authenticating, if only 
because non authenticated ciphertext is malleable

> > 1. The server only picks one identity so you if you send A, B, and C and
> > you get an abort, you don't know if it recognized one or all.
> >> > > The current draft states that if the server recognises an identity
> >> > > but
> >> > > is