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

[Matthias-Christian Ott]

On 12/30/13 22:37, Daniel Kahn Gillmor wrote:
> On 12/28/2013 08:16 AM, Matthias-Christian Ott wrote:
>> There are three categories of cipher suites: insecure, possibly insecure
>> and secure.  At the moment a software developer or administrator
>> categorises the available cipher suites as either insecure (drop
>> connection) or secure (accept connection). Daniel proposed to add at
>> least another category: possibly insecure/low security margin.
> 
> i think this might be a mischaracterization of what i was proposing.  My
> main point was that TLS is a complex security protocol, with many
> possible variants and modifications.

I would rather say it was a misunderstanding and if it was a
mischaracterisation, it was not deliberate. Let me see if I get it right
this time. What you are saying is the following: In addition to
gnutls_priority_set_direct (OpenSSL has something similar), which has
some categories for cipher suites, you want to estimate the security of
the negotiated security parameters? Either the parameters are secure and
you allow the connection or they aren't and you drop the connection. I'm
a bit confused.

gnutls_priority_set_direct with perhaps some more keywords seems to be
exactly what you want. 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.

I would rather find it more useful if GnuTLS had keywords for certain
standards and regulatory institutions built-in. At a previous job we had
to conform to a privacy policy. Nobody could tell me what some data
security requirements meant in terms of concrete key lengths and
cryptographic primitives, so I decided to use the recommendations of the
BSI and BNetzA as they seem legally authoritative for Germany. 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.

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. One user might
need compatibility with SChannel or OpenSSL from 10 years ago because
her or his employer uses software that needs to be compatible while
another user wants only ciphers and parameters that are secure by
today's standards. I would like to see that GnuTLS only enables PFS and
HIGH or ULTRA security parameters by default, but unless you control all
software that is part of your distributed system that uses TLS that's
not feasible and will only lead to system administrators searching for
copy & paste solutions on the web which they don't understand (believe
me, if seen grotesque situations with IPv6, where people disable it
because they don't understand it or think that it's “insecure” because
there is commonly no NAT and other things). This probably has been
discussed in the TLS WG as TLS heavily relies on cryptographic agility
and questionable cipher suites are still not deprecated. What I
understand from Adam Langley's discussion of this issue is that it
heavily depends on other stakeholders involved (not just the
implementors of one TLS implementation) and on the operating environment
you use TLS in (using only GnuTLS in our internal application software
is not the same as serving your website or providing e-mail access to
your customers – try explaining an average customer or even your help
desk staff that they can't use some ancient version of Microsoft
Internet Explorer or Outlook Express because a cipher suite negotiation
failed). Though I generally with NaCl's explanation of this topic, in
practice it's not as easy as that.

Just some thoughts.

Regards,
Matthias-Christian