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 12:10:40PM -0400, Kathleen Moriarty wrote:

> Considering that the use of less than ideal crypto is somewhat
> restricted to the unauthenticated session encryption and is acceptable
> only with legacy systems (and the messages on this thread about
> reaching consensus), I propose the following text changes to 2.9 of
> the crypto agility draft:
> 
> 2.9.  Opportunistic Security
> 
>    Despite the guidance in Section 2.4, opportunistic security [RFC7435]
>    SHOULD also be considered, especially at the time a protocol
>    implementation is deployed and configured.  Using algorithms that are
>    weak against advanced attackers but sufficient against others is a 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 [RFC7435] Section 3.
>    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.
>
> Does the proposed text sound good (or something with the same intent)?

A step in the right direction, but I think we can do better.  The
document under discussion is a crypto agility document.  Agility
plays two roles in cryptographic protocols:

    * Makes it possible to introduce new stronger algorithms.
    * Makes it possible to phase out old deprecated algorithms.

>From an OS perspective, when no particular security level is
demanded, and we're merely trying to get the best possible protection
against passive attacks, the main benefit of agility is the first
one: over time, we end up using stronger crypto.

Rapid deprecation of weaker crypto is net loss for OS when the
result is loss of interoperability and/or fallback to cleartext.

So I think that the focus in the original and proposed text is not
optimal, we ought to first point out that OS benefits from agility
when better crypto is deployed side by side with legacy crypto
(deprecated or not) and is supported by the peers in a given
"conversation".

With that noted, we should observe (with reference to [7435]) that
with OS one should not rush into removal of legacy weak crypto that
is still required for inteoperability with enough systems, and
*does not* facilitate downgrade attacks.  Rather one introduces
better alternatives, encourages users to upgrade their systems,
and waits for the old to become largely unnecessary before removing
support.

That said, when new OS protocols or applications are developed,
that have no legacy interoperability requirements, they SHOULD NOT
grandfather support for algorithms that are already deprecated.

[ I know I did not put this together into a specific suggestion
  for a replacement, I hope this is useful nevertheless. ]

-- 
	Viktor.