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

[Watson Ladd <[e-mail]>]

On Fri, Jul 10, 2015 at 7:29 AM, Martin Rex <[e-mail]> wrote:
> Henrik Grubbström wrote:
>>  Martin Rex <[e-mail]> wrote:
>>> The issue here is the (lack of the) TLSv1.2 signature_algorithms extension.
>>>
>>> Windows SChannel appears to treat the absence of this extension
>>> the same as the presence of an extension with (md5,rsa) (sha1,rsa) (sha1,dsa)
>>>
>>> If you send the TLSv1.2 signature_algorithms extension with the
>>> algorithm matching the signature of the server certificate, e.g.
>>> (sha256,rsa) in the above example, then a TLSv1.2 handshake will succeed.
>>
>> Sounds like it is complying with the TLS v1.2 RFC. Fix your client.
>
>
> Nope, _our_ client is perfectly compliant by _not_ sending TLS extensions.
> SCHannel is violating a MUST requirement, failing to properly process
> a ServerHello without a TLS extension.

Specific overrules general.

>
> https://tools.ietf.org/html/rfc5246#section-7.4.1.2
>
>   7.4.1.2  ClientHello
>
>    extensions
>       Clients MAY request extended functionality from servers by sending
>       data in the extensions field.  The actual "Extension" format is
>       defined in Section 7.4.1.4.
>
>
>                                       A server MUST accept ClientHello
>    messages both with and without the extensions field,
>
>
> The interpretation of rfc5246 that Microsoft is using to explain the
> broken behaviour is in clear conflict with rfc2119 section 6

This interpretation is so obviously wrong. ECDHE support requires
sending extensions. A server configured to only support ECDHE
ciphersuites will fail any handshake that doesn't contain the
necessary extensions. You cannot expect psychic servers to negotiate
unadvertised features.

Why can't you advertise support for the signatures you in fact
support, if you want to advertise support?

>
> https://tools.ietf.org/html/rfc2119#section-6
>
>    6. Guidance in the use of these Imperatives
>
>    Imperatives of the type defined in this memo must be used with care
>    and sparingly.  In particular, they MUST only be used where it is
>    actually required for interoperation or to limit behavior which has
>    potential for causing harm (e.g., limiting retransmisssions)  For
>    example, they must not be used to try to impose a particular method
>    on implementors where the method is not required for
>    interoperability.
>
>
> Requiring a server admin to continue using a sha1WithRsaEncryption
> signed certificate and failing the handshake when a sha256WithRsaEncryption
> signed certificate is installed, or alternatively requiring the server
> admin to disable TLSv1.2 (which happens to be the default in Win7/2008R2)
> is a dumb idea and actively causing harm.

If clients don't support sha256WithRsaEncryption, they won't work with
that server. The problem is clients failing to advertise features,
then their authors complaining about lack of psychic abilities on the
behalf of servers.

>
> So the alleged requirement they're looking at is either not meant
> the way they're reading it, or that requirement is simply VOID because
> it is clearly incompatible with rfc2119 section 6.
>
>
> What the implementor did not take into account is the warning sign
> on the front of rfc5246, where it says "Proposed Standard",
> which is explained by rfc2026:
>
> http://tools.ietf.org/html/rfc2026#section-4.1.1
>
>    Implementors should treat Proposed Standards as immature
>    specifications.  It is desirable to implement them in order to gain
>    experience and to validate, test, and clarify the specification.
>
>
> -Martin
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls



-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.