Subject: [TLS] draft-ietf-tls-tls13-15

From: Eric Rescorla <[email-masked]>
Date: Wed, 17 Aug 2016 14:49:52 -0700

Folks,

I've just submitted draft-ietf-tls-tls13-15.

The major change in this document is the new negotiation syntax as
discussed in Berlin. There are also a number of small tweaks (see
ChangeLog below).

Remaining significant issues:

#588: The computation of the resumption context with external PSKs.
      Also, connected with this, should we require that the client
      prove knowledge of the PSK when offering a PSK.

#443: 0-RTT with server signing. This is possible with the new syntax
      but I didn't specify it in #15.

#580: receive_generation for KeyUpdate [CHAIRS: please bring to closure]

Also a few smaller ones I will be bringing to the list shortly.

Note to implementors:
NSS is currently at draft-14 (Firefox is at draft-13). We intend to
implement draft-15 immediately (hopefully in the next week) and would
welcome interop testing with anyone who is interested.

As usual, comments welcome.

-Ekr

- New negotiation syntax as discussed in Berlin (*)

- Require CertificateRequest.context to be empty during handshake (*)

- Forbid empty tickets (*)

- Forbid application data messages in between post-handshake messages
  from the same flight (*)

- Clean up alert guidance (*)

- Clearer guidance on what is needed for TLS 1.2.

- Guidance on 0-RTT time windows.

- Rename a bunch of fields.

- Remove old PRNG text.

- Explicitly require checking that handshake records not span
  key changes.

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 18 Aug 2016 08:26:22 +0300

> I've just submitted draft-ietf-tls-tls13-15.

Doing brief review:

- Section 4.2.2 talks EdDSA using "ECDSA cipher suites". TLS 1.3 does
  not have those. However, this kind of information is very relevant
  for TLS 1.2 backward compatiblity: you need to assign TLS 1.2
  cipher suites for EdDSA in order to use it in TLS 1.2. TLS 1.3 does
  not care either way.

- I note that accepting PSK and selecting the auth mode seem to be
  in separate messages, which seems quite annoying implementation-
  wise..

- Can the server send arbitrary certificate in response to PSK or is
  it somehow restricted? The document does not seem to talk about it.

- The HelloRetryRequest is problematic in pure-PSK case[1].

[1] One way to do it would be to move the group to extension, which
would only be sent if new group was needed. Then one could always
require at least one extension (the field could also be renamed).
Also, one could make it so that HRR extensions don't have to 
correspond to CH extensions (and unsupported one is a fatal error).

-Ilari

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 18 Aug 2016 05:29:34 -0700

Thanks for the quick review.

>   cipher suites for EdDSA in order to use it in TLS 1.2. TLS 1.3 does

Thanks. Will try to fix.

>   in separate messages, which seems quite annoying implementation-

Can you elaborate on this? The intend is that they both appear in
ServerHello
(in pre_shared_key and signature_algorithms respectively).

>   it somehow restricted? The document does not seem to talk about it.

The document right now is supposed to be PSK XOR server signs, so the
answer is supposed to be "no". If/when we allow both together, then
we'll have to address this, which is a bit tricky.

> correspond to CH extensions (and unsupported one is a fatal error).

Agreed on both counts. PR wanted.
https://github.com/tlswg/tls13-spec/issues/560

-Ekr

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 18 Aug 2016 15:46:02 +0300

> (in pre_shared_key and signature_algorithms respectively).

Eeh, I thought it was in EncryptedExtensions. Reading the text
again, it is IMO really unclear where it goes.

Checking the extension table, it says "Client". Which impiles that
servers don't send it, but 4.2.2 says servers must send it in some
cases.

> we'll have to address this, which is a bit tricky.

Then why does that server signature_algorithms exist? I think that
special PSK authentication modes should be specified in the PSK
extension, so non-PSK clients don't get confused and do inapporiate
things with those indications.

> https://github.com/tlswg/tls13-spec/issues/560
 
David Bejamin already posted a PR about that. Doesn't clearly say
that unknown reason handling.

-Ilari

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 18 Aug 2016 05:55:16 -0700

> servers don't send it, but 4.2.2 says servers must send it in some

Agreed. Table fail. Anyway, if it goes anywhere (see below) it should go in
ServerHello. That was the intent for this draft.

> things with those indications.

Can you elaborate on what you mean here? If it's what I think you mean
(namely put it in the server's pre_share_key message) I used to have that
and davidben convinced me this was better. There's no perfect encoding
here, AFAICT, so if you want to make an alternate suggestion that we could
take a look at, that would be great.

> that unknown reason handling.

Yeah, I read the list before the PRs. I'll take a look but if you want to
comment
that would be great.

-Ekr

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 18 Aug 2016 16:35:41 +0300

> ServerHello. That was the intent for this draft.

Okay, good to know (/me goes to change it in his code).

> take a look at, that would be great.

The issue I'm thinking about is that if missing signature_algorithms means
no certificate, some dumb TLS implementation (and there are plenty of those)
will heed that even in non-PSK mode...
 
> comment that would be great.

The only comment is that I would prefer to allow extensions the without
client including them in ClientHello[1] (obviously fatal if unknown one is
seen[2]), instead of special-casing Cookie.

[1] Of course, if the error is related to values in extension, then the
client had to include it in its ClientHello.

[2] Basically, if client is told that its ClientHello is wrong in some
way it does not understand, obviously it can't fix it.

-Ilari

---

From: David Benjamin <[email-masked]>
Date: Thu, 18 Aug 2016 15:00:10 +0000

> seen[2]), instead of special-casing Cookie.

FWIW, I'm not a fan of special-casing Cookie either. I just left it alone
for that PR and only bothered about moving to an extension since I wasn't
sure how it should work.

Just removing the requirement altogether seems reasonable? Although it
doesn't give much guidance on which are and aren't MTI. Is a TLS client
over TCP obligated to implement Cookie to avoid interop issues? Seems kind
of pointless to require it there, just more things to remember. Whereas a
DTLS client over UDP which doesn't implement cookie is unlikely to work
well. But probably that kind of guidance ought to live elsewhere anyway. Or
maybe we should just declare cookie MTI everywhere and leave it at that.

(Though, I'm sure, in practice, no one will ever send cookie over TLS and
thus some clients won't honor it.)

David

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 19 Aug 2016 14:56:33 -0700

I've reviewed David's PR and I think it's basically sound. Unless I hear
some objection to this over the weekend, I intend to merge it or some
revised version on Monday.

-Ekr