[TLS] analysis of wider impact of TLS1.3 replayabe data

[Stephen Farrell <[e-mail]>]

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