Re: [TLS] AD Review of draft-ietf-tls-tls13

[Dave Garrett <[e-mail]>]

On Friday, May 19, 2017 04:51:21 pm Viktor Dukhovni wrote:
> Which brings us to some more undesirable layer violation in the current
> draft.  The language in question is appropriate for updates to RFC5280,
> but does not belong in TLS.  The problems in question are largely
> already addressed elsewhere (as CAs no longer issue MD5, SHA1, ...
> certificates, browsers no longer support them, ...) and continue to
> be further remediated in the appropriate standards and products.
> 
> Therefore delete:
> 
>    Section 4.2.3 (Legacy algorithms paragraph final sentence):
> 
>       ...                                       TLS 1.3 servers
>       MUST NOT offer a SHA-1 signed certificate unless no valid
>       certificate chain can be produced without it (see
>       Section 4.4.2.2).
> 
>    Section 4.4.2.2:
> 
>    ...          This fallback chain MAY use the deprecated SHA-1 hash
>    algorithm only if the "signature_algorithms" extension provided by
>    the client permits it.  If the client cannot construct an acceptable
>    chain using the provided certificates and decides to abort the
>    handshake, then it MUST abort the handshake with an
>    "unsupported_certificate" alert.
> 
>    Section 4.4.2.4:
> 
>    Any endpoint receiving any certificate signed using any signature
>    algorithm using an MD5 hash MUST abort the handshake with a
>    "bad_certificate" alert.  SHA-1 is deprecated and it is RECOMMENDED
>    that any endpoint receiving any certificate signed using any
>    signature algorithm using a SHA-1 hash abort the handshake with a
>    "bad_certificate" alert.  All endpoints are RECOMMENDED to transition
>    to SHA-256 or better as soon as possible to maintain interoperability
>    with implementations currently in the process of phasing out SHA-1
>    support.

No. I strongly oppose stripping all off this out.

> I note that TLS 1.3 does not have any language prohibiting MD2, MDC2DES,
> MD4, RIPEMD160, private signature oids, ... that may be weaker than SHA-1
> or even MD5.

They're not listed as possible field values anywhere directly in the TLS spec.
If someone wants to add a line to one of the "MUST NOT" lists somewhere for
all hashes weaker than SHA-1, that sounds fine to me.

> Opportunistic unauthenticated TLS ignores the peer certificate and should
> not have to fall back to cleartext just because some certificate in the
> chain is not sufficiently sexy.  There are other legitimate use cases where
> the restrictions above are inappropriate.

Opportunistic unauthenticated TLS isn't the protocol we're defining here.
If your goal isn't authentication, then by all means violate the requirements
laid out for authentication. I have no problem making that explicit, if desired,
however this is not the primary desired operating mode of TLS.

> The reason I am pointing this out is that I just had to waste a bunch of
> time convincing the rest of the OpenSSL team to ignore the draft language
> in question, and just stick with whatever "security level" (floor on
> algorithm strength) the application or default settings requested.  This
> already excludes MD5 by default, and we'll likely adjust the collision
> resistance rating of SHA-1 from 2^80 to its reported ~2^64 strength (from
> the recent Google collision announcement), after which SHA-1 will also
> be excluded at security level 1.  This will be done in the X.509 ala PKIX
> code and not the TLS code, and applications that ignore the chain or do
> DANE-EE(3), ... will not be affected.
> 
> I propose that the current draft language is just a landmine for TLS
> implementations, that addresses a non-problem (or more precisely a
> problem that is more properly and well addressed elsewhere).

TLS is already a minefield of problems. Enumerating many of them explicitly
is a step forward to avoiding them more easily in the future. In a complex
system, just fixing something in one place is not enough. If we list it as
a possible option in the spec, we should be _very_ clear when it is crap.

I'm aware that this is unavoidably messy. Viktor, your input has greatly
helped improve the language here to accommodate varying use-cases,
and I would personally prefer we work together to make the mess correct,
rather than give up and delete the relevant text.


Dave