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

[Johannes Merkle <[e-mail]>]

Hi David,

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

I see your point, but I am not sure, if it is good to maintain a limitation of the previous RFCs for the new curves as
well. At least not, if we agree that point compression is a reasonable feature (which is still discussed below).


> 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


Point compression is simply the ommission of the x-value, and for point expansion, functions are included in OpenSSL and
other crypto libraries. Thus, such mistakes should only occur if someone decides to implement the arithmetic by itself
but is incapable of doing it correctly (and does not perform sufficient testing). This seems to me a quite a case of
carelessness and I don't think, that an RFC should be so fool-proof to prevent that. There are certainly much more
complex aspects in IKE than point compression.


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

If using certificate-based authentication, probably the largest payload is the CERT. It contains a public key and a
signature, which, when using the same curve as for KE, are (together) 3-4 times larger than a compressed KE payload. In
addition, some smaller data fields as the DNs, algorithm identifiers, validity, serial, and some ASN.1 overhead.
But according to RFC 5480 one can use point compression for the public key contained in the certificate as well, which
means that the implementation must be able to handle this anyway.

I agree with you that the saving is small, but from what I have heard about constrained environment, even a saving below
10% can be desirable.

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

This is also true for ECC in IKEv2. Furthermore, the TLS RFCs are WG document, as the IANA registry for elliptic curves
requires IETF consensus.  (I know that by heart, as I am currently also working on the standardization of the Brainpool
curves for TLS.)

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

That is a good point, but unfortunately in IKE, KE methods are not negotiated at all. This is not only an special issue
for ECC or point compression. If the other peer does not understand the curve you are using or ECC at all, that you end
up in INVALID_KE_PAYLOAD notification and have to re-try.

Yes, introducing point compression doubles the number of new possibilities to choose from: 8 instead of 4 in the case of
the 4 groups defined in the draft. But this number is still moderate.


> 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.
> 
An interesting idea. However, I am not sure if making one encoding optional would not increase interoperability problems
due to the lack of negotiation for KE group or point representation. But I would make point compression optional, if you
and the other folks on the list think that is enhances interoperability.


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

First, the number is already small compared to the name space.

As to the definition of separate transform IDs, I don't understand, why only this should allow point compression to be
optional. The transform Id serves for identifying the group. The encoding (compressed or uncompressed) can be determined
from the length of the KE payload and the group.

> 
> 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."
> 
I can do this, but adding this text does not make RFC 6090 a normative reference, right? Or do you mean to replace the
explicit description how to encode in compressed format with this 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.
> 
I understand and please be ensured that I take your critics as constructive and fruitful.

regards,
Johannes