Subject: [TLS] Draft status and updates

From: Eric Rescorla <[email-masked]>
Date: Tue, 1 Dec 2015 10:11:17 -0800

Hi folks,

I've merged a bunch of PRs into the editor's draft, including:

- https://github.com/tlswg/tls13-spec/pull/316
  The new structure for client auth and post-handshake client
  auth we discussed in Yokohama.

- https://github.com/tlswg/tls13-spec/pull/342
  Using the "normal" content types for 0-RTT data and close_notify
  to indicate the end of the 0-RTT application data.

- https://github.com/tlswg/tls13-spec/pull/352
- https://github.com/tlswg/tls13-spec/pull/317
  Use SHA-1 to control what we sign with.

- https://github.com/tlswg/tls13-spec/pull/284
  The anti-downgrade mechanism that Karthik proposed

- https://github.com/tlswg/tls13-spec/pull/345
  Updating the IANA considerations per the discussion in Yokohama.

This clears out the big pipeline stall from PR#316, but probably has
created some bustage. Expect a series of cleanup commits and some
other things that were head-of-line blocked this week and then
draft-11 in the next week or so. Please file PRs and/or github
issues for any issues you see.

In addition, PR#354 (https://github.com/tlswg/tls13-spec/pull/354)
implements the rekey mechanism that we discussed in Yokohama.  There
was broad agreement to adopt something like this.  I would appreciate
it if a few people could give it a sanity check, but absent strong
objections, I intend to merge this PR on Friday.

We also need to discuss three more substantive technical issues:

- Encrypted SNI.
- Whether the 0-RTT handshake messages are hashed into the
  handshake hash.
- Statelessness for HelloRetryRequest, and in particular cookie
  lifetime.

I'll be starting threads on those over the next few days with
the aim of resolving them promptly.

-Ekr

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 1 Dec 2015 20:57:34 +0200

> issues for any issues you see.

Looks like the note about the PSK+ClientCert "attack" got lost
somewhere. While I don't think that is important as the underlying
issue is fixed, I think there might be a note about dangers of using
server certificates in any mode where transcript and configuration
do not jointly imply SS.

Actually, scanning the editor's copy, it looks VERY broken to me:
I don't see how server certificate verify (indirectly) signs on the old
configuration. Such signing is required for security, as otherwise
SS is not impiled by signature, breaking authentication.

Previously, the document was clear about this...
 
> objections, I intend to merge this PR on Friday.

The restrictions on when the rekey message can be sent: Do those
essentially boil down to "any time after sending Finished"?

Also, I think the requirement to immediately send the KeyUpdate
is problematic. I think it should be requirement to send it as
next record(s).

The two aren't the same: The first seemingly requires scheduling
extra flights, which can be problematic. The second can piggyback
on existing flights. 

-Ilari

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 1 Dec 2015 11:19:15 -0800

Ilari,

Thanks for your quick review.

On Tue, Dec 1, 2015 at 10:57 AM, Ilari Liusvaara <[email-masked]>
wrote:

> somewhere.

See the last graf of:
http://tlswg.github.io/tls13-spec/#certificate-verify

I pointed to the e-mail by Sam's group and also prohibit entirely
the use of cert-based client auth in pure PSK, since that
seemed safer. If you think more is needed here I would be happy
to add it.

While I don't think that is important as the underlying

> Previously, the document was clear about this...

I'm sorry, but I'm not following the issue you are raising here. Perhaps
you could expand further? Here's my reasoning.

1. The server delivers the server configuration in handshake #0
and signs the entire transcript with the certificate verify. At this
point the client has assurance of the server's g^s.

2. In handshake #1, the client sends g^x and there is authentication
for g^xs and hence the client knows that any data it is sending to the
server in 0-RTT is actually going to the server.

3. The server provides g^y in his ServerHello and then g^xy and g^xs
are jointly used to produce the traffic keys and also to form a MAC over
the handshake. As Hugo pointed out originally, this alone should
be sufficient to authenticate the server's side of the connection and
you could omit the server CertificateVerify (Hugo, please correct
me if I have misunderstood).

4. However, for consistency reasons (per the discussion in Prague),
the server *also* signs the entire transcript. This authenticates
g^y (even though the MAC with g^xs already authenticated it)
and proves possession of the signing key.

Trying to read between the lines, is your concern that the server is
now no longer explicitly signing over the ServerConfiguration in
its CertificateVerify [Note that the client continues to do so]? The idea
behind removing that was to make the 1-RTT part of the handshake
more uniform regardless of whether 0-RTT data was used.
I'm certainly open to putting that back in if it's needed, but can you
explain your concern in more detail?

> essentially boil down to "any time after sending Finished"?

Except not during 0-RTT.

> extra flights, which can be problematic. The second can piggyback

Good suggestion. PR welcome.  :)

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 1 Dec 2015 11:28:45 -0800

On Tue, Dec 1, 2015 at 11:19 AM, Eric Rescorla <[email-masked]> wrote:

> On Tue, Dec 1, 2015 at 10:57 AM, Ilari Liusvaara <[email-masked]
> > wrote:
>
> its CertificateVerify [Note that the client continues to do so]?
>

And, I should note the server's certificate.

-Ekr

> The idea

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 2 Dec 2015 19:08:45 +0200

> me if I have misunderstood).

Is it guaranteed that the groups are the same?

Even if it is, due to implementation bugs, bad idea to rely upon that.
 
> explain your concern in more detail?

The concern is that attacker that has managed to inject g^s for
known s is able to impersonate the server even through server certificate
validation on subsequent connections (under some conditions).

(Indirectly) signing g^s would prevent this.

... Funkily enough, this attack doesn't work against either tls-unique
nor tls-extractor (however, those still fail nonce check with respect
to SS)...

-Ilari

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 2 Dec 2015 09:29:23 -0800

> Is it guaranteed that the groups are the same?

Yes, it's a requirement that the groups be the same. If the text doesn't
say that, it should.

> Even if it is, due to implementation bugs, bad idea to rely upon that.

Can you expand on this point? Is there a specific easy-to-make
implementation
error you are concerned with?

> validation on subsequent connections (under some conditions).

I'm sorry, I'm still not following. All the data that the server sends is
tied to
g^y which is signed with the server's certificate, so even if s were
published,
the attacker should not be able to inject data which the client would
accept.

With that said, it's certainly true that if the attacker is able to
convince the
client that the server has a certain g^a where a is known to the attacker,
then the client has a problem because he will encrypt data *to* the
attacker in 0-RTT, so obviously we are assuming that the attacker does
not know s and cannot convince the client to accept a g^s of his
choice.

> nor tls-extractor (however, those still fail nonce check with respect

Do you think you could draw a ladder diagram that shows the attack you
are concerned about?

-Ekr

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 2 Dec 2015 21:23:08 +0200

> Yes, it's a requirement that the groups be the same. If the text doesn't

If the document says that, it is so unclear that I didn't even find the
requirement.
 
> implementation error you are concerned with?

There is long history of TLS implementations omitting all kinds of checks,
even ones explicitly called as MUST.

E.g. It would surprise me more not to see any TLS 1.3 implementations that
decrypt 0-RTT data with ciphersuite different from negotiated (despite the
spec clearly forbidding this) than seeing those.
 
> the attacker should not be able to inject data which the client would

I would certainly expect the signature check, if it is there at all, to
be proper nonce over SS.

IIRC, the key exchange is explicitly intended to be secure (but forward
security is lost) if ES is revealed.

Config-authenticated ciphersuites are different matter (the main
challenge there seems to be deciding when those are to be enabled[1],
not so much designing the key exchange[2]).

> not know s and cannot convince the client to accept a g^s of his

Oh yeah, that too... I don't work with 0-RTT that much, as it is way
harder to analyze than 1-RTT (bad thing, I know).

[1] Persistent inpersonation and all that...

[2] Require server to send EarlyData if one is used, then just omit
server Certificate and CertificateVerify.

-Ilari

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 3 Dec 2015 20:20:19 -0800

> not so much designing the key exchange[2]).

I may be being stupid, but I think I'm still not following. Do you think
you could provide a ladder diagram showing the messages that
demonstrate the attack you are concerned about.

Best,
-Ekr