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

[Tero Kivinen <[e-mail]>]

Dan Harkins writes:
> >> Why not keeping the main document general and giving details for
> >> registered groups in an appendix?
> >
> > 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.

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). 

> > 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.

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...

> > 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.

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...
-- 
[e-mail]