Additional Diffie-Hellman Tests for the Internet Key Exchange Protocol Version 2 (IKEv2)
RFC 6989

Note: This ballot was opened for revision 04 and is now closed.

(Ted Lemon) Yes

Comment (2013-05-30 for -04)
No email
send info
+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!

(Sean Turner) Yes

(Jari Arkko) No Objection

(Richard Barnes) No Objection

(Stewart Bryant) No Objection

(Gonzalo Camarillo) No Objection

(Benoît Claise) No Objection

(Spencer Dawkins) No Objection

(Adrian Farrel) No Objection

(Stephen Farrell) (was Discuss) No Objection

Comment (2013-05-30 for -04)
No email
send info
- 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

(Brian Haberman) No Objection

(Joel Jaeggli) No Objection

Barry Leiba No Objection

Comment (2013-05-23 for -04)
No email
send info
-- 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

(Pete Resnick) No Objection

(Martin Stiemerling) (was Discuss) No Objection

Comment (2013-05-27 for -04)
No email
send info
all cleared. Thanks!