Hiya, On 22/02/18 18:05, Russ Housley wrote: > Martin: > > We want good algorithms, and we have created a way to get advice on > algorithms from the CFRG. The algorithms get published in > Informational RFCs, and then standards-track RFCs tell how those > algorithms get used in IETF protocols. It took us a long time to get > all of that sorted out and working, which included the ability to > make downrefs (https://datatracker.ietf.org/doc/downref/ > <https://datatracker.ietf.org/doc/downref/>). Fully agree. > > Profiles are completely different. Fully agree again. > The Suite-B profiles do not > define any protocols, protocol options, or algorithms. Rather the > profiles reference IETF RFCs and state the options and algorithms > that must be supported in a particular environment. That certainly > improves interoperability in that environment. I am not aware of an > IETF MUST statement that was downgraded in these profiles, but I am > aware of some SHOULD statements that were upgraded to MUST. > > Such profiles are necessary, and I think we should make them easy to > find. Informational RFCs (perhaps ones that use int Independent > stream) seem like a good way to make them easy to find. I'm not sure I agree that suite-b like profiles are needed today. And if it were solely a matter of profiling the options allowed for (and widely implemented) in IETF protocols, that'd maybe be ok. But iirc (and this is from memory) suite-b also called for support for less commonly implemented protocol options, and also for use of then rarely-supported, and at the time IPR-unclean, ECC. I'd be concerned that multiple such profiles from multiple sources could damage interop, as there's not much chance that different e.g. national profiles of that kind will end up the same. So while the ISE route will of course remain an option for authors of such drafts, I'd argue that discouraging profiles that do the kind of things done in suite-b is likely a better option. And this draft seems like a fine opportunity to do that. (If we have consensus on saying such.) Don't get me wrong - I don't think suite-b was damaging when it was done, nor that it was done for anything other than good reasons, it's just that times have changed. S. > > Russ > >> On Feb 21, 2018, at 8:31 PM, Martin Thomson >> <martin.thomson@xxxxxxxxx> wrote: >> >> On Thu, Feb 22, 2018 at 11:44 AM, Paul Hoffman >> <paul.hoffman@xxxxxxxxx> wrote: >>> With respect to suites and profiles, saying "country-specific" is >>> going to turn into a rat hole. >> >> Sir, you may dig as many ratholes as you like. I was >> intentionally being terse. Pick another word if you like, I was >> merely offering a suggestion. >> >>> 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, [...] >> >> I don't think that's relevant. We have now what I think is a good >> practice. The CFRG has now, for some time, reviewed crypto and >> made statements about fitness for purpose (Information RFCs). That >> set is potentially larger than the set that we as the IETF might >> want to draw on, but generally they don't publish things that don't >> have customers. The IETF then integrates into protocols as it sees >> fit. That step isn't formalized, but there are many (Stephen >> included) who make a point of holding a high bar for the inclusion >> of new crypto. >> >> Again, my opinion, but profiles aren't that valuable, other than >> what is implicit in what we choose to publish. >> >>> At some point, the IAB might settle this debate. >> >> (IAB hat) The IETF decides its own consensus. >> > > -- 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
