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

[Russ Housley <[e-mail]>]

On Sep 2, 2015, at 6:34 PM, Viktor Dukhovni wrote:

> On Wed, Sep 02, 2015 at 06:06:45PM -0400, Barry Leiba wrote:
> 
>> (Responding to the thread in general, not to Viktor's note in particular.)
>> 
>> I honestly don't see why this issue is relevant to agility at all, and
>> I would just strike the mention altogether, as I don't think it
>> affects the point that we need to have the ability to change
>> algorithms baked into the protocol and designed into the software.
>> 
>> The point of OS is to negotiate the best security we can, and be
>> willing to accept a certain minimal security level, where the
>> definition of what's minimally acceptable will change from one
>> situation to another.
>> 
>> Algorithm agility can help us achieve that, and that might be worth
>> saying.  But whether in a particular OS situation we care willing to
>> negotiate something that we'd otherwise consider deprecated is a
>> question unto itself, not one that guidance on algorithm agility needs
>> to discuss.
> 
> Barry's suggestion works for me.  Perhaps this document need not
> be the one to clarify cipher deprecation for OS.
> 
> But if it does, some text to make it clear that OS is about using
> the *strongest available* crypto, not weak crypto.  But crypto
> weaker than would otherwise be acceptable, may be acceptable with
> OS for some time to facilitate interoperability with legacy systems.
> 
> It can be a sentence or two, just enough to not give the impression
> that weak crypto is preferred with OS.

The words in my current edit buffer are:

   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.

Would it help to change "As a result" to "As a result, when communicating parties do not have strong algorithms in common"?

Russ