Re: [Gen-art] Gen-ART Last Call review of draft-iab-crypto-alg-agility-07.txt

[Russ Housley <[e-mail]>]

Suresh:

Thanks for the review.

> Summary: The draft is almost ready for publication as a BCP but I do 
> have some comments you may wish to address.
> 
> Minor
> =====
> 
> * Section 1
> 
> Not sure what becomes more feasible in this sentence. I am assuming that 
> it is an attack becoming more feasible. If so, suggest rewording to
> something like.
> 
> OLD:
> 
> As new cryptanalysis techniques are developed and computing capabilities 
> improve, the work factor to break a particular cryptographic algorithm 
> will reduce, becoming more feasible for more attackers.
> 
> NEW:
> 
> As new cryptanalysis techniques are developed and computing capabilities 
> improve, the work factor to break a particular cryptographic algorithm 
> will reduce, thus making it more susceptible to attackers.

Does this resolve your concern?  I have provided the whole paragraph because it pulls in some discussion from the SAAG list as well.

   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.  Advances in computing power available to the attacker will
   eventually make any algorithm obsolete.  For this reason, protocols
   need mechanisms to migrate from one algorithm suite to another over
   time.

> * Section 2.6
> 
> Would it be useful to put in a recommendation here to use strongest 
> possible algorithms/suites and longest possible keys for such long lived 
> trust anchor certificates?

I thought about that, but I was concerned that we would see silly key sizes.  I am aware of an attack that was mounted against a very well known site where the attacker provided bogus certificates that were signed with public keys that were 50,000+ bits long.  The attacker sent these over and over, until each of the servers in the data center were dong nothing but public key operations.  There were two fixes.  First, put a limit on the key size.  Second, validate the certificate before doing any operations with the embedded public key.  So, your suggestion is in violation to one part of the fix.

For performance, you want keys that are long enough to be safe and secure, perhaps with some margin, but not overkill.  I hope Section 2.7 already makes this point.

> * Section 3.4
> 
> The default server or
>    responder configuration SHOULD disable such algorithms

I do not understand this comment.

> * Security considerations
> 
> The reference to RFC5166 seems to be wrong and talks about evaluation of 
> congestion control mechanisms. Just randomly searching through the RFC 
> index led to me to RFC5116 that seems to be about authentication 
> encryption algorithms. If this is the correct reference, it needs to be 
> fixed in both this section and in the references section.

Oops.  It should reference RFC 5116.


> Editorial
> =========
> 
> * The document is missing a Table of contents. The ID guidelines 
> recommends a Table of Contents for drafts that are longer than 15 pages.

I added a Table of Contents.

> * Section 1
> 
> s/one or more algorithm identifier/one or more algorithm identifiers/

Fixed.

> * Section 2
> 
> OLD:
> one or more algorithm or suite identifier
> 
> NEW:
> one or more algorithm or suite identifiers

If you are talking about Section 2.1, this has been rewritten based on another comment:

   IETF protocols that make use of cryptographic algorithms MUST support
   one or more algorithm or suite.  The protocol MUST include a
   mechanism to identify the algorithm or suite that is being used.

> * Section 2.2
> 
> OLD:
> one or more strong mandatory-to-implement algorithm or suite
> 
> NEW:
> one or more strong mandatory-to-implement algorithm or suites

Fixed.

> * Section 3.1
> 
> s/The IETF has alway/The IETF has always/

Fixed.

> s/as well as meeting/and should also meet/

How about:

   The selected
   algorithms need to be resistant to side-channel attacks and also meet
   the performance, power, and code size requirements on a wide variety
   of platforms.


> s/depending of the population/depending on the population/

Fixed.

Thanks again,
  Russ