Subject: Re: [tcpinc] CORRECTION: Reminder: Ongoing Working Group Last Call about drafts to choose as WG item

From: Richard Barnes <[email-masked]>
Date: Fri, 31 Jul 2015 10:54:24 -0400

I have a pretty strong preference for (a), the Rescorla draft.   New code
is undesirable in security systems -- better to rely on a known,
battle-tested code base.  So it seems like a no-brainer to use TLS as the
starting point and making the minimum set of changes needed.

--Richard

---

From: Watson Ladd <[email-masked]>
Date: Sun, 2 Aug 2015 07:18:46 -0700

It's true that OpenSSL has been executed more times then some other
implementations. Does this ensure its security?

Bind was more popular  then qmail. Which has a better security record?

>
> --Richard
>
> _______________________________________________
> Tcpinc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpinc

---

From: Yoav Nir <[email-masked]>
Date: Sun, 2 Aug 2015 17:30:21 +0300

> On Jul 31, 2015, at 5:54 PM, Richard Barnes <[email-masked]> wrote:
> 
> I have a pretty strong preference for (a), the Rescorla draft.   New code is undesirable in security systems -- better to rely on a known, battle-tested code base.  

The codebase is going to be new anyway. We’re not likely to be able to shoehorn OpenSSL or NSS into the kernel, especially if we end up having the “hard” operations done in a separate daemon (for the profile of TLS that is likely to emerge here, this may not be necessary).

> So it seems like a no-brainer to use TLS as the starting point and making the minimum set of changes needed. 

We ended up writing our own TLS code, but then we had the full TLS to implement, including certificate validation and RSA signatures, so we had to split things between user-space and kernel. An implementation may opt to perform the diffie-hellman in the kernel, but I still doubt you would be able to use OpenSSL without major modifications.

Yoav

---

From: David Mazieres <[email-masked]>
Date: Sun, 02 Aug 2015 11:11:43 -0700

> starting point and making the minimum set of changes needed.

There are two problems with this argument, though.  First, as already
pointed out, you can't just drop openssl into the kernel, so new code
will have to be written anyway.

Second, things that are easier to implement are easier to implement
correctly.  Even if TCP-use-TLS required 10x or even 100x the
engineering effort/lines of code/chose your metric as tcpcrypt, it would
likely be able to muster the necessary manpower (if people care), given
how huge TLS is.  More available engineering power can certainly be an
advantage, but it doesn't always translate into better security.

Tcpcrypt, by necessity given the size of our team, has been designed to
minimize implementation effort (even more so given the verified
implementation effort at Kestrel, which even if we don't complete it
still informs the design).  That places more design restrictions on us
in terms of complexity.  It's a bit like designing an aircraft where you
face strict weight and balance requirements.  If we add something to
tcpcrypt that requires an extra 40 hours to implement, this is a huge
deal for us.  For TLS, that amount of engineering effort would be in the
noise (again, if people cared).

Those two design methodologies are likely to lead to different failure
modes in tcpcrypt vs. TLS, which is why I think the diversity of
tcpcrypt + TLS could help overall security.

Now there's another thing I worry about, which is my "(if people care)"
asides.  How much is the TLS community willing to make TCPINC a
priority?  With TCP-use-TLS, there may be a non-trivial risk that TCPINC
gets shelved until after the TLS1.3 effort is complete.  If you look
back to past TCPINC sessions, like Toronto
(http://www.ietf.org/proceedings/90/slides/slides-90-tcpinc-0.pdf) and
Dallas
(http://www.ietf.org/proceedings/92/slides/slides-92-tcpinc-2.pdf), you
see repeated claims that, compared to tcpcrypt, TLS-use-TCP is "Easy to
specify and implement."  Also that TCP-use-TLS is a "pretty obvious
subsetting exercise."

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 and the (still proprietary) implementation took so long to
realize, I think there's a good chance that either a) people
underestimated the effort required for TCP-use-TLS, or b) nobody cares
enough about TCP-use-TLS to do the obvious work.

David

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 2 Aug 2015 11:52:18 -0700

On Sun, Aug 2, 2015 at 11:11 AM, David Mazieres <
[email-masked]> wrote:
> 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

---

From: Christian Huitema <[email-masked]>
Date: Sun, 2 Aug 2015 19:07:09 +0000

On Sunday, August 2, 2015 11:12 AM, David Mazieres wrote:
> ...

I too have a strong preference for EKR's draft (a). My main reason is that I see TCP INC as a transition technology, deploying opportunistic encryption first but evolving quickly to strong encryption with authentication. TLS compatibility facilitates that transition. My other reason is that I would much rather maintain a single security stack instead of two.

I have been pondering these issues for some time. I liked the initial TCP-crypt design a lot, but my attraction to it vanished after the "middle-box" compromise. The TCP security protection cannot protect the TCP protocol elements, because doing so would be incompatible with existing middle-boxes. But then we are left with running a security filter on top of TCP, and that's exactly what TLS does.

The question then is whether we deploy a light weight security filter like the current TCP crypt design, or whether we just find a way to shim TLS between the current TCP API and the application. I much prefer the TLS option.

The main argument for TCP Crypt is the cost of implementation. That argument rings a bit hollow for a Windows kernel developer, since we have in fact access to S-Channel in the Windows kernel. Windows web servers rely on the HTTP.SYS kernel driver, which implements TLS using the kernel API for S-Channel. HTTP.SYS has been doing that for a long time, so there is indeed some experience with that solution. 

The other argument for the light weight filter is that the protocol can be smaller, and thus easier to verify, debug, or even prove. The protocol may indeed be smaller, but the size effect mostly comes from leaving out authentication. Without authentication, there is no need for verifying certificates. If one leaves certificate negotiation out, TLS is pretty small. The next big chunk of complexity comes from algorithm agility, but I fully expect that any standardized version of TCP crypt will have to incorporate some support for algorithm agility. At that point, we would have two stacks to implement, which means twice the attack surface and twice the number of potential security bugs.

The logical argument that swayed me towards reusing TLS is the evolution towards authentication. We want to deploy TCP INC to enable opportunistic encryption of old applications that have not yet been upgraded to "Start TLS." But we do not want these applications to be stuck at the "opportunistic" level. The solution in TCP crypt is to use a channel binding API so authentication can be later implemented inside the application. That works, but it requires applications to manage secrets, and points to the evolution of an enlarged TCP crypt stack that would incorporate authentication based on channel binding, and effectively compete with the TLS solutions. At that point, the risk of twice the attack surface and twice the bugs becomes really concerning, not to mention the confusion of two IETF standards to achieve the same thing.

The "TLS filter" approach provides a simpler evolution path. System administrators first use a system option to insert a TLS shim under unprotected applications. In parallel, applications start evolving and adopt a way to "Start TLS." We get a transition state in which the TLS layer incorporated in an application talks to the shim under an unmodified responder. The system administrator initially provision the shim with a self-signed certificate, but may upgrade to a regular certificate and provide actual authentication. All that looks like a clean evolution.

---

From: Christian Huitema <[email-masked]>
Date: Sun, 2 Aug 2015 19:19:53 +0000

On Sunday, August 2, 2015 11:52 AM, Eric Rescorla wrote:
> On Sun, Aug 2, 2015 at 11:11 AM, David Mazieres <[email-masked]> wrote:
> 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.
> 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:
>

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.

> but I think the big issue here is whether or not we would require TLS 1.3 or not.

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

---

From: John-Mark Gurney <[email-masked]>
Date: Sun, 2 Aug 2015 12:51:57 -0700

> I too have a strong preference for EKR's draft (a). My main reason is that I see TCP INC as a transition technology, deploying opportunistic encryption first but evolving quickly to strong encrypti…

How does tcpcrypto not facilitate the trasition to authentication?  It
already has a working OpenSSL modifications that authenticates tcpcrypt
sessions...  or are you saying that tcpcrypt does not provide strong
encryption?

> The main argument for TCP Crypt is the cost of implementation. That argument rings a bit hollow for a Windows kernel developer, since we have in fact access to S-Channel in the Windows kernel. Wind…

Microsoft has not talked publicly about the issues they had w/
implementing and securing HTTP.SYS, and they have a full time set of
engineers they can put on the task, other OSS OS's do not have that
luxury..  Though Microsoft does have an implementatio, very little is
known about it, so too much is unknown about it, IMO, to claim that
full TLS in the kernel is doable and safe...

> The other argument for the light weight filter is that the protocol can be smaller, and thus easier to verify, debug, or even prove. The protocol may indeed be smaller, but the size effect mostly c…

The TLS-use-TCP protocol also leaves out authentication, so I don't
see any differences here...

I do agree that doing two stacks is counter productive and should not
be done..

> The logical argument that swayed me towards reusing TLS is the evolution towards authentication. We want to deploy TCP INC to enable opportunistic encryption of old applications that have not yet b…

I don't see how TLS avoids the application managing secrets, or are you
talking about a full version of TLS in the kernel, but still the
application still needs to manage the secrets, otherwise how else can
it load them into the kernel?

> The "TLS filter" approach provides a simpler evolution path. System administrators first use a system option to insert a TLS shim under unprotected applications. In parallel, applications start evo…

It's sounds like you view TLS-use-TCP as doing full certificate parsing
and validation in the kernel, is this correct?

TLS-use-TCP still doesn't have a profile.. ekr gave a profile "like"
something today, he isn't committing to it, or even suggesting that
be the profile...

-- 
  John-Mark Gurney				Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 2 Aug 2015 13:21:00 -0700

> something today, he isn't committing to it, or even suggesting that

Well, I certainly was suggesting that as a starting point for the modes and
algorithms
that should minimally be supported. As Christian says, I think that we
should certainly
allow implementations to support other modes because one purpose of
TCP-use-TLS
is to act as a bridge to non-opportunistic TLS.

I'm not sure what you mean by "isn't committing". The question of exactly
what
parameters go in the profile is, as Ted has observed repeatedly, ultimately
a WG decision,
not my personal decision, so I'm not sure how I could commit to anything
here.
I think a lot of these decisions are obvious (e.g., AEAD only) and some are
not (should we specify both AES and ChaCha? Should we also specify
AES-256-GCM),
and I would expect others to have opinions. Hence "something like".

-Ekr

---

From: Christian Huitema <[email-masked]>
Date: Sun, 2 Aug 2015 20:30:27 +0000

> and validation in the kernel, is this correct?

There are multiple ways to implement a shim between application and TCP. If I implemented this in the Windows kernel, I would use the existing kernel API. But I can see many other ways.

Your specific question on certificate is a matter of profiles. EKR proposed "ECDH anon with P256 and Curve25519." This is "anonymous Diffie-Helman with elliptic curves." It does not involve any certificate at all.

-- Christian Huitema

---

From: Watson Ladd <[email-masked]>
Date: Sun, 2 Aug 2015 13:36:52 -0700

> Your specific question on certificate is a matter of profiles. EKR proposed "ECDH anon with P256 and Curve25519." This is "anonymous Diffie-Helman with elliptic curves." It does not involve any cer…

Your email talked about authentication. Was that going to interact
with the shim, or just signal to the app that it should do TLS? If the
second, what is the gain from using TLS over TCP instead of opting out
of tcpcrypt if the app will do TCP?

-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.

---

From: Christian Huitema <[email-masked]>
Date: Sun, 2 Aug 2015 21:25:01 +0000

On Sunday, August 2, 2015 1:37 PM, Watson Ladd wrote:
> > There are multiple ways to implement a shim between application and TCP.
> If I implemented this in the Windows kernel, I would use the existing kernel
> API. But I can see many other ways.
> >
> > Your specific question on certificate is a matter of profiles. EKR proposed
> "ECDH anon with P256 and Curve25519." This is "anonymous Diffie-Helman
> with elliptic curves." It does not involve any certificate at all.
> 

There are four scenarios, "shim to shim", "full to shim", "shim to full", and "full to full," where full is a complete implementation of TLS and shim is the subset. Obviously, shim to shim works as long as the two ends have the same shim, and full to full works as long as the two ends implement TLS. 

"Full to shim" sees one client implementing full TLS, and presumably using an IOCTL to disable the shim implementation. If the TLS options proposed by the client are a superset of the TLS options used by the shim, and if the ENO option is used right, we end up with the same TLS over TCP variant as shim to shim.

"Shim to full" sees one server implementing full TLS, presumably using some "start TLS" variant. The shim is systematically disabled on the server's sockets. The ENO option advises the server to switch on TLS, rather than wait for the "Start TLS" message. As long as the TLS options accepted by the server include the options proposed by the shim, we end up with the same TLS over TCP variant as shim to shim.

The obvious issue is the potential for downgrade attacks and MITM insertion, but that's something LS has to deal with anyhow.

-- Christian Huitema

---

From: Watson Ladd <[email-masked]>
Date: Sun, 2 Aug 2015 22:09:42 -0700

> There are four scenarios, "shim to shim", "full to shim", "shim to full", and "full to full," where full is a complete implementation of TLS and shim is the subset. Obviously, shim to shim works as…

You didn't answer the question, but half of it. Okay, I'll provide the
other half, where we use tcpcrypt instead. We'll use two bits: will
offer tls, will offer tcpcrypt, and fall back to tls otherwise.

> "Full to shim" sees one client implementing full TLS, and presumably using an IOCTL to disable the shim implementation. If the TLS options proposed by the client are a superset of the TLS options u…

So in my above proposal we end up with tcpcrypt protecting the
channel, as what was the shim indicates it wants tcpcrypt, and the
negotiation works.

> "Shim to full" sees one server implementing full TLS, presumably using some "start TLS" variant. The shim is systematically disabled on the server's sockets. The ENO option advises the server to sw…

This is symmetric with above. Or am I missing something? So once again
both proposals do the same thing. Can someone beat the donkey until it
decides?

---

From: John-Mark Gurney <[email-masked]>
Date: Sun, 2 Aug 2015 23:24:12 -0700

> - RFC5705 tickets [or PSK in 1.3]

Is this what you are proposing for the profile?  or is this just, oh
one profile might be the above, but I'm not proposing anything?

I want to be clear before we start discussing this as a proposal, since
the language above doesn't sound like one to me...

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 3 Aug 2015 04:16:35 -0700

> one profile might be the above, but I'm not proposing anything?

This is what I presently intend to put in the next version of the draft,
though I'm open to arguments that some aspect of it is wrong.
Does that count as proposing?

-Ekr

---

From: Mirja Kühlewind <[email-masked]>
Date: Mon, 3 Aug 2015 13:58:38 +0200

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-masked]>:
> 
> 
> 
> 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.
> 
> of whether or not TLS is the right choice here. But maybe I'm just too close to

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 3 Aug 2015 05:02:57 -0700

On Mon, Aug 3, 2015 at 4:58 AM, Mirja Kühlewind <
[email-masked]> 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.

Best,
-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 3 Aug 2015 05:03:42 -0700

> I'm more than happy to do this.

(By which I mean that I will do so....)

-Ekr

---

From: Mirja Kühlewind <[email-masked]>
Date: Mon, 3 Aug 2015 14:11:51 +0200

Hi Ekr,

> Am 02.08.2015 um 22:21 schrieb Eric Rescorla <[email-masked]>:
> 
> I'm not sure what you mean by "isn't committing". The question of exactly what
> parameters go in the profile is, as Ted has observed repeatedly, ultimately a WG decision,
> not my personal decision, so I'm not sure how I could commit to anything here.
> not (should we specify both AES and ChaCha? Should we also specify AES-256-GCM),
> and I would expect others to have opinions. Hence "something like“.

As long as this is not a wg doc, it’s you individual doc. Therefore you can simple decided what should be in this doc and no wg consensus/decisrion is needed. I would suggest you, so provide one complete solution where you pick one set of features along with one set of parameters. Where possible maybe describe why a certain mechanism/parameter was chosen or indicate that further discussion might be needed/is appreciated. I believe that would help a lot for people to better understand you approach.

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Mon, 03 Aug 2015 11:44:40 -0400

> - RFC5705 tickets [or PSK in 1.3]

This rough cut doesn't include TLS Extractors or TLS Unique.  If it's
going to satisfy the the session ID capacity of
draft-bittau-tcpinc-tcpeno it needs to include one of these mechanisms
at least, right?

   --dkg

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 3 Aug 2015 08:47:50 -0700

> draft-bittau-tcpinc-tcpeno it needs to include one of these mechanisms

Good catch. Yes, it needs some sort of channel binding support, however
TLS-Unique does not appear on the wire, so it didn't seem to be part
of the profile (hence my omitting it). I agree, however, that the document
should describe this clearly.

-Ekr

---

From: David Mazieres <[email-masked]>
Date: Mon, 03 Aug 2015 10:39:50 -0700

> - AES_128_GCM; AES_256_GCM; ChaCha/Poly1305

This is a naive question, but could we get some guidance from the powers
that be on what ciphers are and are not appropriate for an experimental
TCPINC protocol document?

Technically, Curve25519 and ChaCha/Poly1305 both seem like fine options.
Tcpcrypt was even using Poly1305 in an earlier version (I can't remember
if it ever made it into one of our drafts).  We removed it from fear
that this would cause standardization issues.  It seems Curve25519 is
still an internet draft with informational status, while RFC7539 is an
informational RFC.  Is it inappropriate for an experimental TCPINC
protocol document to depend on informational RFCs?

In order to ensure an apples-to-apples comparison between tcpcrypt and
TCP-use-TLS, I'd like to suggest that we at least attempt to agree on
one or two initial cipher suites for both protocols to support.

David

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 3 Aug 2015 10:43:47 -0700

> one or two initial cipher suites for both protocols to support.

FWIW, in TLS we expect to advance standards track drafts for both Curve25519
and ChaCha/Poly, so I don't think that's going to cause dependency issues.

-Ekr

---

From: Yoav Nir <[email-masked]>
Date: Mon, 3 Aug 2015 20:49:18 +0300

> On Aug 3, 2015, at 8:39 PM, David Mazieres <[email-masked]> wrote:
> 

Hi, David

RFC 7539 is marked as Informational because it is a product of the CFRG, which is a research group. The algorithms are not something invented in the IETF, so standards track is not appropriate.

It’s fine to use both Curve25519 and ChaCha/Poly, and the already-approved "ChaCha20, Poly1305 and their use in IKE & IPsec <https://tools.ietf.org/html/draft-ietf-ipsecme-chacha20-poly1305-12>” which *is* standards track references it. I expect the TLS draft and the drafts for Curve25519 for both IKE and TLS to work the same way.

Yoav

---

From: John-Mark Gurney <[email-masked]>
Date: Mon, 3 Aug 2015 12:08:48 -0700

> Does that count as proposing?

Yes, I agree w/ the above proposal, though it might be nice to include
a comparable ECDH curve of equivalent security strength to go w/
AES-256..

But otherwise the proposal looks fine..

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 03 Aug 2015 20:19:26 +0100

Hi Eric,

On 02/08/15 19:52, Eric Rescorla wrote:
> way. 

So I don't get the argument for allowing any earlier versions of TLS
here at all. Why do you prefer that?

My reasons for assuming your profile, when documented, (which it is not
currently, regardless of one's familiarity with TLS) would only be a
profile of TLS 1.3 were:

- If you allow earlier versions, you get all the pain of backwards
compatibility, the need to ensure you don't have any of the old bugs,
etc. etc.

- Implementations will have to be able to respond sensibly to all sorts
of old crap ClientHello stuff at least, and maybe more. That will make
the TCPINC profile much more complex than needed, or else, make the
TCPINC profile very likely to be incompletely specified.

- I think it is also likely to increase the chances of failing to
successfully negotiate a session, simply on the basis of the number
of twistable knobs in the various versions of TLS. For example, will
there be a need for the TLS h/w accelerator bug-fixing oversized
ClientHello nonsense bytes in some cases if TCPINC goes this route?

- With earlier versions you lose whatever security analysis will be
done for TLS1.3 which is being designed to make that kind of analysis
much easier. Earlier versions are all hard to analyse, and nobody
has done work on, or afaik plans work on, analysis of this profile
over older various versions of TLS.

- Assuming QUIC is standardised and as planned also uses a profile of
TLS1.3 (albeit likely less constrained than for TCPINC), we've diverged
quite oddly.

- I assumed you'd want some 0-RTT stuff, much as I'm not a fan of
that.

- I don't see any need for almost 400 ciphersuites and all the crap
that goes with those, the TLS1.3 MTI ciphersuites should be more than
enough for TCPINC. (Too much in fact, IMO.)

- In summary, inheriting two decades of cruft for, I think, zero real
benefit, seems to me like a bad plan. There is also a major benefit in
not having every WG participant having to convince themselves that the
spec has successfully avoided that two decades of cruft via clever
profiling.

Actually the only benefit I think one can claim from allows earlier
versions of TLS would be that it makes it easier for folks who currently
have TLS code and want to re-use that for TCPINC. If that is your
argument than a) I don't find it very compelling and b) I think it means
you also need to document how it's relatively easy to take a current
generic TLS implementation and make it conform to the TCPINC profile.
(By "document" here I don't mean in an I-D though, that could be done
just fine via code or emails arguing the case.)

So - why prefer inheriting cruft? (Apologies in advance for the very
loaded question:-)

Cheers,
S.

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 3 Aug 2015 13:01:20 -0700

> a comparable ECDH curve of equivalent security strength to go w/
People seem to think that P-384 or Goldilocs-448 is the curve of choice for
that application.

-Ekr