Re: [saag] AD review of draft-iab-crypto-alg-agility-06

[Joel Sing <[e-mail]>]

Viktor Dukhovni <ietf-dane <at> dukhovni.org> writes:
> I should note, that premature deprecation of algorithms and/or
> protocol features by library maintainers who are not attuned to
> the needs of OS applications is already having detrimental effects.
> 
> For example, LibreSSL 2.2.2 has not only removed support for SSL
> 2.0 and SSL 3.0, but has also removed TLS server support for
> SSL-2.0-compatible HELLO.

I strongly recommend that you check your facts, in order to avoid 
distributing misinformation in a public forum:

- LibreSSL 2.2.2 has support for SSLv3 - it is disabled by default,
  however it can be re-enabled by an application at runtime (or by using
  the appropriate functions directly).

- LibreSSL 2.2.2 has server support for SSLv2 ClientHello messages and it 
  will not be removed any time soon.

> This means that servers linked with LibresSSL are unable to complete
> a TLS handshake with clients that have not yet disabled SSL 2.0
> and are still sending SSLv2-compatible HELLO.

This is inaccurate. I believe you are confusing this with a bug that was
introduced in the 2.2.2 release, which has already been fixed in 2.2.3. A 
TLS ClientHello that contained no extensions was incorrectly handled,
resulting in interoperability issues and handshake failures with some
clients.

> Such clients are not uncommon.  The Postfix user who ran into this
> problem reverted to linking Postfix with OpenSSL.  In the OpenSSL
> "master" branch (future 1.1.0), SSL 2.0 and SSL 3.0 are disabled
> just like in LibreSSL 2.2.2, but support for SSLv2-compatible HELLO
> is retained (on servers, but the client code will never send such
> a HELLO).
>
> It takes care and sound judgement to preserve interoperability,
> and not all applications have the same needs.  So while the
> "marketing" message needs to be clear and unequivocal (stop using
> obsolete crypto), in libraries the underlying technical changes to
> support that need to be constructed more carefully, and final
> removal may be the last step of a process that happens across
> multiple releases that gradually reduce support. 
> 
>     * Remove from use by default.
>     * Reduce relative preference.
>     * Require non-default compile-time options to enable.
>     * Remove the code.

You have practically just described the process that LibreSSL is using.
The main difference is the timeline under which the process is being
executed.

> Applications can move more aggressively, and use appropriate APIs
> to disable obsolete crypto faster because they are better positioned
> to know where to draw the line between security and interoperability
> with legacy systems.

Deprecation is difficult, since those who are doing it are often told
that they are doing the wrong thing, usually by people who try to discredit
the projects and teams that are busy making progress. Hopefully the
misinformation and inaccurate assertions above are not an example of this.