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

[Russ Housley <[e-mail]>]

On Sep 1, 2015, at 5:19 PM, Viktor Dukhovni wrote:

> On Tue, Sep 01, 2015 at 04:58:31PM -0400, Russ Housley wrote:
> 
>> I'm trying to pull together the things that I have heard on this thread
>> over the last week regarding Section 2.9.  I think I have captured them.
>> Please let me know if I missed something?
>> 
>> 2.9.  Opportunistic Security
>> 
>>   Despite the guidance in Section 2.4, opportunistic security [RFC7435]
>>   also deserves consideration, especially at the time a protocol
>>   implementation is deployed and configured.  Using algorithms that are
>>   weak against advanced attackers but sufficient against others is one
>>   way to make pervasive surveillance significantly more difficult.  As
>>   a result, algorithms that would not be acceptable in many negotiated
>>   situations are acceptable for opportunistic security when legacy
>>   systems are in use for unauthenticated encrypted sessions as
>>   discussed in Section 3 of [RFC7435] as long as their use does not
>>   facilitate downgrade attacks.  Similarly, weaker algorithms and
>>   shorter key sizes are also acceptable for opportunistic security with
>>   the same constraints.  That said, the use of strong algorithms is
>>   always preferable.
> 
> I still think that the focus on just the weak(er) algorithms in OS
> is unfortunate.  Rather agility and OS work hand-in-hand to improve
> communications to the extent possible.  As new algorithms are
> deployed, opportunistic peers will autmatically start to use stronger
> cryptography.  
> 
> Once new algorithms have largely displaced legacy algorithms, one
> can begin considering retirement of algorithms that used to be
> required for interoperability.  This process is likely to take
> longer for OS protocols/applications because interoperability
> carries greater weight when security is not a hard requirement and
> the alternative is cleartext.
> 
> So I'd like to see text that first emphasises the good news (over
> time agility improves the security of OS protocols).  Then the bad
> news (retirement of legacy crypto takes longer).  And finally notes
> that OS is not carte-blanche for weak crypto, new OS applications
> need to start with non-deprecated crypto, and legacy crypto needs
> to still be retired once no longer needed.

The whole point of the document is to make it easy to migrate from one algorithm suite to another more desirable one.  However, sometimes we want to keep an algorithm around that would otherwise have been discarded to achieve opportunistic security.  You seem to be trying to pull the points from the rest of the document into this paragraph.

Russ