On Fri, Sep 23, 2016 at 04:08:38PM -0700, Watson Ladd wrote: > Dear all, > We've got API guidance and application layer interactions on the TODO > list, and both of these are important and don't show up yet. I can't > credibly commit to taking a big stab at them, but hopefully this email > is detailed enough that it serves as a starting point. > > The problems with the application layer interaction center around > 0-RTT and client post-authentication. 0-RTT data is replayable, and > furthermore does not authenticate SNI or other extensions that might > affect its interpretation at the server. I smell possible bugs where > extension data isn't properly treated with 0-RTT vs. 1-RTT fallback: > the current draft probably should include something like "any > extensions which influence the interpretation of this data must be the > same".
In composing my list of extensions to pay attention when doing 0-RTT (SNI and ALPN), I considered matters like: - Does this seem like it would affect 0-RTT interpretation. - What are the TLS 1.2 rules on it? - Is it even meaningful with PSK? - Is it just low-level connection control? ALPN was included because it definitely affects 0-RTT interpretation (even against TLS 1.2 rules) and SNI because of TLS 1.2 rules (SNI was later removed from the list). There might be future extensions that do have an effect on 0-RTT (some proposed extensions to Token Binding perhaps?). And it is of course theoretically possible that TLS stack implements some extension in a very odd way. > The difference between received 0-RTT data and other data doesn't > necessarily line up with connection state while processing, as the TLS > stack could have transitioned to normal 1-RTT operation while 0-RTT > data is still sitting around waiting to be processed. This is really > an API problem, but can also be caused by application layer choices: > if the 0-RTT data can't be cleanly parsed, and some leaks into 1-RTT, > life gets a bit weird. Is "life gets a bit weird" an euphemism for "there will likely be security issues here"? :-) Also, it is very likely that 0-RTT would need its own read API, because it is pretty unlikely that existing API could be safely retrofitted or even purpose-built unified API be designed that isn't just asking for security problems via mixing 0-RTT and 1-RTT data. It gets even more fun in DTLS, where 0-RTT packets can be reordered after Client Finished, so more 0-RTT data arrives when the connection has already transitioned to 1-RTT. Perhaps the last one could be solved by requiring the library to discard any such packets and not pass them forward. > Post-handshake auth is an ugly one for both. It can complete > asynchronously with respect to data exchange, which is not what the > desired semantics usually are. Generally we want each request to have > a single authentication context. Designing APIs to handle this is > hard, and applications will have to be aware of how TLS authentication > works to have rules for it. Add in the ability to stream data in both > directions, and life gets interesting. I'm really not sure what this > should look like. At least you must have client and server agree on authentication context of every given request. If they don't, vulernabilities WILL result. And then there have been multiple CVEs due to applications using wrong authentication context in some situation. (This is the reason one needs to be especially careful when combining dynamic client certificates with HTTP/2... Basically, it can not be done safely without coordination on application layer). One likely wants application protocol to be able to specify part of or the entiere request context and to extract that part in the other end when requesting a certificate selection. This is to allow putting part of coordination data into the request itself. However, this is not sufficient for e.g. HTTP/2 signaling, so more needs to be exchanged at application layer. E.g. HTTP/2 would want to signal which stream triggered the client certificate request, in order to enable the client to not be completely dumb in certificate selection. And then upon completion of the authentication (either successful or explicitly rejected), signal the application with the new certificate chain and the context the request had. -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
