Andrea, That would help a lot, in my opinion.
The one remaining question is whether anything can be said about backwards compatibility. But as we know from (e.g.) SSL/TLS experience, allowing negotiation down to deprecated algorithms can be viewed as a weakness. Maybe there is nothing useful you can say in Version 1 about backwards compatibility for Version 2. Thanks Brian On 2010-04-24 08:48, [email protected] wrote: > Brian, > > Thank you for your review (attached). > > This email is a response to the issue that you raised regarding cryptographic > algorithms. Please let me know whether there is something I missed, as I > want to ensure that we fully address your comment in the next update of the > draft. > > Rather than have one document for the protocol and another for algorithms, we > have relied on versioning the protocol. I propose making the following > changes to the document: > > 1. Change Section 1.2 on "Versions" to read: > > "There is a provision made in the syntax for an explicit version number. > Only version "1.0" is currently specified. > > The purpose for versioning the protocol is to provide a mechanism by which > changes to required cryptographic algorithms (e.g., SHA-256) and attributes > (e.g., key size) can be deployed without disrupting existing implementations; > likewise out-dated implementations can be de-commissioned without disrupting > operations involving newer protocol versions." > > 2. Add the following to the Security Considerations Section 10.6 on > "Miscellaneous Considerations" > > "Many protocols need to be algorithm agile. One reason for this is that in > the past many protocols had fixed sized fields for information such as hash > outputs, keys, etc. This is not the case for DSKPP, except for the key size > in the computation of DSKPP-PRF. Another reason was that protocols did not > support algorithm negotiation. This is also not the case for DSKPP, except > for the use of SHA-256 in the MAC confirmation message. Updating the key > size for DSKPP-PRF or the MAC confirmation message algorithm will require a > new version of the protocol, which is supported with the Version attribute." > > Andrea Doherty > P.S. We will also address the Nits that you raised in the next update of the > draft. > > -----Original Message----- > From: Brian E Carpenter [mailto:[email protected]] > Sent: Wednesday, April 21, 2010 8:57 PM > To: [email protected]; General Area Review Team > Subject: Gen-ART LC review of draft-ietf-keyprov-dskpp-10.txt > > > > _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
