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

From: Paul Hoffman <[email-masked]>
Date: Tue, 20 Feb 2018 21:45:29 +0000

This document seems fine in general. I have concern about a possible misperception that one document that is made historic by it (RFC 6460) could affect the standards status of two documents that refer to it, namely RFC 6650 and RFC 8253. To prevent the misperception, I propose the following additions in Section 4.5:

   RFC 6605, "Elliptic Curve Digital Signature Algorithm (DSA) for
   DNSSEC" [RFC6605], states that material was copied liberally from RFC
   6460.
becomes
   RFC 6605, "Elliptic Curve Digital Signature Algorithm (DSA) for
   DNSSEC" [RFC6605], states that material was copied liberally from RFC
   6460. The standards status of RFC 6605 is not affected by RFC 6460
   being moved to Historic status.

   RFC 8253, "PCEPS: Usage of TLS to Provide a Secure Transport for the
   Path Computation Element Communication Protocol (PCEP)" [RFC8253],
   points RFC 6460 for the TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 and
   TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 cipher suites.  Both of these
   ciphersuites are defined in [RFC5289], which would have been a better
   reference.
becomes
   RFC 8253, "PCEPS: Usage of TLS to Provide a Secure Transport for the
   Path Computation Element Communication Protocol (PCEP)" [RFC8253],
   points RFC 6460 for the TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 and
   TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 cipher suites.  Both of these
   ciphersuites are defined in [RFC5289], which would have been a better
   reference. Regardless, the standards status of RFC 8253 is not
   affected by RFC 6460 being moved to Historic status.

--Paul Hoffman

---

From: Russ Housley <[email-masked]>
Date: Wed, 21 Feb 2018 16:34:53 -0500

Paul:

I just posted draft-housley-suite-b-to-historic-04, which add two sentences to state that the standards-track status of RFC 6605 and RFC 8253 are unchanged.

Russ

> On Feb 20, 2018, at 4:45 PM, Paul Hoffman <[email-masked]> wrote:
>

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 21 Feb 2018 21:40:17 +0000

> I just posted draft-housley-suite-b-to-historic-04, which add two sentences to state that the standards-track status of RFC 6605 and RFC 8253 are unchanged.

Thanks, that clears my issues.

--Paul Hoffman

---

From: Paul Wouters <[email-masked]>
Date: Wed, 21 Feb 2018 17:34:52 -0500 (EST)

> I just posted draft-housley-suite-b-to-historic-04, which add two sentences to state that the standards-track status of RFC 6605 and RFC 8253 are unchanged.

I'm fine with the document, although it is a little confusing to have
something as Historic, while the technology described in it is not
historic in the sense of:

https://www.ietf.org/iesg/statement/designating-rfcs-as-historic.html

 	A document is labelled Historic when what it describes is no longer
 	considered current: no longer recommended for use.

Since suite B is AES_GCM and AES_GMAC they are both current and still
recommended for use. I wonder if that could be more clearly indicated.
Something along the lines of "While some algorithms in Suite B are still
recommend for use within the IETF and its related industries, the term
"Suite B" for a collection of these has been obsoleted"

I guess "Suites" or "profiles" from certain goverments or organisations
really do not belong in an IETF RFC. For that reason, I wonder if the
following paragraph should be cut:

    In July 2015, NSA published the Committee for National Security
    Systems Advisory Memorandum 02-15 as the first step in replacing
    Suite B with NSA's Commercial National Security Algorithm (CNSA)
    Suite.  Information about the CNSA Suite can be found in [CNSA].

While I agree it is helpful to point them to the successor of Suite B,
it sets up the scenario for a new RFC with the finalised successor of
Suite B. I'd rather leave that to the publications of governments and
other industries.

Now some nits unrelated to this document but triggered by it:

Another example of our bug in the tools site missing updating links:

https://tools.ietf.org/html/draft-housley-suite-b-to-historic-03

This does not show there is a version -04, even though there is. I
really hope our tools team can find the time to work on this
repeatedly occuring bug, and go through the existing site to find
them all and fix their references. Its not just a brief time period
from publishing either, as the 01 version doesn't indicate that there
is -02 -03 or -04 now and -01 was published 20 days ago.

And amusingly, I cannot visit:

https://www.iad.gov/iad/programs/iad-initiatives/cnsa-suite.cfm

without an error:

 	www.iad.gov uses an invalid security certificate. The certificate is not
 	trusted because the issuer certificate is unknown.

It seems my browsers does not trust "DOD ID SW CA-37" (neither firefox
with the system CA store, nor google-chrome with its builtin CA store)

Paul

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 22 Feb 2018 00:08:05 +0000

On 21/02/18 22:34, Paul Wouters wrote:
> 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;-)

---

From: Martin Thomson <[email-masked]>
Date: Thu, 22 Feb 2018 11:18:48 +1100

On Thu, Feb 22, 2018 at 11:08 AM, Stephen Farrell
<[email-masked]> wrote:
> 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.

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 22 Feb 2018 00:44:57 +0000

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

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 22 Feb 2018 01:10:10 +0000

Hiya,

On 22/02/18 00:44, Paul Hoffman wrote:
>> 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.
>

---

From: Martin Thomson <[email-masked]>
Date: Thu, 22 Feb 2018 12:31:30 +1100

On Thu, Feb 22, 2018 at 11:44 AM, Paul Hoffman <[email-masked]> 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.

---

From: Paul Wouters <[email-masked]>
Date: Wed, 21 Feb 2018 20:47:07 -0500 (EST)

On Thu, 22 Feb 2018, Paul Hoffman wrote:

> In what way is publishing Informational RFCs that specify country-specific cryptographic algorithms *not* considered to be good for interoperability?

Algorithms should be accepted based on their individual merits, not
based on their origin. So for example, I'm fine with a suite for IoT
algorithms, as those have specific requirements.

National requirements however, are not international standards, and are
often riddled with secrets. We should not codify that in RFCs

> 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? Wha…

They would have to show the merit of these from a technical point of
view. Not from an origin/inventor/vetted point of view.

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

I'm fine with IoT profiles, 3gpp/mobile profiles, cloud profiles.
interplanetary profiles.

> Disclaimer: I got paid to help with the Suite B specs in the IETF and was completely open about it while doing so.

At the time, that was a good thing. Thanks for improving the standards
of the time!

Paul

---

From: Russ Housley <[email-masked]>
Date: Thu, 22 Feb 2018 13:05:23 -0500

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/>).

Profiles are completely different.  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.

Russ

> On Feb 21, 2018, at 8:31 PM, Martin Thomson <[email-masked]> wrote:
>

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 22 Feb 2018 20:19:22 +0000

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.

>>> 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, [...]
>> 
>> 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.
>>