(Not on the list; hopefully this goes through the approval at some point.)
Heya,
I have considered implementing this at some point, but hadn’t really read
through it (or the ENO draft) before. I got prompted to (by two parties, no
less), so here’s few comments:
[1] is there binding to the ENOs in SYN/SYN-ACK? I did not see it, but I think
it is useful to have to prevent downgrade attacks if someday someone wants to
use TLS + some other (more secure perhaps) ENO method
[2] not fond of embedding TLS 1.3 bits in the draft either, but I guess it is
fine (there’s also some weird reference {{server-first-flight at least in the
.txt I read)
(perhaps they could be in an appendix if WG really considered them useful?)
[3] zero-RTT exchange would be nice to solve somehow to be non-replayable (it
is an open todo, but I would really hate to see it not solved at some point);
perhaps stick something within the TLS ENO payload (and add the binding noted
in [1]). Of course, if this is more generic problem in general, some sort of
generic ‘ENO nonce’ might be desirable instead.
Anyway, overall I consider this pretty readable and concise draft (+- the TLS
1.3 complaint), with admittedly open bits but I do not see really _big_
problems there as such. And I applaud reuse of *TLS, as reused crypto is
usually safer/saner than ’new’ crypto :)
Cheers,
-Markus
P.S. Kivinen still owes you guys a review.
_______________________________________________
Tcpinc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tcpinc
