Re: Last Call: <draft-housley-suite-b-to-historic-03.txt> (Reclassification of Suite B Documents to Historic Status) to Informational RFC

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

 




On 21/02/18 22:34, Paul Wouters wrote:
> 
> I guess "Suites" or "profiles" from certain goverments or organisations
> really do not belong in an IETF RFC.

+many

It's a fine thing if the crypto used in IETF standards is useful
for national standards. It's IMO a really bad idea for the IETF
to be in the business of ratifying any particular government's
choices of crypto suites like this. (Before someone asks, AES is
IMO not the same kind of thing here, we can debate why another
time, and yes, I do think we sinned in just this manner in the
past.)

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 (whether from the US or otherwise) that could be a
significant impediment to Internet-scale interop.

I therefore think that this document needs to clearly make the
point that these suite-b related RFCs were never standards, that
that was the correct situation, and that'd it'd be a bad plan
for us to ever standardise or "bless" such national algorithm
suites. (Even better if we admitted it was a bad plan to do all
those suite-b RFCs in a way that was easily confusable with
standards, but I'm not sure we'd get rough consensus on this
last point.)

Put more concretely, I disagree with section 5 of the document.

As-is, I read the document as giving the impression that US
security related standards are treated differently by the IETF,
something that probably was understandably true in the past,
but that may be more and more used as a precedent by other
governments in future who would like to see special treatment
of their chosen national cipher suites in our standards. And
just a few of those could significantly damage interop, if
any of those governments move to require use of locally
chosen suites.

Cheers,
S.

-- 
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


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

  Powered by Linux