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". 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. API guidance is generally pretty easy, even if most implementations have massively failed at being reasonable. I do not want to point fingers, but someone thought having true and false values mean exactly opposite things was a good idea in a C API at one point. 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. Sincerely, Watson _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
