[146826] in cryptography@c2.net mail archive
Re: [Cryptography] Suite B after today's news
daemon@ATHENA.MIT.EDU (Ralph Holz)
Sun Sep 8 13:26:18 2013
X-Original-To: cryptography@metzdowd.com
Date: Sun, 08 Sep 2013 13:17:47 +0200
From: Ralph Holz <ralph-cryptometzger@ralphholz.de>
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>, cryptography@metzdowd.com
In-Reply-To: <E1VIcUh-0004u2-7l@login01.fos.auckland.ac.nz>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
Hi,
>> BTW, I do not really agree with your argument it should be done via TLS
>> extension.
>
> It's done that way based on discussions on (and mostly off) the TLS list by
> various implementers, that was the one that caused the least dissent.
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?
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.
It really boils down to this: how fast do we want to have it? I spoke to
one of the TACK devs a little while ago, and he told me they'd go for
the IETF, too, but their focus was really on getting the code out and
see an effect before that. The same seems to be true for CT - judging by
their commit frequency in the past weeks, they have similar goals.
I don't think it hurts to let users and operators vote with their feet here.
Ralph
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
