Re: [TLS] 0-RTT & resumption

[Eric Rescorla <[e-mail]>]

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 <[e-mail]> wrote:

>
>
> On Mon, Aug 3, 2015 at 11:51 PM, Ilari Liusvaara <
> [e-mail]> wrote:
>
>> 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
>
>
> 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.
>
>
> - 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).
>>
>
> 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?
>
>
> - EncryptedExtensions looks to be mandatory in some exchanges, optional
>>   in others. I agree it should be mandatory in all (issue #213).
>>
>
> Me too. That's just editing error.
>
>
>
>> - "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)?
>>
>
> 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.
>
>
>> - 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)?
>>
>
> Yes. good catch.
>
>
> 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).
>>
>
> This seems like a good argument.
>
>
>
>> I think it would simplify the security analysis a bit if CertificateVerify
>> was always immediately before Finished and covered everything before that
>> point.
>>
>
> Isn't this always the case presently? Are you just thinking we should say
> it's
> a rule?
>
> -Ekr
>
>