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

[Daniel Kahn Gillmor]

On 12/03/2013 06:11 PM, Matthias-Christian Ott wrote:
> I wonder whether LEGACY and NORMAL are good categories. I think the
> actual security levels need some more thinking. Unfortunately I don't
> have good answers either.

I think most users need something simple for guidance.  A small set of
levels like EXPORT,LEGACY,NORMAL,HIGH,ULTRA fits the bill.

People who have very specific needs can still have access to all the
grubby details and could just as well ignore this summary sec_param.

> In mod_gnutls, mod_ssl and nginx, you could implement this as a library
> that reads environment variables of the request (e.g. SSL_CIPHER in
> mod_gnutls and mod_ssl) and computes the security from this – no patches
> for TLS libraries required. For other types of software this could be
> implemented as a separate library as well.

i don't think you can do this.  For example, SSL_CIPHER doesn't expose
the number of bits in the DHE key exchange handshake.  Also, the
underlying TLS library could itself add new features that this
hypothetical external library doesn't know anything about.

I think the TLS library itself (which has all of the specific knowledge
about the transport layer) is the right place for this.

I see it as in some ways analogous to the xssl API -- simplicity and a
minimum of knobs, for users without specialized needs, but who want to
be able to tell how secure their connections are.

> Businesses with regulatory requirements that must use a certain set of
> cryptography algorithms or must ensure a minimal key length etc. could
> also make use of this.

For this specific use case, where there is a hard limit, i think the
user would be better off using the priority string.

>>  1) how do we track something like this across TLS renegotiation?  if a
>>     session starts off with a weakest link of LEGACY, and then
>>     renegotiates to NORMAL, is the current session "NORMAL"?  or would
>>     we consider it LEGACY because the original connection was LEGACY?
> 
> Can you give an example of an implementation with this behaviour? I
> vaguely remember that SChannel on Windows 7 and Internet Explorer 9 had
> some problems when experimented with GnuTLS and ECDH and ECDSA only
> cipher suites (it pretended to know only 3DES and RSA or something like
> this).

each peer can choose to trigger a renegotiation (a new TLS handshake) at
any time.  It's not a I haven't done much testing with this, though.

> Tt's not clear to me whether you mean developers using GnuTLS or
> “end-users”. End-users probably need more practical advice like “You are
> using an oudated version of web browser/application XY that is not
> secure by todays standards. Thus you can only access limited
> information. Please upgrade to version A.B to gain full access”. This
> definitely doesn't belong in a TLS library.

right; I'm talking about developers who use the GnuTLS library, not end
users.  The TLS library seems like the right place to provide this
information to the developers, so that they can decide what to display
to the end user.

> Is your focus on web sites and applications (seems easier) or on all
> software which uses TLS?

I'd like to provide this information at the TLS layer itself, so that
web sites and applications can make use of it.

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1027 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20131204/e6f72a75/attachment.sig>