On Fri, Apr 29, 2016 at 04:52:08PM +1000, Martin Thomson wrote: > 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.
Well, this is about the size one needs for the required state. > > 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). That ~40 bytes (IIRC, it was actually 37) was done by exploiting every- thing I could out of the rules in WIP #344 and relied on EDI being preserved. EDI looks like rather sizable structure currently (even after compressing the configuration_id by obvious means). > >> [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. That kind of non-obvious stuff really needs to be included. They way it is right now written, I think very few TLS stacks are going to get it right. > > 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. My point is: Future extensions can give their rules, TLS 1.3 spec needs to give rules about present ones. > > 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 4. If 0-RTT is accepted, client checks the ALPN server sent and compares it with value it impiled. If those don't match, the client MUST abort. 1) would be: 1. store ALPN in the ticket/session 2. if doing 0-RTT, before accepting 0-RTT data, check if the 0-RTT ALPN is acceptable. If it isn't, reject 0-RTT. 3. If 0-RTT was rejected, select new ALPN, signal it in Encrypted Extensions. That would make ALPN and EDI mutually exclusive in EncryptedExtensions. > 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. Well, the applications obviously have to be able to deal with the protocol possibly changing. > 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. Well, any state they can't recover. -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
