On Thu, Oct 15, 2015 at 3:43 AM, Markus Stenberg <[email protected]>
wrote:
> (Not on the list; hopefully this goes through the approval at some point.)
>
> Heya,
>
Thanks for the review.
> 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
>
Can you expand on this point? Is the idea that you'd like the TLS handshake
to
attest the TCP-ENO handshake so that if you:
(a) had multiple ENO options where you offered TLS and BestProtocol?
(b) were using TLS with some sort of authentication mechanism
Then you could detect that you had been forced into TLS rather than
BestProtocol?
> [2] not fond of embedding TLS 1.3 bits in the draft either, but I guess it
> is fine (
The chairs (both former and current) made clear that I should do this, but
I'm
not that fond of it either
there’s also some weird reference {{server-first-flight at least in the
> .txt I read)
>
Yeah, I'll fix this.
> (perhaps they could be in an appendix if WG really considered them
> useful?)
>
This seems like a good compromise.
What do other people think?
> [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.
>
I've been thinking about this a bit. Basically, if you had any kind of
nonce in the
server's SYN/ACK, then you wouldn't have a replay problem. This isn't
something
you can do in the generic TLS setting, but you could easily do it here.
Thanks,
-Ekr
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
_______________________________________________
Tcpinc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tcpinc
