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

From: Russ Housley <[email-masked]>
Date: Tue, 1 Sep 2015 19:40:28 -0400

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

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 2 Sep 2015 03:40:29 +0000

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

>     need mechanisms to migrate from one algorithm suite to another over

Sounds good.

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

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

> Oops.  It should reference RFC 5116.

Great.

>> s/one or more algorithm identifier/one or more algorithm identifiers/

OK.

>     mechanism to identify the algorithm or suite that is being used.

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

>> one or more strong mandatory-to-implement algorithm or suites

OK.

>> s/The IETF has alway/The IETF has always/

OK.

>     the performance, power, and code size requirements on a wide variety

Great.

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

Great.

Thanks
Suresh

---

From: Jari Arkko <[email-masked]>
Date: Wed, 2 Sep 2015 22:04:55 +0300

Suresh, thanks for the review again! Russ, Suresh had some further questions. I’d like to deal with them before the draft gets finally approved, which might happen tomorrow.

Jari

On 02 Sep 2015, at 06:40, Suresh Krishnan <[email-masked]> wrote:

> _______________________________________________
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 2 Sep 2015 21:48:01 +0100

Russ and Suresh have a discussion going on, that I think is almost
resolved. In any case I'll make sure that stuff is handled before
we send to RFC editor. (There are a couple of other threads that'll
result in minor changes too.)

Cheers,
S.

---

From: Russ Housley <[email-masked]>
Date: Thu, 3 Sep 2015 14:58:51 -0400

Suresh:

{ Dropping parts that have been resolved. }

> It would be nice to clarify.

The idea is that only the administrators that must follow the legislation or regulations need to enable them.  I think this point is clear already, but you did not copy the whole sentence:

   The default server or
   responder configuration SHOULD disable such algorithms; in this way,
   explicit action by the system administrator is needed to enable them
   where they are actually required.

Fixed.

Russ