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

[Andrey Jivsov]

I believe that the compact representation of the point documented here 
http://tools.ietf.org/html/draft-jivsov-ecc-compact is suitable for any 
IETF protocol. It doesn't expect changes of processing rules, that would 
be a non-starter.


For example, consider how it would work for IKE 
http://tools.ietf.org/html/rfc4753. Section 7 tells that IKE KE uses x|y 
sequence. My proposal would change it to x.


The bring a question of "isn't there up to 1 bit of entropy present in 
y"? I prove in the spec that it's valued as zero, i.e. it doesn't add 
anything to the security. Regardless, of the answer to whether there is 
0 or 1 of entropy present in y, the ambiguity of y/-y must be resolved 
and the method I propose does so by a minor tweak to the key generation, 
to generate a "compliant" key ( As a matter of fact, no tweaks are 
needed for ECDH keys, only for ECDSA keys. ECDH keys are always 
"compliant" when only the x of the shared point is used. )


This means that the IKE initiators and responders generate their 
ephemeral keys in such a way that the simple dropping of the y is what 
constitutes the compact representation.


This works the same way for SMIME with ECDH. Sender is free to generate 
a "compliant" ephemeral ECDH and the rest of processing rules are 
identical to current SMIME with point compression method.


BTW, I believe that a crypto software should always generate only 
"compliant" ECC keys, because there is no loss of security in doing so. 
Then the compact representation is worry free and is never conditioned 
on the type of the key.


On 01/08/2013 08:52 AM, Stephen Kent wrote:

Folks,

I think my initial concern has been misunderstood, or maybe I
misunderstood the
purported benefits of the proposed mechanism.

When I asked about compatibility with existing S/MIME specs, I was not
referring to
details of how the EC public key is represented in  a cert, per se.

Andrey's message on 1/4 said:

"Point compression is more beneficial for storage security for reasons
of performance and storage efficiency. For storage efficiency side: when
there are multiple recipients per message, each associated with one
ECDH-related field, it's possible for ECDH-specific payload to get
arbitrary large for a fixed short message. For the performance argument:
*if the message was encrypted to N recipients, to decode it only one
recipient will be used, and thus the calculation of 'y' is done once but
the space is saved for N. *

My question was whether this technique, in bold above, is compatible
with the current, normal
processing for S/MINE, or whether it would require S/MIME to operate
differently (at the originator
or at any recipient) in order to reduce the overhead in the fashion
alluded to above.

I don;t think that question has been answered.

Steve


___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Stephen Kent]

Folks,

I think my initial concern has been misunderstood, or maybe I 
misunderstood the

purported benefits of the proposed mechanism.

When I asked about compatibility with existing S/MIME specs, I was not 
referring to

details of how the EC public key is represented in  a cert, per se.

Andrey's message on 1/4 said:

"Point compression is more beneficial for storage security for reasons 
of performance and storage efficiency. For storage efficiency side: when 
there are multiple recipients per message, each associated with one 
ECDH-related field, it's possible for ECDH-specific payload to get 
arbitrary large for a fixed short message. For the performance argument: 
*if the message was encrypted to N recipients, to decode it only one 
recipient will be used, and thus the calculation of 'y' is done once but 
the space is saved for N. *


My question was whether this technique, in bold above, is compatible 
with the current, normal
processing for S/MINE, or whether it would require S/MIME to operate 
differently (at the originator
or at any recipient) in order to reduce the overhead in the fashion 
alluded to above.


I don;t think that question has been answered.

Steve
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Johannes Merkle]

Andrey,

>
> For any new format / protocol / feature, RFC 6090 + 
> http://tools.ietf.org/html/draft-jivsov-ecc-compact should be a more
> natural path.

Well, RFC 6090 is not always a good reference, at least it is very unfortunate 
that the signature scheme KT-I is not
fully compatible with ECDSA (Errata 2777).

> I agree that the statement was unclear. I was saying that because the 
> certificates contain only one public key, the
> space saving is only size-of-the-curve+1 byte per certificate. Nonetheless, 
> given that certificates need to be
> pre-processed and validated, and these results are often cached, the overhead 
> of calculation of the 'y' is probably not
> material.

For X.509 certificates, the ANSI format is already well established, so the 
alternative method is hardly relevant there.
As you said, it is more a suggestion to consider for new specifications.


-- 
Johannes
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Andrey Jivsov]

On 01/07/2013 07:52 AM, Stephen Kent wrote:


On 1/4/13 3:23 PM, Andrey Jivsov wrote:

...

Point compression is more beneficial for storage security for reasons
of performance and storage efficiency. For storage efficiency side:
when there are multiple recipients per message, each associated with
one ECDH-related field, it's possible for ECDH-specific payload to get
arbitrary large for a fixed short message. For the performance
argument: if the message was encrypted to N recipients, to decode it
only one recipient will be used, and thus the calculation of 'y' is
done once but the space is saved for N.

Are you confident that this attempt at space efficiency is consistent
with S/MIME processing rules?
Or are you suggesting that S/MIME and other secure email standards
become alg-specific to take
advantage of this optimization?


If you are asking if my proposal is compatible with the current format 
that IETF standards use, which is by and large is SEC1, then, no, my 
proposal is not binary identical to the SEC1. The issue of this 
interoperability is discussed in the spec.


While I believe that my proposal, which is written for modp curves, is 
superior to (modp subset of) SEC1, I realize that adding an alternative 
compact representation / point compression to existing standards is an 
uphill battle. For existing standards that define some point compression 
I would only say that if one finds that the point compression is not 
actually used / configured in real-world implementations, please take a 
look at my proposal as it may be a format that will eventually find its 
way into the implementations if standardized (IPR issues is one such a 
concern).


For any new format / protocol / feature, RFC 6090 + 
http://tools.ietf.org/html/draft-jivsov-ecc-compact should be a more 
natural path.



Even for certificates that have one public key there is some benefit,
given that the certificates are pre-precessed for chain validation and
are often cached.

Most IETF security protocols make use of X.509 (PKIX) certs. X.509 certs
always contain just one key.
So I'm puzzled by the phrase "Even for certificates that have one public
key ..."


I agree that the statement was unclear. I was saying that because the 
certificates contain only one public key, the space saving is only 
size-of-the-curve+1 byte per certificate. Nonetheless, given that 
certificates need to be pre-processed and validated, and these results 
are often cached, the overhead of calculation of the 'y' is probably not 
material.

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Stephen Kent]

On 1/4/13 3:23 PM, Andrey Jivsov wrote:

...

Point compression is more beneficial for storage security for reasons 
of performance and storage efficiency. For storage efficiency side: 
when there are multiple recipients per message, each associated with 
one ECDH-related field, it's possible for ECDH-specific payload to get 
arbitrary large for a fixed short message. For the performance 
argument: if the message was encrypted to N recipients, to decode it 
only one recipient will be used, and thus the calculation of 'y' is 
done once but the space is saved for N.
Are you confident that this attempt at space efficiency is consistent 
with S/MIME processing rules?
Or are you suggesting that S/MIME and other secure email standards 
become alg-specific to take

advantage of this optimization?


Even for certificates that have one public key there is some benefit, 
given that the certificates are pre-precessed for chain validation and 
are often cached.
Most IETF security protocols make use of X.509 (PKIX) certs. X.509 certs 
always contain just one key.
So I'm puzzled by the phrase "Even for certificates that have one public 
key ..."


Steve
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Andrey Jivsov]

Thank you, Johannes, for your comments. I will integrate them in the 
next revision.


I do agree that for online protocols like IKE and TLS the point 
compression of the ephemeral ECDH is not that beneficial.


Point compression is more beneficial for storage security for reasons of 
performance and storage efficiency. For storage efficiency side: when 
there are multiple recipients per message, each associated with one 
ECDH-related field, it's possible for ECDH-specific payload to get 
arbitrary large for a fixed short message. For the performance argument: 
if the message was encrypted to N recipients, to decode it only one 
recipient will be used, and thus the calculation of 'y' is done once but 
the space is saved for N.


Even for certificates that have one public key there is some benefit, 
given that the certificates are pre-precessed for chain validation and 
are often cached.


On 01/04/2013 04:10 AM, Johannes Merkle wrote:

Hi Andrey,

point compression has been deleted from the draft due to the strong objections 
in this WG. The possibility to choose
from two distinct encodings was considered inappropriate complexity given the 
limited benefit.

Generally, I think that your draft has its value, albeit probably not for IKE.

Some nits:
Line 256:
Recall that the x is an integer in the underlying finite field.
should be
Recall that the x is an element in the underlying finite field represented 
by an integer.
^^^
^
Line 352:
When p = 4*k+3, as is the case of [SuiteB] the Brainpool curves
should be
When p = 3 mod 4, as is the case of [SuiteB] and the Brainpool curves
 ^^^ ^^^
Remark: Writing p = 4*k+3 is unfortunate, as k has been used to denote the 
private key in Section 4.2

Section 5:
First, key pairs must be generated as defined in Section 4.2 to allow
compact representation.
But, as you have pointed out in Section 3:
Some protocols, such as ECDH, don't depend on the exact value of
the y.
Thus, in these protocols, it does not matter, if the key is "compliant" or not. 
This should be explained, not only in
Section 5 but also in the beginning of Section 4.2.

regards,
Johannes


Andrey Jivsov schrieb am 03.01.2013 08:07:

Sorry for bringing up this so late, but I just noticed the discussion about the 
point compression in this thread.

I posted the "Compact representation of an elliptic curve point" 
http://tools.ietf.org/html/draft-jivsov-ecc-compact
that I think is helpful as a generic definition of a compressed point.

I know that https://datatracker.ietf.org/doc/draft-merkle-ikev2-ke-brainpool/ 
-03 moved away from the compressed
representation, but the preceding discussion is one of the reasons why I 
created this draft. It's unfortunate that with
current state of ECC at IETF there is always an uncertainty/complexity such as 
"do we use an uncompressed point or
compressed point; and there is IPR". There is also an issue of what's hashed 
and how the {x,y} is encoded. In the end in
practice this means that there is no compression used.

I want to add as an alternative point of view that for new features or 
protocols there is also a way to reduce
complexity by using only the compact point representation, such as in 
http://tools.ietf.org/html/draft-jivsov-ecc-compact.
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec





___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Johannes Merkle]

Hi Andrey,

point compression has been deleted from the draft due to the strong objections 
in this WG. The possibility to choose
from two distinct encodings was considered inappropriate complexity given the 
limited benefit.

Generally, I think that your draft has its value, albeit probably not for IKE.

Some nits:
Line 256:
   Recall that the x is an integer in the underlying finite field.
should be
   Recall that the x is an element in the underlying finite field represented 
by an integer.
   ^^^
^
Line 352:
   When p = 4*k+3, as is the case of [SuiteB] the Brainpool curves
should be
   When p = 3 mod 4, as is the case of [SuiteB] and the Brainpool curves
^^^ ^^^
Remark: Writing p = 4*k+3 is unfortunate, as k has been used to denote the 
private key in Section 4.2

Section 5:
   First, key pairs must be generated as defined in Section 4.2 to allow
   compact representation.
But, as you have pointed out in Section 3:
   Some protocols, such as ECDH, don't depend on the exact value of
   the y.
Thus, in these protocols, it does not matter, if the key is "compliant" or not. 
This should be explained, not only in
Section 5 but also in the beginning of Section 4.2.

regards,
Johannes


Andrey Jivsov schrieb am 03.01.2013 08:07:
> Sorry for bringing up this so late, but I just noticed the discussion about 
> the point compression in this thread.
> 
> I posted the "Compact representation of an elliptic curve point" 
> http://tools.ietf.org/html/draft-jivsov-ecc-compact
> that I think is helpful as a generic definition of a compressed point.
> 
> I know that https://datatracker.ietf.org/doc/draft-merkle-ikev2-ke-brainpool/ 
> -03 moved away from the compressed
> representation, but the preceding discussion is one of the reasons why I 
> created this draft. It's unfortunate that with
> current state of ECC at IETF there is always an uncertainty/complexity such 
> as "do we use an uncompressed point or
> compressed point; and there is IPR". There is also an issue of what's hashed 
> and how the {x,y} is encoded. In the end in
> practice this means that there is no compression used.
> 
> I want to add as an alternative point of view that for new features or 
> protocols there is also a way to reduce
> complexity by using only the compact point representation, such as in 
> http://tools.ietf.org/html/draft-jivsov-ecc-compact.
> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
> 
> 

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Andrey Jivsov]

Sorry for bringing up this so late, but I just noticed the discussion 
about the point compression in this thread.


I posted the "Compact representation of an elliptic curve point" 
http://tools.ietf.org/html/draft-jivsov-ecc-compact that I think is 
helpful as a generic definition of a compressed point.


I know that 
https://datatracker.ietf.org/doc/draft-merkle-ikev2-ke-brainpool/ -03 
moved away from the compressed representation, but the preceding 
discussion is one of the reasons why I created this draft. It's 
unfortunate that with current state of ECC at IETF there is always an 
uncertainty/complexity such as "do we use an uncompressed point or 
compressed point; and there is IPR". There is also an issue of what's 
hashed and how the {x,y} is encoded. In the end in practice this means 
that there is no compression used.


I want to add as an alternative point of view that for new features or 
protocols there is also a way to reduce complexity by using only the 
compact point representation, such as in 
http://tools.ietf.org/html/draft-jivsov-ecc-compact.

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Scott Fluhrer (sfluhrer)]

Well, no; step 2 of the check is unnecessary for the standard IKE groups (1, 2, 
5, 14-18), and it is extremely expensive as written; and while there are 
optimizations possible, it's still not cheap.

-Original Message-
From: Johannes Merkle [mailto:johannes.mer...@secunet.com] 
Sent: Friday, December 07, 2012 7:20 AM
To: Scott Fluhrer (sfluhrer)
Cc: Yaron Sheffer; Manfred Lochter; Yoav Nir; Dan Harkins; IPsecme WG; 
rfc-...@rfc-editor.org; Sean P. Turner
Subject: Re: [IPsec] I-D on Using the ECC Brainpool Curves for IKEv2 Key 
Exchange

For MODP groups, we can just refer to RFC 2631, Section 2.1.5


___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Tero Kivinen]

Johannes Merkle writes:
> > I think it would be best to take the ECDH processing rules (mostly
> > from 5903 but also add the checks if those are needed) and create new
> > RFC that will update 5996. This document should not include any
> > groups.
> > 
> I assume that my draft should refer to this RFC-to-be, right?

Most certainly, if we can agree to make such RFC, and get it published
fast enough. The question is, whether there is enough interest to make
such RFC, and who would be willing to work on such document. 
-- 
kivi...@iki.fi
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Yaron Sheffer]

Hi Johannes,

Scott and I are working on this draft. You can expect an initial version 
within a week.


Thanks,
Yaron

On 12/07/2012 12:52 PM, Johannes Merkle wrote:

Hi Tero,



I think it would be best to take the ECDH processing rules (mostly
from 5903 but also add the checks if those are needed) and create new
RFC that will update 5996. This document should not include any
groups.


I assume that my draft should refer to this RFC-to-be, right?




___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Johannes Merkle]

Hi Scott,

> - Standard MODP groups (1, 2, 5, 14-18): informational leakage from a small 
> group attack is minimal (see section 2.2 of the paper); hence, the only check 
> needed is a verification that the peer's public value r is in range (1 < r < 
> p-
> 
> - MODP groups with small subgroups (22-24): there is some informational 
> leakage from a small subgroup attack (see section 2.1 of the paper); hence, 
> you need to check both that the peer's public value is in range (1 < r < p-1) 
> and that r**q = 1 mod p (where q is the size of the subgroup)

For MODP groups, we can just refer to RFC 2631, Section 2.1.5

> 
> - EC groups; there is some informational leakage possible (see section 2.3); 
> hence, you need to check that the peer's public value is valid; that is, it 
> is not the point-at-infinity, and that the x and y parameters from the peer's 
> public value satisfies the curve equation, that is, y**2 = x**3 + ax + b mod 
> p.  Note that even though the paper specifically targets odd characteristic 
> EC curves, their advice of checking the curve equation is equally applicable 
> to even characteristic curves as well. 
> 
As I said in my earlier mail, we could refer to SEC1, Section 3.2.2.1

> 
> Now, as for whether checking the peer's public value ought to be a 
> requirement, even if you aren't reusing private keys, I would still say that 
> it ought to be.  If we look at the ECDH point addition/doubling code, well, 
> they are designed to work correctly if you give them valid points (that is, 
> points that are actually on the curve).  If you just take bit patterns you 
> received in a packet from the peer, and just give them to the EC routines, 
> well, there's no inherent requirement what might happen if the values don't 
> happen to be valid.  If the implementation uses the standard textbook point 
> addition/doubling code, we can predict what will happen -- however, a 
> specific implementation might decide to do something different.  Because of 
> this (and because checking is so cheap -- we're talking maybe 1% of the cost 
> of the cost of doing the ECDH phase two), I would strongly urge anyone to do 
> this check.
> 

In general, the potential information leakage does not depend on the 
implementation. In case of ephemeral DH keys all
secret information involved in the DH-KE (the private DH key) is renewed in 
every execution. Thus, all that can be
learned is only relevant for the current session. And this information is known 
to the sending peer anyway.

However, if there is any statistical dependence between the private DH keys of 
different executions, the above argument
is not valid anymore. Thus, the validation of the H-key is necessary as soon as 
complete independence is not ensured,
e.g. by deploying an (P)RNG with insufficient entropy. The dependences should 
not be exploitable for attacks in case
that strong PRNG are used. But since you can not be certain about the security 
of a practical PRNG (its entropy source
or internal state may be influenced or leaked) it is always advisable to 
perform the public key validation.

Johannes


> -Original Message-
> From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of 
> Yaron Sheffer
> Sent: Saturday, December 01, 2012 2:29 PM
> To: Scott Fluhrer (sfluhrer)
> Cc: Johannes Merkle; Manfred Lochter; Yoav Nir; Dan Harkins; IPsecme WG; 
> rfc-...@rfc-editor.org; Sean P. Turner
> Subject: Re: [IPsec] I-D on Using the ECC Brainpool Curves for IKEv2 Key 
> Exchange
> 
> Hi Scott,
> 
> OK, I see your point (no pun intended). Regarding ECDH secret reuse, can you 
> please review http://tools.ietf.org/html/rfc5996#section-2.12. That section 
> was supposed to cover the relevant security considerations. In fact I think 
> your attack is alluded to in the paper we reference from that section (see 
> Sec. 5, first paragraph).
> 
> If this needs to become a MUST requirement for IKEv2 peers using ECDH, it 
> needs to be spelled out and not left as an exercise to the reader. 
> But we have to understand whether this is a general requirement, or it only 
> applies to peers that are reusing ECDH private keys for multiple IKE sessions.
> 
> Thanks,
>   Yaron
> 
> On 12/01/2012 08:44 PM, Scott Fluhrer (sfluhrer) wrote:
>> I would humbly disagree.  A peer might try to send us an invalid KE, with a 
>> bogus point that acts as if it were of small order with our implementation; 
>> let us call this bogus point P, and its small order n.  We would then 
>> generate sk's based on the point (e mod n)P (where e is the value of our 
>> ECDH secret); because n is small, that allows the attacker to recover the 
>> value (e mod n).
>>
>> If we reuse

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

[Johannes Merkle]

Hi Tero,

> 
> I think it would be best to take the ECDH processing rules (mostly
> from 5903 but also add the checks if those are needed) and create new
> RFC that will update 5996. This document should not include any
> groups.
> 
I assume that my draft should refer to this RFC-to-be, right?



-- 
Johannes
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Johannes Merkle]

Hi Scott,


> Sigh, immediately after sending this, I remembered that even characteristic 
> EC curves tend to have cofactors h>1, hence there is further checking 
> required for them.  Scratch what I said that the what I said for odd 
> characteristic EC curves applies to even as well -- that checking is 
> necessary, but it is not sufficient.
> 

After having verified that the point (x,y) = P satisfies the curve equation and 
is not the point at infinity O, checking
n*P = O is sufficient. If the cofactor h is 1 then this last check is not even 
necessary. The validation algorithm is
defined in detail in SEC1, Section 3.2.2.1. This reference should be used for 
the validation requirements.

Checking n*P = O is costly, but fortunately, all NIST and Brainpool curves have 
cofactor 1 making this check uneccesary.

BTW: The check n*P = O can be omitted even for non-trivial cofactor, if h*P is 
used as public DH key instead of P, i.e.
if the Elliptic Curve Cofactor Diffie-Hellman Primitive described in Section 
3.3.2 of SEC1 is used.

Johannes

> -Original Message-
> From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of 
> Scott Fluhrer (sfluhrer)
> Sent: Monday, December 03, 2012 9:28 AM
> To: Yaron Sheffer
> Cc: Johannes Merkle; Manfred Lochter; Yoav Nir; Dan Harkins; IPsecme WG; 
> rfc-...@rfc-editor.org; Sean P. Turner
> Subject: Re: [IPsec] I-D on Using the ECC Brainpool Curves for IKEv2 Key 
> Exchange
> 
> As for http://tools.ietf.org/html/rfc5996#section-2.12, it's fine as far as 
> it goes, however (IMHO) it rather punts on what self-checks are actually 
> needed.  It does refer to the Menezes and Ustaoglu paper, which is quite 
> good, however, it would be better if you spell out exactly what tests the 
> implementer would need to run for each IKE group.  An implementation might 
> have problems determining from the paper what is appropriate; for example, 
> groups 22-24 would be considered "DSA groups" by the nomenclature of the 
> paper (see section 2.1); however nowhere in the IKE documents are they 
> actually labeled as such.
> 
> Here is a quick run-down:
> - Standard MODP groups (1, 2, 5, 14-18): informational leakage from a small 
> group attack is minimal (see section 2.2 of the paper); hence, the only check 
> needed is a verification that the peer's public value r is in range (1 < r < 
> p-1)
> 
> - MODP groups with small subgroups (22-24): there is some informational 
> leakage from a small subgroup attack (see section 2.1 of the paper); hence, 
> you need to check both that the peer's public value is in range (1 < r < p-1) 
> and that r**q = 1 mod p (where q is the size of the subgroup)
> 
> - EC groups; there is some informational leakage possible (see section 2.3); 
> hence, you need to check that the peer's public value is valid; that is, it 
> is not the point-at-infinity, and that the x and y parameters from the peer's 
> public value satisfies the curve equation, that is, y**2 = x**3 + ax + b mod 
> p.  Note that even though the paper specifically targets odd characteristic 
> EC curves, their advice of checking the curve equation is equally applicable 
> to even characteristic curves as well. 
> 
> 
> Now, as for whether checking the peer's public value ought to be a 
> requirement, even if you aren't reusing private keys, I would still say that 
> it ought to be.  If we look at the ECDH point addition/doubling code, well, 
> they are designed to work correctly if you give them valid points (that is, 
> points that are actually on the curve).  If you just take bit patterns you 
> received in a packet from the peer, and just give them to the EC routines, 
> well, there's no inherent requirement what might happen if the values don't 
> happen to be valid.  If the implementation uses the standard textbook point 
> addition/doubling code, we can predict what will happen -- however, a 
> specific implementation might decide to do something different.  Because of 
> this (and because checking is so cheap -- we're talking maybe 1% of the cost 
> of the cost of doing the ECDH phase two), I would strongly urge anyone to do 
> this check.
> 
> -Original Message-
> From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of 
> Yaron Sheffer
> Sent: Saturday, December 01, 2012 2:29 PM
> To: Scott Fluhrer (sfluhrer)
> Cc: Johannes Merkle; Manfred Lochter; Yoav Nir; Dan Harkins; IPsecme WG; 
> rfc-...@rfc-editor.org; Sean P. Turner
> Subject: Re: [IPsec] I-D on Using the ECC Brainpool Curves for IKEv2 Key 
> Exchange
> 
> Hi Scott,
> 
> OK, I see your point (no pun intended). Regarding ECDH secret reuse, can you 
> please review http://tools.ietf.or

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

[Scott Fluhrer (sfluhrer)]

Sigh, immediately after sending this, I remembered that even characteristic EC 
curves tend to have cofactors h>1, hence there is further checking required for 
them.  Scratch what I said that the what I said for odd characteristic EC 
curves applies to even as well -- that checking is necessary, but it is not 
sufficient.

-Original Message-
From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Scott 
Fluhrer (sfluhrer)
Sent: Monday, December 03, 2012 9:28 AM
To: Yaron Sheffer
Cc: Johannes Merkle; Manfred Lochter; Yoav Nir; Dan Harkins; IPsecme WG; 
rfc-...@rfc-editor.org; Sean P. Turner
Subject: Re: [IPsec] I-D on Using the ECC Brainpool Curves for IKEv2 Key 
Exchange

As for http://tools.ietf.org/html/rfc5996#section-2.12, it's fine as far as it 
goes, however (IMHO) it rather punts on what self-checks are actually needed.  
It does refer to the Menezes and Ustaoglu paper, which is quite good, however, 
it would be better if you spell out exactly what tests the implementer would 
need to run for each IKE group.  An implementation might have problems 
determining from the paper what is appropriate; for example, groups 22-24 would 
be considered "DSA groups" by the nomenclature of the paper (see section 2.1); 
however nowhere in the IKE documents are they actually labeled as such.

Here is a quick run-down:
- Standard MODP groups (1, 2, 5, 14-18): informational leakage from a small 
group attack is minimal (see section 2.2 of the paper); hence, the only check 
needed is a verification that the peer's public value r is in range (1 < r < 
p-1)

- MODP groups with small subgroups (22-24): there is some informational leakage 
from a small subgroup attack (see section 2.1 of the paper); hence, you need to 
check both that the peer's public value is in range (1 < r < p-1) and that r**q 
= 1 mod p (where q is the size of the subgroup)

- EC groups; there is some informational leakage possible (see section 2.3); 
hence, you need to check that the peer's public value is valid; that is, it is 
not the point-at-infinity, and that the x and y parameters from the peer's 
public value satisfies the curve equation, that is, y**2 = x**3 + ax + b mod p. 
 Note that even though the paper specifically targets odd characteristic EC 
curves, their advice of checking the curve equation is equally applicable to 
even characteristic curves as well. 


Now, as for whether checking the peer's public value ought to be a requirement, 
even if you aren't reusing private keys, I would still say that it ought to be. 
 If we look at the ECDH point addition/doubling code, well, they are designed 
to work correctly if you give them valid points (that is, points that are 
actually on the curve).  If you just take bit patterns you received in a packet 
from the peer, and just give them to the EC routines, well, there's no inherent 
requirement what might happen if the values don't happen to be valid.  If the 
implementation uses the standard textbook point addition/doubling code, we can 
predict what will happen -- however, a specific implementation might decide to 
do something different.  Because of this (and because checking is so cheap -- 
we're talking maybe 1% of the cost of the cost of doing the ECDH phase two), I 
would strongly urge anyone to do this check.

-Original Message-
From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Yaron 
Sheffer
Sent: Saturday, December 01, 2012 2:29 PM
To: Scott Fluhrer (sfluhrer)
Cc: Johannes Merkle; Manfred Lochter; Yoav Nir; Dan Harkins; IPsecme WG; 
rfc-...@rfc-editor.org; Sean P. Turner
Subject: Re: [IPsec] I-D on Using the ECC Brainpool Curves for IKEv2 Key 
Exchange

Hi Scott,

OK, I see your point (no pun intended). Regarding ECDH secret reuse, can you 
please review http://tools.ietf.org/html/rfc5996#section-2.12. That section was 
supposed to cover the relevant security considerations. In fact I think your 
attack is alluded to in the paper we reference from that section (see Sec. 5, 
first paragraph).

If this needs to become a MUST requirement for IKEv2 peers using ECDH, it needs 
to be spelled out and not left as an exercise to the reader. 
But we have to understand whether this is a general requirement, or it only 
applies to peers that are reusing ECDH private keys for multiple IKE sessions.

Thanks,
Yaron

On 12/01/2012 08:44 PM, Scott Fluhrer (sfluhrer) wrote:
> I would humbly disagree.  A peer might try to send us an invalid KE, with a 
> bogus point that acts as if it were of small order with our implementation; 
> let us call this bogus point P, and its small order n.  We would then 
> generate sk's based on the point (e mod n)P (where e is the value of our ECDH 
> secret); because n is small, that allows the attacker to recover the value (e 
> mod n).
>
> If we reuse the same ECDH secret for multiple exchanges 

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

[Scott Fluhrer (sfluhrer)]

As for http://tools.ietf.org/html/rfc5996#section-2.12, it's fine as far as it 
goes, however (IMHO) it rather punts on what self-checks are actually needed.  
It does refer to the Menezes and Ustaoglu paper, which is quite good, however, 
it would be better if you spell out exactly what tests the implementer would 
need to run for each IKE group.  An implementation might have problems 
determining from the paper what is appropriate; for example, groups 22-24 would 
be considered "DSA groups" by the nomenclature of the paper (see section 2.1); 
however nowhere in the IKE documents are they actually labeled as such.

Here is a quick run-down:
- Standard MODP groups (1, 2, 5, 14-18): informational leakage from a small 
group attack is minimal (see section 2.2 of the paper); hence, the only check 
needed is a verification that the peer's public value r is in range (1 < r < 
p-1)

- MODP groups with small subgroups (22-24): there is some informational leakage 
from a small subgroup attack (see section 2.1 of the paper); hence, you need to 
check both that the peer's public value is in range (1 < r < p-1) and that r**q 
= 1 mod p (where q is the size of the subgroup)

- EC groups; there is some informational leakage possible (see section 2.3); 
hence, you need to check that the peer's public value is valid; that is, it is 
not the point-at-infinity, and that the x and y parameters from the peer's 
public value satisfies the curve equation, that is, y**2 = x**3 + ax + b mod p. 
 Note that even though the paper specifically targets odd characteristic EC 
curves, their advice of checking the curve equation is equally applicable to 
even characteristic curves as well. 


Now, as for whether checking the peer's public value ought to be a requirement, 
even if you aren't reusing private keys, I would still say that it ought to be. 
 If we look at the ECDH point addition/doubling code, well, they are designed 
to work correctly if you give them valid points (that is, points that are 
actually on the curve).  If you just take bit patterns you received in a packet 
from the peer, and just give them to the EC routines, well, there's no inherent 
requirement what might happen if the values don't happen to be valid.  If the 
implementation uses the standard textbook point addition/doubling code, we can 
predict what will happen -- however, a specific implementation might decide to 
do something different.  Because of this (and because checking is so cheap -- 
we're talking maybe 1% of the cost of the cost of doing the ECDH phase two), I 
would strongly urge anyone to do this check.

-Original Message-
From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Yaron 
Sheffer
Sent: Saturday, December 01, 2012 2:29 PM
To: Scott Fluhrer (sfluhrer)
Cc: Johannes Merkle; Manfred Lochter; Yoav Nir; Dan Harkins; IPsecme WG; 
rfc-...@rfc-editor.org; Sean P. Turner
Subject: Re: [IPsec] I-D on Using the ECC Brainpool Curves for IKEv2 Key 
Exchange

Hi Scott,

OK, I see your point (no pun intended). Regarding ECDH secret reuse, can you 
please review http://tools.ietf.org/html/rfc5996#section-2.12. That section was 
supposed to cover the relevant security considerations. In fact I think your 
attack is alluded to in the paper we reference from that section (see Sec. 5, 
first paragraph).

If this needs to become a MUST requirement for IKEv2 peers using ECDH, it needs 
to be spelled out and not left as an exercise to the reader. 
But we have to understand whether this is a general requirement, or it only 
applies to peers that are reusing ECDH private keys for multiple IKE sessions.

Thanks,
Yaron

On 12/01/2012 08:44 PM, Scott Fluhrer (sfluhrer) wrote:
> I would humbly disagree.  A peer might try to send us an invalid KE, with a 
> bogus point that acts as if it were of small order with our implementation; 
> let us call this bogus point P, and its small order n.  We would then 
> generate sk's based on the point (e mod n)P (where e is the value of our ECDH 
> secret); because n is small, that allows the attacker to recover the value (e 
> mod n).
>
> If we reuse the same ECDH secret for multiple exchanges (which is normally 
> safe), this allows someone who controls some of the peers we talk to to 
> recover the secret value for exchanges he does not control; this is not good.
>
> Hence, we need to either mandate checking the point we receive, or forbid 
> ECDH secret reuse.
>
> -Original Message-
> From: Yaron Sheffer [mailto:yaronf.i...@gmail.com]
> Sent: Saturday, December 01, 2012 5:32 AM
> To: Scott Fluhrer (sfluhrer)
> Cc: Yoav Nir; Johannes Merkle; IPsecme WG; Manfred Lochter; Sean P. 
> Turner; Dan Harkins; rfc-...@rfc-editor.org
> Subject: Re: [IPsec] I-D on Using the ECC Brainpool Curves for IKEv2 
> Key Exchange
>
> Actually, I think we

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

[Tero Kivinen]

Johannes Merkle writes:
> > OK, I see your point (no pun intended). Regarding ECDH secret
> > reuse, can you please review
> > http://tools.ietf.org/html/rfc5996#section-2.12. That section was
> > supposed to cover the relevant security considerations. In fact I
> > think your attack is alluded to in the paper we reference from
> > that section (see Sec. 5, first paragraph).
> > 
> 
> I agree with you that this is a general issue that should be
> addressed generally. Yet, as a precaution, I could also include such
> a requirement in the current draft.

Looking at the ECDH problems there seems to be in specifications (i.e.
what checks are needed, RFC5114 refering to wrong RFC (it should refer
to 5903 not 4753) etc, it seems we need to do something for this. I do
not think it is good idea to include this kind of things as errata.
Also I do not think we should include generic ECDH processing rules in
to the draft specifying some EC groups.

I think it would be best to take the ECDH processing rules (mostly
from 5903 but also add the checks if those are needed) and create new
RFC that will update 5996. This document should not include any
groups.

Then the question is what to do to 5114. The 5114 points to the 4753
and there is the problem that 4753 was modified with errata. This
means that 5114 is also affected by the same errata, meaning complient
implementatation should follow the same errata, i.e. the same format
that is defined in the 5903.

We should have made that 5903 to include also the 2 other groups from
the 5114, i.e. groups 25 and 26, and we really should have obsoleted
ALL ECP groups (19-21, 25-26) and allocated new numbers for all of
those. 

If that new document includes all ECDH processing rules, perhaps that
can be made to update all previous ECDH RFCs, and it can say all ECDH
curves use exactly same processing rules?
-- 
kivi...@iki.fi
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Johannes Merkle]

Hi Yaron,

> 
> OK, I see your point (no pun intended). Regarding ECDH secret reuse, can you 
> please review
> http://tools.ietf.org/html/rfc5996#section-2.12. That section was supposed to 
> cover the relevant security
> considerations. In fact I think your attack is alluded to in the paper we 
> reference from that section (see Sec. 5, first
> paragraph).
> 

I agree with you that this is a general issue that should be addressed 
generally. Yet, as a precaution, I could also
include such a requirement in the current draft.


> If this needs to become a MUST requirement for IKEv2 peers using ECDH, it 
> needs to be spelled out and not left as an
> exercise to the reader. But we have to understand whether this is a general 
> requirement, or it only applies to peers
> that are reusing ECDH private keys for multiple IKE sessions.
> 

If the ECDH key is chosen at random for each negotiation, then the attacker can 
only gain knowledge on the shared secret
and private key of the current negotiation. There is no other secret 
information involved that could be learned.

Johannes

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Yaron Sheffer]

Hi Scott,

OK, I see your point (no pun intended). Regarding ECDH secret reuse, can 
you please review http://tools.ietf.org/html/rfc5996#section-2.12. That 
section was supposed to cover the relevant security considerations. In 
fact I think your attack is alluded to in the paper we reference from 
that section (see Sec. 5, first paragraph).


If this needs to become a MUST requirement for IKEv2 peers using ECDH, 
it needs to be spelled out and not left as an exercise to the reader. 
But we have to understand whether this is a general requirement, or it 
only applies to peers that are reusing ECDH private keys for multiple 
IKE sessions.


Thanks,
Yaron

On 12/01/2012 08:44 PM, Scott Fluhrer (sfluhrer) wrote:

I would humbly disagree.  A peer might try to send us an invalid KE, with a 
bogus point that acts as if it were of small order with our implementation; let 
us call this bogus point P, and its small order n.  We would then generate sk's 
based on the point (e mod n)P (where e is the value of our ECDH secret); 
because n is small, that allows the attacker to recover the value (e mod n).

If we reuse the same ECDH secret for multiple exchanges (which is normally 
safe), this allows someone who controls some of the peers we talk to to recover 
the secret value for exchanges he does not control; this is not good.

Hence, we need to either mandate checking the point we receive, or forbid ECDH 
secret reuse.

-Original Message-
From: Yaron Sheffer [mailto:yaronf.i...@gmail.com]
Sent: Saturday, December 01, 2012 5:32 AM
To: Scott Fluhrer (sfluhrer)
Cc: Yoav Nir; Johannes Merkle; IPsecme WG; Manfred Lochter; Sean P. Turner; Dan 
Harkins; rfc-...@rfc-editor.org
Subject: Re: [IPsec] I-D on Using the ECC Brainpool Curves for IKEv2 Key 
Exchange

Actually, I think we have it wrong. There is no reason for a *valid* peer to 
send an incorrect KE. And IKEv2 already protects against a MITM doing such a 
thing. As we all know, the protocol assumes that messages
#3 and #4 can be observed by an attacker, and protects against malicious 
changes to any of the 4 messages, including the KE value.

In other words, I would say this is a QA-level test that MAY be performed by 
the sender. Not one that MUST be performed by the recipient.

By the way, there are related protocols that need this test for their security 
and do include it: SPSK, and my own RFC 6631 (IKEv2 with PACE).
See e.g. https://tools.ietf.org/html/rfc6631#section-3.4.

Thanks,
Yaron


On 12/01/2012 12:00 AM, Scott Fluhrer (sfluhrer) wrote:

With ECDH, there are two separate EC points that are output by the algorithm:

- There's the public value xG (where x is our secret); this is passed
in the KE payload
- There's the shared secret value xyG (where x is our shared secret, and y is 
the peer's secret); this is used in the key derivation function.

What RFC5903 says is:
- The public value xG will be expressed as explicit x, y coordinates.
- The shared secret value xyG (that is, the value we give to the sk generation 
function) will be only the x coordinate; the y coordinate will not be used.

Yes, this implies that doing point compression on the shared secret value 
doesn't make much sense (as point compression discards all but one bit of y -- 
the format that RFC5903 chooses already discards all the bits of y).  However, 
the argument about point compression was never about the shared secret value; 
instead, it was about the repesentation that appeared in the KE payload (that 
is, the one that is specified to have both the x and y coordinates).

As for Dan's question, it was about whether we should validate the public value 
we get from the peer, well, the public value does have explicit x and y 
coordinates, and so it makes sense to check them.


-Original Message-
From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf
Of Yoav Nir
Sent: Friday, November 30, 2012 4:39 PM
To: Johannes Merkle
Cc: IPsecme WG; Manfred Lochter; Sean P. Turner; Dan Harkins;
rfc-...@rfc-editor.org
Subject: Re: [IPsec] I-D on Using the ECC Brainpool Curves for IKEv2
Key Exchange

Hi Johannes,

Dan't question made me realise something I hadn't noticed before.

In section 2.3, the draft says:
 For the encoding of the key exchange payload and the derivation of
 the shared secret, the methods specified in [RFC5903] are adopted.

 In an ECP key exchange in IKEv2, the Diffie-Hellman public value
 passed in a KE payload consists of two components, x and y,

However, according to RFC 5903:
The Diffie-Hellman shared secret value consists of the x value of
the Diffie-Hellman common value.

In fact RFC 5903 replaced 4753 just to say that the encoding consists only of 
x, not both x and y.

This also relates to Dan't question. If the y value is missing, what is there 
to verify?

Yoav

On Nov 30, 2012, at 7:57 PM, Dan Harkins  wrote:



   Hi Johannes,

On Fri, Nov

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

[Scott Fluhrer (sfluhrer)]

I would humbly disagree.  A peer might try to send us an invalid KE, with a 
bogus point that acts as if it were of small order with our implementation; let 
us call this bogus point P, and its small order n.  We would then generate sk's 
based on the point (e mod n)P (where e is the value of our ECDH secret); 
because n is small, that allows the attacker to recover the value (e mod n).

If we reuse the same ECDH secret for multiple exchanges (which is normally 
safe), this allows someone who controls some of the peers we talk to to recover 
the secret value for exchanges he does not control; this is not good.

Hence, we need to either mandate checking the point we receive, or forbid ECDH 
secret reuse.

-Original Message-
From: Yaron Sheffer [mailto:yaronf.i...@gmail.com] 
Sent: Saturday, December 01, 2012 5:32 AM
To: Scott Fluhrer (sfluhrer)
Cc: Yoav Nir; Johannes Merkle; IPsecme WG; Manfred Lochter; Sean P. Turner; Dan 
Harkins; rfc-...@rfc-editor.org
Subject: Re: [IPsec] I-D on Using the ECC Brainpool Curves for IKEv2 Key 
Exchange

Actually, I think we have it wrong. There is no reason for a *valid* peer to 
send an incorrect KE. And IKEv2 already protects against a MITM doing such a 
thing. As we all know, the protocol assumes that messages
#3 and #4 can be observed by an attacker, and protects against malicious 
changes to any of the 4 messages, including the KE value.

In other words, I would say this is a QA-level test that MAY be performed by 
the sender. Not one that MUST be performed by the recipient.

By the way, there are related protocols that need this test for their security 
and do include it: SPSK, and my own RFC 6631 (IKEv2 with PACE). 
See e.g. https://tools.ietf.org/html/rfc6631#section-3.4.

Thanks,
Yaron


On 12/01/2012 12:00 AM, Scott Fluhrer (sfluhrer) wrote:
> With ECDH, there are two separate EC points that are output by the algorithm:
>
> - There's the public value xG (where x is our secret); this is passed 
> in the KE payload
> - There's the shared secret value xyG (where x is our shared secret, and y is 
> the peer's secret); this is used in the key derivation function.
>
> What RFC5903 says is:
> - The public value xG will be expressed as explicit x, y coordinates.
> - The shared secret value xyG (that is, the value we give to the sk 
> generation function) will be only the x coordinate; the y coordinate will not 
> be used.
>
> Yes, this implies that doing point compression on the shared secret value 
> doesn't make much sense (as point compression discards all but one bit of y 
> -- the format that RFC5903 chooses already discards all the bits of y).  
> However, the argument about point compression was never about the shared 
> secret value; instead, it was about the repesentation that appeared in the KE 
> payload (that is, the one that is specified to have both the x and y 
> coordinates).
>
> As for Dan's question, it was about whether we should validate the public 
> value we get from the peer, well, the public value does have explicit x and y 
> coordinates, and so it makes sense to check them.
>
>
> -Original Message-
> From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf 
> Of Yoav Nir
> Sent: Friday, November 30, 2012 4:39 PM
> To: Johannes Merkle
> Cc: IPsecme WG; Manfred Lochter; Sean P. Turner; Dan Harkins; 
> rfc-...@rfc-editor.org
> Subject: Re: [IPsec] I-D on Using the ECC Brainpool Curves for IKEv2 
> Key Exchange
>
> Hi Johannes,
>
> Dan't question made me realise something I hadn't noticed before.
>
> In section 2.3, the draft says:
> For the encoding of the key exchange payload and the derivation of
> the shared secret, the methods specified in [RFC5903] are adopted.
>
> In an ECP key exchange in IKEv2, the Diffie-Hellman public value
> passed in a KE payload consists of two components, x and y,
>
> However, according to RFC 5903:
>The Diffie-Hellman shared secret value consists of the x value of
>the Diffie-Hellman common value.
>
> In fact RFC 5903 replaced 4753 just to say that the encoding consists only of 
> x, not both x and y.
>
> This also relates to Dan't question. If the y value is missing, what is there 
> to verify?
>
> Yoav
>
> On Nov 30, 2012, at 7:57 PM, Dan Harkins  wrote:
>
>>
>>   Hi Johannes,
>>
>> On Fri, November 30, 2012 4:11 am, Johannes Merkle wrote:
>>> We have submitted a new revision of the Internet Draft on Using the 
>>> ECC Brainpool Curves (defined in RFC 5639) for IKEv2 Key Exchange 
>>> https://datatracker.ietf.org/doc/draft-merkle-ikev2-ke-brainpool/
>>>
>>> Since there was considerable objection to the point compression 
>>> method in the WG, w

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

[Yaron Sheffer]

Actually, I think we have it wrong. There is no reason for a *valid* 
peer to send an incorrect KE. And IKEv2 already protects against a MITM 
doing such a thing. As we all know, the protocol assumes that messages 
#3 and #4 can be observed by an attacker, and protects against 
malicious changes to any of the 4 messages, including the KE value.


In other words, I would say this is a QA-level test that MAY be 
performed by the sender. Not one that MUST be performed by the recipient.


By the way, there are related protocols that need this test for their 
security and do include it: SPSK, and my own RFC 6631 (IKEv2 with PACE). 
See e.g. https://tools.ietf.org/html/rfc6631#section-3.4.


Thanks,
Yaron


On 12/01/2012 12:00 AM, Scott Fluhrer (sfluhrer) wrote:

With ECDH, there are two separate EC points that are output by the algorithm:

- There's the public value xG (where x is our secret); this is passed in the KE 
payload
- There's the shared secret value xyG (where x is our shared secret, and y is 
the peer's secret); this is used in the key derivation function.

What RFC5903 says is:
- The public value xG will be expressed as explicit x, y coordinates.
- The shared secret value xyG (that is, the value we give to the sk generation 
function) will be only the x coordinate; the y coordinate will not be used.

Yes, this implies that doing point compression on the shared secret value 
doesn't make much sense (as point compression discards all but one bit of y -- 
the format that RFC5903 chooses already discards all the bits of y).  However, 
the argument about point compression was never about the shared secret value; 
instead, it was about the repesentation that appeared in the KE payload (that 
is, the one that is specified to have both the x and y coordinates).

As for Dan's question, it was about whether we should validate the public value 
we get from the peer, well, the public value does have explicit x and y 
coordinates, and so it makes sense to check them.


-Original Message-
From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Yoav 
Nir
Sent: Friday, November 30, 2012 4:39 PM
To: Johannes Merkle
Cc: IPsecme WG; Manfred Lochter; Sean P. Turner; Dan Harkins; 
rfc-...@rfc-editor.org
Subject: Re: [IPsec] I-D on Using the ECC Brainpool Curves for IKEv2 Key 
Exchange

Hi Johannes,

Dan't question made me realise something I hadn't noticed before.

In section 2.3, the draft says:
For the encoding of the key exchange payload and the derivation of
the shared secret, the methods specified in [RFC5903] are adopted.

In an ECP key exchange in IKEv2, the Diffie-Hellman public value
passed in a KE payload consists of two components, x and y,

However, according to RFC 5903:
   The Diffie-Hellman shared secret value consists of the x value of
   the Diffie-Hellman common value.

In fact RFC 5903 replaced 4753 just to say that the encoding consists only of 
x, not both x and y.

This also relates to Dan't question. If the y value is missing, what is there 
to verify?

Yoav

On Nov 30, 2012, at 7:57 PM, Dan Harkins  wrote:



  Hi Johannes,

On Fri, November 30, 2012 4:11 am, Johannes Merkle wrote:

We have submitted a new revision of the Internet Draft on Using the
ECC Brainpool Curves (defined in RFC 5639) for IKEv2 Key Exchange
https://datatracker.ietf.org/doc/draft-merkle-ikev2-ke-brainpool/

Since there was considerable objection to the point compression
method in the WG, we have removed this option altogether and define
only the uncompressed KE payload format, which is in full accordance
with RFC 5903.


Any feedback is welcome.


  I see that there is a requirement that an implementation MUST verify
that the D-H common value is not the point-at-infinity. Do you think
there should also be a requirement that an implementation MUST verify
that the x- and y-coordinates received from a peer satisfy the
equation of the negotiated curve (and abort the exchange if not)?

  regards,

  Dan.


___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec


___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Yoav Nir]

Right. I cut-and-pasted and didn't notice that it said "shared secret". Never 
mind. 


On Dec 1, 2012, at 12:00 AM, Scott Fluhrer (sfluhrer)  
wrote:

> With ECDH, there are two separate EC points that are output by the algorithm:
> 
> - There's the public value xG (where x is our secret); this is passed in the 
> KE payload
> - There's the shared secret value xyG (where x is our shared secret, and y is 
> the peer's secret); this is used in the key derivation function.
> 
> What RFC5903 says is:
> - The public value xG will be expressed as explicit x, y coordinates.
> - The shared secret value xyG (that is, the value we give to the sk 
> generation function) will be only the x coordinate; the y coordinate will not 
> be used.
> 
> Yes, this implies that doing point compression on the shared secret value 
> doesn't make much sense (as point compression discards all but one bit of y 
> -- the format that RFC5903 chooses already discards all the bits of y).  
> However, the argument about point compression was never about the shared 
> secret value; instead, it was about the repesentation that appeared in the KE 
> payload (that is, the one that is specified to have both the x and y 
> coordinates).
> 
> As for Dan's question, it was about whether we should validate the public 
> value we get from the peer, well, the public value does have explicit x and y 
> coordinates, and so it makes sense to check them.
> 
> 
> -Original Message-
> From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of 
> Yoav Nir
> Sent: Friday, November 30, 2012 4:39 PM
> To: Johannes Merkle
> Cc: IPsecme WG; Manfred Lochter; Sean P. Turner; Dan Harkins; 
> rfc-...@rfc-editor.org
> Subject: Re: [IPsec] I-D on Using the ECC Brainpool Curves for IKEv2 Key 
> Exchange
> 
> Hi Johannes,
> 
> Dan't question made me realise something I hadn't noticed before. 
> 
> In section 2.3, the draft says:
>   For the encoding of the key exchange payload and the derivation of
>   the shared secret, the methods specified in [RFC5903] are adopted.
> 
>   In an ECP key exchange in IKEv2, the Diffie-Hellman public value
>   passed in a KE payload consists of two components, x and y,
> 
> However, according to RFC 5903:
>  The Diffie-Hellman shared secret value consists of the x value of
>  the Diffie-Hellman common value.
> 
> In fact RFC 5903 replaced 4753 just to say that the encoding consists only of 
> x, not both x and y.
> 
> This also relates to Dan't question. If the y value is missing, what is there 
> to verify?
> 
> Yoav
> 
> On Nov 30, 2012, at 7:57 PM, Dan Harkins  wrote:
> 
>> 
>> Hi Johannes,
>> 
>> On Fri, November 30, 2012 4:11 am, Johannes Merkle wrote:
>>> We have submitted a new revision of the Internet Draft on Using the 
>>> ECC Brainpool Curves (defined in RFC 5639) for IKEv2 Key Exchange 
>>> https://datatracker.ietf.org/doc/draft-merkle-ikev2-ke-brainpool/
>>> 
>>> Since there was considerable objection to the point compression 
>>> method in the WG, we have removed this option altogether and define 
>>> only the uncompressed KE payload format, which is in full accordance 
>>> with RFC 5903.
>>> 
>>> 
>>> Any feedback is welcome.
>> 
>> I see that there is a requirement that an implementation MUST verify 
>> that the D-H common value is not the point-at-infinity. Do you think 
>> there should also be a requirement that an implementation MUST verify 
>> that the x- and y-coordinates received from a peer satisfy the 
>> equation of the negotiated curve (and abort the exchange if not)?
>> 
>> regards,
>> 
>> Dan.
> 
> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
> 
> Email secured by Check Point

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Dan Harkins]

On Fri, November 30, 2012 1:03 pm, Yaron Sheffer wrote:
> The problem I have with this discussion is, this check (if really
> required) should have been in the base protocol, because the protocol
> has supported EC groups from day one. It doesn't belong in a specific
> curve definition. We could use the errata process to add it. It's not
> ideal, but certainly better than republishing RFC 5996.

  Yes, this check is required for the reasons Scott explained.

  I think "the protocol has supported EC groups from day one" is a
bit of an overstatement. EC support was poorly defined as the protocol
says that g^ir is the shared secret and it's an octet string. That's it.
Many people who were familiar with ECDH assumed that, when doing
ECDH, that octet string is just the x-coordinate of the point that
results from completing the exchange. (Note: it's bad for protocols
to leave it up to the reader to assume).

  Then along came RFC 4753 that said the concatenation of the x-
and y-coordinates (in that order) was the thing that was "used in the
formation of SKEYSEED." Well that screwed up all the people who
(rightly) assumed that it was just the x-coordinate. This was realized
a bit late so now we have RFC 5903 which obsoletes RFC 4753 that
says the ECDH shared secret is the x-coordinate. Unfortunately,
RFC 5114 adds two more ECP groups-- 25 and 26- but says that
the format of the shared secret for them is per 4753, i.e. the wrong
way. And RFC 5114 has not (yet) been obsoleted to fix that.

  So we can have an IKEv2-compliant implementation from prior to
June 2010 that will not interoperate with an IKEv2-compliant
implementation after June 2010. And to be a truly RFC-compliant
implementation it would mean that you represent the ECDH shared
secret differently for P256 and P224. Yuck, what a mess. A recipe
for spagetti code.

  RFC 5996 followed this mess but did nothing to specify what is
the right behavior for ECDH while it was obsoleting RFC 4306.

  While I tend to agree that specification of this critical issue should
not be left to the RFC that defines the curve that horse has already
left the barn for IKEv2. As far as republishing RFC 5996 is concerned,
I think a better approach would be to acknowledge that interoperability
is problematic with IKEv2 and there's not much we can do about it now,
so the best way to proceed is to obsolete it before it gets traction in
the field. And I know a draft that can do just that!

  regards,

  Dan.

> Thanks,
>   Yaron
>
> On 11/30/2012 08:26 PM, Scott Fluhrer (sfluhrer) wrote:
>> There should *absolutely* be a requirement that any point you receive
>> from the peer is actually a point on the curve.
>>
>> What can happen if you don't?  Well, that depends on the implementation
>> of the point addition/doubling; what happens with the normal
>> implementation is that it acts as if it was a different curve with a
>> different curve order -- this means that someone introducing a bogus
>> value can give us a point with a small order (which can't happen with
>> the normal Brainpool curves, because those curves have prime orders).
>>
>> In addition, validating the values is cheap; easily worth the gain.
>>
>>
>> Also, given the you validate the peer's value, and forbid public points
>> which are the point-at-infinity, doubling checking that the D-H common
>> value is not the point at infinity appears to be unneeded.  The
>> Brainpool Curves are (again) of prime order; this implies that the D-H
>> common value is the point at infinity only if the peer's public value is
>> the point at infinity (which ought to be forbidden), or our secret value
>> is a multiple of the curve order (in which case, our public value is the
>> point at infinity).
>>
>>
>> -Original Message-
>> From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf
>> Of Dan Harkins
>> Sent: Friday, November 30, 2012 12:57 PM
>> To: Johannes Merkle
>> Cc: IPsecme WG; Manfred Lochter; Turner, Sean P.; rfc-...@rfc-editor.org
>> Subject: Re: [IPsec] I-D on Using the ECC Brainpool Curves for IKEv2 Key
>> Exchange
>>
>>
>>Hi Johannes,
>>
>> On Fri, November 30, 2012 4:11 am, Johannes Merkle wrote:
>>> We have submitted a new revision of the Internet Draft on Using the
>>> ECC Brainpool Curves (defined in RFC 5639) for IKEv2 Key Exchange
>>> https://datatracker.ietf.org/doc/draft-merkle-ikev2-ke-brainpool/
>>>
>>> Since there was considerable objection to the point compression method
>>> in the WG, we have removed this option altogether and define only the
>>> uncompressed KE payload format, which is in full accordance with

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

[Scott Fluhrer (sfluhrer)]

With ECDH, there are two separate EC points that are output by the algorithm:

- There's the public value xG (where x is our secret); this is passed in the KE 
payload
- There's the shared secret value xyG (where x is our shared secret, and y is 
the peer's secret); this is used in the key derivation function.

What RFC5903 says is:
- The public value xG will be expressed as explicit x, y coordinates.
- The shared secret value xyG (that is, the value we give to the sk generation 
function) will be only the x coordinate; the y coordinate will not be used.

Yes, this implies that doing point compression on the shared secret value 
doesn't make much sense (as point compression discards all but one bit of y -- 
the format that RFC5903 chooses already discards all the bits of y).  However, 
the argument about point compression was never about the shared secret value; 
instead, it was about the repesentation that appeared in the KE payload (that 
is, the one that is specified to have both the x and y coordinates).

As for Dan's question, it was about whether we should validate the public value 
we get from the peer, well, the public value does have explicit x and y 
coordinates, and so it makes sense to check them.


-Original Message-
From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Yoav 
Nir
Sent: Friday, November 30, 2012 4:39 PM
To: Johannes Merkle
Cc: IPsecme WG; Manfred Lochter; Sean P. Turner; Dan Harkins; 
rfc-...@rfc-editor.org
Subject: Re: [IPsec] I-D on Using the ECC Brainpool Curves for IKEv2 Key 
Exchange

Hi Johannes,

Dan't question made me realise something I hadn't noticed before. 

In section 2.3, the draft says:
   For the encoding of the key exchange payload and the derivation of
   the shared secret, the methods specified in [RFC5903] are adopted.

   In an ECP key exchange in IKEv2, the Diffie-Hellman public value
   passed in a KE payload consists of two components, x and y,

However, according to RFC 5903:
  The Diffie-Hellman shared secret value consists of the x value of
  the Diffie-Hellman common value.

In fact RFC 5903 replaced 4753 just to say that the encoding consists only of 
x, not both x and y.

This also relates to Dan't question. If the y value is missing, what is there 
to verify?

Yoav

On Nov 30, 2012, at 7:57 PM, Dan Harkins  wrote:

> 
>  Hi Johannes,
> 
> On Fri, November 30, 2012 4:11 am, Johannes Merkle wrote:
>> We have submitted a new revision of the Internet Draft on Using the 
>> ECC Brainpool Curves (defined in RFC 5639) for IKEv2 Key Exchange 
>> https://datatracker.ietf.org/doc/draft-merkle-ikev2-ke-brainpool/
>> 
>> Since there was considerable objection to the point compression 
>> method in the WG, we have removed this option altogether and define 
>> only the uncompressed KE payload format, which is in full accordance 
>> with RFC 5903.
>> 
>> 
>> Any feedback is welcome.
> 
>  I see that there is a requirement that an implementation MUST verify 
> that the D-H common value is not the point-at-infinity. Do you think 
> there should also be a requirement that an implementation MUST verify 
> that the x- and y-coordinates received from a peer satisfy the 
> equation of the negotiated curve (and abort the exchange if not)?
> 
>  regards,
> 
>  Dan.

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Yoav Nir]

Hi Johannes,

Dan't question made me realise something I hadn't noticed before. 

In section 2.3, the draft says:
   For the encoding of the key exchange payload and the derivation of
   the shared secret, the methods specified in [RFC5903] are adopted.

   In an ECP key exchange in IKEv2, the Diffie-Hellman public value
   passed in a KE payload consists of two components, x and y,

However, according to RFC 5903:
  The Diffie-Hellman shared secret value consists of the x value of
  the Diffie-Hellman common value.

In fact RFC 5903 replaced 4753 just to say that the encoding consists only of 
x, not both x and y.

This also relates to Dan't question. If the y value is missing, what is there 
to verify?

Yoav

On Nov 30, 2012, at 7:57 PM, Dan Harkins  wrote:

> 
>  Hi Johannes,
> 
> On Fri, November 30, 2012 4:11 am, Johannes Merkle wrote:
>> We have submitted a new revision of the Internet Draft on
>> Using the ECC Brainpool Curves (defined in RFC 5639) for IKEv2 Key
>> Exchange
>> https://datatracker.ietf.org/doc/draft-merkle-ikev2-ke-brainpool/
>> 
>> Since there was considerable objection to the point compression method in
>> the WG, we have removed this option altogether
>> and define only the uncompressed KE payload format, which is in full
>> accordance with RFC 5903.
>> 
>> 
>> Any feedback is welcome.
> 
>  I see that there is a requirement that an implementation MUST verify
> that the D-H common value is not the point-at-infinity. Do you think
> there should also be a requirement that an implementation MUST verify
> that the x- and y-coordinates received from a peer satisfy the equation
> of the negotiated curve (and abort the exchange if not)?
> 
>  regards,
> 
>  Dan.

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Yaron Sheffer]

The problem I have with this discussion is, this check (if really 
required) should have been in the base protocol, because the protocol 
has supported EC groups from day one. It doesn't belong in a specific 
curve definition. We could use the errata process to add it. It's not 
ideal, but certainly better than republishing RFC 5996.


Thanks,
Yaron

On 11/30/2012 08:26 PM, Scott Fluhrer (sfluhrer) wrote:

There should *absolutely* be a requirement that any point you receive from the 
peer is actually a point on the curve.

What can happen if you don't?  Well, that depends on the implementation of the 
point addition/doubling; what happens with the normal implementation is that it 
acts as if it was a different curve with a different curve order -- this means 
that someone introducing a bogus value can give us a point with a small order 
(which can't happen with the normal Brainpool curves, because those curves have 
prime orders).

In addition, validating the values is cheap; easily worth the gain.


Also, given the you validate the peer's value, and forbid public points which 
are the point-at-infinity, doubling checking that the D-H common value is not 
the point at infinity appears to be unneeded.  The Brainpool Curves are (again) 
of prime order; this implies that the D-H common value is the point at infinity 
only if the peer's public value is the point at infinity (which ought to be 
forbidden), or our secret value is a multiple of the curve order (in which 
case, our public value is the point at infinity).


-Original Message-
From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Dan 
Harkins
Sent: Friday, November 30, 2012 12:57 PM
To: Johannes Merkle
Cc: IPsecme WG; Manfred Lochter; Turner, Sean P.; rfc-...@rfc-editor.org
Subject: Re: [IPsec] I-D on Using the ECC Brainpool Curves for IKEv2 Key 
Exchange


   Hi Johannes,

On Fri, November 30, 2012 4:11 am, Johannes Merkle wrote:

We have submitted a new revision of the Internet Draft on Using the
ECC Brainpool Curves (defined in RFC 5639) for IKEv2 Key Exchange
https://datatracker.ietf.org/doc/draft-merkle-ikev2-ke-brainpool/

Since there was considerable objection to the point compression method
in the WG, we have removed this option altogether and define only the
uncompressed KE payload format, which is in full accordance with RFC
5903.


Any feedback is welcome.


   I see that there is a requirement that an implementation MUST verify that 
the D-H common value is not the point-at-infinity. Do you think there should 
also be a requirement that an implementation MUST verify that the x- and 
y-coordinates received from a peer satisfy the equation of the negotiated curve 
(and abort the exchange if not)?

   regards,

   Dan.


___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec


___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Scott Fluhrer (sfluhrer)]

There should *absolutely* be a requirement that any point you receive from the 
peer is actually a point on the curve.

What can happen if you don't?  Well, that depends on the implementation of the 
point addition/doubling; what happens with the normal implementation is that it 
acts as if it was a different curve with a different curve order -- this means 
that someone introducing a bogus value can give us a point with a small order 
(which can't happen with the normal Brainpool curves, because those curves have 
prime orders).

In addition, validating the values is cheap; easily worth the gain.


Also, given the you validate the peer's value, and forbid public points which 
are the point-at-infinity, doubling checking that the D-H common value is not 
the point at infinity appears to be unneeded.  The Brainpool Curves are (again) 
of prime order; this implies that the D-H common value is the point at infinity 
only if the peer's public value is the point at infinity (which ought to be 
forbidden), or our secret value is a multiple of the curve order (in which 
case, our public value is the point at infinity).


-Original Message-
From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Dan 
Harkins
Sent: Friday, November 30, 2012 12:57 PM
To: Johannes Merkle
Cc: IPsecme WG; Manfred Lochter; Turner, Sean P.; rfc-...@rfc-editor.org
Subject: Re: [IPsec] I-D on Using the ECC Brainpool Curves for IKEv2 Key 
Exchange


  Hi Johannes,

On Fri, November 30, 2012 4:11 am, Johannes Merkle wrote:
> We have submitted a new revision of the Internet Draft on Using the 
> ECC Brainpool Curves (defined in RFC 5639) for IKEv2 Key Exchange 
> https://datatracker.ietf.org/doc/draft-merkle-ikev2-ke-brainpool/
>
> Since there was considerable objection to the point compression method 
> in the WG, we have removed this option altogether and define only the 
> uncompressed KE payload format, which is in full accordance with RFC 
> 5903.
>
>
> Any feedback is welcome.

  I see that there is a requirement that an implementation MUST verify that the 
D-H common value is not the point-at-infinity. Do you think there should also 
be a requirement that an implementation MUST verify that the x- and 
y-coordinates received from a peer satisfy the equation of the negotiated curve 
(and abort the exchange if not)?

  regards,

  Dan.


___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Dan Harkins]

  Hi Johannes,

On Fri, November 30, 2012 4:11 am, Johannes Merkle wrote:
> We have submitted a new revision of the Internet Draft on
> Using the ECC Brainpool Curves (defined in RFC 5639) for IKEv2 Key
> Exchange
> https://datatracker.ietf.org/doc/draft-merkle-ikev2-ke-brainpool/
>
> Since there was considerable objection to the point compression method in
> the WG, we have removed this option altogether
> and define only the uncompressed KE payload format, which is in full
> accordance with RFC 5903.
>
>
> Any feedback is welcome.

  I see that there is a requirement that an implementation MUST verify
that the D-H common value is not the point-at-infinity. Do you think
there should also be a requirement that an implementation MUST verify
that the x- and y-coordinates received from a peer satisfy the equation
of the negotiated curve (and abort the exchange if not)?

  regards,

  Dan.


___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Johannes Merkle]

We have submitted a new revision of the Internet Draft on
Using the ECC Brainpool Curves (defined in RFC 5639) for IKEv2 Key Exchange
https://datatracker.ietf.org/doc/draft-merkle-ikev2-ke-brainpool/

Since there was considerable objection to the point compression method in the 
WG, we have removed this option altogether
and define only the uncompressed KE payload format, which is in full accordance 
with RFC 5903.


Any feedback is welcome.

-- 
Johannes
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Tero Kivinen]

David McGrew (mcgrew) writes:
> >Just a note: the relative saving of point compression is larger when
> >sending hash + URL instead of the CERT.
> 
> What's the scenario here?   If hash + URL is sent, the certificate still
> has to be retrieved.

Usually not, as it is already cached in the client. I.e. it only needs
to fetched first time unknown hash is seen. After fetching it first
time, and validating the cert the recipient of the hash + URL does not
need to fetch it again when the same peer connects later.

In most cases the devices talking to each other using IPsec is quite
small set of devices, so caching their certificates does not take too
much resources (especially if you just store the public key, hash and
end of validity time (i.e. when you need to do something next time,
either fetch CRL, or revalidate the cert because it expired etc). 

> It might not be part of the IKE exchange, but moving it to HTTP
> doesn't mean that it doesn't contribute to bytes on the wire (or
> over the air, in the case of wireless).

The another reason for this feature in IKEv2 is to make the IKE_AUTH
packet smaller, so it does not need to be fragmented. IKE_AUTH packet
is UDP and there are some problems in some environments if it gets too
big and starts to get fragmented. This option moves big parts of the
IKE_AUTH packet away from UDP packet to separete TCP session.
-- 
kivi...@iki.fi
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Yoav Nir]

On Nov 8, 2012, at 4:24 PM, David McGrew (mcgrew) wrote:

> 
> 
> On 11/8/12 3:26 AM, "Johannes Merkle"  wrote:
> 
>> Hi Tero,
>> 
>>> Every single option adds complexity, so I do not think we should add
>>> more optional things.
>> 
>> Point compression is not the focus of our draft. Given the opposition it
>> is facing here, I suggest to wait for further
>> replies and if point compression turns out to be objected by the majority
>> on this list, I will not insist on this feature.
>> BTW: In an earlier thread Dan Haskins has already indicated his
>> preference to leave point compression out.
>> 
>>> 
>>> Not sending the CERT, but replacing it with hash and url offers much
>>> bigger savings, and people are not even doing that.
>> You can not be sure that this option isn't used is some constrained
>> environments.
>> 
>> Just a note: the relative saving of point compression is larger when
>> sending hash + URL instead of the CERT.
> 
> What's the scenario here?   If hash + URL is sent, the certificate still
> has to be retrieved.  It might not be part of the IKE exchange, but moving
> it to HTTP doesn't mean that it doesn't contribute to bytes on the wire
> (or over the air, in the case of wireless).
> 

Since we tend to meet the same people all the time (or communicate with the 
same parties), usually the hash+URL would lead to retrieving the certificate 
from a cache, rather than from a remote web server.

Of course, if my implementation is running on a "thing", it doesn't have a 
cache and this argument doesn't apply.

Yoav


___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[David McGrew (mcgrew)]

On 11/8/12 3:26 AM, "Johannes Merkle"  wrote:

>Hi Tero,
>
>> Every single option adds complexity, so I do not think we should add
>> more optional things.
>
>Point compression is not the focus of our draft. Given the opposition it
>is facing here, I suggest to wait for further
>replies and if point compression turns out to be objected by the majority
>on this list, I will not insist on this feature.
>BTW: In an earlier thread Dan Haskins has already indicated his
>preference to leave point compression out.
>
>> 
>> Not sending the CERT, but replacing it with hash and url offers much
>> bigger savings, and people are not even doing that.
>You can not be sure that this option isn't used is some constrained
>environments.
>
>Just a note: the relative saving of point compression is larger when
>sending hash + URL instead of the CERT.

What's the scenario here?   If hash + URL is sent, the certificate still
has to be retrieved.  It might not be part of the IKE exchange, but moving
it to HTTP doesn't mean that it doesn't contribute to bytes on the wire
(or over the air, in the case of wireless).

David

>
>> 
>> Note, that negotiating the use of point compression without retry or
>> not would waste more bytes then the point compression saves... The KE
>> payload is in the first packet, which means that to be able to
>> negotiate it beforehand would require one extra roundtrip. The IKEv2
>> headers + notify payloads etc would be 2 * (28 + 8 bytes) = 72 bytes
>> which is already quite big EC key Y part...
>
>What I had in mind are constraint environments where using bandwidth
>saving techniques like point compression can be
>assumed to be the default.
>
>
>> If I remember right the reason IKEv2 does not use point compression
>> for the current groups was that there was some IPR. Is that issue
>> already been cleared?
>
>The the patent expires in 2014.
>http://cr.yp.to/patents/us/6141420.html
>
>-- 
>Johannes

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Dan Harkins]

  Hi Derek,

On Wed, November 7, 2012 10:27 am, Derek Atkins wrote:
> Hi,
>
> On Wed, November 7, 2012 1:21 pm, Johannes Merkle wrote:
>> Hi David,
>>
>> 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.
>
> You're making the assumption that an implementor is using OpenSSL or has
> already implemented point compression.  IMHO that is not a reasonable
> assumption.  Many implementations use their own crypto libraries and
> therefore would have to implement these compression and expansion
> functions, including all the potential errors thereto.  So saying "it's
> easy, it's in OpenSSL" is not, IMHO, a reassuring statement or argument.

  Decompression is just a square root and a discriminator to say whether
the result is y or -y. All the brainpool curves are of the form p mod 4 = 3,
where p is the prime defining the curve. For such curves the square root
of n would be n^((p+1)/4) mod p. This is straightforward to implement
with any big number library.

  regards,

  Dan.




___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Derek Atkins]

Hi,

On Wed, November 7, 2012 1:21 pm, Johannes Merkle wrote:
> Hi David,
>
> 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.

You're making the assumption that an implementor is using OpenSSL or has
already implemented point compression.  IMHO that is not a reasonable
assumption.  Many implementations use their own crypto libraries and
therefore would have to implement these compression and expansion
functions, including all the potential errors thereto.  So saying "it's
easy, it's in OpenSSL" is not, IMHO, a reassuring statement or argument.

-derek

-- 
   Derek Atkins 617-623-3745
   de...@ihtfp.com www.ihtfp.com
   Computer and Internet Security Consultant

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Johannes Merkle]

Hi Tero,

> Every single option adds complexity, so I do not think we should add
> more optional things. 

Point compression is not the focus of our draft. Given the opposition it is 
facing here, I suggest to wait for further
replies and if point compression turns out to be objected by the majority on 
this list, I will not insist on this feature.
BTW: In an earlier thread Dan Haskins has already indicated his preference to 
leave point compression out.

> 
> Not sending the CERT, but replacing it with hash and url offers much
> bigger savings, and people are not even doing that.
You can not be sure that this option isn't used is some constrained 
environments.

Just a note: the relative saving of point compression is larger when sending 
hash + URL instead of the CERT.

> 
> Note, that negotiating the use of point compression without retry or
> not would waste more bytes then the point compression saves... The KE
> payload is in the first packet, which means that to be able to
> negotiate it beforehand would require one extra roundtrip. The IKEv2
> headers + notify payloads etc would be 2 * (28 + 8 bytes) = 72 bytes
> which is already quite big EC key Y part... 

What I had in mind are constraint environments where using bandwidth saving 
techniques like point compression can be
assumed to be the default.


> If I remember right the reason IKEv2 does not use point compression
> for the current groups was that there was some IPR. Is that issue
> already been cleared?

The the patent expires in 2014.
http://cr.yp.to/patents/us/6141420.html

-- 
Johannes
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Tero Kivinen]

Johannes Merkle writes:
> 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). 

Every single option adds complexity, so I do not think we should add
more optional things. 

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

You can replace X.509 cert in CERT payload with hash and url, which
will make the payload to be around 60 bytes or so depending on the
length of the url used (5 bytes for header + 20 bytes for hash, and 29
bytes for url in format of "http://123.123.123.123:1234/";). Bit more
if the URL has IPv6 address.

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

Not sending the CERT, but replacing it with hash and url offers much
bigger savings, and people are not even doing that.

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

Note, that negotiating the use of point compression without retry or
not would waste more bytes then the point compression saves... The KE
payload is in the first packet, which means that to be able to
negotiate it beforehand would require one extra roundtrip. The IKEv2
headers + notify payloads etc would be 2 * (28 + 8 bytes) = 72 bytes
which is already quite big EC key Y part... 

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

I would prefer not to do that.

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

If I remember right the reason IKEv2 does not use point compression
for the current groups was that there was some IPR. Is that issue
already been cleared?
-- 
kivi...@iki.fi
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Johannes Merkle]

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 Gr

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

[David McGrew (mcgrew)]

Hi Johannes,

On 11/7/12 6:57 AM, "Johannes Merkle"  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
).

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

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

[Johannes Merkle]

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

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.

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

Johannes

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[David McGrew (mcgrew)]

Hi Johannes,

Some quick comments:

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.

The paragraph starting "The corresponding twisted curves ..." is a
distinct and self-contained topic.  I suggest putting it into its own
section.  


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

David

On 11/5/12 8:35 AM, "Johannes Merkle"  wrote:

>We have submitted a new revision of the Internet Draft Using the ECC
>Brainpool Curves (defined in RFC 5639) for IKEv2
>Key Exchange
>https://datatracker.ietf.org/doc/draft-merkle-ikev2-ke-brainpool/
>
>Last week, this draft has also been submitted to the Independent
>Submission Editor.
>
>The draft specifies 4 new code points for the IKEv2 transform ID registry
>(224, 256, 384 and 512 bit curve) and
>specifies the encoding of the KE payload with and without point
>compression. The test vectors are shared with Dan's
>draft on IKEv1 
>http://tools.ietf.org/html/draft-harkins-brainpool-ike-groups-01. I have
>removed the "twisted curves" and
>included a note how to use them internally (for efficient implementation)
>using input / output transformations.
>
>Any feedback is welcome.
>
>-- 
>Johannes
>___
>IPsec mailing list
>IPsec@ietf.org
>https://www.ietf.org/mailman/listinfo/ipsec

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Johannes Merkle]

We have submitted a new revision of the Internet Draft Using the ECC Brainpool 
Curves (defined in RFC 5639) for IKEv2
Key Exchange
https://datatracker.ietf.org/doc/draft-merkle-ikev2-ke-brainpool/

Last week, this draft has also been submitted to the Independent Submission 
Editor.

The draft specifies 4 new code points for the IKEv2 transform ID registry (224, 
256, 384 and 512 bit curve) and
specifies the encoding of the KE payload with and without point compression. 
The test vectors are shared with Dan's
draft on IKEv1 
http://tools.ietf.org/html/draft-harkins-brainpool-ike-groups-01. I have 
removed the "twisted curves" and
included a note how to use them internally (for efficient implementation) using 
input / output transformations.

Any feedback is welcome.

-- 
Johannes
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec