On Thu, Apr 28, 2016 at 2:40 PM, Ilari Liusvaara <ilariliusva...@welho.com> wrote:
> On Thu, Apr 28, 2016 at 01:43:41PM -0700, Eric Rescorla wrote: > > On Thu, Apr 28, 2016 at 12:32 PM, Ilari Liusvaara < > ilariliusva...@welho.com> > > wrote: > > > > > > > - 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. > > Client sends ClientHello with 0RTT data, gets HelloRetryRequest back and > resends ClientHello. For hash continuation to work, the new ClientHello > needs to contain the EarlyData extension, which would imply there is > 0RTT data following that too. > No, I don't think you need to have the extension. Either the server is keeping state and there's no problem or the server is offloading state in a cookie (mechanism TBD) and in either case it just needs the state as of the beginning of the new ClientHello. > > - 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. > > Note that carelessly doing post-handshake auth can lead to nasty issues > (fortunately it is not allowed for HTTP/2!). > I expect that post-handshake client auth will be allowed for HTTP/2. Can you elaborate on your concern. And wonder what it would do to the handshake state machine to have the > possibility of the CertificateRequest message (you need state machine to > avoid all sorts of attacks). Well note that the EncryptedExtensions. > > - 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". > > And what is "all" with current extensions (defined as whatever is in > registry currently + whatever TLS 1.3 base defines)? I think ciphersuite > (apporiately transformed) and ALPN. Are there others? > Yes, that's what I meant. > > > - 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. > > The table of authentication block (Certificate+CertificateVerify+Finished > sequences) base keys and hashes (section 6.3.4 in current Editor's Copy). > Thanks, I've fixed this > - 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 can replay-cache on ClientHello hash. > Unfortunately this does not work perfectly in distributed systems, which is the original source of the concern. > > > - 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. > > Can ciphersuite C02B (ECDHE_ECDSA/...) become 00AA (DHE_PSK/...) > upon use of the created PSK? Ah, I see. I thought about whether we should prohibit that and decided against it. But I could be convinced the other way. > > [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. > > False positives? Try implementation errors. > Well, it seems like there are two concerns here re: implementation errors. 1. That servers will bungle this check and reject 0-RTT when they should accept it [false positive] 2. That servers will bungle this check and accept 0-RTT when they should reject it (and that we'll be relying on that). Is your concern the first or the second? > 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. > > I mean do you need explicit indication, as opposed to taking the > protocol the accepted 0-RTT data was for and not signaling it. > Well, the current draft does not have explicit indication. All of the 0-RTT context is tied to the ticket. -Ekr > Otherwise you need MUST abort requirement for the client. > > > -Ilari >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
