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

[Suresh Krishnan <[e-mail]>]

Hi Russ,
   Thanks for addressing the comments. Your suggested changes look good. 
I have one clarification and one additional text change request inline.

On 09/01/2015 07:41 PM, Russ Housley wrote:
> 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.

Sounds good.

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

Makes sense.

>
>> * Section 3.4
>>
>> The default server or
>>     responder configuration SHOULD disable such algorithms
>
> I do not understand this comment.

This text seems to be at odds with the earlier statement that

"Some nations specify cryptographic algorithms, and then require their 
use through legislation or regulations"

It would be nice to clarify.

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

Great.

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

OK.

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

s/one or more algorithm or suite/one or more algorithms or suites/

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

OK.

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

OK.

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

Great.

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

Great.

Thanks
Suresh