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

[Viktor Dukhovni <[e-mail]>]

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.

-- 
	Viktor.