Subject: [IPsec] New draft on IKE Diffie-Hellman checks

From: Yaron Sheffer <[email-masked]>
Date: Mon, 10 Dec 2012 20:43:54 +0200

Hi,

following the recent discussion on the mailing list, Scott Fluhrer and 
myself just published a draft that updates RFC 5996 by adding the 
required recipient-side tests for ECDH. Please see 
http://www.ietf.org/internet-drafts/draft-sheffer-ipsecme-dh-checks-00.txt.

We have not addressed the issues raised by Dan and Tero regarding 
inconsistencies between various RFCs that define ECDH groups for IKE. I 
personally deem these issues to be out of scope of the current document.

Comments are very welcome.

Thanks,
     Yaron

---

From: Hugo Krawczyk <[email-masked]>
Date: Mon, 10 Dec 2012 14:50:27 -0500

The tests in sections 2.1 and 2.3 are cheap and can serve as sanity checks
for an implementation as stated in the draft, even if DH is not reused.

On the other hand, the test in 2.2 is expensive, equivalent to a group
exponentiation, and therefore should not be recommended without DH re-use
(in which case the test is an expensive waste).

Actually, the right recommendation (or MUST) for 2.2 groups is NOT to reuse
DH values.
Indeed, the reason to reuse DH is to save an exponentiation but if you do
so you pay with an extra exponentiation for the membership test. Moreover,
while the exponentiation you are saving can be performed offline (before
the run of the IKE session), the group membership test is online, so either
way it makes no sense to reuse the DH exponents.
By the way, if you forbid re-use, you need to actually mandate fresh
exponents with each session (otherwise, an implementation maybe tempted to
avoid re-use by using g^x, g^{x+1}, g^{x+2}, etc.)

Hugo

On Mon, Dec 10, 2012 at 1:43 PM, Yaron Sheffer <[email-masked]>wrote:

> myself just published a draft that updates RFC 5996 by adding the required
> recipient-side tests for ECDH. Please see http://www.ietf.org/internet-**
> drafts/draft-sheffer-ipsecme-**dh-checks-00.txt<http://www.ietf.org/internet-drafts/draft-sheffer-ipsecme-dh-checks-00.txt>
> .
>
> ______________________________**_________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/ipsec<https://www.ietf.org/mailman/listinfo/ipsec>
>

---

From: "Scott Fluhrer (sfluhrer)" <[email-masked]>
Date: Mon, 10 Dec 2012 21:53:36 +0000

From: [email-masked] [mailto:[email-masked]] On Behalf Of Hugo Krawczyk
Sent: Monday, December 10, 2012 2:50 PM
To: Yaron Sheffer
Cc: IPsecme WG
Subject: Re: [IPsec] New draft on IKE Diffie-Hellman checks

The tests in sections 2.1 and 2.3 are cheap and can serve as sanity checks for an implementation as stated in the draft, even if DH is not reused.

On the other hand, the test in 2.2 is expensive, equivalent to a group exponentiation, and therefore should not be recommended without DH re-use (in which case the test is an expensive waste).

Actually, the right recommendation (or MUST) for 2.2 groups is NOT to reuse DH values.
Indeed, the reason to reuse DH is to save an exponentiation but if you do so you pay with an extra exponentiation for the membership test. Moreover, while the exponentiation you are saving can be performed offline (before the run of the IKE session), the group membership test is online, so either way it makes no sense to reuse the DH exponents.
I cannot disagree with anything you say.  However, the real reason the 2.2 groups (22, 23, 24) exist is the other MODP groups do not conform to NIST SP 800-56A (see section 5.5.1.1).  And, SP 800-56A also mandates the checks we recommend (section 5.6.2.4).
That is, if you are implementing (say) group 24 specifically for conformance reasons, you’re going to do that test anyways (yes, it may be an expensive waste for cryptographical reasons, however, it isn’t for conformance reasons).  In that scenario, DH reuse does make sense (because not doing DH reuse doesn’t let you eliminate the test).
I would agree that maybe we need to extend the draft to discuss these noncryptographical issues.

By the way, if you forbid re-use, you need to actually mandate fresh exponents with each session (otherwise, an implementation maybe tempted to avoid re-use by using g^x, g^{x+1}, g^{x+2}, etc.)

Hugo
On Mon, Dec 10, 2012 at 1:43 PM, Yaron Sheffer <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

following the recent discussion on the mailing list, Scott Fluhrer and myself just published a draft that updates RFC 5996 by adding the required recipient-side tests for ECDH. Please see http://www.ietf.org/internet-drafts/draft-sheffer-ipsecme-dh-checks-00.txt.

We have not addressed the issues raised by Dan and Tero regarding inconsistencies between various RFCs that define ECDH groups for IKE. I personally deem these issues to be out of scope of the current document.

Thanks,
    Yaron

_______________________________________________
IPsec mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ipsec

---

From: "Dan Harkins" <[email-masked]>
Date: Mon, 10 Dec 2012 14:02:21 -0800 (PST)

Hello,

> personally deem these issues to be out of scope of the current document.

  If you're planning on updating a standards-track product of this working
group then isn't it up to the group to decide whether they want to tackle
various issues?

  Dan.

---

From: Yaron Sheffer <[email-masked]>
Date: Tue, 11 Dec 2012 00:09:01 +0200

Yes it is. That's why I mentioned that this is my personal opinion. You 
might have different personal opinions.

	Yaron

---

From: Hugo Krawczyk <[email-masked]>
Date: Mon, 10 Dec 2012 17:56:28 -0500

If the recommendation is to be compatible with the unnecessary checks of
56A in this case then say that.
As written now, one would assume that there is a security benefit to it.
(That's how we carry legacy misconceptions from standard to standard.)

Hugo

On Mon, Dec 10, 2012 at 4:53 PM, Scott Fluhrer (sfluhrer) <
[email-masked]> wrote:

>  ** **
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Hugo Krawczyk
> *Sent:* Monday, December 10, 2012 2:50 PM
> *To:* Yaron Sheffer
> *Cc:* IPsecme WG
> *Subject:* Re: [IPsec] New draft on IKE Diffie-Hellman checks****
>
> ** **
>
> way it makes no sense to reuse the DH exponents.****
>
> I cannot disagree with anything you say.  However, the real reason the 2.2
> groups (22, 23, 24) exist is the other MODP groups do not conform to NIST
> SP 800-56A (see section 5.5.1.1).  And, SP 800-56A also mandates the checks
> we recommend (section 5.6.2.4).****
>
> That is, if you are implementing (say) group 24 specifically for
> conformance reasons, you’re going to do that test anyways (yes, it may be
> an expensive waste for cryptographical reasons, however, it isn’t for
> conformance reasons).  In that scenario, DH reuse does make sense (because
> not doing DH reuse doesn’t let you eliminate the test).****
>
> I would agree that maybe we need to extend the draft to discuss these
> noncryptographical issues.****
>
> ** **
>
>
> Hugo****
> On Mon, Dec 10, 2012 at 1:43 PM, Yaron Sheffer <[email-masked]>
> wrote:****
>
> Hi,
>
> recipient-side tests for ECDH. Please see
> https://www.ietf.org/mailman/listinfo/ipsec****
>
> ** **
>

---

From: "Dan Harkins" <[email-masked]>
Date: Tue, 11 Dec 2012 10:06:06 -0800 (PST)

Hello,

  I have a few comments.

  - The Introduction says that "It turns out using EC groups in
     some scenarios require...additional tests. This document
     defines these tests." Well the memo is defining more than
     EC. I think the Intro should introduce us to the why, which
     is sort of mentioned in the next section. It would be better
     to state in the Intro that the memo is defining group
     membership tests to apply to DH values received during
     IKEv2. Then let section 2 have normative text for what's
     REQUIRED and what's RECOMMENDED and set up the reason
     for the sub-sections-- i.e. different kinds of DH groups have
     different kinds of group membership tests.

  - The IANA considerations imply that this is placing requirements
     on future RFCs. That being the case, I think the subsections
     of section 2 should not be so group-number-specific, e.g.
     today's group numbers should not be in the subsection titles.
     I'd suggest:

     2.1 MODP Groups Based on Sophie-Germain Primes
     2.2 MODP Groups With a Small Sub-Group
     2.3 Elliptic Curve Groups Over a Prime Finite Field

     and then in each of them you say what the group membership
     test is and only then say that as of publication of this memo
     the following groups are covered by this section...list the group
     numbers.

     This will allow, for example, Johannes' draft to say that the
     membership tests for the groups it is defining are in section
     2.3 of RFCXYZ and that section heading won't say "groups
     19-21, 25, 26" which would be somewhat clumsy.

     Also, don't say that a=-3 in 2.3. Just say that a, b, and p are
     from the domain parameter set defining the group. I think it's
     better to just define the test, let the reader get a, b, and p.

  - I'd also suggest a sub-section like this:

     2.4 Elliptic Curve Groups Over a Characteristic-2 Finite Field

     And the check is that the x- and y-coordinates are binary
     polynomials of degree m-1 (where m is field size of the curve)
     and that:

            y^2 + xy = x^3 + ax^2 + b (in GF(2^m))

     I know that the binary curves in RFC2409's registry were
     removed from the RFC5996's registry but some may be defined
     in the future and it would be good to cover all the possibilities
     now.

  - I think it should be mentioned that elliptic curve groups
     have a co-factor, h, and if h > 1 that a further check is
     also required, namely, if the x- and y-coordinates define
     a point Q then ensure that:

           hQ = point-at-infinity

     Add this check to both 2.3 and 2.4. Of course if h=1 then this
     check can be skipped.

  - Let IANA know what registry these new requirements are
     being place on. It says, "The groups mentioned here are managed
     by IANA." I suggest adding "in [IKEV2IANA]." and add the following
     in the References:

     [IKEV2IANA] Internet Assigned Numbers Authority, "Internet Key
                        Exchange Version 2 (IKEv2) Parameters", Transform
                        Type 4-- Diffie-Hellman Group Transform IDs.

  regards,

  Dan.

---

From: "Dan Harkins" <[email-masked]>
Date: Tue, 11 Dec 2012 13:32:26 -0800 (PST)

I made a mistake below. Thanks to Dan Brown for pointing it out.

On Tue, December 11, 2012 10:06 am, Dan Harkins wrote:
[snip]
>      Add this check to both 2.3 and 2.4. Of course if h=1 then this

  The check should be hQ != point-at-infinity. An equivalent check
could be nQ = point-at-infinity where n is the order of the group
formed by the generator, G.

  regards,

  Dan.

---

From: Dan Brown <[email-masked]>
Date: Tue, 11 Dec 2012 21:36:21 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Dan Harkins
> Sent: Tuesday, December 11, 2012 4:32 PM
> To: Dan Harkins
> Cc: IPsecme WG
[DB] Well, the hQ != infinity check is insufficient for security, and not equivalent to ensuring that nQ=infinity.

Dan, sorry, I did not explain these details in my response to you.

Best regards,

Dan

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

---

From: "Dan Harkins" <[email-masked]>
Date: Tue, 11 Dec 2012 14:01:35 -0800 (PST)

> Dan, sorry, I did not explain these details in my response to you.

  That's interesting. Your paper "Validating EC Public Keys" (Antipa,
Brown, Menezes, Struik and Vanstone) says in section 3 that the
steps to validate an EC public key, W=(xw, yw), are:

  1. W != infinity
  2. xw and yw are properly represented elements of the finite field
  3. W satisfies the defining equation of the curve; and
  4. nW = infinity

It then says that "if h=1, then condition 4 is implied by the other
three conditions. In some protocols the check that nW = infinity may
either be embedded in the protocol computations or replaced by the
check that hW != infinity."

  Can you explain why hQ != infinity is insufficient and not equivalent
to nQ = infinity?

  thanks and best regards,

  Dan.

---

From: Dan Brown <[email-masked]>
Date: Tue, 11 Dec 2012 22:28:47 +0000

Hmm, I think this may be getting too far off-topic for IPSec, since IKE mostly uses ephemeral keys ...

> From: Dan Harkins [mailto:[email-masked]]
> Sent: Tuesday, December 11, 2012 5:02 PM
> 

[DB] Sorry about that mistake in the paper.  That paper was mostly about skipping the check number 3, not step 4.

>   Can you explain why hQ != infinity is insufficient and not equivalent

[DB] I should first correct myself when I said "insufficient for security".  This only really applies for very large h, which would be a very unusual case. 

Now suppose that G has order n and H has order h.  Then Q=G+H has order hn, not h.  In particular, it would pass the simpler test of hQ != inf.  

Suppose s is a static private key s, and P = sG is the corresponding public key.  

The shared secret is s applied to Q is Z = sQ = sG + sH = P + sH.  Therefore, Z is confined to a small set, and can leak information about s, which is the main security problem.

So, log_2(h) bits of the private key can be leaked.  For most curves, h is small, and this is not too big a deal.  

Anyway, the hQ != infinity test is not equivalent to the nQ = infinity test.

---

From: "Scott Fluhrer (sfluhrer)" <[email-masked]>
Date: Wed, 12 Dec 2012 18:53:15 +0000

Maybe we should talk about who the audience of this RFC ought to be.

I'm positing an audience of people who know little about elliptic curves; they have no idea about what a cofactor or a Sophie-Germain prime is.  All they're interested in is trying to implement this protocol in a secure manner, and want to dig into the mathematical details as little as possible.

With that in mind, I have comments below:

> Sent: Tuesday, December 11, 2012 1:06 PM
> To: Yaron Sheffer
> Cc: IPsecme WG

And what's a Sophie-Germain prime?  Yes, I know (and definition you're using is not the definition that Ms. Germain originally gave it); however, a random implementor is unlikely to.

The reason I put the group numbers in the titles is to make it easier for an implementer to decide, for a specific group, which section is appropriate.  Perhaps another approach for achieving that goal would be better.

>      better to just define the test, let the reader get a, b, and p.

RFC5903 doesn't list the value of 'a' for those curves; that's why I listed it here.  I don't believe it is appropriate to send someone to a document which doesn't list the details we say it lists.

>            hQ != point-at-infinity

This is a cheap check (if h=2, I believe that's just a check that a coordinate != 0, and as you say below, it's even cheaper if h=1).  However, is there a specific attack that is possible if you don't do the check?  If you're worried about someone modifying the DH public value with this value, IKE already has protections against that in place.  If you're worried about someone learning the value of (e mod h) (where e is the private ECDH multiplier), this check doesn't prevent that.

>      Add this check to both 2.3 and 2.4. Of course if h=1 then this

Neither RFC5114 nor RFC5903 list the value of the cofactor for the curves it defines.  How then do we expect someone to implement the test if they don't know that already?

Remember the goal; keep things simple for the implementor.  Yes, this cofactor test is cheap; however, if that check doesn't actually prevent an attack, I'd prefer that we don't make the implementor worry about it (especially since it asks for a detail that isn't listed in the RFCs that defines the curves)

> > inconsistencies between various RFCs that define ECDH groups for IKE.
> > I personally deem these issues to be out of scope of the current
> document.
> >

---

From: Johannes Merkle <[email-masked]>
Date: Thu, 13 Dec 2012 11:40:53 +0100

> I'm positing an audience of people who know little about elliptic curves; they have no idea about what a cofactor or a Sophie-Germain prime is.  All they're interested in is trying to implement thi…

Why not keeping the main document general and giving details for registered groups in an appendix?

> The reason I put the group numbers in the titles is to make it easier for an implementer to decide, for a specific group, which section is appropriate.  Perhaps another approach for achieving that…

The mapping between the registered groups and the individual subsections should be given in the appendix.

> This is a cheap check (if h=2, I believe that's just a check that a coordinate != 0, and as you say below, it's even cheaper if h=1).  However, is there a specific attack that is possible if you do…

You are right, this is exactly what Daniel has pointed out. Unfortunately, in case of a non-trivial cofactor, the check
n*P != 0 necessary to prevent an attacker from learning (e mod h) is not cheap at all. In that case, the suggestion of
Hugo applies as well, i.e. it is better to recommend not to reuse DH keys for EC groups with non-trivial cofactor.

-- 
Johannes

---

From: "Scott Fluhrer (sfluhrer)" <[email-masked]>
Date: Thu, 13 Dec 2012 15:57:32 +0000

> From: Johannes Merkle [mailto:[email-masked]]
> Sent: Thursday, December 13, 2012 5:41 AM
> To: Scott Fluhrer (sfluhrer)
> Cc: Dan Harkins; Yaron Sheffer; IPsecme WG
> > I'm positing an audience of people who know little about elliptic curves;
> they have no idea about what a cofactor or a Sophie-Germain prime is.  All
> they're interested in is trying to implement this protocol in a secure
> manner, and want to dig into the mathematical details as little as possible.
> 

Hmmmm, I like that suggestion.

> 
> 
> > The reason I put the group numbers in the titles is to make it easier for an
> implementer to decide, for a specific group, which section is appropriate.
> Perhaps another approach for achieving that goal would be better.
> 
> > This is a cheap check (if h=2, I believe that's just a check that a coordinate
> != 0, and as you say below, it's even cheaper if h=1).  However, is there a
> specific attack that is possible if you don't do the check?  If you're worried
> about someone modifying the DH public value with this value, IKE already
> has protections against that in place.  If you're worried about someone
> learning the value of (e mod h) (where e is the private ECDH multiplier), this
> check doesn't prevent that.
> 
> You are right, this is exactly what Daniel has pointed out. Unfortunately, in
> case of a non-trivial cofactor, the check n*P != 0 necessary to prevent an
> attacker from learning (e mod h) is not cheap at all. In that case, the
> suggestion of Hugo applies as well, i.e. it is better to recommend not to
> reuse DH keys for EC groups with non-trivial cofactor.

Here's what I'm wrestling with; every curve that we currently support (and, in fact, every prime curve I've heard anyone suggest) has h=1 (having h>1 makes the discrete log problem be a factor of sqrt(h) easier, for no benefit that I can see); hence, this cofactor test is moot.  So, do we complicate our description (at least, of the prime curve section) with a test that never really applies?

Now, if we do have a section covering even characteristic curves, those have h>1 (the math pretty much forces that), and so a discussion there wouldn't be entirely out of place.  On the other hand, there are standardized ways of defining the ECDH operation so that the cofactor doesn't cause any leakage ("ECC CDH", where the shared secret really is hxyG); if the group is defined using that primitive, such a cofactor test beforehand is unneeded.  Will such a group use such a modified DH operation?  Well, given that no such groups are currently defined, we can't say.

My opinion: in the prime curve section, there's no reason to mention a cofactor; and that it's premature to put in an even characteristic curve section.

---

From: "Hilarie Orman" <[email-masked]>
Date: Wed, 12 Dec 2012 13:49:52 -0700

> And what's a Sophie-Germain prime?  Yes, I know (and definition you're using is not the definition that Ms. Germain originally gave it)

The term came into mathematical parlance long after the death of the
mathematician.

Hilarie

---

From: "Dan Harkins" <[email-masked]>
Date: Thu, 13 Dec 2012 14:58:58 -0800 (PST)

> Hmmmm, I like that suggestion.

  That's a great suggestion. Yaron also mentioned the idea of adding
a note column to the DH group repository that references the particular
section of your draft (instruct IANA to update the registry with the section
and the RFC number that gets assigned to your draft). I think both of
those would be good.

> Here's what I'm wrestling with; every curve that we currently support
> (and, in fact, every prime curve I've heard anyone suggest) has h=1
> (having h>1 makes the discrete log problem be a factor of sqrt(h) easier,
> for no benefit that I can see); hence, this cofactor test is moot.  So, do
> we complicate our description (at least, of the prime curve section) with
> a test that never really applies?

  Maybe not. It might make sense to say that all the curves have an
implied co-factor of 1 though.

> Now, if we do have a section covering even characteristic curves, those
> have h>1 (the math pretty much forces that), and so a discussion there
> wouldn't be entirely out of place.  On the other hand, there are
> standardized ways of defining the ECDH operation so that the cofactor
> doesn't cause any leakage ("ECC CDH", where the shared secret really is
> hxyG); if the group is defined using that primitive, such a cofactor test
> beforehand is unneeded.  Will such a group use such a modified DH
> operation?  Well, given that no such groups are currently defined, we
> can't say.
>
> My opinion: in the prime curve section, there's no reason to mention a
> cofactor; and that it's premature to put in an even characteristic curve
> section.

  OK, I agree with the former, but why not just cover all the possibilities
by  mentioning the characteristic curves? It's supposed to be a forward-
looking document that's placing requirements on future RFCs that add
new groups and there's no reason why someone couldn't add such a curve.
I think it would be cleaner to have everything covered here instead of
having this one mention 3 of 4 and another RFC mention the 4th.

  Dan.

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 20 Dec 2012 15:52:12 +0200

> and the RFC number that gets assigned to your draft). I think both of

Now, when I am reading the actual context (I was bit swamped with
other things last week) I think this is good idea.

I.e. make the document define the generic ideas in the body, make IANA
considerations section to add the note field to the IANA registry,
which specifies this RFC and subsection in it for each group.

When I originally got the emails from Yaron about the IANA registry, I
wasn't sure whether the implementor needs to know these facts or just
the draft author writing new RFCs that adds new groups.

Now as it seems clear that each implementor needs to know this
information, I think new column to the IANA registry is good way
forward.

And I do not think we need appedix to list the current groups, we can
just put it in the IANA considerations section, as they need to add
that column and that column has all the information (i.e. mapping from
the group to the checks needed). 

> implied co-factor of 1 though.

If we are going to add binary group subsection (and I think we
should), I think we should also add special section for groups having
h > 1 (whatever that means :-).

It does not matter that there is no groups now defined using that
section, and if it is as slow because of the checks it might be there
never will be, but at least then we do not need to think again what
kind of checks are needed if someone defines such group. It also makes
it sure that if someone defines such group he will use correct checks
for the groups, and not just assume that section 2.3 is ok, as this is
elliptic curve group...

> having this one mention 3 of 4 and another RFC mention the 4th.

As we seem to have people who know about these checks and are
interested in this issues, I would really like to get all cases
covered. It will make IANA experts life also easier if there is all
cases covered in the this document...

For example I (as an current IANA expert for the IPsec registry) would
have no idea to know whether some EC group has h > 1 or not, and
whether it means something special. If there is no text about it in
the document, I most likely would not notice it at all.

Now if this document do have separate section, I would most likely
send question to auhtors and ask them to verify which of these two
subsection is approprite in their document if they have not already
pointed it out in their document.

So I am all in favor of making this document forward-looking document,
and include checks for those groups which are not yet used, but which
might be added later. Also as implementors will come to this document
through the IANA registry which points to specific subsection, other
subsections in this document does not matter to them...
-- 
[email-masked]

---

From: Johannes Merkle <[email-masked]>
Date: Thu, 20 Dec 2012 15:05:41 +0100

> which specifies this RFC and subsection in it for each group.
Which way to prefer for the "new" EC groups, i.e. the Brainpool I-Ds from Dan and me?
1. Also include references to these I-D in the draft IKE Diffie-Hellman checks
2. Include a note in the IANA section of each Brainpool I-D to add for these curves a reference to the corresponding
section of the DH-checks RFC?

Johannes

---

From: Yaron Sheffer <[email-masked]>
Date: Thu, 20 Dec 2012 16:33:34 +0200

Hi Johannes,

note that this discussion is still a bit tentative, as we are working 
with Sean to add the "DH checks" draft into our charter. But anyway...

For formal reasons, I would like to avoid a dependency from "DH Checks" 
on Brainpool. So the better option is #2: have Brainpool I-Ds refer to 
our I-D in their IANA Considerations.

I would like to use this opportunity to wish everyone on this list Happy 
Holidays and a Happy New Year. Paul and I did consider creating a 
Christmas video for your enjoyment (like 
http://www.youtube.com/watch?v=-YR-d3JHYec&feature=youtu.be), luckily 
for everyone we decided to skip it this year :-)

	Yaron

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 21 Dec 2012 11:56:47 +0200

> 1. Also include references to these I-D in the draft IKE

Yes, reference to the Diffie-Hellman checks RFC is needed.

> 2. Include a note in the IANA section of each Brainpool I-D to add
> for these curves a reference to the corresponding section of the
> DH-checks RFC?

Yes. 
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 21 Dec 2012 12:01:16 +0200

> our I-D in their IANA Considerations.

Ups, I misread the previous comment. I meant that the new brainpool
etc drafts should have normative reference to the DH checks draft, not
the other way around. There is no need to change the DH checks draft
to include reference to the new drafts as that would lock those two
drafts together, neither can go forward without the other. The
brainpool draft can just write in its IANA considerations section that
this document adds these groups, and these are the checks that needs
to be done for them (i.e. what to put in the DH checks column etc).

So I agree with Yaron about this...
-- 
[email-masked]