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

[Viktor Dukhovni <[e-mail]>]

On Fri, Jul 17, 2015 at 06:18:41PM +0100, Stephen Farrell wrote:

> [1] https://tools.ietf.org/html/draft-iab-crypto-alg-agility-06

Quick comments (mostly nits):

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.

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.

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".

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/

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".

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

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/

       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/

	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).

	   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.

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.

       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/

   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.


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.

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.
    
[ Have to stop here for now, have not read the rest yet. ]

-- 
	Viktor.