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

The challenge is knowing when old algorithms can be dropped safely.  There has to be widespread adoption of newer algorithms and there has to be evidence of that widespread adoption.  Removal from the OS is the last step.  Prior to that the usage of the old algorithm has to drop to near zero, and that will happen only when it's evident to the party that chooses which algorithm to use is confident the other party is capable of using the newer algorithm.

Each of these steps takes a long time.  The process moves along more quickly if there is some sort of measurement or reporting of which algorithms the responding party is capable of using.

See RFC 6975 for our attempt to deal with this for DNSSEC.

Thanks,

Steve

Sent from my iPhone

> On Sep 1, 2015, at 1:16 PM, Viktor Dukhovni <ietf-dane@dukhovni.org> wrote:
> 
> On Tue, Sep 01, 2015 at 07:02:01PM +0200, Eliot Lear wrote:
> 
>>> Rapid deprecation of weaker crypto is net loss for OS when the
>>> result is loss of interoperability and/or fallback to cleartext.
>> 
>> Of course, this holds true when there are no alternatives from which to
>> select.  And it ties back to the second advantage you cited:
>> 
>>> Makes it possible to phase out old deprecated algorithms.
> 
> Eventually, when "essentially everyone" supports better options,
> the old can be dropped even by OS clients and servers.  So the
> second benefit is "delayed" for OS, we quickly lift the "ceiling"
> and as time goes by and this becomes practical lift the "floor".
> 
>> But what is it one has to do?  Why is the answer simply to specify MTI
>> two actively used suites and then vary which two over some (hopefully
>> long) period over time?
> 
> Two might not in practice be enough for OS, if deployed software
> lasts 10+ years without upgrades.  Sure, only two suites might be
> MTI at a given time, but implementations will often need to continue
> to support "past" MTI suites, if those are the best available for
> a sufficient number of peers.
> 
> Thus a suite that used to be "MTI", but no longer is, becomes
> de-facto required for OS.  Actually this applies not just OS, in
> practice even mandatory security protocols need to worry about
> interoperability.  
> 
> The difference is mostly in how quickly deprecated crypto is
> abandoned, because cleartext is rarely better than weak crypto
> (modulo facilitation of downgrades against even non-OS peers ala
> logjam and EXPORT ciphers).
> 
> While browsers and webservers are moving quick to abandon RC4 in
> 2015, SMTP servers and clients are going to continue to support it
> for at least another year or two.  Some SMTP serevrs already don't
> tolerate RC4 and create pressure on the legacy systems to upgrade.
> For most, it makes more sense to continue to receive mail than to
> enforce crypto-correctness.  The overall process takes longer.
> 
> --
>    Viktor.
> 
> _______________________________________________
> saag mailing list
> saag@ietf.org
> https://www.ietf.org/mailman/listinfo/saag