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. On 02/09/15 20:04, Jari Arkko wrote: > 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 <suresh.krish...@ericsson.com> > wrote: > >> 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 >> >> >> _______________________________________________ >> Gen-art mailing list >> Gen-art@ietf.org >> https://www.ietf.org/mailman/listinfo/gen-art >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
