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

Sent from my mobile device

> On Oct 4, 2018, at 12:44 AM, Eric Rescorla <ekr@rtfm.com> wrote:
> 
> 
> 
>> On Tue, Oct 2, 2018 at 3:07 PM Benjamin Kaduk <kaduk@mit.edu> wrote:
>> On Wed, Oct 03, 2018 at 01:02:55AM +0300, Yoav Nir wrote:
>> > 
>> > 
>> > > On 3 Oct 2018, at 0:36, Paul Wouters <paul@nohats.ca> wrote:
>> > > 
>> > > On Tue, 2 Oct 2018, Salz, Rich wrote:
>> > > 
>> > >> *  (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.
>> > > 
>> > > 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?
>> 
>> 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).
> 
> 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.

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

Kathleen 

> 
> -Ekr
> 
>> 
>> -Ben
>> 
>> _______________________________________________
>> saag mailing list
>> saag@ietf.org
>> https://www.ietf.org/mailman/listinfo/saag
> _______________________________________________
> saag mailing list
> saag@ietf.org
> https://www.ietf.org/mailman/listinfo/saag