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

[[e-mail] (Martin Rex)]

Viktor Dukhovni wrote:
> On Tue, Jul 07, 2015 at 10:45:25AM -0700, Eric Rescorla wrote:
>> 
>> So if you can't express SHA1 in signature_algorithms, then the server can't
>> send you a certificate signed with SHA-1.
> 
> This is a very unfamiliar use of the word "can't".  In practice
> most servers will send whatever (fixed) certificate chain they're
> configured with, no matter the content of the signature_algorithm
> extension.  Servers that possess otherwise equivalent chains that
> differ only in the signature algorithm are rather rare beasts AFAIK.
> 
> Which SSL libraries allow server administrators to configure multiple
> chains based on the signature algorithm?


Unfortunately, a non-marginal installed base is exhibiting this self-imposed
(mis)behaviour of connection failure: Microsoft SChannel beginning 
with Windows 7 / 2008R2 (aka WinNT 6.1), and Windows 8 / 2012 and
Windows 8.1 / 2012R2 exhibit the same (mis)behaviour.

When you install a server certificate with a sha256WithRsaEncryption signature
on a Microsoft IIS on one of these platforms, enable TLSv1.2 on the server
and try to connect with an extension-free ClientHello that offers
client_version= (3,3), you will face a connection failure (IIS simply closes
the network connection--IIS is notorious in failing to put fatal alerts
on the wire).

The handshake succeeds (with TLSv1.1) if the client offers at most TLSv1.1,
or if the client offers TLSv1.2 in a SSL Version2 CLIENT-HELLO rather than
an extensionless TLS ClientHello, if TLSv1.2 is disabled on IIS, or if
a server certificate with only sha1WithRsaEncryption ist used.


> 
> My impression is that chain selection based on the extension is
> largely wishful thinking.


To me, it looks more like a lack of thinking on part of the spec writers
and the implementors.  Just how dumb the idea is should become obvious
if you compare the handshake result for TLSv1.1 and for TLSv1.2.
Essentially, this is a TLS protocol version intolerance created by 
the TLSv1.2 protocol specification itself.


-Martin