Subject: [tcpinc] new drafts of TCP-ENO and tcpcrypt

From: Daniel B Giffin <[email-masked]>
Date: Wed, 4 Oct 2017 16:31:40 -0700

We've posted new versions of the TCP-ENO and tcpcrypt
drafts:

  https://datatracker.ietf.org/wg/tcpinc/documents/

The changes address the concerns in recent list discussion,
intending to ready the documents for IETF last call.

The TCP-ENO document now makes no reference to tcpcrypt or
TCP-Use-TLS; that is, it does not specify any values for
those protocols in the "TCP encryption protocol identifiers"
IANA registry.

The changes to the tcpcrypt document are, briefly:

  - remove citation from abstract
  - fix IPR text
  - define PRK, OKM before use
  - "session caching" => "session resumption"
  - the segment with last byte of Init1/Init2 "MUST" set PSH
  - define "abort the connection" with reference to RFC793
  - improve language about non-reuse of session secrets
  - "application frame" => "encryption frame"
  - "ignore frame" => "drop TCP segments"
  - clarify FIN/FINp interaction
  - IANA considerations: specify registry names appropriately
    and add "Reference" columns

daniel

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Thu, 5 Oct 2017 13:42:15 +0200

Hi Daniel, hi all,

thanks for all the work and changes. I just realized that I didn’t answer (yet) David’s last mail but the resolution now is fine. Thanks for the additional explanation!

I’ve just requested IETF last call for both docs and put them on the telechat agenda for Oct 26. Likely there will be more comments from different directorates and the ADs and we potentially need another version then (just before the telechat or right after) but I’m not expecting any real issues.

Thanks for the good work!
Mirja

> Am 05.10.2017 um 01:31 schrieb Daniel B Giffin <[email-masked]>:
>

---

From: Gregorio Guidi <[email-masked]>
Date: Sun, 8 Oct 2017 01:33:34 +0200

> Thanks for the good work!

Hi all,

Having followed the standardization of tcpcrypt on the tpcinc mailing 
list (as a passive observer), I wanted to check with you on a point that 
was not heavily discussed as far as I can see: the choice of the 
"mandatory to implement" (MTI) algorithms for key agreement.

I explain my concern: tcpcrypt defines ECDHE-P256 and ECDHE-P521 as MTI 
algorithms, however these are based on the NIST elliptic curves that - 
while widely deployed and offering great security - have been subject to 
some criticism in the last years. You have probably seen many times the 
arguments raised against them. The following is a good summary:

https://cr.yp.to/newelliptic/nistecc-20160106.pdf

Not all arguments in the paper are relevant for the key agreement used 
in tcpcrypt, but many are. It is especially relevant the fact that 
tcpcrypt is "tailored to TCP implementations, which often reside in 
kernels or other environments in which large external software 
dependencies can be undesirable". This means that the usual path to 
integrate P256 and P521, that is, linking to a big library such as 
OpenSSL, will be impractical in many cases. This opens up the potential 
pitfalls described in the paper, since new low-level code will be needed 
to integrate the primitives into the TCP stack.

 From a more detached point of view, the choice of ECDHE-P256 and 
ECDHE-P521 is a "conservative" one that is not likely to do any damage 
in practice. But still, I would say that as of 2017, the rough consensus 
is that the choice of the NIST curves does not reflect anymore the state 
of the art in the field, especially for new applications.

Looking back at the archives, I can find an exchange from last year on 
the topic:
https://mailarchive.ietf.org/arch/msg/tcpinc/QWLophMkudMGU_X0_w_8YcRl910

Having ECDHE-Curve25519 and ECDHE-Curve448 as MTI was suggested, but the 
lack of implementations for Curve448 was mentioned. Unfortunately this 
is still an issue: there are implementations available but no stable and 
well-proved implementation of Curve448 is there yet, as shown here:
https://en.wikipedia.org/wiki/Comparison_of_TLS_implementations#Supported_elliptic_curves

Nonetheless, in the time passed since that exchange, the adoption of 
Curve25519 has consolidated further, so the option to have 
ECDHE-Curve25519 as the only MTI would not look so bad in my view.

All in all, I feel that the current choice of algorithm could have a 
slight detrimental effect on the adoption of tcpcrypt, but how much is 
difficult to tell. I leave to you to judge whether this could be 
considered a valid concern or not.

Thanks for all the work,
Gregorio

---

From: [email-masked]
Date: Sat, 07 Oct 2017 21:56:47 -0700

Gregorio Guidi <[email-masked]> writes:

> list (as a passive observer), I wanted to check with you on a point
> that was not heavily discussed as far as I can see: the choice of the

You raise a reasonable question.  There are a lot of trade-offs.  On one
hand, it would be nice to have a scheme with longer than 32-byte keys.
But then it's probably easier to find a P521 ECDHE implementation to
cram into the kernel than a curve448.  Should we have Curve25519 and
P521?  But whatever library supports P521 probably also supports P256,
so it's less work to do both of those.  Also, the best reference for the
two Edwards curves is an informational RFC, vs. IEEE and NIST standards
for the other ones.

One good thing is that MTI is almost irrelevant given the way the
different public key algorithms have been assigned their own ENO TEP
Identifiers.  It's almost as if this document is defining four separate
protocols that just happen to be able to share 99% of the code.  But of
course we need to encourage people to implement the same algorithms
initially...

David

---

From: iang <[email-masked]>
Date: Fri, 13 Oct 2017 17:24:18 +0100

On 08/10/2017 00:33, Gregorio Guidi wrote:

> ...
> Having ECDHE-Curve25519 and ECDHE-Curve448 as MTI was suggested, but 
> the lack of implementations for Curve448 was mentioned. Unfortunately 
> this is still an issue: there are implementations available but no 
> stable and well-proved implementation of Curve448 is there yet, as 
> shown here:

+1.  The notion that we need two MTIs with one longer than 256 bits in 
an embedded optimistic half-measure needs some serious justification.  
And the one that fits best in kernel, isolated from external libraries, 
is likely best for attack surface.  I'd put my money on Curve25519 every 
day of the month for that.

iang

---

From: David Mazieres <[email-masked]>
Date: Mon, 16 Oct 2017 18:40:11 -0700

Some of the tcpcrypt authors have talked over the proposal to make
ECDHE-Curve25519 MTI instead of P256 and P521.  We think this argment
has merit if it won't hamper standardization and adoption of the
protocol at this juncture.

One of the original motivations for making P256 MTI was that if P256 is
broken, then the world is in some trouble anyway.  A counter-argument
might be that such trouble could be slightly reduced if people could
turn on tcpcrypt with ECDHE-Curve25519.  Further tipping the balance in
favor of ECDHE-Curve25519 is the fact that it's probably easier to find
safe implementations of Curve25519 than P256 to embed in the kernel.
Certainly Curve25519 is a lot more widely used now than when we started
the tcpcrypt project, making it not unreasonable to revisit the
decision.

Question one is whether there's anyone in the working group who thinks
it would be a bad idea to make this change--i.e., to have a single MTI
algorithm, namely ECDHE-Curve25519.  If so, please speak up.

Question two, if no one object to this change and some people want to
see it, is whether it is now too late to make this change without
jeopardizing the RFC.  Can we still make such a change in last call?
It's obviously not a lot of text to change, but a fairly big semantic
change.  We'd appreciate guidance on this question from people with more
IETF experience.

Thanks,
David

---

From: Kyle Rose <[email-masked]>
Date: Tue, 17 Oct 2017 10:13:38 -0400

On Oct 16, 2017 9:40 PM, "David Mazieres" <[email-masked]>
wrote:

Speaking as interested party rather than chair, I was in favor of this
change over a year ago and remain in favor of it.

Mirja and David Black: can you provide guidance here?

Kyle

---

From: Mirja Kühlewind <[email-masked]>
Date: Tue, 17 Oct 2017 16:43:27 +0200

Hi David, hi Kyle, hi all,

 > Mirja and David Black: can you provide guidance here?

Yes, if the change is the right thing to do, you should do it. If there is 
agreement in the working group to make this change, I don't think we need 
another working group last call (but that's actually in the judgment of the 
chairs). So the only question would be, do we need another IETF last call for 
this? However, the IETF last call is still running. Therefore I would like to 
ask you to bring attention about this change to the [email-masked] mail list, 
meaning one of the authors could reply to the IETF last call email and 
explain that and why this change is planned. And then we can probably handle 
this basically like a last call comment and just update the draft 
respectively. In this case it would also be good if the authors could submit 
the updated version right at the end of the IETF last call, so this Friday, 
such that the ADs could review the updated version for the telechat next 
week. Would that be possible?

Mirja

---

From: "Black, David" <[email-masked]>
Date: Tue, 17 Oct 2017 22:58:38 +0000

> ask you to bring attention about this change to the [email-masked] mail list,

I concur, and I will go do that by forwarding Gregorio's message to the IETF
list, providing a pointer to ianG's message of support and indicating that the
draft authors concur, also with a message pointer.  My rationale for forwarding
Gregorio's message is that it provides solid answers to the inevitable "why is
this change being made?" question both directly and in the form of a pointer
to the extensive DJB & T. Lange implementation-oriented critique of the
NIST curves.

Thanks, --David

> -----Original Message-----
> From: Tcpinc [mailto:[email-masked]] On Behalf Of Mirja Kühlewind
> Sent: Tuesday, October 17, 2017 10:43 AM
> To: Kyle Rose <[email-masked]>; David Mazieres expires 2018-01-14 PST
> <mazieres-ddragqirgwht7ezx2d39a3jw72@temporary-
> address.scs.stanford.edu>; Black, David <[email-masked]>
> Cc: tcpinc <[email-masked]>; Gregorio Guidi <[email-masked]>; ianG
> <[email-masked]>
> Subject: Re: [tcpinc] Making ECDHE-Curve25519 the only MTI for tcpcrypt
> 
> _______________________________________________
> Tcpinc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpinc

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Wed, 18 Oct 2017 09:02:44 +0200

Sounds like a good plan. Thanks!

> Am 18.10.2017 um 00:58 schrieb Black, David <[email-masked]>:
>

---

From: David Mazieres <[email-masked]>
Date: Mon, 23 Oct 2017 13:25:37 -0700

We are considering the following proposal for MTI key exchange protocols
in tcpcrypt:

  1. Implementations MUST support Curve25519.

  2. Implementations SHOULD support Curve448 to the extent that suitable
     implementations are available.

  3. Implementations MAY support P256 and P521 (particularly since
     hardware implementations are widely available for the former).

(Obviously whatever algorithms are supported can always be disabled by
configuration--this is just about what the software MUST support, not
what everyone must use.)

The security ADs have not 100% signed off on this approach yet, but seem
receptive to it.  However, given the timeline, we would like to
parallelize things and find out *now* if there are any objections to the
proposal.  Based on the working group discussion, I think everyone will
be happy, so please speak up now if you object.

Thanks,
David

---

From: Rene Struik <[email-masked]>
Date: Mon, 23 Oct 2017 21:22:47 -0400

Hi David:

This should be okay as long as people are painfully aware that 
implementations should take algorithm agility into account [1]. In 
particular, no complaining about vested interests down the road, in case 
a suite change should be required. The protocol should also support 
*now* algorithm agility, via indicator functions of the suite in question.

Rene

[1] RFC 7696 - Guidelines for Cryptographic Algorithm Agility and 
Selecting Mandatory-to-Implement Algorithms (November 2015)

-- 
email: [email-masked] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

---

From: David Mazieres <[email-masked]>
Date: Mon, 23 Oct 2017 18:49:00 -0700

> *now* algorithm agility, via indicator functions of the suite in question.

Yup.  We already have algorithm agility, and the only question is which
of the four specified algorithms to make mandatory to implement.

Thanks,
David

---

From: iang <[email-masked]>
Date: Tue, 24 Oct 2017 12:41:51 +0200

> be happy, so please speak up now if you object.

In general +1.

The only quibble I would have is that 2. Curve448 should be a MAY. 
Firstly, a caveated SHOULD becomes a MAY, at some level of 
approximation.  Secondly, if we manage to convince an enemy to crunch 
Curve25519 then we have won a great victory, and we can upgrade at our 
leisure with newer information.

But it is only a quibble - I wouldn't hold up any vote on this just 
because of an idle bar prediction on consequences.

iang

---

From: David Mazieres <[email-masked]>
Date: Tue, 24 Oct 2017 11:26:29 -0700

> because of an idle bar prediction on consequences.

Point taken.  However, the rationale behind the SHOULD is that:

A) The ADs were slightly uncomfortable with only one MTI, though not
   adamantly opposed to it, and

B) People really should implement Curve448, so why not write the
   document in such a way as to encourage it?

So the SHOULD is a nice compromise between one MTI and two MTIs, where
sure we only have one MTI, but we've encouraged people who want a second
key exchange algorithm to converge on the same one.  This way down the
line, when Curve448 is widely supported in software, people will be more
likely to include it.

Make sense?

David

---

From: iang <[email-masked]>
Date: Tue, 24 Oct 2017 23:19:33 +0200

> line, when Curve448 is widely supported in software, people will be more

Yes - makes sense - after this earlier thread I went back and read the 
earlier comments.  It's what it takes.  Let's do it.

iang

---

From: Gregorio Guidi <[email-masked]>
Date: Wed, 25 Oct 2017 09:43:30 +0200

>earlier comments.  It's what it takes.  Let's do it.

Agreed, the plan looks excellent to me.

Thanks a lot for all your efforts, 
Gregorio