Hiya, On 22/02/18 00:44, Paul Hoffman wrote: > 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? I tried to distinguish algorithms and suites in my mail. I like Martin's proposed text, except in that it confuses those. For algorithms like AES etc it is possible, and is in fact the case, that the broad swathe of academic cryptographers are fine with AES and we know how to deal with other algorithms to get to a position where we (the IETF) give 'em a thumbs up or down. That could become the case for one of the Chinese algorithms that are recently appearing as I-Ds or yet another one from DJB or a sarkky one from Peter Gutmann or whomever. Such was never, and could never, be the case with suite-b as that particular set of choices was only really of use to folks who were selling to the US gov or to people who were happy to follow what the US gov wanted as a customer. For suites, there aren't really useful objective metrics we can judge, as there can be with algorithms. (Even if the latter aren't entirely formal.) So such suites become a kind of end-run around our process, even when well-intended. That'd be as true of nation state defined suites as it would of industry-specific ones. Now that we actually do use all this crypto stuff in reality and not just in theory, I think IETF RFCs for nation-state specific things like suite-b are in fact dangerous for interop. A decade ago, that didn't really matter much, but today I think it does, as there is a significant danger that such things become mandatory to use for people in some parts of the Internet. And of course, almost any difference at all between such suites means breaking interop and once two people in different rooms (or even the same person a few weeks apart) define full-on suites like these, they'll end up with some interop-breaking differences. Cheers, S. > 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. > -- PGP key change time for me. New-ID 7B172BEA; old-ID 805F8DA2 expires Jan 24 2018. NewWithOld sigs in keyservers. Sorry if that mucks something up;-)
Attachment:
0x7B172BEA.asc
Description: application/pgp-keys
Attachment:
signature.asc
Description: OpenPGP digital signature
