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

From: Paul Wouters <[email-masked]>
Date: Tue, 2 Oct 2018 10:57:29 -0400 (EDT)

I think this group is a better discussion place for this item.

Can we add this to the agenda for Bangkok to discuss?

Paul

---------- Forwarded message ----------
Date: Fri, 28 Sep 2018 15:40:46
From: Paul Wouters <[email-masked]>
Cc: IETF <[email-masked]>
To: Russ Housley <[email-masked]>
Subject: Re: nation state crypto profiles - draft-jenkins-cnsa-cmc-profile-00

On Fri, 28 Sep 2018, Russ Housley wrote:

> That thread came to the conclusion that the IETF should not process profiles
> for any nations states.   In my opinion, there is value in making it easy for
> implementers to find such profiles.  So, if the Independent Stream Editor is
> willing to process such profiles, they can be published as RFCs, which would
> not consume any resources from the IETF leadership.

I do not agree the thread came to that conclusion. I see people
disagreed and stop the discussion, because everyone agreed the
draft in question to make Suite B historic was not disputed.

People outside the IETF do not understand the subtleties of different
IETF streams, and having an RFC is seen as a stamp of approval of
the international community. Therefore, I do indeed believe we should
not make the same mistake again.

The USG seems to be doing a fine job making FIPS publications available
without these being enshrined in RFCs.

I am against the IETF publishing CNSA or any other nation state
cryptography profiles.

Paul

---

From: Nalini J Elkins <[email-masked]>
Date: Tue, 2 Oct 2018 16:10:12 +0000 (UTC)

Paul,

I would support a discussion somewhere on this draft.  One thing that I see has to do with cryptoagility.

This is from the https://tools.ietf.org/html/draft-jenkins-cnsa-cmc-profile-00

> The purpose behind this flexibility is to avoid vendors and customers
> making two major transitions in a relatively short timeframe, as we
> anticipate a need to shift to quantum-resistant cryptography in the

> near future.

I am concerned that the flexibility in being able to change / shift crypto algorithms for many enterprise data centers is abysmally slow.

I had wanted to put together a draft in this area.  One of the folks who is very interested in quantum crypto was helping me.  It would be great to think of ways that we can do better.
 
Thanks,

Nalini Elkins
CEO and Founder
Inside Products, Inc.
www.insidethestack.com
(831) 659-8360

________________________________
From: Paul Wouters <[email-masked]>
To: [email-masked] 
Sent: Tuesday, October 2, 2018 7:57 AM
Subject: [saag] Discuss at SAAG? was Re: nation state crypto profiles - draft-jenkins-cnsa-cmc-profile-00 (fwd)

Paul

---------- Forwarded message ----------

Cc: IETF <[email-masked]>

cryptography profiles.

Paul

_______________________________________________

saag mailing list

[email-masked]

https://www.ietf.org/mailman/listinfo/saag

---

From: Paul Wouters <[email-masked]>
Date: Tue, 2 Oct 2018 15:46:34 -0400 (EDT)

> I had wanted to put together a draft in this area.  One of the folks who is very interested in quantum crypto was helping me.  It would be great to think of ways that we can do better.

Unfortunately, it seems that standards and industry are moving away from
a full crypto negotiation (like IKE and to a lesser extend TLS) and try
to do this kind of agility in versioning only because it is deemed less
error prone. This comes as a result of the many downgrade attacks to
weak export level crypto algorithms were found.

But that is a separate discussion from the nation state discussion, but
could also be an interesting topic for SAAG.

Paul

---

From: Dmitry Belyavsky <[email-masked]>
Date: Tue, 2 Oct 2018 23:12:22 +0300

Dear Paul,

One of the problems causing an interest of publishing national standards
as RFCs is the necessity to be registered in various IANA registries
(e.g. TLS ciphersuites identifiers) to use them for national-wide purposes
along with "first class" algorithms.

I strongly support discussing this topic in Bangkok.

-- 
SY, Dmitry Belyavsky

---

From: Carl Wallace <[email-masked]>
Date: Tue, 02 Oct 2018 16:41:06 -0400

What's the difference between a nation state profile and a similar or same
profile that has been marshaled through a commercial entity?
What's the difference between a nation state profile and a profile from a
very large company? Is a market cap limit next?
Would elimination of all affiliation flatten the space in a good way or is
the current truth in packaging preferred?

---

From: Nico Williams <[email-masked]>
Date: Tue, 2 Oct 2018 16:15:39 -0500

> profile that has been marshaled through a commercial entity?

None, of course.

I don't object to having codepoint assignments for all sorts of
cryptographic algorithms from various nation states and even
corporations.

I also don't object to FYI publications of these, though presumably any
nation state or large corporation could setup their own SDOs, therefore
we perhaps should not lend then either the ISE's nor the IETF nor
RFC-Editor's resources -- we just can't really refuse IANA resources.

What we should want is for required-to-implement algorithms to be ones
we reasonably believe are secure, and we should pick those for reasons
other than national origin of said algorithms.  We should make these
decisions on a case-by-case basis, as we long have.

Nico
--

---

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

> the current truth in packaging preferred?

These are good questions for a SAAG discussion.

If we have an industry wide recommendation, I think that could qualify
for an IETF reviewed and published document. And I feel external entities
dictating algorithms or bypassing IETF review via the Independent Stream
Editor, should not be published by the IETF/ISE.

Some of this work for recommending algorithms is already done by the IETF,
for example see RFCa4307/ 8247 and RFC 7321/8221 and I think these kind
of usage documents are within the scope of the IETF. And I believe
recommendations by the relevant WGs such as IPsecME or TLS is where this
kind of work needs to happen, if the end result is the publication of an
RFC.

Paul

---

From: Michael Richardson <[email-masked]>
Date: Tue, 02 Oct 2018 19:29:44 -0400

Dmitry Belyavsky <[email-masked]> wrote:
    > One of the problems causing an interest of publishing national
    > standards as RFCs is the necessity to be registered in various IANA
    > registries (e.g. TLS ciphersuites identifiers) to use them for
    > national-wide purposes along with "first class" algorithms.

If I understand what you are saying, you said it backwards.

   I think you are saying that national standards feel that they must publish as
   RFCs in order to be able to acquire IANA numbers for protocols.

But, for IPsec, this certainly isn't true.

https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml
shows "Expert Review" for almost all values.

That's a pretty low bar.

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