Subject: Re: [saag] Discuss at SAAG? was Re: nation state crypto profiles - draft-jenkins-cnsa-cmc-profile-00

From: "Salz, Rich" <[email-masked]>
Date: Tue, 2 Oct 2018 20:22:04 +0000

*   (e.g. TLS ciphersuites identifiers) to use them for national-wide purposes
  *   along with "first class" algorithms.

TLS has moved to “doc required”  Not “RFC required.”  And added a column that says whether it is “recommended” or “no comment.”  This seems like it will work out well.

---

From: Paul Wouters <[email-masked]>
Date: Tue, 2 Oct 2018 17:36:22 -0400 (EDT)

> TLS has moved to “doc required”  Not “RFC required.”  And added a column that says whether it is “recommended” or “no comment.”  This seems like it will work out well.

Similarly, for IKE/IPsec, the IANA registries are Expert Review, not "RFC required"

Paul

---

From: Yoav Nir <[email-masked]>
Date: Wed, 3 Oct 2018 01:02:55 +0300

> On 3 Oct 2018, at 0:36, Paul Wouters <[email-masked]> wrote:
> 
> Similarly, for IKE/IPsec, the IANA registries are Expert Review, not "RFC required”

Right. So if SAAG (or the IESG) can guide the designated experts about national crypto, that would be great.

Suppose (and this is just an example) the Russian government would like to use TLS 1.3 with the Kuznyechik cipher. This is assuming that it has an AEAD mode defined, so it can be used. They have several options:
They can publish a document on gostperevod.com <http://gostperevod.com/> and ask IANA to register the Kuznyechik AEAD in the TLS registries.
They can publish a draft (in addition to #1) and then ask IANA to register the Kuznyechik AEAD in the TLS registry while asking the RFC editor to publish.
The can publish on gostperevod.com <http://gostperevod.com/> and tell everyone to squat on (0x13, 0x79)

I think we can all agree that #3 is a bad outcome, but that is what they will do if IANA won’t allocate identifiers.

IMO #1 is good enough, provided we can get guidance from SAAG or the IESG to recommend such registration.

It should be noted that a line should be drawn somewhere. I think a nation state with serious cryptographers such as Russia should get a code point for its national crypto.  I think someone who has come up with a great new algorithm that he totally cannot break should not get a code point. Somewhere between these two extremes the line should be drawn. The question is where?

Yoav

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 2 Oct 2018 17:07:20 -0500

> It should be noted that a line should be drawn somewhere. I think a nation state with serious cryptographers such as Russia should get a code point for its national crypto.  I think someone who has…

That's a question for the corresponding registry's Designated Experts,
presumably.  RFC 8447 gives guidance to the experts (for the ciphersuite
registry):

   Note:  The role of the designated expert is described in RFC 8447.
      The designated expert [RFC8126] ensures that the specification is
      publicly available.  It is sufficient to have an Internet-Draft
      (that is posted and never published as an RFC) or a document from
      another standards body, industry consortium, university site, etc.
      The expert may provide more in-depth reviews, but their approval
      should not be taken as an endorsement of the cipher suite.

which seems to push the Experts towards being pretty generous about
approving codepoint requests.  I would be surprised if #1 above was
controversial (but, to be clear, would welcome a conversation with the
experts if needed; I'm not trying to force anyone's hand).

-Ben

---

From: Yoav Nir <[email-masked]>
Date: Wed, 3 Oct 2018 01:30:23 +0300

> On 3 Oct 2018, at 1:07, Benjamin Kaduk <[email-masked]> wrote:
> 
>> They can publish a document on gostperevod.com <http://gostperevod.com/> <http://gostperevod.com/ <http://gostperevod.com/>> and ask IANA to register the Kuznyechik AEAD in the TLS registries.
>> The can publish on gostperevod.com <http://gostperevod.com/> <http://gostperevod.com/ <http://gostperevod.com/>> and tell everyone to squat on (0x13, 0x79)
>> 

Right. Which is why I’m asking.

> controversial

As soon as it’s about national (or “vanity”) crypto, it becomes controversial. Even if it isn’t, I’d like people’s opinions as to where to draw the line.

> (but, to be clear, would welcome a conversation with the

---

From: Jim Schaad <[email-masked]>
Date: Tue, 2 Oct 2018 17:06:14 -0700

From: saag <[email-masked]> On Behalf Of Yoav Nir
Sent: Tuesday, October 2, 2018 3:03 PM
To: Paul Wouters <[email-masked]>
Cc: Security Area Advisory Group <[email-masked]>
Subject: Re: [saag] Discuss at SAAG? was Re: nation state crypto profiles - draft-jenkins-cnsa-cmc-profile-00

On 3 Oct 2018, at 0:36, Paul Wouters <[email-masked] <mailto:[email-masked]> > wrote:

1.	They can publish a document on gostperevod.com <http://gostperevod.com>  and ask IANA to register the Kuznyechik AEAD in the TLS registries.
2.	They can publish a draft (in addition to #1) and then ask IANA to register the Kuznyechik AEAD in the TLS registry while asking the RFC editor to publish.
3.	The can publish on gostperevod.com <http://gostperevod.com>  and tell everyone to squat on (0x13, 0x79)

One of the other issues that can arise from doing #1 and not doing #2 is that the version on #1 may not be in a widely understood language whereas the version that would get published as a draft (or RFC) would be in English.

Jim

Yoav

---

From: Yoav Nir <[email-masked]>
Date: Wed, 3 Oct 2018 07:16:26 +0300

On 3 Oct 2018, at 3:06, Jim Schaad <[email-masked]> wrote:

From: saag <[email-masked] <mailto:[email-masked]>> On Behalf Of Yoav Nir
Sent: Tuesday, October 2, 2018 3:03 PM
To: Paul Wouters <[email-masked] <mailto:[email-masked]>>
Cc: Security Area Advisory Group <[email-masked] <mailto:[email-masked]>>
Subject: Re: [saag] Discuss at SAAG? was Re: nation state crypto profiles - draft-jenkins-cnsa-cmc-profile-00

> On 3 Oct 2018, at 0:36, Paul Wouters <[email-masked] <mailto:[email-masked]>> wrote:
>  

They still need to ask IANA for an assignment, and IANA would refer it to the designated experts. Those designated experts (Rich, Nick, and I for TLS) can enforce that the document is available in English. In fact, without requiring this, they could slip a chapter of War and Peace by us and it would get an IANA code point. 

It’s not like getting a document past the ISE makes it well-reviewed. How much review did RFC 7801 get?  It’s in English and technical looking. We can enforce that.

Yoav

---

From: Jim Schaad <[email-masked]>
Date: Tue, 2 Oct 2018 22:04:27 -0700

From: Yoav Nir <[email-masked]> 
Sent: Tuesday, October 2, 2018 9:16 PM
To: Jim Schaad <[email-masked]>
Cc: Paul Wouters <[email-masked]>; Security Area Advisory Group <[email-masked]>
Subject: Re: [saag] Discuss at SAAG? was Re: nation state crypto profiles - draft-jenkins-cnsa-cmc-profile-00

On 3 Oct 2018, at 3:06, Jim Schaad <[email-masked] <mailto:[email-masked]> > wrote:

From: saag < <mailto:[email-masked]> [email-masked]> On Behalf Of Yoav Nir
Sent: Tuesday, October 2, 2018 3:03 PM
To: Paul Wouters < <mailto:[email-masked]> [email-masked]>
Cc: Security Area Advisory Group < <mailto:[email-masked]> [email-masked]>
Subject: Re: [saag] Discuss at SAAG? was Re: nation state crypto profiles - draft-jenkins-cnsa-cmc-profile-00

On 3 Oct 2018, at 0:36, Paul Wouters < <mailto:[email-masked]> [email-masked]> wrote:

1.	They can publish a document on  <http://gostperevod.com/> gostperevod.com and ask IANA to register the Kuznyechik AEAD in the TLS registries.
2.	They can publish a draft (in addition to #1) and then ask IANA to register the Kuznyechik AEAD in the TLS registry while asking the RFC editor to publish.
3.	The can publish on  <http://gostperevod.com/> gostperevod.com and tell everyone to squat on (0x13, 0x79)

And it was implemented, the test vectors checked and a rough check was done that the supplied Russian version matched the English version.  That’s more that I would normally expect from a designated expert

jim

Yoav

---

From: Michael Richardson <[email-masked]>
Date: Wed, 03 Oct 2018 09:31:04 -0400

Yoav Nir <[email-masked]> wrote:
    > They still need to ask IANA for an assignment, and IANA would refer it
    > to the designated experts. Those designated experts (Rich, Nick, and I
    > for TLS) can enforce that the document is available in English. In

Why would you insist on this?
If the community wanted Specification Required, wouldn't we have said that,
rather than Expert Review?

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 3 Oct 2018 15:45:09 +0000

Because it is the view of the current set of experts, at least, that a specification needs to be available.

---

From: Paul Wouters <[email-masked]>
Date: Wed, 3 Oct 2018 13:01:53 -0400 (EDT)

> Because it is the view of the current set of experts, at least, that a specification needs to be available.

Is there a way to say 'specification required and expert review' ?

This is not the same as 'RFC required' because it could be a non-IETF
crypto algorithm specified elsewhere in a national publication.

Note that this is a little off-topic. I am fine (up to a point) for
assigning code points to national algorithms as long as we have
code points. It is the "recommendations" for "suites" that I have
a problem with. I do not want the IETF to recommend any crypto
other than via CFRG.

Paul

---

From: Yoav Nir <[email-masked]>
Date: Wed, 3 Oct 2018 20:33:51 +0300

> On 3 Oct 2018, at 20:01, Paul Wouters <[email-masked]> wrote:
> 

Yes. You say “Specification Required”:  https://tools.ietf.org/html/rfc8126#section-4.6 <https://tools.ietf.org/html/rfc8126#section-4.6>

4.6 <https://tools.ietf.org/html/rfc8126#section-4.6>.  Specification Required

   For the Specification Required policy, review and approval by a
   designated expert (see Section 5 <https://tools.ietf.org/html/rfc8126#section-5>) is required, and the values and
   their meanings must be documented in a permanent and readily
   available public specification, in sufficient detail so that
   interoperability between independent implementations is possible.
   This policy is the same as Expert Review, with the additional
   requirement of a formal public specification.  In addition to the
   normal review of such a request, the designated expert will review
   the public specification and evaluate whether it is sufficiently
   stable and permanent, and sufficiently clear and technically sound to
   allow interoperable implementations.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 03 Oct 2018 16:45:14 -0400

> Is there a way to say 'specification required and expert review' ?

Yes, it's Specification Required.
(Expert Review is implied.  Just went through this in CELLAR)

    > crypto algorithm specified elsewhere in a national publication.

Yes.

    > assigning code points to national algorithms as long as we have code
    > points. It is the "recommendations" for "suites" that I have a problem
    > with. I do not want the IETF to recommend any crypto other than via
    > CFRG.

in most cases, we have at least 32-bit number spaces, or it's strings,
so I just see a reason to be stingy.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 3 Oct 2018 21:44:29 -0700

On Tue, Oct 2, 2018 at 3:07 PM Benjamin Kaduk <[email-masked]> wrote:

> > >> TLS has moved to “doc required”  Not “RFC required.”  And added a
> column that says whether it is “recommended” or “no comment.”  This seems
> like it will work out well.
> > >
> > Suppose (and this is just an example) the Russian government would like
> to use TLS 1.3 with the Kuznyechik cipher. This is assuming that it has an
> AEAD mode defined, so it can be used. They have several options:
> > They can publish a document on gostperevod.com <http://gostperevod.com/>
> and ask IANA to register the Kuznyechik AEAD in the TLS registries.
> > They can publish a draft (in addition to #1) and then ask IANA to
> register the Kuznyechik AEAD in the TLS registry while asking the RFC
> editor to publish.
> > I think we can all agree that #3 is a bad outcome, but that is what they
> will do if IANA won’t allocate identifiers.
> >
> > It should be noted that a line should be drawn somewhere. I think a
> nation state with serious cryptographers such as Russia should get a code
> point for its national crypto.  I think someone who has come up with a
> great new algorithm that he totally cannot break should not get a code
> point. Somewhere between these two extremes the line should be drawn. The
> question is where?
>

Speaking as an individual, not AD.

My understanding of the intent of the current rules for TLS was to grant
code points as long as there was a document describing the cipher suite,
even if the DEs thought the algorithms were silly or potentially insecure.

The reasoning here was that having code points marked Not Recommended was
better than having people squatting.

-Ekr

> -Ben
>
> _______________________________________________
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag
>

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 3 Oct 2018 21:46:24 -0700

At least part of the discussion around SR versus ER was about the validity
of I-Ds. Specifically, we wanted I-Ds to be a valid form of documentation
and there was some disagreement about whether they were for the purposes of
Specification Required. ER allowed us to specify that threshold clearly.

-Ekr

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 4 Oct 2018 08:38:17 -0400

Sent from my mobile device

> On Oct 4, 2018, at 12:44 AM, Eric Rescorla <[email-masked]> wrote:
> 
> 
> 
> My understanding of the intent of the current rules for TLS was to grant code points as long as there was a document describing the cipher suite, even if the DEs thought the algorithms were silly or potentially insecure.
> 
> The reasoning here was that having code points marked Not Recommended was better than having people squatting.

Agreed.  There was consensus on this choice as well in the TLS WG.

Kathleen

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 4 Oct 2018 14:49:02 +0000

*   The reasoning here was that having code points marked Not Recommended was better than having people squatting.

They’re actually “no comment” as opposed to Not Recommended.  The only way something gets to be recommended is if it’s a WG document.  This is, admittedly, a fine point and could well be lost on many, but it’s important.

---

From: Sean Turner <[email-masked]>
Date: Thu, 4 Oct 2018 10:53:20 -0400

> On Oct 4, 2018, at 10:49, Salz, Rich <[email-masked]> wrote:
> 
> 	• The reasoning here was that having code points marked Not Recommended was better than having people squatting.
>  

Agreed that it will be lost on most, but I think it kind of makes sense.  The interesting flip side here is that there are going to be some perfectly good algorithms are not marked as Recommended.

spt

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 4 Oct 2018 08:05:14 -0700

On Thu, Oct 4, 2018 at 7:49 AM Salz, Rich <[email-masked]> wrote:

>
>    - The reasoning here was that having code points marked Not
>    Recommended was better than having people squatting.
>
>
>
> They’re actually “no comment” as opposed to Not Recommended.
>

Well, it might be useful to go back to the text here:

   Per this document, a "Recommended" column has been added to many of
   the TLS registries to indicate parameters that are generally
   recommended for implementations to support.  Adding a "Recommended"
   parameter (i.e., "Y") to a registry or updating a parameter to
   "Recommended" status requires Standards Action.  Not all parameters
   defined in Standards Track documents need to be marked as
   "Recommended".

   If an item is not marked as "Recommended" (i.e., "N"), it does not
   necessarily mean that it is flawed; rather, it indicates that the
   item either has not been through the IETF consensus process, has
   limited applicability, or is intended only for specific use cases.

Perhaps the most appropriate thing would be to characterize the "N"
marking as "it is not a 'Recommended code point'".

The only way something gets to be recommended is if it’s a WG document.

To be more precise, in IETF 8447, it's Standards Action, which might or
might not be a WG document.

-Ekr

> This is, admittedly, a fine point and could well be lost on many, but it’s
> important.
>

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 4 Oct 2018 15:07:33 +0000

Ø  Perhaps the most appropriate thing would be to characterize the "N" marking as "it is not a 'Recommended code point'".

Yes.  I’d prefer “-“ instead of “N” but NBD.

---

From: Nico Williams <[email-masked]>
Date: Thu, 4 Oct 2018 10:50:29 -0500

On Thu, Oct 04, 2018 at 10:53:20AM -0400, Sean Turner wrote:
> > 	• The reasoning here was that having code points marked Not
> > They’re actually “no comment” as opposed to Not Recommended.  The
> > only way something gets to be recommended is if it’s a WG document.
> > This is, admittedly, a fine point and could well be lost on many,
> > but it’s important.
> 
> Agreed that it will be lost on most, but I think it kind of makes
> sense.  The interesting flip side here is that there are going to be
> some perfectly good algorithms are not marked as Recommended.

That is just fine.  There's no reason we should want all "perfectly good
algorithms" to be, or even any other than those we already have as,
Recommended.

To go from "no comment" to Recommended, a "perfectly good algorithm"
would have to be more than perfectly good: the IETF would have to need
additional Recommended algorithms due to obsolescence of existing ones.

Nico
--

---

From: Sean Turner <[email-masked]>
Date: Thu, 4 Oct 2018 11:58:59 -0400

> On Oct 4, 2018, at 11:50, Nico Williams <[email-masked]> wrote:
> 

Exactly!

spt

---

From: Sean Turner <[email-masked]>
Date: Thu, 4 Oct 2018 12:04:22 -0400

> On Oct 4, 2018, at 11:07, Salz, Rich <[email-masked]> wrote:
> 

In hindsight, “-“ would have been a little less in your face.  But, one of the things we also wanted to deal with were complaints by implementors that some customers were combing through the IANA registries and requesting that everything be implemented.  IMHO an “N” works better there.

spt

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 4 Oct 2018 15:44:01 -0500

I think I may have lost track of the threading, but I'll note that for the
TLS registries, we do use Specification Required, with a note about what
constitutes a valid specification that explicitly allows I-Ds that are not
progressed any further.

-Ben