> 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.
Would it make sense for an opportunistic client to advertise all algorithms commonly supported in the server certs? After all, there are relatively few signature/hash pairs in use, and they are changing very slowly over time. -----Original Message----- From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Viktor Dukhovni Sent: Monday, July 13, 2015 11:02 AM To: tls@ietf.org Subject: Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek) 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. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
