On Sunday, August 2, 2015 11:52 AM, Eric Rescorla wrote: > On Sun, Aug 2, 2015 at 11:11 AM, David Mazieres > <[email protected]> wrote: >> Well, a priori, one can argue that even though TCP-use-TLS may require >> more engineering effort in absolute terms than tcpcrypt, the delta >> between application-level TLS (required anyway) and transport-level TLS >> is smaller than the effort required for all of tcpcrypt (which can't be >> shared). However, a posteriori, given that we still don't have a >> profile > > I'd like to address this "profile" issue briefly, since it seems to be a > sticking point > for a number of people. First, there seem to be two different things that > people mean > when they say "profile": > > (1) A description of the particular operational modes of TLS that people > should > support. > (2) A (somewhat?) self-contained document that describes just the subset of > TLS that people need to support. > > ... > > I'd basically assumed that when people meant a profile they meant #1, and > as I said, I think it's fairly obvious, and pretty orthogonal to the question > of whether or not TLS is the right choice here.
I agree with #1. The point is to reuse the existing TLS implementation, so we do not end up with two security stacks and twice the attack surface. Also, as we consider transition from opportunistic encryption to strong encryption, I envisage an upgraded app implementation doing some variation of "Start TLS" and talking to a legacy implementation implementing the TLS shim. That works if the TLS shim is a subset of TLS, where the subset is defined in terms of algorithm suites and authentication options. > But maybe I'm just too close to > things so it's not obvious to others. In any case, what you'd want is > something > like: > > - ECDH_anon with P256 and Curve25519 > - AES_128_GCM; AES_256_GCM; ChaCha/Poly1305 > - SHA256 for the PRF > - Session hash > - No renegotiation [Banned in TLS 1.3] > - No compression [Banned in TLS 1.3] > - RFC5705 tickets [or PSK in 1.3] Works for me, as long as this is considered as the "minimal" profile, and does not preclude evolution to the full TLS scenario sketched above. > I'm sure there are a few other things people would like nailed down, > but I think the big issue here is whether or not we would require TLS 1.3 or > not. > I would argue for not, but i can understand why people would feel the other > way. If we're taking "profile" to mean (2) above, which is what I take to be > the direction the WG would like, then it's obviously easier to write down if > you only commit to one version of TLS. I can see the point of mandating TLS 1.3 and 0-RTT for the shim scenario. We want opportunistic encryption, and part of "opportunistic" is to not degrade perf, in particular latency. -- Christian Huitema _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
