Re: [IPsec] I-D on Using the ECC Brainpool Curves for IKEv2 Key Exchange

["David McGrew (mcgrew)" <[e-mail]>]

Hi Johannes,

On 11/7/12 6:57 AM, "Johannes Merkle" <[e-mail]> wrote:

>Hi David,
>
>> I strongly encourage you to remove the "Compressed" point format.  Doing
>> so will minimize the changes between RFC 5903 and make the draft easier
>>to
>> support, and improve the overall implementation by making it simpler.
>> Also, it is not clear that there is any advantage to the "compressed"
>> format.   It saves at most 64 bytes in total for a complete IKEv2 key
>> establishment, and since IKEv2 exchanges typically send a lot more data
>> than that, it sounds like a false economy to add complexity in order to
>> avoid a little bit of data.
>
>I do not think that using point compression is complex.

Sure, it is not a giant amount of complexity, but is any complexity
warranted here?   If the compressed format is omitted, then the formats
for all five of the EC groups registered in Diffie-Hellman Group Transform
IDs, and that of the brainpool curves, would be identical, so that an
implementation of the brainpool curves could be handled as "same software
operating on different group parameters".   That is much preferable to
having different group logic for different DH Group IDs.

>The rule, how to determine the representation of the KE payload
>(by bit length) is very simple and common crypto libraries like OpenSSL
>provide EC point expansion functions, so there
>is not much an implementation could do wrong.

Well, there are some steps that could be done wrong: a receiver-side
implementation could fail to check and handle lengths correctly, it could
fail to compute the y-coordinate from the x-coordinate correctly, either
of which could result in an exploitable vulnerability.  This might seem
like a minor point, but it is clear that crypto protocols should avoid
complexity, especially in how they parse data (this brings to mind an
interesting recent presentation on this is
<http://www.ists.dartmouth.edu/events/abstract-sassaman-patterson.html>).

>
>On the other hand, there may be environments where every byte savings
>counts. For instance, when using IPsec for
>communications between military radio equipment, bandwidth can be very
>limited. Another example could be implementation
>in embedded environments. For instance, I have talked with major car
>manufacturers who are really concerned about
>bandwidth limitations on their internal bus in the context of secure
>communication between control units. IKE is an
>option for such communications.

I don't think the byte savings of any protocol option can be justified by
considering only the number of bytes that it would eliminate from the
communications.  What matters is the relative savings, that is, the total
number of bytes in the communications with and without that option.  How
many bytes will IKEv2 take, in an embedded context, say, with and without
the compressed format?  It should be possible to estimate a minimum based
on draft-kivinen-ipsecme-ikev2-minimal-01.   Looking at the table of
payloads in Section 2, it appears that the total bytes exchanged is going
to be considerably larger than that saved by the compressed format.

>
>Point compression is a quite common technique and supported by relevant
>ECC standards, i.e. ANSI X9.62/X9.63, IEEE P1363
>and SEC, but also by many IETF standards like TLS, CMS, PKIX, SSH. IMHO,
>IKE should allow this option like TLS does.

A minor point: the use of ECC in TLS is not part of the standard, but is
an informational extension.  More importantly, the TLS ECC RFC allows the
negotiation of supported point formats; only uncompressed format is a
MUST-implement (see Section 5.1.2 of RFC4492).  In contrast,
draft-merkle-ikev2-ke-brainpool-00 requires all implementations to support
compressed format.   There is a clear preference in IETF to avoid having a
compressed format as a MUST-implement, so I am concerned that keeping it
in the draft will be an inhibitor.

One way that you could change the draft to make the compressed format
optional is to define a different DH Group ID for each of the existing
groups and each of the formats, which would double the number of groups.
This might be acceptable to the WG if the number of groups could be kept
small.  

>Actually for IKE, the bandwidth limitations may be more relevant than for
>TLS, where point compression is supported as well.
>
>> 
>> The paragraph starting "The corresponding twisted curves ..." is a
>> distinct and self-contained topic.  I suggest putting it into its own
>> section.  
>> 
>This is a good point, I will do this in the next revision.
>
>> 
>> In some places, the draft gives [SEC1] as a normative reference, where
>> RFC6090 is also applicable (Sections 4.1 and 6 apply jn Section 2.2 of
>> draft-merkle-ikev2-ke-brainpool, for instance).
>> 
>
>RFC 6090 does not define a FieldElement-to-OctetString conversion but
>only Integer-to-OctetString. In order to use a
>reference to RFC 6090, I would have to change the text to
>+++
>... by representing the field element as integer in the interval [0,p-1]
>and then using the Integer-to-OctetString
>conversion method specified in [RFC6090]...
>+++
>This makes the whole sentence more difficult to comprehend. On the other
>hand, I do not see any advantage in pointing to
>RFC 6090 instead to SEC1.

I didn't mean to suggest eliminating the reference to SEC1, sorry if I was
unclear on that.   What I was meant to suggest is text like "The
compressed format is equivalent to the compact representation of Section
4.2 of RFC6090, using the conversion between integers and octet strings of
Section 6 of the same reference."

Let me take a step back here and explain some of my motivations.   Here is
the big picture as I see it: it is good for IKE to embrace ECC, and it is
reasonable thing to have some diversity of ECC parameters, to provide a
fallback in case of unanticipated future results in cryptanalysis.  So I
would like to see the brainpool IKE groups be something that IPsec
implementers are comfortable with implementing (and I'm making suggestions
that I hope will move the draft in that direction).  Additionally, if in
the future we do end up having additional ECC parameters that get
contributed to IKE, it would be a good thing for the WG to have
established a precedent favoring a consistency across ECP groups.

Thanks and regards,

David

>
>Johannes
>