Re: [Cfrg] RFC 5742 conflict review for draft-dolmatov-kuznyechik

[Stephen Farrell <[e-mail]>]

Hiya,

On 02/02/16 09:40, Dmitry Belyavsky wrote:
> Dear Stephen,
> 
> On Mon, Feb 1, 2016 at 7:33 PM, Stephen Farrell <[e-mail]>
> wrote:
> 
>>
>> Hi Simon,
>>
>> On the higher level, I agree with those who think this is
>> not a 5742 conflict, but I'll point the rest of the IESG
>> at this thread so they can read about it themselves.
>>
>> On 01/02/16 16:27, Simon Josefsson wrote:
>>>
>>> Yes.  I think Camellia is a good example here.  I recall seeing
>>> implementations that preferred Camellia over AES when both were
>>> available, which I suspect was due to misunderstanding or mistake.  The
>>> document can inform the reader about some aspects, but sometimes having
>>> too much rope available causes bad things to happen.
>>
>> I agree that that happened and was undesirable, but I think
>> that the mistake then was in the TLS code point allocation.
>> We (the IETF) should've made sure that the registry or the
>> specification that created the code points clarified things
>> for implementers. With TLS1.3, I think the TLS WG have
>> decided to structure the IANA registries so this'll end up
>> better. I forget if that'd also mean re-structuring the
>> registries for earlier TLS versions or not, but in any case
>> the issue is one for the TLS WG (or IPSECME or whoever) and
>> not something that the ISE ought handle in the basic spec
>> describing the algorithm details.
>>
> 
> I am not sure that it's a good idea to avoid code point allocation.

I did not make any argument to avoid codepoint allocations for
national or vanity algorithms. (To be honest, I would personally
prefer that, but it's not achievable, so I don't argue for it.)

I reported that the TLS WG have agreed to clarify which code points
correspond to algorithms that the IETF prefer/recommend and which
do not. National and vanity algorithms will be part (but not all) of the
latter set, except where a national algorithm (like AES) is broadly
accepted as being desirable. Perhaps some day a GOST algorithm will be
in the former set, but for now I don't think any are.

> As nation-wide regulation requires using nation-specific algorithms,

Yes. Those are IMO a bad idea, but a sad reality that we do need
to handle. (To provide just one reason why they are a bad idea,
many more devices and people now are mobile and do cross national
borders, assuming such details of their Internet connectivity can
be "national" seems to me to not recognise reality.)

> there will appear specifications for using these algorithms with TLS etc.
> 
> The best solution I can imagine for the real world is allocating code
> points
> for nation-wide algorithms together with providing comments for the
> implementers,
> that the corresponding algorithm/ciphersuite/etc is nation-specific and not
> mandatory.

Yes, that is part of what I think the TLS WG have agreed. The tricky
part IMO is to get the pejorative terms correct:-) Note though that
some algorithms might be outside the preferred set because they are
considered a backup or hedge against analysis, e.g. perhaps TLS
codepoints for curve448 will be handled that way. So not everything
outside the preferred set will be national/vanity/undesirable.

Anyway if you are interested in that, the TLS WG mailing list is the
right venue for discussion of TLS registration schemes and codepoints.
If you want to discuss the topic of national algorithms in the IETF
independent of a particular protocol, then the saag list is the right
venue.

Cheers,
S.


> 
>