[gnutls-devel] overall sec_param (weakest link) for a gnutls session?

[peter williams]

Use an old idea.

Ssl handshake contains basic policy negotiation apparatus (lists of ciphersuite names).

Let x509 extensions convey lists of such names, too. Implement class based discovery, which directs selection of suite.

Do the unthinkable (ignore 25 years of stupid cypherpunks advice about hierarhical cert models, built on failed religion): implement discovery based cert chaining, in which receiving party finds "best" cert chain to user cert's public key - where multiple ca may issue (policy annotated) user cert for a given public key. Policy based discovery of chain delivers negotiation of ciphersuite classes, which constrains ssl handshakes selection of suite from list offered.

Matthias-Christian Ott <ott at mirix.org> wrote:

><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --> 
>
>On 01/03/14 22:03, Nikos Mavrogiannopoulos wrote:
>> On 12/31/2013 12:52 AM, Matthias-Christian Ott wrote:
>>> It required me to find, read and translate their documents into an OpenSSL
>>> cipher list and to choose the key lengths accordingly. When new
>>> recommendations are available, I would have to repeat this procedure. I
>>> would prefer it if GnuTLS had a keyword BSI or something similar to
>>> always conform to the latest recommendation (other systems
>>> administrators I know who run TLS protected web sites don't even know
>>> what a key length or a certain cipher is (sic!) and probably wouldn't
>>> make any efforts to comply with the recommendations). keylength.com
>>> lists other recommendations of other institutions that might be
>>> relevant. Also GnuTLS already has some Suite B support.
>> 
>> Hello,
>>  I don't know how practical it is to have priority strings for every
>> possible jurisdiction. We can have though options for the major ones.
>
>If I'm not mistaken, cipher suites only specify key lengths or symmetric
>ciphers and GnuTLS security parameters are only used for key generation
>not for connections. As Daniel correctly suggested, this is not enough.
>
>At 30C3 BetterCrypto.org was presented and received some press attention
>in Germany. Looking at their “Applied Crypto Hardening” document, which
>targets system administrators, configuring TLS implementations is still
>too hard and requires too much effort. Most administrators will never
>bother.
>
>I think we need security profiles for GnuTLS. A security profile covers
>all parameters that are relevant for security including cipher suites,
>key lengths and TLS extensions. GnuTLS could include some default
>profiles, such as profiles based on recommendations of institutions like
>NIST or ENISA. Security profiles are by default loaded from a
>system-wide security profile registry (some directory consists of
>security profile files) according to a system-wide security policy which
>specifies the default profile. If the system administrator or
>application software configures nothing else, GnuTLS uses the default
>profile specified in the system-wide security policy. Configuring all
>software thus in general reduces to changing a single profile name in
>the system-wide security policy.
>
>All paths for the registry, profiles and policy are of course changeable
>and there will be an API to specify them programmatically instead of
>loading them from files.
>
>What you you think?
>
>Regards,
>Matthias-Christian
>
>_______________________________________________
>Gnutls-devel mailing list
>Gnutls-devel at lists.gnutls.org
>http://lists.gnupg.org/mailman/listinfo/gnutls-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20140105/6cbd261a/attachment-0001.html>