Re: 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)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



---- On Wed, 18 Oct 2017 00:18:05 +0100  Black<David.Black@xxxxxxxx> 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.

 > 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 

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





[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]