Re: [TLS] Draft status and updates

[Eric Rescorla <[e-mail]>]

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

> Ilari,
>
> Thanks for your quick review.
>
> On Tue, Dec 1, 2015 at 10:57 AM, Ilari Liusvaara <[e-mail]
> > wrote:
>
>> On Tue, Dec 01, 2015 at 10:11:17AM -0800, Eric Rescorla wrote:
>> >
>> > 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.
>>
>> Looks like the note about the PSK+ClientCert "attack" got lost
>> 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
>> 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...
>>
>
> 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]?
>

And, I should note the server's certificate.

-Ekr


> 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?
>
>
>
> > 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.
>>
>> The restrictions on when the rekey message can be sent: Do those
>> essentially boil down to "any time after sending Finished"?
>>
>
> Except not during 0-RTT.
>
>
> 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.
>>
>
> Good suggestion. PR welcome.  :)
>
> -Ekr
>
>
>>
>>
>> -Ilari
>>
>
>