Re: [TLS] EXTERNAL: TLS 1.3 Authentication and Integrity only Cipher Suites

[Viktor Dukhovni <[e-mail]>]

> On Feb 10, 2021, at 11:57 PM, Jack Visoky <jmvisoky=[e-mail]> wrote:
> 
> I would just like to recognize that there are some situations where it isn't needed.

One classic case where Postfix supports TLS 1.[0-2] NULL ciphers
is loopback TLS (process to process communication via [127.0.0.1]
or a unix-domain socket).  Here, one would generally not use TLS
at all, but it can be useful for client authentication.

The use-case is far from common, and encrypting anyway is typically
a viable alternative, but there is a sound case that encryption adds
little value, if you can capture the traffic on [127.0.0.1] you can
also capture the same content prior to encryption (just trace the
sending process reading cleartext data from disk, or the receiving
process writing it to disk).

I am not saying there is or is not a compelling case for NULL ciphers,
but just noting a use-case where encryption does not add much value.

Performance-wise, indeed on many a CPU AESGCM is cheaper than SHA2.
So turning off encryption is not always a performance win.  It rather
depends...

If client and server conditionally support NULL ciphers in a debugging
configuration, one might also be able to debug some TLS-related problems
that are otherwise difficult to debug.  This too is a rare situation, and
comes with a risk of accidental misuse.

There is merit in keeping the combinatorial complexity of TLS 1.3
as small as possible, reducing implementation attack surface, ...

The key question, that is difficult to answer is whether the right
balance is adequately accomplished with "N" in the recommended column,
with most implementations then either not supporting said ciphersuites
at all, or disabling them by default.  If so, perhaps some specialised
implementations could use them appropriately.  On the other hand the
"specialised" applications might get used outside their originally
intended use-cases, in ways the designers never anticipated.

Do we leave the choice to use TLS wisely to the developers and users,
or we judge that misuse is inevitable, and the use-case not sufficiently
compelling?  I am somewhat inclined to do the latter.  Despite the fact
that'd I'd otherwise be inclined to argue for anonDH ciphers, which have
reasonable applications in unauthenticated opportunistic TLS, where any
presented certificates are just ignored bloat that increase the attack
surface.  I would have liked to see support for these retained in TLS 1.3,
but accept their omission as a legitimate tradeoff.  If NULL ciphers are
added (which IMHO are the greater risk), then perhaps I'd have a good
case to make to have anonDH/anonECDH ciphers re-introduced...

-- 
	Viktor.