Subject: Making ECDHE-Curve25519 the only MTI for tcpcrypt (RE: Last Call: <draft-ietf-tcpinc-tcpcrypt-07.txt> (Cryptographic protection of TCP Streams (tcpcrypt)) to Experimental RFC)

From: "Black, David" <[email-masked]>
Date: Tue, 17 Oct 2017 23:18:05 +0000

The message forwarded below suggests that ECDHE-Curve25519 should be the only mandatory to implement (MTI) key agreement algorithm for tcpcrypt instead of requiring both ECDHE-P256 and ECDHE-P521.

As a tcpinc WG chair, I'm forwarding this message to the IETF list as an IETF Last Call comment on this draft.  Additional messages on the tcpinc list indicate support of this change from:
	- ianG (https://www.ietf.org/mail-archive/web/tcpinc/current/msg01343.html)
	- some of the draft authors (https://www.ietf.org/mail-archive/web/tcpinc/current/msg01342.html, https://www.ietf.org/mail-archive/web/tcpinc/current/msg01344.html)
	- the draft shepherd (https://www.ietf.org/mail-archive/web/tcpinc/current/msg01346.html) 
There has been no objection to this change so far - I'll watch for any further comments on the tcpinc list and forward any that don't already cc: the IETF list.

Thanks, --David

-----Original Message-----
From: Tcpinc [mailto:[email-masked]] On Behalf Of Gregorio Guidi
Sent: Saturday, October 7, 2017 7:34 PM
To: Mirja Kuehlewind (IETF) <[email-masked]>
Cc: David Mazieres expires 2017-12-29 PST <[email-masked]>; tcpinc <[email-masked]>; Daniel B Giffin <[email-masked]>
Subject: Re: [tcpinc] new drafts of TCP-ENO and tcpcrypt

On 10/05/2017 01:42 PM, Mirja Kuehlewind (IETF) wrote:
> 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

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

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

---

From: Denis Ovsienko <[email-masked]>
Date: Wed, 18 Oct 2017 11:44:59 +0100

---- On Wed, 18 Oct 2017 00:18:05 +0100  Black<[email-masked]> wrote ---- 
 > The message forwarded below suggests that ECDHE-Curve25519 should be the only mandatory to implement (MTI) key agreement algorithm for tcpcrypt instead of requiring both ECDHE-P256 and ECDHE-P521. 

Let make two points -- one editorial and one technical.

I tried to look for the norm concerned in Section 3.1 (Cryptographic algorithms) first, then searched the document for the words "mandatory" and "MTI" (which it does not contain) and eventually found the MUST at the end of Section 5 (Key agreement schemes). Having to hunt around to find that specific sentence didn't feel quite right.

 > There has been no objection to this change so far - I'll watch for any further comments on the tcpinc list and forward any that don't already cc: the IETF list. 

Let me suggest a couple documents.

RFC 6709 (Design Considerations for Protocol Extensions) Section 4.5 (Cryptographic Agility) recommends having two algorithms of "distinct lineage" for a few reasons it explains.

BCP 201 a.k.a. RFC 7696 (Guidelines for Cryptographic Algorithm Agility and Selecting Mandatory-to-Implement Algorithms) Section 3.1 (Picking One True Cipher Suite Can Be Harmful) further justifies the need for more than one algorithm. The document also makes other relevant points.

Even if draft-ietf-tcpinc-tcpcrypt has nothing to do with the problems reviewed there (which is not so as far as it seems to me and may seem to other readers), it would help to make references and specifically clarify how the choices relate with the points made in those guidelines.

-- 
    Denis Ovsienko

---

From: Paul Wouters <[email-masked]>
Date: Wed, 18 Oct 2017 14:48:30 -0400 (EDT)

> Even if draft-ietf-tcpinc-tcpcrypt has nothing to do with the problems reviewed there (which is not so as far as it seems to me and may seem to other readers), it would help to make references and…

Let me suggest two other documents dealing with Mandatory To Implement
for IKE and ESP/AH as well as another example on how to specify these:

https://tools.ietf.org/html/rfc8221

https://tools.ietf.org/html/rfc8247

Paul

---

From: "Black, David" <[email-masked]>
Date: Wed, 18 Oct 2017 22:41:31 +0000

> > BCP 201 a.k.a. RFC 7696 (Guidelines for Cryptographic Algorithm Agility and
> Selecting Mandatory-to-Implement Algorithms) Section 3.1 (Picking One True
> Cipher Suite Can Be Harmful) further justifies the need for more than one
> algorithm. The document also makes other relevant points.

Not exactly - section 3.3 (NB: not 3.1) is focused on why it's a bad idea to bake the One True Cipher Suite into a protocol design in a fashion that prevents the crypto from being changed.  tcpcrypt did not do that - the draft specifies multiple algorithms and creates an IANA registry for them, e.g., to enable others to be added in the future.

In contrast, the second paragraph in Section 3 of RFC 7696 appears to be a cogent summary of the concern:

   Ideally, two independent sets of mandatory-to-implement algorithms
   will be specified, allowing for a primary suite and a secondary
   suite.  This approach ensures that the secondary suite is widely
   deployed if a flaw is found in the primary one.

Thanks, --David

> From: Tcpinc [mailto:[email-masked]] On Behalf Of Paul Wouters
> Sent: Wednesday, October 18, 2017 2:49 PM
> To: Denis Ovsienko <[email-masked]>
> Cc: tcpinc <[email-masked]>; [email-masked]
> Subject: Re: [tcpinc] Making ECDHE-Curve25519 the only MTI for tcpcrypt (RE:
> Last Call: <draft-ietf-tcpinc-tcpcrypt-07.txt> (Cryptographic protection of TCP
> Streams (tcpcrypt)) to Experimental RFC)
> 
> > RFC 6709 (Design Considerations for Protocol Extensions) Section 4.5
> (Cryptographic Agility) recommends having two algorithms of "distinct
> lineage" for a few reasons it explains.
> >
> > BCP 201 a.k.a. RFC 7696 (Guidelines for Cryptographic Algorithm Agility and
> Selecting Mandatory-to-Implement Algorithms) Section 3.1 (Picking One True
> Cipher Suite Can Be Harmful) further justifies the need for more than one
> algorithm. The document also makes other relevant points.
> >
> > Even if draft-ietf-tcpinc-tcpcrypt has nothing to do with the problems
> reviewed there (which is not so as far as it seems to me and may seem to
> other readers), it would help to make references and specifically clarify how
> the choices relate with the points made in those guidelines.
> 
>