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

From: Joel Sing <[email-masked]>
Date: Mon, 31 Aug 2015 16:38:00 +0000 (UTC)

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.

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 1 Sep 2015 15:40:06 +0000

> distributing misinformation in a public forum:

Turns out the removal was inadvertent, as a side-effect of a bug
in handling HELLO with no extensions.  And the issue was resolved
in 2.2.3.  My larger point still stands, removal needs to be
handled with are.

> resulting in interoperability issues and handshake failures with some

Not confusing, as the bug had not yet been identified, but rather
reporting the best information I had at the time.  Yes, non-support
for SSL 2.0 turned out to be unintentional.

My post was not about LibreSSL as-such, LibreSSL just happened to
be a convenient recent example.  I have many more issues with
opportunistic TLS interoperability in Microsoft's Schannel than
LibreSSL, but most are long-standing problems, rather than real or
apparent recent changes.  I've reported the problems to Microsoft.

The Postfix users who ran into problems with LibreSSL 2.2.2 reported
the problem to the LibreSSL team.  We're all doing what we can.

> The main difference is the timeline under which the process is being

Good to know.  Timelines are of course a matter of judgement and
the needs of the community using the software.

> misinformation and inaccurate assertions above are not an example of this.

Let's not get carried away with imputing ill-will.  A follow-up
correction of the factual details is quite sufficient.

-- 
	Viktor.

---

From: Eliot Lear <[email-masked]>
Date: Thu, 3 Sep 2015 16:57:02 +0200

Hi Victor,

Sorry for the delay.

On 8/26/15 3:50 PM, Viktor Dukhovni wrote:
> Are there many servers out there with 512-bit DH keys not only for
> export ciphers but across the board?

It's clearly not present on most servers, but it is out there.  I expect
a cleanup has been going on because I'm seeing less bounces this week
than I did in previous weeks.  And it's old code.  The new stuff seems
to do just fine.

Eliot