Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek)

[Viktor Dukhovni <[e-mail]>]

On Mon, Jul 13, 2015 at 05:11:29PM +0000, Andrei Popov wrote:

> I think a good design is to have the client explicitly advertise any
> algorithms the client is willing/able to support, and for the server to
> honor the client's capabilities.

To the extent possible.  However, the server SHOULD NOT refuse to
continue the handshake merely because it believes that some
certificates in its chain might have signatures the client can't
check.  The point being that the client may not need or attempt to
check those signatures.

> IMHO the existing specs already meet the above goal,

No, the language about the certificate chain is needlessly restrictive.
The decision as to whether the chain works for the client or not,
SHOULD be left to the client.  The server's job is to *try* to avoid
problems by sending a known-compatible chain when available.

> No, I don't care for SHA1; let's deprecate it ASAP. I do care for a
> straightforward and deterministic handshake where the client MUST advertise
> supported algorithms and the server MUST honor the client's capabilities.

The MUST honour bit cleanly applies to choices of algorithms in
signature the server makes during and after the handshake.  However,
honouring the algorithms for the chain signatures is more subtle.
Yes, send a compatible chain when possible, HOWEVER, DO NOT prejudge
the client's inability to handle an alternative chain if that's
all you have.  As explained before, opportunistic TLS, DANE, pinning,
...  may mean that the client does not in fact examine the signatures
in the chain and the handshake would succeed, if only the server
were not needlessly pedantic.

Let's not be needlessly pedantic.

> Having shipped a product that implements the strict interpretation of the
> current specs (WRT signature_algorithms) for a number of years now, I
> remember exactly 3 related problem reports. Without pointing fingers (as
> much as possible), here they are:

Past performance is not a guarantee of future returns.

Today, TLS 1.2 clients generally support all the defined hash
algorithms, so problems are rare.  In the future, there will be
new hash algorithms that not all clients will support, and there
will servers with chains that are signed with bleeding-edge
algorithms, there's no need to reject connections from clients that
don't need to verify said signatures.


> My preference would be to keep the client explicitly advertising its
> capabilities, and the server strictly honoring the client-advertised
> capabilities. And since the concept of "default algorithms" confuses
> people, let's just get rid of it in 1.3. Conveniently, most of this WG no
> longer wants SHA1 or MD5. Why not just make signature_algorithms (even
> more) clearly and unambiguously MTI in 1.3?

An opportunistic TLS or DANE TLSA client cannot advertise the
capability of supporting algorithms it was aware existed (by ignoring
all signatures in the chain).

We surely don't want to muddy the waters by adding "wildcard"
algorithm code-points, and new APIs for clients to request that
the TLS stack send those.

The proposal on the table is simply sensible.  The server lacks
sufficient information to make an informed decision as to whether
its chain is unacceptable, and therefore should send whatever chain
it has if it lacks a known compatible chain.  This is simply sound
engineering.  The alternative is needless incompatibility. 

That this also fixes the problem for some folks who don't want to
make sending the extension mandatory (and happen to get back a
chain they can accept) is a harmless accident.

-- 
	Viktor.