Bug#464625: please support OpenSSL-compatible ciphher nammes

[brian m. carlson]

On Fri, Feb 04, 2011 at 12:15:14PM +0100, Nikos Mavrogiannopoulos wrote:
> This is quite nice, but you should understand that not all people are like
> you. GnuTLS has to be usable by a variety of people with different backgrounds.
> What we do is to offer simple options for everyone and more advanced ones
> for everyone else.

I'm happy for you to provide simple choices for people that don't know
any better and don't need to.  I just want the full ability to specify
the nitty-gritty details.

> > In fact, I happen to know that the documentation for GnuTLS is wrong
> > when it claims that "[t]here are no known weaknesses of" MD2.  Such
> 
> You are right. We do not claim to be authorities. More mistakes might
> be possibly existing in the documentation. It is a collaborate effort, so
> we would appreciate if you report them.
> 
> > (AFAICT) GnuTLS has existed.  And that's to say nothing about it being
> > dog-slow (14 times slower than SHA-256).
> 
> We don't support MD2 in gnutls. It is not even implemented in libgcrypt.

lakeview ok % gnutls-cli -l |grep MD2
MACs: SHA1, MD5, SHA256, SHA384, SHA512, MD2, RIPEMD160, MAC-NULL
PK-signatures: RSA-SHA1, RSA-SHA256, RSA-SHA384, RSA-SHA512, RSA-RMD160, DSA-SHA1, RSA-MD5, RSA-MD2


> > The GnuTLS priorities (which I am not
> > proposing removing, only adding to) are defined only very vaguely in
> > gnutls-cli(1).
> 
> They are described in the function gnutls_priority_init() at:
> http://www.gnu.org/software/gnutls/manual/html_node/Core-functions.html#Core-functions
> If it is about documentation, you can suggest what is not clear to
> you, or what you think it is missing and we can improve the documentation.

They're specified almost identically in that documentation compared to
gnutls-cli.  You have failed to specify what a "secure" ciphersuite is.
Does it include RC4?  Does it include AES?  Does it include CAMELLIA?
Does it include ciphersuites that use MD5 other than in conjunction with
SHA-1?  Does it include ciphersuites using anonymous Diffie-Hellman?
Does it include Fortezza?

Obviously you see where I'm coming from here.  By reading the
documentation, I need to be able to know exactly which ciphersuites are
being used and in what order.

> > Not  Looking at the source, RC4 is defined in SECURE256, and
> > due to major weaknesses in its key scheduling (which can be used very
> > effectively against e.g. WEP), I would absolutely not want to use it if
> > any other choice were available.
> 
> The known attacks on RC4 are not effective against the TLS' usage of
> RC4. Having said that, you might be right that it might not deserve to be
> on the secure set.

The attacks may not be useful against TLS's usage, but the fact that
there's a 37% chance the first byte of the keystream is 1 and a 12%
chance that the second is 3 is a significant weakness.  Encrypted data
should be statistically indistinguishable from random data.

> The gnutls syntax allows that as well. Just add it after the other
> ciphers. However
> you shouldn't rely on that since the client is the one that is
> actually setting the
> priority order.

If you already implement the features I'm requesting, then you should
probably close this bug report.  If not, what parts of the OpenSSL
syntax do you support?  What parts don't you support?

Also, while it is customary to use the first choice of the client that's
available, I can't see where in the specification that's required.  In
fact, some server (e.g. Facebook) choose differently for performance
reasons.

> > I think it's reasonable to allow OpenSSL-compatible ciphersuite names.
> > In fact, I think it's a really good idea.  I would even implement it
> > myself,
> We are open to suggestions that will make the priority strings better. We
> could even add such compatibility if you contribute it (in a way that
> doesn't replace the existing strings of course).

I don't care about replacing the existing strings unless they in some
way conflict with the OpenSSL strings, in which case something will need
to be worked out.  Perhaps a different interface might be useful in that
case.

> > but I refuse to assign copyright[0], and I'm not going to waste
> > time writing code that will be thrown away.  Nevertheless, I strongly
> > urge you to support the OpenSSL syntax.
> > [0] This is a blanket policy unless we've executed a consulting contract
> > that says otherwise.  I think that when I make a contribution to a
> > project that it's only fair to be attributed as the author of my work;
> > my copyright notice ensures that I get credit for the work I've done.
> 
> I can live with that, eventhough in gnutls we acknowlege all authors with the
> "author" field on every file. The copyright transfer is for FSF and ensures an
> easier case if legal issues occur.

I understand what the FSF's rationale is for them wanting a copyright
assignment.  I don't agree.  It's also perfectly legal for someone to
remove the "Author" field on the file; it's not to remove a copyright
notice.  My full rationale is at
<http://bk2204.tumblr.com/post/3094203883/why-i-dont-assign-copyright>.

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-gnutls-maint/attachments/20110204/0c886df2/attachment.pgp>