Subject: Re: [lamps] Request for review of revised RFC 5759

From: Stephen Farrell <[email-masked]>
Date: Tue, 6 Mar 2018 21:41:55 +0000

Hiya,

I commented on making the suite-b profiles historic on the IETF
discuss list. (Probably better to keep that discussion on that
list and not here - thread is at [1], but briefly I suggested we
not do another suite-b-like exercise within the IETF.)

Russ asked me to take a peek at this draft as part of some
offlist discussion about that.

Generally the content of the draft seems reasonable. If it is the
case that the choices in this profile are widely implemented (and
I'm guessing they are), then I would support a profile with such
content being processed as a BCP (and hence coming under IETF change
control).

If there is a real need to retain change control and keep this as
a national profile, then see my opinion on [1], I'm not supportive
of that. (But in this case, as the content seems to not involve
any "innovative" or odd choices, and if done via the ISE, I'm only
very very mildly opposed - almost neutral:-)

I'd encourage the authors to consider if they need an RFC that is
not under IETF change control for this content. I can't see how
that'd be beneficial tbh but maybe I'm missing something. And if
the content had IETF consensus, then I'd guess that'd help in terms
of getting implementations that match the profile more quickly.

If there are other documents to come, that do make "innovative"
choices (e.g. algs or params that are not widely implemented),
then I think even a national profile for that published via the
ISE is a bad idea, (but again, discussion of that via [1] is
better).

Cheers,
S

[1] https://www.ietf.org/mail-archive/web/ietf/current/msg106634.html

On 31/01/18 20:59, Michael Jenkins wrote:
> The US National Security Agency (NSA) has begun the process of updating
> the "Suite B for..." RFCs to define requirements for implementing and
> configuring IETF protocols in compliance with the 2016 revision of
> CNSSP-15 (the Commercial National Security Algorithm, or CNSA, suite).
> These RFCs are intended for use by commercial product vendors who wish
> their products to be used in US National Security Systems, over which
> NSA has oversight.
> 
> As part of this process, the older RFCs will be moved to Historical
> status, and we plan to publish new RFCs via the ISE. We are seeking
> review and comment of the drafts prior to publication, and so will be
> announcing the drafts on appropriate mail-lists as we produce them.
> 
> The first draft updates RFC 5759, and addresses requirements for RFC
> 5280 compliant public-key certificates and CRLs that contain or
> reference algorithms in the CNSA suite. It is available at
> <https://www.ietf.org/internet-drafts/draft-jenkins-cnsa-cert-crl-profile-01.txt>.
> We would appreciate any comments you might have regarding the draft,
> either via the mail-list or via direct reply.
> 
> 
> Mike Jenkins <[email-masked]>
> Lydia Zieglar <[email-masked]>
> NSA
> 
> 
> 
> _______________________________________________
> Spasm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spasm
>

---

From: Richard Barnes <[email-masked]>
Date: Tue, 6 Mar 2018 16:48:53 -0500

On Feb 20, 2018 21:48, "Paul Hoffman" <[email-masked]> wrote:

On 31 Jan 2018, at 12:59, Michael Jenkins wrote:

The first draft updates RFC 5759, and addresses requirements for RFC 5280
> compliant public-key certificates and CRLs that contain or reference
> algorithms in the CNSA suite. It is available at <
> https://www.ietf.org/internet-drafts/draft-jenkins-cnsa-
> cert-crl-profile-01.txt>. We would appreciate any comments you might have
> regarding the draft, either via the mail-list or via direct reply.
>

This looks good on its face. However, I would argue that the reference
[CNSA] is a normative reference: one cannot evaluate whether the
requirements in the draft match the requirements in [CNSA] without reading
and understanding [CNSA].

A big issue, however, is that [CNSA] points to:
   https://www.iad.gov/iad/programs/iad-initiatives/cnsa-suite.cfm
I cannot read that document on any of my browsers because the certificate
used for TLS is invalid in current browsers, and attempting to switch to
the HTTP version redirects to the insecure HTTPS version.

I know that this is not something that the authors can fix on their own,
but I would strongly object to the IETF moving this document forwards as an
RFC with a normative reference that no one can read without making TLS
changes in their browsers.

Should we also stop accepting references that are only available over
"http://" URLs?

I might not object to that, but seems silly to do one of these things and
not the other.

--Richard

Lots of US federal agencies have HTTPS web sites that are readable by the
general public; this should be no different.

--Paul Hoffman

---

From: "Paul Hoffman" <[email-masked]>
Date: Tue, 06 Mar 2018 14:39:41 -0800

> Should we also stop accepting references that are only available over

No. Those URLs do not impede reading by developers.

> I might not object to that, but seems silly to do one of these things 

Why is it "silly" to object to a URL that I literally cannot read 
without reducing the security of my browser?

--Paul Hoffman

---

From: Richard Barnes <[email-masked]>
Date: Tue, 6 Mar 2018 18:02:48 -0500

On Mar 6, 2018 17:39, "Paul Hoffman" <[email-masked]> wrote:

> not the other.

Why is it "silly" to object to a URL that I literally cannot read without
reducing the security of my browser?

The reduction in security from allowing an unknown cert for a single site
(which is what your browser does; it doesn't wholesale add the CA without a
bunch more effort) is no more than the reduction in security from visiting
a non-HTTPS URL.  Arguably less.

--Richard

--Paul Hoffman

---

From: Michael Jenkins <[email-masked]>
Date: Wed, 7 Mar 2018 10:39:29 -0500

Update on this, such as it is:

As Paul says, access to CNSSP-15 without altering the local security 
configuration isn't in my power to fix directly. I am reliably informed 
that the DOD PKI is working on a solution (which might involve a new 
CABF guidelines compliant root). I'm also looking into having it posted 
somewhere authoritative but without side-effects.

In the (could be ample) meantime, the best I can do is post the document 
to the mail-list. So, you can find it attached to this email (and, by 
extension, so can anyone who can access the spasm mail archive).

I hope this meets the near-term need.

Mike

On 02/20/2018 09:48 PM, Paul Hoffman wrote:
> requirements in the draft match the requirements in [CNSA] without 
> reading and understanding [CNSA].
>
> I cannot read that document on any of my browsers because the 
> certificate used for TLS is invalid in current browsers, and 
> attempting to switch to the HTTP version redirects to the insecure 
> HTTPS version.
>
> I know that this is not something that the authors can fix on their 
> own, but I would strongly object to the IETF moving this document 
> forwards as an RFC with a normative reference that no one can read 
> without making TLS changes in their browsers. Lots of US federal 
> agencies have HTTPS web sites that are readable by the general public; 
> this should be no different.
>
> --Paul Hoffman
>

---

From: "Paul Hoffman" <[email-masked]>
Date: Thu, 08 Mar 2018 14:58:15 -0400

Humorously, you have now caused a better URL for that document to 
appear. Your message is archived at:
     https://mailarchive.ietf.org/arch/msg/spasm/e6Lprn5oXI4bFdP4SYAUhksMIh4
The attachment itself is at:
     https://mailarchive.ietf.org/arch/attach/spasm/pdf2BY7gK.pdf

According to the design of the mail archive, you should be able to use 
either of those URLs forever.

--Paul Hoffman

---

From: Michael Jenkins <[email-masked]>
Date: Fri, 9 Mar 2018 09:33:16 -0500

Hi Stephen,

> I'd encourage the authors to consider if they need an RFC that is not under IETF change control for this content. 

Thanks for taking the time to look at the draft and comment. I wanted to 
respond that we certainly are considering the benefits and costs of 
publishing this information, and which mechanisms for publication might 
be more or less appropriate. Your input (and Martin's, Paul W's, and 
Paul H's) plays a significant role in that discussion.

Mike