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

[Daniel Kahn Gillmor]

On 12/30/2013 06:52 PM, Matthias-Christian Ott wrote:

> I would rather say it was a misunderstanding and if it was a
> mischaracterisation, it was not deliberate. 

sure, i didn't mean it adversarially :)

> gnutls_priority_set_direct with perhaps some more keywords seems to be
> exactly what you want.

Right, so one direction is to have a few keywords or to be able to use
ULTRA vs. MEDIUM vs. WEAK or something in the priority string directly.
 This is the way that a service administrator could make a hard cutoff.

But you're right that i'm also asking for something else: i'd like a way
that gnutls could expose a "weakest link" value for connections that
*are* made.  This would make it possible to do a simpler audit of
existing traffic patterns, for example, or to identify (and possibly
respond differently to) particular peers whose traffic patterns are
below average, or to have a probationary period for these weaker
configurations before they are removed entirely.

> An application developer calls
> gnutls_priority_set_direct or uses the defaults which should be secure
> (although this is debatable) and GnuTLS enforces a specific security
> level where a lot of parameters are controllable by “TLS experts”. I
> think you can't make it simpler than doing nothing and using the defaults.

The trouble with "just using the defaults" is that different TLS-using
applications (quite reasonably) have different defaults.  For example,
for SMTP, where the default will almost certainly be for negotiating
peers to fall back to cleartext and avoid the TLS stack entirely, you
probably don't want to be super strict about what you accept.  (but you
still might want to have a sense of what strength was used by a given
peer, for example, to amass a list of common SMTP peers with poor crypto
practices, whose administrators you could contact and encourage to
improve their configurations)

Likewise, some web site operators offer their same site under both HTTP
and HTTPS -- they are willing to talk to clients who don't use TLS at
all.  they are likely to have lower-bar requirements for their TLS
choices than would a site that expecting all access to arrive via HTTPS.

> I would rather find it more useful if GnuTLS had keywords for certain
> standards and regulatory institutions built-in. 

I don't think this is a mutually-exclusive suggestion.  Being able to
say (for example) LATEST-ENISA-LONGTERM in a priority string would be
very handy.   This is a separate feature request, though.

> Because of different software versions, TLS implementations and
> especially proprietary software, it is also very difficult to agree on a
> safe default cipher suite list and security parameters.

I agree with your analysis here: In the face of old and outdated,
heterogenous peers that you need to allow to access your system, TLS's
algorithm agility is actually difficult beast to use effectively.  OTOH,
that agility is what has allowed us to continue to use TLS rather than
having to invent entirely new transport layer (which would have even
worse compatibility issues).  building in reporting of weakest-link
negotiated parameters to gnutls would help operators of gnutls-backed
services to be proactive about reviewing and planning to use TLS's
algorithm agility to stay current, and to identify which peers (if any)
in a typical traffic pattern might need to be repaired/replaced before
tightening up the requirements.

i hope this helps explain why i think such a feature would be useful.

	--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/20131230/85e9fe77/attachment-0001.sig>