Hiya, First, with no hats, if the WG were to have a poll on whether or not to include 0rtt in TLS1.3, then as a participant in the work here, I'd be firmly arguing to leave it out entirely. I really think an over-emphasis on reducing latency for browsers is going to bite us (and the Internet) in the ass in the same ways that emphasising interop over security has in the past with fallbacks to older, worse versions of TLS/SSL, with all their inherent flaws and bits of e.g. crappy "export" crypto support. Absent 0rtt, TLS1.3 seems to me to be an excellent step forward in security. With 0rtt, I think it also becomes a dangerous implement. So, that's my personal opinion, while not wearing an AD hat.
However, if I'm in the rough about the above, (which seems to me to be the case now) then my job as AD when I get a publication request that includes 0rtt, will include figuring out if that's safe or not. And I've no clue how I'll do that unless the WG have already done some analysis of the many, many protocols that use TLS. Note that I do not consider "use a different API" to be a sufficient answer here (it is necessary, but not sufficient). Given that there are 263 RFCs that reference RFC5246 [1] and google scholar counts 2738 documents that cite RFC5246 [2] I'm puzzled as to how we can know the consequences of adding that dangerous implement to TLS1.3. I've been worried about this for a while now, but the recant thread started by Kyle Nekritz [3] prompted me to send this as I think that's likely just the tip of an iceberg. E.g., I'd be worried about cross-protocol attacks one might be able to try with JS in a browser if the JS can create arbitrary HTTP header fields which I think is the case. I'm also worried about things like EAP-TLS and RADIUS/Diameter if used via TLS etc where we don't necessarily have the right people active on this list. While I don't have any concrete attacks, the ability to create replayable data smells really really bad to me and I've no idea how we can honestly be confident we've done a good job on TLS1.3 while such smells linger. I'd also note that my overall impression of the TRON w/s was that researchers thought 1rtt was mostly ready, but that there was no similar confidence in 0rtt. I also don't think "another TRON" is the answer here, as we'd not have the right people in the room who'd know the consequences of replay for all instances of <foo>/TLS. Lastly, just in case: Note that I am not saying that I'll block a publication request for TLS1.3 that includes 0rtt based on my own technical opinion if I'm in the rough. I'm saying that I have no idea how I'll do an AD evaluation of such a thing so I need help from the WG in analysing the broader impact of 0rtt, and if that's not done before the publication request, we'll have to figure it out then. And that could be messy, if we make a bunch of late discoveries that 0rtt creates issues for a bunch of instances of <foo>/TLS1.3. So, can people suggest ways in which we can figure out the impact of replayable data across all the many uses of TLS? Thanks, S. [1] http://www.arkko.com/tools/allstats/citations-rfc5246.html [2] https://scholar.google.com/scholar?q=http%3A%2F%2Fwww.hjp.at%2Fdoc%2Frfc%2Frfc5246.html&btnG=&hl=en&as_sdt=0%2C5 [3] https://mailarchive.ietf.org/arch/msg/tls/K-PmKrP6Df_qIVq_BTielgtQwUY
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
