[146885] in cryptography@c2.net mail archive

home help back first fref pref prev next nref lref last post

Re: [Cryptography] Suite B after today's news

daemon@ATHENA.MIT.EDU (Peter Gutmann)
Mon Sep 9 00:00:53 2013

X-Original-To: cryptography@metzdowd.com
Date: Mon, 09 Sep 2013 14:35:31 +1200
From: Peter Gutmann <pgut001@cs.auckland.ac.nz>
To: cryptography@metzdowd.com, pgut001@cs.auckland.ac.nz,
	ralph-cryptometzger@ralphholz.de
In-Reply-To: <522C5CDB.8040307@ralphholz.de>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com

Ralph Holz <ralph-cryptometzger@ralphholz.de> writes:

>I've followed that list for a while. What I find weird is that there should
>be much dissent at all. This is about increasing security based on adding
>quite well-understood mechanisms. What's to be so opposed to there?

There wasn't really much dissent (there was some discussion, both on and off-
list, which I've tried to address in updates of the draft), it's just that the
WG chairs don't seem to want to move on it.

>Does adding some ciphersuites really require an extension, maybe even on the
>Standards Track? I shouldn't think so, looking at the RFCs that already do
>this, e.g. RFC 5289 for AES-GCM. Just go for an Informational. FWIW, even
>HTTPS is Informational.

I've heard from implementers at Large Organisations that having it non-
standards-track makes it hard to get it adopted there.  I guess I could go for
Informational if all else fails.

>I don't think it hurts to let users and operators vote with their feet here.

That's what's already happened/happening, problem is that without an RFC to
nail down at least the extension ID it's a bit hard for commercial vendors to
commit to it.

Peter.
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

home help back first fref pref prev next nref lref last post