RE: Remove SHOULD for elliptic curve groups in IKEv2

[andrew.krywaniuk@alcatel.com]

> >3. SHOULD   This word, or the adjective "RECOMMENDED", mean
> that there
> >    may exist valid reasons in particular circumstances to ignore a
> >    particular item, but the full implications must be understood and
> >    carefully weighed before choosing a different course.

The valid reason for ignoring them is that the patent owners seem unwilling
to disclose exactly what they own. The implication of ignoring them is that
you won't be able to match the preferred security profile of many(?) other
implementations.

> In the IETF, SHOULDs are supposed to reflect reality. The IPsec WG
> has been particularly bad at this, with the TIGER example being an
> excellent example.

But are the SHOULDs supposed to reflect the current reality or the
anticipated reality of when the protocol advances to draft standard? IKEv1
never advanced that far; if it had, we would have had to remove TIGER, or at
least reduce it to a MAY. If you weren't able to specify MUST or SHOULD for
features that aren't widely implemented yet, then we wouldn't be able to
define new protocols.

Andrew
-------------------------------------------
There are no rules, only regulations. Luckily,
history has shown that with time, hard work,
and lots of love, anyone can be a technocrat.



> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com
> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Paul Hoffman / VPNC
> Sent: Tuesday, March 12, 2002 11:01 AM
> To: andrew.krywaniuk@alcatel.com; ipsec@lists.tislabs.com
> Subject: RE: Remove SHOULD for elliptic curve groups in IKEv2
>
>
> At 10:10 AM -0500 3/12/02, Andrew Krywaniuk wrote:
> >I don't know if should == near requirement as far as crypto
> algorithms are
> >concerned. After all, Tiger was a should for how many years?
> Plus, people
> >tend to ignore crypto requirements and implement what they
> feel like (e.g.
> >wrt DES, Group 1, DSA, El Gamal). The fact is, everybody
> here plans to
> >support ECDH or at least would like to. I see no problem in
> being forward
> >looking and making it a should.
>
> In the IETF, SHOULDs are supposed to reflect reality. The IPsec WG
> has been particularly bad at this, with the TIGER example being an
> excellent example.
>
> The relevant paragraph from RFC 2119 says:
>
> >3. SHOULD   This word, or the adjective "RECOMMENDED", mean
> that there
> >    may exist valid reasons in particular circumstances to ignore a
> >    particular item, but the full implications must be understood and
> >    carefully weighed before choosing a different course.
>
> The full implications of not doing elliptic curves are not discussed
> in the IKEv2 document, probably because they are highly debatable.
> Are elliptic curve calculations faster with acceleration hardware?
> How can we be sure that they are as secure as RSA? Are there
> interoperability issues that we don't know about because almost no
> one has tested them? How easy is it to mis-implement them and not
> know it? What are the patent issues associated with them?
>
> If people think that elliptic curves will become more useful and
> popular in the future, it is fine to list them in the document as
> MAY. (If we think they will be the next TIGER or or DES, we should
> eliminate them, but that doesn't seem to be the case yet.)
>
> --Paul Hoffman, Director
> --VPN Consortium
>