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

[Viktor Dukhovni <[e-mail]>]

On Tue, Aug 25, 2015 at 01:39:39PM -0400, Viktor Dukhovni wrote:

> > I don't think anyone is saying that bad crypto isn't better than no
> > crypto, but how we define OS and continue to use the definition may
> > matter for algorithm and cipher suite deprecation efforts.  It's long
> > been a practice for legacy systems to continue to use deprecated
> > protocols, algorithms and cipher suites, but we've said they are not
> > in compliance with RFCXXXX.  Do we really want to start down a path of
> > saying it's okay because it falls under OS?  I'd rather not.  We would
> > get to about the same result, but perhaps we could have more success
> > with deprecation transitions if these older options are not 'blessed'.
> 
> How to position deprecation is more of a marketing than a technical
> question.  I agree that we don't want to dilute the message that
> deprecated ciphers should be phased out as quickly as possible.
> OS is not a license to indefinitely ignore deprecation.
> 
> The key issue is what "as quickly as possible" means.  For OS, it is likely
> to mean that the process takes longer, because the relative priorities of
> interoperability and security are different than with non-OS designs.
> 
> So by all means, publish unequivocal deprecation of RC4, ... but expect
> that OS applications will take some time to act on such publications and
> rightly so.

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.

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.

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.

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.

-- 
	Viktor.