Subject: [tcpinc] draft-rescorla-tcpinc-tls-option-04 comments

From: Markus Stenberg <[email-masked]>
Date: Thu, 15 Oct 2015 13:43:47 +0300

(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.

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 18 Oct 2015 15:10:07 -0700

> (Not on the list; hopefully this goes through the approval at some point.)

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

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
>
> _______________________________________________
> Tcpinc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpinc