Additional Diffie-Hellman Tests for the Internet Key Exchange Protocol Version 2 (IKEv2)
RFC 6989
Yes
No Objection
Note: This ballot was opened for revision 04 and is now closed.
(Sean Turner; former steering group member) Yes
(Ted Lemon; former steering group member) Yes
+1 to Stephen Farrell's DISCUSS Barry commented on the text I quote below, saying that it didn't seem like protocol behavior. It makes sense to me as protocol behavior, but I see why it might have raised a question: The recipient of a DH public key that fails one of the above tests can assume that the sender is either truly malicious or else it has a bug in its implementation. It would probably be more clearly a protocol behavior if it said "must assume" rather than "can assume." I assume that it doesn't say must because must could be taken as normative, but I think that's okay. You could also say "assumes." You should take out the second comma in this sentence, because the extra comma softens the connection between "is secure" and "in the sense," which is the opposite of what I think you are trying to convey: On the other hand, the error notification is secure, in the sense that no secret information is leaked. I'm really happy to see this work being done—thanks for doing it!
(Adrian Farrel; former steering group member) No Objection
(Barry Leiba; former steering group member) No Objection
-- Section 2.5 -- The recipient of a DH public key that fails one of the above tests can assume that the sender is either truly malicious or else it has a bug in its implementation. How is this "protocol behavior"? How is the statement even helpful? -- Section 7.2 -- In the reference for IANA-DH-Registry, IANA's preferred URL to publish omits the "xml" part. Please use this: http://www.iana.org/assignments/ikev2-parameters/#ikev2-parameters-8
(Benoît Claise; former steering group member) No Objection
(Brian Haberman; former steering group member) No Objection
(Gonzalo Camarillo; former steering group member) No Objection
(Jari Arkko; former steering group member) No Objection
(Joel Jaeggli; former steering group member) No Objection
(Martin Stiemerling; former steering group member) (was Discuss) No Objection
all cleared. Thanks!
(Pete Resnick; former steering group member) No Objection
(Richard Barnes; former steering group member) No Objection
(Spencer Dawkins; former steering group member) No Objection
(Stephen Farrell; former steering group member) (was Discuss) No Objection
- 2.4: code "MAY be modified" - even for me, that's a 2119 bogosity. - 2.4: I'm curious (and haven't read the references:-). Why do MODP implementations that re-use DH private values not need to be updated because of 2.2? - 2.5@ "INVALID_SYNTAX" ? Yuk. This is not syntactical. Is there no better error message to pick? - terminology nit: sometimes you say secret DH key and sometimes (maybe only 4.2?) yoy say private DH keys. My prefernce is to talk about public and private DH values, but whatever. - 4.3 the MUST here seems bogus and somewhat optimistic
(Stewart Bryant; former steering group member) No Objection