Subject: Re: [TLS] 0-RTT & resumption

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 4 Aug 2015 09:51:49 +0300

On Sat, Jul 25, 2015 at 09:07:49PM +0200, Eric Rescorla wrote:
> 
> 
> We agreed on how to do this in Prague. The sticking point was establishing
> the cipher suite. I have WIP text on my machine for both of these which I
> will be
> sending early next week, once I get enough sleep to be able to clean it up,
> so I'd ask people to sit tight till then.
> 

Okay, now the PR (#211) seems to be up, let's review:

- Lacks client-driven client authentication[1]. All client auth is server
  driven, which I think isn't very useful in real world (there are all
  sorts of bad hacks[2] trying to work around lack of client-driven auth).
- EncryptedExtensions looks to be mandatory in some exchanges, optional
  in others. I agree it should be mandatory in all (issue #213).
- "The client's cryptographic determining parameters match the parameters
  that the server has negotiated based on the rest of the ClientHello."
  ... Does that mean the client has to guess what ciphersuite the server
  will choose (more than pure-PSK vs. GDHE, which is unvaoidable with
  just one encrypted block)?
- Regarding other extensions, it doesn't look to be the same list as
  ServerHello extensions, as max_fragment_length is on ServerHello,
  but certainly makes no sense as 0-RTT extension (I didn't see any other
  possibly relevant extensions).
- Am I reading the syntax wrong, or does the extensions field in server
  configuration only allow exactly one extension (shouldn't it be zero
  or more)?

Also, regarding issue #212, unless the Certificate is handled specially,
it would mean that the signature does not cover certificate. And not
signing the certificate (esp. the public key within) causes problems
in some exotic cases (I don't know if any of those cases pop up in TLS
1.3).

I think it would simplify the security analysis a bit if CertificateVerify
was always immediately before Finished and covered everything before that
point.

On client side, one gets that "no certificate" special case anyway.

[1] A lot of time, the client knows if it is going to present client
certificate or not before it initiates the handshake.

[2] At best ugly, at worst security problem.

-Ilari

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 4 Aug 2015 05:40:48 -0700

On Mon, Aug 3, 2015 at 11:51 PM, Ilari Liusvaara <
[email-masked]> wrote:

> Okay, now the PR (#211) seems to be up, let's review

Oops. It wasn't supposed to be done. I meant to make it a PR against my
own branch so that I could get early comments from MT, but obviously that
didn't work out. Regardless, thanks for your comments.

>   sorts of bad hacks[2] trying to work around lack of client-driven auth).

This is just extending existing practice for 1-RTT handshakes.

I tend to agree with you that it would be good to change that, but I didn't
want
to do that in this PR, because it would be a big semantic change in TLS.
I suggest you start a new thread on this topic, or perhaps add it to
Andrei's
client auth thread?

>   in others. I agree it should be mandatory in all (issue #213).

Me too. That's just editing error.

>   just one encrypted block)?

The client knows what the server selected based on his previous offer and
the server's configuration (which by hypothesis is still extant) so the
server
should choose the same value again.

>   configuration only allow exactly one extension (shouldn't it be zero

Yes. good catch.

> in some exotic cases (I don't know if any of those cases pop up in TLS

This seems like a good argument.

> was always immediately before Finished and covered everything before that

Isn't this always the case presently? Are you just thinking we should say
it's
a rule?

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 7 Aug 2015 14:50:14 -0700

I've updated the PR based on feedback from Dave, Ilari, and Martin.

https://github.com/tlswg/tls13-spec/pull/211

I'll merge this PR on 8/11 unless there are serious objections. As usual
please send minor changes as github comments and/or PRs.

-Ekr

On Tue, Aug 4, 2015 at 5:40 AM, Eric Rescorla <[email-masked]> wrote:

> I tend to agree with you that it would be good to change that, but I
> didn't want

---

From: Ilari Liusvaara <[email-masked]>
Date: Sat, 8 Aug 2015 08:42:32 +0300

> please send minor changes as github comments and/or PRs.
 
Few small comments (I leave larger stuff out):

1)

"If indicate the same parameters as the server indicated in that connection."

I can't parse this.

2)

"Send the same cryptographic determining parameters (Section 
{{cryptographic-determining-parameters}}) with the previous connection"

What if client is resuming connection for the first time and is keying
0-RTT accordingly?

I presume that the ciphersuite used for 0-RTT is then the ciphersuite
from session being resumed but key exchange changed to PSK (e.g.
TLS_ECDHE_FOO_WITH_BAR -> TLS_PSK_WITH_BAR), as this is the ciphersuite
resumed session would use.

(Where is the rule on what ciphersuite resumed session uses stated?
I thought the ciphersuite always needed to have the same symmetric
part?)

-Ilari