On Mon, Aug 3, 2015 at 5:02 AM, Eric Rescorla <[email protected]> wrote: > > > On Mon, Aug 3, 2015 at 4:58 AM, Mirja Kühlewind < > [email protected]> wrote: > >> Hi ekr, >> >> as an individual contributor: I believe the wg would like to see (1) in >> the next version of the draft. However, please keep in mind that a lot of >> the people in the wg are not TLS experts but rather come from the transport >> community. Even though a self-contained document is not required, it would >> be useful to provide as much verbally explanation as possible on what the >> list below means; this means it would be useful to get an overview of what >> features are in our proposal without having to read tons of TLS documents. > > > I'm more than happy to do this. >
(By which I mean that I will do so....) -Ekr > > >> >> Mirja >> >> >> > Am 02.08.2015 um 20:52 schrieb Eric Rescorla <[email protected]>: >> > >> > >> > >> > 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. >> > >> > As I said in the WG meeting, I don't think that the latter is that >> useful and I'm >> > actually somewhat surprised that people want it. To be honest, I didn't >> realize >> > that there was much demand for it prior to Prague, which is why I >> didn't bother >> > to produce anything. Probably a failure of understanding on my part, so >> sorry >> > about that. >> > >> > 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. 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] >> > >> > 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. >> > >> > -Ekr >> > >> > >> > _______________________________________________ >> > Tcpinc mailing list >> > [email protected] >> > https://www.ietf.org/mailman/listinfo/tcpinc >> >> >
_______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
