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

[Daniel Kahn Gillmor]

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.

We cannot expect application authors to know in detail about every
possible knob or tweak available to the TLS stack.  Indeed, as TLS
itself evolves, the application may have even bee written against an
implementation of TLS that was unaware of certain knobs or settings.

In practice, the authors of a TLS library will often know much more
about the TLS stack itself than the application authors will know.

So as authors of a TLS library, we really should provide a *simple*
interface that provides an application author with a rough estimate of
our belief about the strength of the weakest link, without requiring the
application authors to be experts in the nuances of TLS.

(for application authors who happen to actually be experts in the
nuances of TLS, we should of course continue to provide decent access to
the full parameters of the TLS session, and useful ways to control them;
but we shouldn't require this kind of knowledge of our users).

	--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/daa710c2/attachment.sig>