> > 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 > -----Original Message----- > From: Tcpinc [mailto:tcpinc-bounces@xxxxxxxx] On Behalf Of Paul Wouters > Sent: Wednesday, October 18, 2017 2:49 PM > To: Denis Ovsienko <denis@xxxxxxxxxxxxx> > Cc: tcpinc <tcpinc@xxxxxxxx>; ietf@xxxxxxxx > 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) > > On Wed, 18 Oct 2017, Denis Ovsienko wrote: > > > 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. > > > 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 > > _______________________________________________ > Tcpinc mailing list > Tcpinc@xxxxxxxx > https://www.ietf.org/mailman/listinfo/tcpinc