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

[Russ Housley <[e-mail]>]

Viktor:

Apologies.  I seem to have missed this message when I did the updates for -07.  Thankfully, Stephen noticed.  The document will be improved by tackling these comments.

> Intro paragraph 2:
> 
>       Advances in computing power available to the attacker will eventually
>       make any algorithm obsolete.
> 
>    I think this overstates the plausible advances in computing power.
>    Many of the symmetric algorithms in use today are far outside the
>    realm of any physically realizable brute force attack, unless also
>    weakened through analytic techniques.

Pulling some thoughts from the things Kenny said earlier this week, I suggest:

   Cryptographic algorithms age; they become weaker with time.  As new
   cryptanalysis techniques are developed and computing capabilities
   improve, the work required to break a particular cryptographic
   algorithm will reduce, making an attack on the algorithm more
   feasible for more attackers.  While it is unknown how cryptoanalytic
   attacks will evolve, it is certain that they will get better.  It is
   unknown how much better they will become, or when the advances will
   happen.  Protocol designers need to assume that advances in computing
   power or advances cryptoanalytic techniques will eventually make any
   algorithm obsolete.  For this reason, protocols need mechanisms to
   migrate from one algorithm suite to another over time.

> Section 2.1 second para top of page 4:
> 
>       Regardless of the approach used, protocols historically negotiate the
>       symmetric cipher and cipher mode together to ensure that they are
>       completely compatible.
> 
>   I would drop the word "completely".  And ditto in the next paragraph.

Done.

> Section 2.2 first para:
> 
>       For this reason, the protocol MUST specify one or more strong
>       mandatory-to-implement algorithm or suite.
> 
>   One or more is I believe more typically plural, so that would
>   be "algorithms or suites".

Done.

> Section 2.2.1:
> 
>       This approach allows other protocols can make use of CMS
>       and make different mandatory-to-implement algorithm choices.
> 
>   s/can/to/

Done.

> Section 2.4:
> 
>       Without integrity protection of algorithm or suite selection,
>       the attempt to transition to a new algorithm or suite may
>       introduce new opportunities for downgrade attack.
> 
>   Perhaps "for a downgrade attack" or "for downgrade attacks".

Done.

> I find section 2.5 too vague, not sure what point it is really
> trying to make.

I'm not sure how to handle this comment.  I guess the point that I am trying to make is that there can be too many levels of indirection and still preserve the integrity of the first part of the negotiation.

> Section 2.6:
> 
>       The impacts of legacy software an long support tails on security
>       can be reduced by making it easy to rollover from old algorithms
>       and suites to new ones.
> 
>    s/impacts/impact/
>    s/an long/and long/
>    s/rollover/transition/

Done.

>       Without clear mechanisms for algorithm and suite rollover,
>       preserving interoperability becomes a difficult social
>       problem.  For example, consider web browsers.  Dropping
>       support for an algorithm suite can break connectivity to
>       some web sites, and the browser vendor will lose users by
>       doing so.  This situation creates incentives to support
>       algorithm suites that would otherwise be deprecated, but
>       preserving interoperability.
> 
>    s/rollover/transitions/
>    s/but preserving/in order to preserve/

Merging with comments from others, the current text is:

   Without clear mechanisms for algorithm and suite transition,
   preserving interoperability becomes a difficult social problem.  For
   example, consider web browsers.  Dropping support for an algorithm
   suite can break connectivity to some web sites, and the browser
   vendor will lose users by doing so.  This situation creates
   incentives to support algorithm suites that would otherwise be
   deprecated in order to preserve interoperability.

> 	The digital signature on a trust anchor certificate [RFC5280]
> 	is often expected to last decades, which hinders the
> 	transition away from a weak signature algorithm or short
> 	key length.
> 
>    This example is somewhat flawed, browsers and CAs are well
>    along the process of deprecating SHA-1, while ignoring its
>    presence in trust-anchor certificates, because their self-signatures
>    are typically not checked (check not needed).

I have updated the example:

   Transition in Internet infrastructure is particularly difficult.  The
   digital signature on the certificate for an intermediate
   certification authority (CA) [RFC5280] is often expected to last
   decades, which hinders the transition away from a weak signature
   algorithm or short key length.  Once a long-lived certificate is
   issued with a particular signature algorithm, that algorithm will be
   used by many relying parties, and none of them can stop supporting it
   without invalidating all of the subordinate certificates.  In a
   hierarchical system, many subordinate certificates could be impacted
   by the decision to drop support for a weak signature algorithm or an
   associated hash function.

> 	   Institutions, being large or dominate users within a large
> 	   user base, can assist by coordinating the demise of an
> 	   algorithm suite, making the rollover easier for their own
> 	   users as well as others.
> 
>    Somehow the meaning of the above eludes me.  It needs a rewrite.

The point is that big customers can help with the social part of the transition by putting pressure on their suppliers.  I'm not sure what part to change to make that more clear for you.

> Section 2,7:
> 
>       When selecting or negotiating a suite of cryptographic algorithms,
>       the strength of each algorithm SHOULD be considered.  The algorithms
>       in a suite SHOULD be roughly equal;
> 
>    s/roughly equal/comparably strong/ or (to really spell it out):
>                   /have comparable best known attack work-factors/
> 
>    However if a particular element of a suite is believed stronger
>    than the rest, we don't need to get too pedantic about that.
>    Slightly lop-sided choices are OK if the stronger outlier is
>    adequately fast, and weaker variants are not widely used.

That was the point of "roughly".  Also, the second paragraph bring in the point about performance being a factor.

How about this:

   When selecting or negotiating a suite of cryptographic algorithms,
   the strength of each algorithm SHOULD be considered.  The algorithms
   in a suite SHOULD be roughly equal; however, the security service
   provided by each algorithm in a particular context needs to be
   considered when making the selection.  Algorithm strength needs to be
   considered at the time a protocol is designed.  It also needs to be
   considered at the time a protocol implementation is deployed and
   configured.  Advice from from experts is useful, but in reality, such
   advice is often unavailable to system administrators that are
   deploying a protocol implementation.  For this reason, protocol
   designers SHOULD provide clear guidance to implementors, leading to
   balanced options being available at the time of deployment.

>       For example, cipher suites include Diffie-Hellman or RSA without
>       specifying a particular public key length.  If the algorithm
>       identifier or suite identifier named a particular public key
>       length, migration to longer ones would be more difficult.  On
>       the other hand, inclusion of a public key length would make it
>       easier to migrate away from short ones when computational
>       resources available to attacker dictate the need to do so.
>       Therefore, flexibility on asymmetric key length is both desirable
>       and undesirable at the same time.
> 
>       s/cipher suites include/TLS cipher suites include/

Done.

>   Overall I think this text is wrong to weasel out.  Failure to
>   negotiate the DH parameter size has proved rather problematic
>   in TLS, with servers needing to guess at universally inteoperable
>   prime bit length.  This is being addressed, with the DH groups
>   extension now supporting standard prime groups as well as standard
>   EC curves.  Underspecified algorithms MUST NOT be used.  Either
>   fix the parameters, or negotiate them.

You raise an important point.  I suggest:

   Performance is always a factor is selecting cryptographic algorithms.
   Performance and security need to be balanced.  Some algorithms offer
   flexibility in their strength by adjusting the key size, number of
   rounds, authentication tag size, prime group size, and so on.  For
   example, TLS cipher suites include Diffie-Hellman or RSA without
   specifying a particular public key length.  If the algorithm
   identifier or suite identifier named a particular public key length,
   migration to longer ones would be more difficult.  On the other hand,
   inclusion of a public key length would make it easier to migrate away
   from short ones when computational resources available to attacker
   dictate the need to do so.  The flexibility on asymmetric key length
   has lead to interoperability problems, and to avoid these problems in
   the future any aspect of the algorithm not specified by the algorithm
   identifier MUST be negotiated, including key size and parameters.

> Section 2.8:
> 
>       Protocol designers MUST be prepared for the supported cryptographic
>       algorithm set to change over time.  There is a spectrum of ways
>       to enable the transition, and Section 3 discusses dome of the
>       related issues.
> 
>    s/is a spectrum/are a number/
>    "spectrum" implies some sort of continuum, which does not apply here.

Done.

> Section 2.9:
> 
>    Opportunistic security is no excuse for designing in weaker
>    algorithms into new protocols.  The text in RFC7435 relating
>    to tolerating weaker algorithms in the name of interoperability
>    is intended only for legacy systems.  When we're grafting crypto
>    onto existing systems that run over cleartext, even weak crypto
>    is better than none, but only if is already in use and required
>    for interop.  For de-novo designs, the crypto should be just as
>    strong.  Let's not lose from the get-go.
> 
>    Opportunistic security emphases adapting to peer capabilities,
>    and incrementatl deployment, and should be considered where it
>    would lead to greater use of security than all-or-nothing
>    approaches.  The agility angle here, is that when deprecating
>    algorithms that are still in wide use, opportunistic protocols
>    might take longer to phase them out, because interoperability
>    is a higher priority than in protocols with mandatory security.

Kathleen proposed a major rewrite of this section earlier this week, and you have already provided comments on that.

Russ