Hi Tim,
On Tue, August 28, 2012 7:28 am, Polk, William T. wrote:
hi Dan,
Thanks for getting this work underway.
First observation: I think a reference to RFC 6090 is warranted.
Yes, good point. I'll add a reference to it at the start of section 2 where
the equation for the curves is noted.
Second Observation: 80 bit crypto is on its last legs. Do we really need
to specify curves with less than 112 bit strength?
There is the notion that "if it's worth protecting, it's worth protecting
properly" and I'm not sure of the current usefulness of 80-bit crypto but
this is more for completeness. The Brainpool defined them and I'm just
asking for a magic numbers to be assigned to all the defined curves.
That also is the the answer to the "14 code points, oh my!" comments.
Note that we still have over 32,000 code points available so we're talking
about taking 4/100th of 1%.
Third Observation: The security considerations section does not address
the security strength of 192 or 384 bit curves. It feels incomplete,
although I guess most readers can work it out for themselves.
I refer the reader to RFC 5639 which mentions the security considerations
of the curves. If you like I can also mention something about how the best
known attacks run on the order of the square root of the order. Would that
be satisfactory?
General observation: my experience is that specifying so many curves
dilutes implementer enthusiasm. We finally started to get some interest
in ECC support for FIPS 201 when we pared the list down from six curves in
three families to two prime curves (P-256 and P-384).
That is a very good observation. I guess we should talk to the Brainpool.
Their consortium seems to have some large and important companies in
it. The concern is that one of the members would promote the use of a
particular curve in some operational or regulatory fashion and it's
important that the users of the IKEv1 registry be able to work anywhere.
Specifying two alternatives for each security level feels like an
implementer's nightmare. Are Brainpool implementations general enough to
handle the normal and twisted curves at a particular level? If the
implementations are agnostic, maybe that should get noted in yout
insecurity considerations.
You're right, it is a nightmare! As it turns out quite a few of my test
vectors are wrong. I think implementations will be agnostic and I will
mention agnosticism.
thanks for your comments!
Dan.
Tim
________________________________
From: secdir-boun...@ietf.org [secdir-boun...@ietf.org] On Behalf Of Yoav
Nir [y...@checkpoint.com]
Sent: Tuesday, August 28, 2012 7:52 AM
To: Stephen Farrell
Cc: sec...@ietf.org
Subject: Re: [secdir] I-D Action:
draft-harkins-brainpool-ike-groups-00.txt
On Aug 28, 2012, at 2:31 PM, Stephen Farrell wrote:
On 28 Aug 2012, at 12:24, Sean Turner <turn...@ieca.com> wrote:
BTW - Dan's submitted a draft about the topic we had in Vancouver.
Comments are welcome.
I've one: I didn't realize Dan wanted 14 code points. That seems a lot.
BTW: Johannes Merkle submitted
http://tools.ietf.org/html/draft-merkle-ikev2-ke-brainpool-00 that
requests points for the same curves for IKEv2.
I'm wondering if we really need 7 different strengths as opposed to, say,
3, and whether we need both a twisted and non-twisted variation for each.
Neither document discusses the why one would prefer the twisted to the
non-twisted variant, or the non-twisted to the twisted. RFC 5639 does not
give such considerations either, but documents that relate to protocols
should IMO.
Yoav
_______________________________________________
secdir mailing list
sec...@ietf.org
https://www.ietf.org/mailman/listinfo/secdir
wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview
_______________________________________________
secdir mailing list
sec...@ietf.org
https://www.ietf.org/mailman/listinfo/secdir
wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview
_______________________________________________
secdir mailing list
sec...@ietf.org
https://www.ietf.org/mailman/listinfo/secdir
wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview
