On Fri, Sep 23, 2016 at 10:47 PM, Ilari Liusvaara <ilariliusva...@welho.com> wrote: > 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).
Are we sure this is safe to remove? It probably depends on higher layer protocol semantics. I would suggest that we make 0-RTT per application layer support: each application needs to opt in to 0-RTT, and we should ensure each higher level protocol is aware of the interactions and writes a description of what to do for each extension. Yes, this is hideous and a ton of work. I'm not convinced there is a safe alternative. > > 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. Yes. In particular I think the TLS state machine transitions need to be ordered with respect to the arrival and sending of data. The challenge for a multithreaded program (yes, some programs have multiple threads sending and receiving at once) is making this make sense, or even a single-threaded program where the TLS stack can change state at times not visible to the sending thread. Maybe there is some slop here, like 0-RTT can become 1-RTT on send, but this raises all sorts of problems for receiving. I think we need to require separation in the API. > > > 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. This is the sanest solution I can think of. When DTLS 1.3 is produced it should be noted. > > >> 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. This is going to require major changes to APIs and to the HTTP/2 layer. It also interacts with token binding, whee! My question then becomes one of what we actually need: can we assume that leakage between authentication contexts over a single session is safe because all contexts represent the same principal, by restricting the usages, or is this overly restrictive? When we have multiple requests and replies in flight and the authentication state changes, things get nasty. If we think of TLS as sending a stream of events including authentication changes to the application, this fits the semantics of the TLS draft as I understand them to be, but does not necessarily fit what application protocols want. There might be a semantic mismatch here requiring reworking of one or another part. Sincerely, Watson > > > -Ilari -- "Man is born free, but everywhere he is in chains". --Rousseau. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
