On Thu, Apr 28, 2016 at 1:43 PM, Eric Rescorla <e...@rtfm.com> wrote:
> On Thu, Apr 28, 2016 at 12:32 PM, Ilari Liusvaara < > ilariliusva...@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 >> > >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
