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. - 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
