To keep it short, +1 to Viktor’s point. -- Regards, Uri Blumenthal
On 7/13/15, 14:01 , "TLS on behalf of Viktor Dukhovni" <tls-boun...@ietf.org on behalf of ietf-d...@dukhovni.org> wrote: >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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
