On Feb 21, 2018, at 4:18 PM, Martin Thomson <martin.thomson@xxxxxxxxx> wrote: > > On Thu, Feb 22, 2018 at 11:08 AM, Stephen Farrell > <stephen.farrell@xxxxxxxxx> wrote: >> If the suite-b term is outmoded, and if there's utility in some >> RFC to document that, then I would argue that we ought only do >> that in a way that does not open doors for yet more national >> suites > > I think that Stephen is on to something here. I think that it would > be worthwhile acknowledging this point explicitly in this document. > "In the past, the IETF published country-specific cryptographic > algorithms and profiles. This practice is no longer considered to be > good for interoperability." As a new paragraph in Section 1 or 2. In what way is publishing Informational RFCs that specify country-specific cryptographic algorithms *not* considered to be good for interoperability? How could they make interoperability worse? Without Informational RFCs for AES, SHA-128, and so on, interoperability would drop markedly as developers looked to less reliable and stable places when writing implementations. With respect to suites and profiles, saying "country-specific" is going to turn into a rat hole. What if an large industry trade association from one country wants to specify a suite in an RFC? What if a profile is developed jointly by three countries, two of which are obviously beholden to the third? Or...? You might say that there should be no Informational RFCs specifying cryptographic suites and profiles at all unless the profile was put together in the IETF, and that would make sense given that externally-generated cryptographic suites and profiles change over time. But that is just as true as protocol profiles that are common in industry trade associations. This is just a continuation of the question of what externally-generated specifications should be in the RFC series as Informational RFCs: it is not specific to suites, profiles, or "country-specific". At some point, the IAB might settle this debate. There is now plenty of experience with Informational document from outside the IETF, and plenty of easy-to-see potholes. --Paul Hoffman Disclaimer: I got paid to help with the Suite B specs in the IETF and was completely open about it while doing so.
<<attachment: smime.p7s>>
