Re: [TLS] #445: Enhanced New Session Ticket

On Thu, Apr 28, 2016 at 1:43 PM, Eric Rescorla <ekr@rtfm.com> wrote:

> On Thu, Apr 28, 2016 at 12:32 PM, Ilari Liusvaara <
> ilariliusvaara@welho.com> wrote:
>
>> Some comments:
>>
>
> Please note: this PR is still a WIP. I'll be updating it in a bit...
>
>
>
>> - I presume 0-RTT used in retried ClientHello uses (and for the verify
>>   mechanism to work, that needs to be allowed!) uses ClientHello1...
>>   ClientHello2 as its base hash?
>>
>
> I don't think I understand what you are asking. Can you rephrase.
>
>
>
>> - Is that 0-RTT Finished message needed? It is the only 0-RTT handshake
>>   message...
>>
>
> I think so it's a proof that the client knows the key. Also, per the
> discussion in
> Buenos-Aires we expect to be adding
>
>
>
>> - Server can send CertificateRequest in GDHE-PSK or PSK mode???
>>
>
> Is there a reason that's undesirable? Note that it can always do
> post-handshake
> authentication, so we need to ensure that this is secure. My understanding
> is
> that because it covers the server's Finished, it therefore builds in the
> PSK
> value (per the analyis from Scott et al.). Do you have a concern with this.
>
>
> - What are 'etc' for parameters for 0-RTT data? Use the present
>>   extension list here and have any future extensions that matter here
>>   explicitly define their interaction.
>>
>
> The list is an example. The operative word is "all".
>
> - The requirement for server to validate its extensions... Hopefully
>>   there is no security reason for that... I really don't see it being
>>   implemented correctly (and the description looks completely screwy[1]).
>>
>
> This is an important requirement. For instance, you need the same ALPN
> value.
>
>
>
>> - 1 RTT server context presumably ends in CertificateRequest, not
>>   CertificateVerify (the Certificate and CertificateVerify are
>>   impiled).
>>
>
> I'm not sure which section of the draft you're referring too here.
>

Ah, right, I got confused about sections. Thanks.

>
>
> - You might want flag for if server promises replay protection or
>>   not in NST.
>>
>
> We discussed this in BE and the consensus was that it was not clear how
> the server implemented this and so it was unwise to promise it.
>
>
>
>> - You might want to specify that allow_dhe_resumption doesn't
>>   change key exchange, only authentication (so DHE_CERT becomes
>>   DHE_PSK and ECDHE_CERT becomes ECDHE_PSK).
>
>
> I'm not sure I follow. It changes key exchange. If we want to have
> a resumption mode that has the server sign, we'll need a different
> indicator here.
>
>
> [1] There are many extensions that are not relevant because those
>> control server authentication (e.g. status_request, status_request_v2,
>> signed_certificate_timestamp, server_certificate_type). And some that
>> are low-level connection control (e.g. max_fragment_length)
>
>
> Yes, I am being conservative here because false positives don't seem like
> they will happen a lot.
>
>
> ALPN is special here tho: It needs to match the impiled 0-RTT ALPN
>> (does one want that extension in 0-RTT case anyway?).
>>
>
> Yes, you absolutely need ALPN for early data.
>
> -Ekr
>
>
>>
>> -Ilari
>>
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
>
>