Subject: [TLS] TLS 1.3 draft -11

From: Eric Rescorla <[email-masked]>
Date: Mon, 28 Dec 2015 14:52:49 -0500

Folks,

In the spirit of making a useful checkpoint, I just posted the latest
version of the
editor's draft as draft-11. Here's the major changes:

- Port the CFRG curves & signatures work from RFC4492bis.

- Remove sequence number and version from additional_data, which
  is now empty.

- Reorder values in HkdfLabel.

- Add support for version anti-downgrade mechanism.

- Update IANA considerations section and relax some of the policies.

- Unify authentication modes. Add post-handshake client authentication.

- Remove early_handshake content type. Terminate 0-RTT data with
  an alert.

- Reset sequence number upon key change (as proposed by Fournet et al.)

The major open issues I am aware of are:

- Figuring out whether we want to hash in additional data from the 0-RTT
exchange
  into the 1-RTT handshake (Issue #351, some on-list comments by Ilari, and
the
  discussion over the past few days about DTLS). I believe that the
conclusion of
  these discussions was that there was not a clear security issue here and
that
  there were different views of the aesthetics of inclusion versus
exclusion.
  Arguments/corrections welcome here.

- Closing on Encrypted SNI. My sense is that to the extent to which people
have
  enthusiasm for this, it's for the proposal that I posted on 12/5:
  https://www.ietf.org/mail-archive/web/tls/current/msg18633.html
  Chairs: can you please help drive this to conclusion?

- Details of state pickling for stateless reject. I owe the list a proposal
here.

- We still need clearer text around data volumes, which might, I suppose,
result
  in concluding that we don't need rekey. I'll send mail about this
separately
  shortly.

- Hugo's proposal to explicitly include the random values in the handshake
  hashes. Chairs, can you please help drive this to conclusion as well?

-Ekr

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 29 Dec 2015 09:12:11 +0200

> - Unify authentication modes. Add post-handshake client authentication.

I noticed the following:

1) In previous drafts with the OPTLS design, 1-RTT Finished messages
used SS as key (for avoiding circular logic or something like that).
But -11 seems to specify Master Secret.

2) Post-handshake auth seems to need hash forking, whereas everything
else (except 0-RTT, which likely gets implemented differently anyway)
only needs multitap hashes (even for CertificateVerify).

3) If any extension tries to add new message between ServerConfiguration
and Certificate or Finished and Certificate, the defintion goes screwy
(one expects the hash to end just before Certificate). And there are
two non-deprecated extensions that do just that...

4) There is also one (infamous) extension (not deprecated) that uses
Supplemental Data mesage from server to client. Where does that message
go? Right after EncryptedExtensions (one creative interpretation)?

> - Details of state pickling for stateless reject. I owe the list a proposal

This a bit more subtle than it seems. Looks like you need to put the
Client Random in that state too, in order to avoid rehandshakes
from blowing up.

The server needs some way of telling apart a retry and a rehandshake,
otherwise it tries to recover the state on rehandshake, which is very wrong
and won't work.

Also, I would set the default maximum TTL at 0 (don't save between
connections unless application profile says so).

-Ilari