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.

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

Reply via email to