On 29 April 2016 at 15:58, Ilari Liusvaara <ilariliusva...@welho.com> wrote: >> [HRR state] > > That enlarges the state that needs to be kept. If one keeps extensions, > one only needs ~40 bytes. Whereas saving full hash state needs IIRC 114 > bytes (SHA-256) or 228 bytes (SHA-384). And cookies are max. 255 bytes.
Cookies are as yet undefined, but I would imagine that these would be just the same size as the pre-shared-key identity for all the same reasons. > And not many hash implementations support dumping and reloading state. What would you prefer? We could specify some very strict rules about what changes a client can make to their ClientHello so that the server can simply store things that might change (like the early_data extension, which will disappear on the second attempt, and whether a key share was needed, and so forth). >> [client auth] > > The problem being that > client and server end up being confused about authority the data is sent > as, resulting exploitable security issues (avoiding this in HTTP/2 takes > application-layer coordination). The confused deputy problem, yes. That's a "feature" that we have to retain, so I don't see much point bellyaching over it. That said, we can (and are) improving things in HTTP/2. >> [extension checking on resumption] > > So the 'etc' stands for "whatever will be defined by future extensions"? > One might want to make that clearer. > > Also, things get screwy with SNI, and I think it is better not to try to > use SNI with PSK. The primary function of SNI is routing. Remove it and stuff breaks. Thus, I would say include it, but make sure it doesn't result in a change in configuration. The simplest thing to do is reject PSK if the old SNI != the new SNI. > The rest besides ALPN and SNI looks to me those are either meaningless > or should be taken anew. That is probably true for a lot of them. But we can't say that for certain. For instance, when we defined EMS, which is irrelevant here, it was important that it be present when resuming or bad things happened. I'm not suggesting that exact thing will happen again, but we can't presume that we won't need this. > I mean for the subsequent handshake. Since 0-RTT ALPN and connection > ALPN needs to match, either: > > 1) Take the 0-RTT ALPN implicitly as connection ALPN. > 2) Signal the same ALPN again, and have that client MUST check it matches > and abort otherwise. I believe that we have to do the latter. Since we can't be sure that the server knows the ALPN from before if it has to reject 0-RTT. My plan for this is: 1. store ALPN in the ticket/session 2. if doing 0-RTT, before accepting 0-RTT data, perform the normal ALPN negotiation 3. check the negotiated ALPN with the stored value, and if they don't match reject the 0-RTT data Note that this means that clients will have to deal with having to change protocols when 0-RTT data is rejected. But I don't see any other way to do this. This also assumes that TLS session resumption is not carrying over application state in addition to TLS state. I believe that is reasonable, though it's worth stating. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
