Skip to main content

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

Yes

(Sean Turner)

No Objection

(Adrian Farrel)
(Benoît Claise)
(Brian Haberman)
(Gonzalo Camarillo)
(Jari Arkko)
(Joel Jaeggli)
(Pete Resnick)
(Richard Barnes)
(Spencer Dawkins)
(Stewart Bryant)

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

(Sean Turner; former steering group member) Yes

Yes (for -04)

                            

(Ted Lemon; former steering group member) Yes

Yes (2013-05-30 for -04)
+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

No Objection (for -04)

                            

(Barry Leiba; former steering group member) No Objection

No Objection (2013-05-23 for -04)
-- 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

No Objection (for -04)

                            

(Brian Haberman; former steering group member) No Objection

No Objection (for -04)

                            

(Gonzalo Camarillo; former steering group member) No Objection

No Objection (for -04)

                            

(Jari Arkko; former steering group member) No Objection

No Objection (for -04)

                            

(Joel Jaeggli; former steering group member) No Objection

No Objection (for -04)

                            

(Martin Stiemerling; former steering group member) (was Discuss) No Objection

No Objection (2013-05-27 for -04)
all cleared. Thanks!

(Pete Resnick; former steering group member) No Objection

No Objection (for -04)

                            

(Richard Barnes; former steering group member) No Objection

No Objection (for -04)

                            

(Spencer Dawkins; former steering group member) No Objection

No Objection (for -04)

                            

(Stephen Farrell; former steering group member) (was Discuss) No Objection

No Objection (2013-05-30 for -04)
- 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

No Objection (for -04)