[Cryptography] From Nicaragua to Snowden - why no national standards should be considered in cryptosec

[Stephen Farrell]

On 27/02/16 10:37, Dmitry Belyavsky wrote:
> Dear Donald,
> 
> On Sat, Feb 27, 2016 at 6:49 AM, Donald Eastlake <d3e3e3 at gmail.com> wrote:
> 
>> On Fri, Feb 26, 2016 at 9:18 PM, Stephen Farrell
>> <stephen.farrell at cs.tcd.ie> wrote:
>>>
>>> ...
>>>
>>> I think likely the best we can do is to annotate cipher code points
>>> (e.g. in IANA registries) as being "desirable" or "other" and to
>>> discourage everyone from implementing "other." If we can come up
>>> with an acceptable but disparaging term for "other" that'd be great
>>> ("crap" has been suggested but might not be effective).
>>
>> What's wrong with the typical standards term "deprecated"?
>>
>>
> They are NOT deprecated (at least, some of them). 

Right.

> For example, in Russia
> we have 4 algorithms of a digital signature, 2 of them are definitely
> deprecated
> but 2 others are required to be implemented. So smth like "National" (may
> be with
> mentioning the countries) will be ok and non-pejorative.

There's that. But "national" is also no good as a label, as
AES is national and some national algs are less well vetted/known
than others.

And there's also the set of algs that we think are ok, but are
not yet needed, e.g. codepoints associated with Curve448 might
not be needed right now, but might move to "good" status later.

Deprecated also doesn't quite seem right for e.g. integer DH
where we might want to prefer ECDH even though integer DH is
still fine with sufficient length primes.

And then (for TLS) there's stuff like SRP where almost nobody
cares and we might not want that code in general libraries so
maybe that's also better not in the "good" category too.

Deprecated does match stuff like RC4 quite well of course.

Anyway, in the IETF the TLS WG have agreed to try to figure this
out for TLS ciphersuites. They've not started that work yet, as
they're busy with TLS1.3 but the bikeshedding will happen there
in the not too distant future.

Cheers,
S.

> 
> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3840 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20160227/c1678a57/attachment.bin>