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

["Blumenthal, Uri - 0553 - MITLL" <[e-mail]>]

To keep it short, +1 to Viktor’s point.
-- 
Regards,
Uri Blumenthal





On 7/13/15, 14:01 , "TLS on behalf of Viktor Dukhovni"
<[e-mail] on behalf of [e-mail]> 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
>[e-mail]
>https://www.ietf.org/mailman/listinfo/tls