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

[Viktor Dukhovni <[e-mail]>]

On Mon, Aug 31, 2015 at 04:38:00PM +0000, Joel Sing wrote:

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

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.

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

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.

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

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

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

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

-- 
	Viktor.