Skip to main content

Additional Diffie-Hellman Tests for the Internet Key Exchange Protocol Version 2 (IKEv2)
draft-ietf-ipsecme-dh-checks-05

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 IESG member
Yes
Yes (for -04) Unknown

                            
Ted Lemon Former IESG member
Yes
Yes (2013-05-30 for -04) Unknown
+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 IESG member
No Objection
No Objection (for -04) Unknown

                            
Barry Leiba Former IESG member
No Objection
No Objection (2013-05-23 for -04) Unknown
-- 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 IESG member
No Objection
No Objection (for -04) Unknown

                            
Brian Haberman Former IESG member
No Objection
No Objection (for -04) Unknown

                            
Gonzalo Camarillo Former IESG member
No Objection
No Objection (for -04) Unknown

                            
Jari Arkko Former IESG member
No Objection
No Objection (for -04) Unknown

                            
Joel Jaeggli Former IESG member
No Objection
No Objection (for -04) Unknown

                            
Martin Stiemerling Former IESG member
(was Discuss) No Objection
No Objection (2013-05-27 for -04) Unknown
all cleared. Thanks!
Pete Resnick Former IESG member
No Objection
No Objection (for -04) Unknown

                            
Richard Barnes Former IESG member
No Objection
No Objection (for -04) Unknown

                            
Spencer Dawkins Former IESG member
No Objection
No Objection (for -04) Unknown

                            
Stephen Farrell Former IESG member
(was Discuss) No Objection
No Objection (2013-05-30 for -04) Unknown
- 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 IESG member
No Objection
No Objection (for -04) Unknown