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

[Nico Williams <[e-mail]>]

On Fri, May 19, 2017 at 04:51:21PM -0400, 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:

+1

Grounds:

 - layering violation (though arguably this TLS 1.3 could be made to
   update RFC5280, we shouldn't want to do that)

 - banning some, but not all weak algorithms is a knee-jerk reaction --
   it's reactionary

 - this hurts applications that don't care for TLS server
   authentication -- applications which either don't care for server
   authentication at all, or which will use channel binding

 - it's much better to have a security level knob that disables weak
   algorithms

   (apps which don't care for TLS server authentication... need two such
   knobs: one for server authentication (on/off) and one for security
   level for key agreement, PRF, and ciphersuite negotiation)

> 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.

That could be fixed, of course.  But let's not.

> 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

I much prefer the idea that there MUST be a security level knob for the
user/application.

> 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.

That's right: for PKIX server authentication, the security level
enforcement should be done in PKIX code, not in TLS code.  This is an
excellent example of how layering in Internet protocols should translate
into layering into implementations.  Conversely, this is also an example
of how layering violations in Internet protocols lead to layering
violations in implementations.

> 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).

+1.

Nico
--