Subject: [IPsec] Using ECC Brainpool curves with ipsec

From: Johannes Merkle <[email-masked]>
Date: Tue, 03 Jul 2012 17:59:27 +0200

Hi,

in RFC 5639, we have specified a new set of elliptic curve parameters for use in cryptographic applications. Meanwhile,
support for these "Brainpool Curves" has been included in some crypto libraries as openssl (recently) and crypto++.
However, in order to use the Brainpool Curves with IKE and IPSec, still some specifications and IANA registry updates
are needed. We are now planning to prepare such an RFC to allow usage of the ECC Brainpool curves with ipsec.

In order to go forward with this effort, we would like to discuss some questions and potential issues. The WG feedback
on these is most appreciated.

[Question 0] Is the WG interested in shepherding an RFC specifying all that's necessary to use the Brainpool curves in
ipsec? And what category would be preferred, standard track or informational.

[Question 1] Should we include IKEv1 in the specs as well? It seems that some people in the WG do not like the idea of
updating this obsolete protocol. On the other hand, many applications still use IKEv1 and specifying the use of the
Brainpool curves only for IKEv2 would exclude these.

[Question 2] If IKEv1 is to be considered, the registry for IPSEC Authentication Methods (Value 3) needs to be updated,
because the values for ECDSA are specific for each curve. What policy for updating this IANA registry can be assumed?
IANA currently requires a standard track RFC, but there has recently been some discussion on relaxing this, in
particular, http://www.ietf.org/mail-archive/web/ipsec/current/msg07428.html and
http://www.ietf.org/mail-archive/web/ipsec/current/msg07654.html .
For the corresponding IKEv2 registry (Auth Method), only Expert Review is required.

[Question 3] If IKEv1 is to be considered, it seems reasonable to write only one RFC covering IKEv1 and IKEv2. Actually,
we also plan to prepare analogous specifications for TLS, so an option would be to write a common RFC for IKE and TLS
analogously to RFC 5114. However, according to the update policy of the IANA registry EC Named Curve for TLS, such an
RFC would have to be shepherded by the tls WG. Does this prevent or considerably complicate the creation of a joint RFC
for IKE and TLS? Would preparing separate RFCs for IKE and TLS be preferable?

[Question 4] In RFC 5639, for each of the bit lengths 160, 192, 224, 256, 320, 384, 512 two curves are defined, one
being the “quadratic twist” of the other – their algebraic structure (and hence, security level) is equivalent, but one
of them allows particular efficient arithmetic. In order to leave the choice of the curve for a given bit length to the
implementation we propose to register IANA values (for Auth method and Diffie-Hellman Group) for both curves for each
bit length. Of course, this doubles the number of number assignments. Any objections on this?

[Question 5] In Germany, not only ECDSA is in use with IKE and IPSec but also ECGDSA (Elliptic Curve German Digital
Signature Algorithm) according to ISO 14888-3, which is a slight variant of ECDSA. The advantage of ECGDSA over ECDSA is
that signature generation does not need any inversion modulo the group order, which removes the necessity of
corresponding code. This advantage is particularly interesting when using devices with limited computation power and
storage like smart cards or electronic control units in cars. In particular, car manufacturers have expressed their
desire to deviate from EDSA For this reason, we would like to specify values for ECGDSA (with the individual bit lengths
and curves) as Authentication Method as well. Would the WG support inclusion of this additional signature algorithm?

[Question 6] In cryptographic applications using elliptic curves, point compression (see Section 4.2 in RFC 6090) is
frequently used in particular in environments with limited bandwidth and storage capacity. However, in IKE this
mechanism is currently not supported as, according to RFC 5903, the KE payload consists of the concatenation of two
components, x and y, each of which having the same length as the underlying finite field. We propose to add support for
point compression for the KE Payload to IKE by allowing also the use of a compressed form of x, e.g. of 64 bits,
representing only the least significant bit. In contrast to the (obsolete) draft-ietf-ipsec-ike-ecc-groups-10, RFC 5903
does not specify a data format for the ECDH KE payload in which the uncompressed form is explicitly specified (e.g. in a
leading byte), uncompressed and compressed form could only be implicitly distinguished by their bit length (as specified
in the KE header). Does this raise any issue with implementations? What are your opinions and preferences?

Johannes
--
Johannes Merkle
secunet Security Networks AG
[email-masked]
www.secunet.com

---

From: "Dan Harkins" <[email-masked]>
Date: Mon, 9 Jul 2012 09:50:30 -0700 (PDT)

Hello,

On Tue, July 3, 2012 8:59 am, Johannes Merkle wrote:
> Hi,
>
> in RFC 5639, we have specified a new set of elliptic curve parameters for
> use in cryptographic applications. Meanwhile,
> support for these "Brainpool Curves" has been included in some crypto
> libraries as openssl (recently) and crypto++.
> However, in order to use the Brainpool Curves with IKE and IPSec, still
> some specifications and IANA registry updates

  I think that's a great idea.

> In order to go forward with this effort, we would like to discuss some
> questions and potential issues. The WG feedback
> [Question 0] Is the WG interested in shepherding an RFC specifying all
> that's necessary to use the Brainpool curves in

  I can't speak for the group but I would like to see an RFC that defines the
IANA considerations for using these curves in IKE. Informational is probably
fine unless the answer to question 2 below requires Standards Track.

> [Question 1] Should we include IKEv1 in the specs as well? It seems that
> some people in the WG do not like the idea of
> updating this obsolete protocol. On the other hand, many applications
> still use IKEv1 and specifying the use of the

  Absolutely yes. There are still a lot of IKEv1 implementations out there
and also there are other protocols that use the IANA registry from IKEv1,
namely IEEE 802.11-2012. Any curve that you add to the IKEv2 registry
has to be added to the IKEv1 registry.

> [Question 2] If IKEv1 is to be considered, the registry for IPSEC
> Authentication Methods (Value 3) needs to be updated,
> because the values for ECDSA are specific for each curve. What policy for
> updating this IANA registry can be assumed?
> particular,
> http://www.ietf.org/mail-archive/web/ipsec/current/msg07428.html and

  Hopefully that will be relaxed.

> [Question 3] If IKEv1 is to be considered, it seems reasonable to write
> only one RFC covering IKEv1 and IKEv2. Actually,
> we also plan to prepare analogous specifications for TLS, so an option
> would be to write a common RFC for IKE and TLS
> analogously to RFC 5114. However, according to the update policy of the
> IANA registry EC Named Curve for TLS, such an
> RFC would have to be shepherded by the tls WG. Does this prevent or
> considerably complicate the creation of a joint RFC

  This seems reasonable. The body of the RFC will probably just be IANA
considerations. The domain parameter sets of the curves are already defined
so you just need to get IANA to allocate magic numbers for their use.

> [Question 4] In RFC 5639, for each of the bit lengths 160, 192, 224, 256,
> 320, 384, 512 two curves are defined, one
> being the “quadratic twist” of the other – their algebraic structure
> (and hence, security level) is equivalent, but one
> of them allows particular efficient arithmetic. In order to leave the
> choice of the curve for a given bit length to the
> implementation we propose to register IANA values (for Auth method and
> Diffie-Hellman Group) for both curves for each

  There's approximately 65k available assignments so this shouldn't be a
problem. Why would anyone want to do the untwisted version if the twisted on
is more efficient? Are there any IPR considerations to the twisted version?

> [Question 5] In Germany, not only ECDSA is in use with IKE and IPSec but
> also ECGDSA (Elliptic Curve German Digital
> Signature Algorithm) according to ISO 14888-3, which is a slight variant
> of ECDSA. The advantage of ECGDSA over ECDSA is
> corresponding code. This advantage is particularly interesting when using
> devices with limited computation power and
> storage like smart cards or electronic control units in cars. In
> particular, car manufacturers have expressed their
> desire to deviate from EDSA For this reason, we would like to specify
> values for ECGDSA (with the individual bit lengths
> and curves) as Authentication Method as well. Would the WG support
> inclusion of this additional signature algorithm?

  Unless this got wider acceptance my personal take is: pass.

> [Question 6] In cryptographic applications using elliptic curves, point
> compression (see Section 4.2 in RFC 6090) is
> mechanism is currently not supported as, according to RFC 5903, the KE
> payload consists of the concatenation of two
> components, x and y, each of which having the same length as the
> underlying finite field. We propose to add support for
> representing only the least significant bit. In contrast to the (obsolete)
> draft-ietf-ipsec-ike-ecc-groups-10, RFC 5903
> does not specify a data format for the ECDH KE payload in which the
> uncompressed form is explicitly specified (e.g. in a
> leading byte), uncompressed and compressed form could only be implicitly
> distinguished by their bit length (as specified

  My preference would be to leave the KE payload alone.

  regards,

  Dan.

> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
>

---

From: Johannes Merkle <[email-masked]>
Date: Mon, 09 Jul 2012 19:12:51 +0200

Dan,

thanks for your reply. You happen to be the first one.
See my comments below.

> has to be added to the IKEv1 registry.
This is also our perception but we would prefer a WG consensus on that.

> is more efficient? Are there any IPR considerations to the twisted version?

A similar question has been raised as response to my analogous posting on the tls mailing list.
The reason why some people might prefer the "normal" curves is that for these it is easier to avoid patents. This is
always a big issue with ECC. While the Brainpool curves avoid special primes to facilitate patent-free implementations,
we still wanted to leave the implementors a choice between "fast" and "slower but more patent-safe" by introducing the
quadratic twist.

>   My preference would be to leave the KE payload alone.

So, you mean not to allow point compression? Our proposal is *not* to change the KE payload syntax but only to allow
variation in its bit length and to define rules for interpretation depending on its length. This means merely an
extension of the rules defined for the NIST curves (RFC 5903), not a contradiction.

BTW: TLS explicitly allows point compression.

Johannes

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 18 Jul 2012 21:45:38 +0300

[I have been on vacation for a month, so thats why I am only coming
back to this now].

Johannes Merkle writes:
> [Question 0] Is the WG interested in shepherding an RFC specifying
> all that's necessary to use the Brainpool curves in ipsec? And what
> category would be preferred, standard track or informational.

I think it might be good idea to get some usable elliptic curves too.
The groups 19-21 is mostly unusable now as we messed up with their
format in the original RFC4753 and they changes we made in RFC5903 are
not backward compatible with the original RFC4753 and the
interoperability problem just causes timeout on the initiator.

> [Question 1] Should we include IKEv1 in the specs as well? It seems
> that some people in the WG do not like the idea of updating this
> obsolete protocol. On the other hand, many applications still use
> IKEv1 and specifying the use of the Brainpool curves only for IKEv2
> would exclude these.

I would be strongly against for including support for protocol which
has been obsoleted 7 years ago. If people want to use this kind of
groups in IKEv1 they can use the new group mode and negotiate groups
on the fly. There is no need to add them to IKEv1.

> Authentication Methods (Value 3) needs to be updated, because the
> values for ECDSA are specific for each curve. What policy for
> updating this IANA registry can be assumed? IANA currently requires
> a standard track RFC, but there has recently been some discussion on
> relaxing this, in particular,

Hmm... So you are talking adding them for both Diffie-Hellman and
ECDSA uses?

Adding them to ECDSA is more difficult. Adding them for Diffie-Hellman
use requires updating of one expert review 16-bit registry for IKEv2.
The same registry in the IKEv1 is RFC required, so it does not require
standard track RFC.

Adding them for authentication use (ECDSA use) will most likely get
more opposition. First of all, I am not at all happy how the ECDSA
groups are added to the IKEv2 authentication method. The
authentication methods registry is only 8-bit in IKEv2 (it is 16-bit
registry in IKEv1). This does not matter if we have only few ECDSA
groups with one hash algorithm for each, but when we are adding more
groups it seems to bad idea for each of them having separate number.
Especially if someone later decides that they want to use all ECDSA
groups with SHA 3 too...

I think we should have made the ECDSA support for IKEv2 in such way
that we had added some subfields to the authentication field, i.e.
only allocated one value for ECDSA and put the curve number inside the
authentication payload and perhaps even separated the hash algorithm
from it. There is 3 bytes of reserved data in the authentication
payload immediately after the auth method. Perhaps we could use those. 

It is most likely too late now, but we still want to make sure we do
not allocate too many entries from that registry, i.e. is there need
to add all the groups in there, do we really need that many different
strengths? Which hash algorithm do we use with what group?

Also note, that authentication methods are not negotiated in IKEv2,
i.e. there is no way to know whether the other end supports the
authentication algorithm you wanted to use. On the other hand as you
need to have credentials for the other end you are using, so most
if other end would be accepting your authentication credentials it
also supports the authentication method that needs to be used to use
then.

On the IKEv1 there is another problem. The authentication method is
negotiated (in main mode), but it MUST be same for both directions, so
both ends must support same types of credentials. Also as you pointed
out the authentication algorithgms registry for IKEv1 is still
Standard track RFC required and there has been multiple people in the
WG opposing to changing it.

So adding support for authentication methods do require more work for
both IKEv1 and IKEv2.

> [Question 3] If IKEv1 is to be considered, it seems reasonable to
> write only one RFC covering IKEv1 and IKEv2. Actually, we also plan
> to prepare analogous specifications for TLS, so an option would be
> to write a common RFC for IKE and TLS analogously to RFC 5114.
> However, according to the update policy of the IANA registry EC
> Named Curve for TLS, such an RFC would have to be shepherded by the
> tls WG. Does this prevent or considerably complicate the creation of
> a joint RFC for IKE and TLS? Would preparing separate RFCs for IKE
> and TLS be preferable?

I would suggest writing separate RFCs for TLS. It might seem like good
idea to write only one RFC, but that just causes confusion to the
actual users of the RFC. They are either TLS or IPsec implementors,
and it is confusing if you are not using the same terms which are
already used in those protocols.

We only write those documents once (hopefully), but they are (again
hopefully) used more than once, so it is better to optimize for the
reader... 

> [Question 4] In RFC 5639, for each of the bit lengths 160, 192, 224,
> 256, 320, 384, 512 two curves are defined, one being the $,1r|(Bquadratic
> twist$,1r}(B of the other $,1rs(B their algebraic structure (and hence, security
> level) is equivalent, but one of them allows particular efficient
> arithmetic. In order to leave the choice of the curve for a given
> bit length to the implementation we propose to register IANA values
> (for Auth method and Diffie-Hellman Group) for both curves for each

For Diffie-Hellman groups with 16-bit registry, no. For the
Authentication Algorithms registry with only 8-bit registry, yes. On
the other hand if we do take those reserved fields in to use in the
IKEv2 authentication payload and put the parameters there then I see
no reason to limit the number of groups. 

> [Question 5] In Germany, not only ECDSA is in use with IKE and IPSec
> but also ECGDSA (Elliptic Curve German Digital Signature Algorithm)
> according to ISO 14888-3, which is a slight variant of ECDSA. The
> advantage of ECGDSA over ECDSA is that signature generation does not
> need any inversion modulo the group order, which removes the
> necessity of corresponding code. This advantage is particularly
> interesting when using devices with limited computation power and
> particular, car manufacturers have expressed their desire to deviate
> from EDSA For this reason, we would like to specify values for
> ECGDSA (with the individual bit lengths and curves) as
> Authentication Method as well. Would the WG support inclusion of
> this additional signature algorithm?

I think it might be good idea for IKEv2 (and bad idea for IKEv1), but
at least there I think we should add it differently than what is done
for the current ECDSA code, i.e not make separate number for each
group (which would be 28 (i.e. >10% of the whole registry) if we add
all 7 strengths with 2 formats and each with both ECDSA and ECGDSA).

> [Question 6] In cryptographic applications using elliptic curves,
> point compression (see Section 4.2 in RFC 6090) is frequently used
> in particular in environments with limited bandwidth and storage
> capacity. However, in IKE this mechanism is currently not supported
> as, according to RFC 5903, the KE payload consists of the
> concatenation of two components, x and y, each of which having the
> same length as the underlying finite field. We propose to add
> support for point compression for the KE Payload to IKE by allowing
> also the use of a compressed form of x, e.g. of 64 bits,
> representing only the least significant bit. In contrast to the
> (obsolete) draft-ietf-ipsec-ike-ecc-groups-10, RFC 5903 does not
> specify a data format for the ECDH KE payload in which the
> uncompressed form is explicitly specified (e.g. in a leading byte),
> uncompressed and compressed form could only be implicitly
> distinguished by their bit length (as specified in the KE header).
> Does this raise any issue with implementations? What are your
> opinions and preferences?

I have been under impression that the point compression is one of
those items which are patented and that is the reason why it is not
been used in the IKEv2. Also as I said earlier the authentication
methods are not negotiated, thus if one ends send KE payload in point
compressed format and other end does not implement point compression
because of licensing reasons they cannot talk to each other.

So as a summary (my opinion):

1) NO for IKEv1
2) Yes, for IKEv2 Diffie-Hellman groups
3) Maybe, for the IKEv2 ECDSA Authentication methods, with stronger
   support if we actually allocate only one authentication method
   number (or two, one for ECDSA, and another for ECGDSA) and move
   parameters inside the reserved fields. 

Adding the ECDSA do require more work, and for that I would think it
would be best to make this as a WG item (i.e. recharter to include
it). 
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 18 Jul 2012 21:51:16 +0300

> has to be added to the IKEv1 registry.

Why would any other protocol use IKEv1 IANA registries? Are you now
talking about the authentication method registry or the diffie-hellman
groups registry?

It is bad idea to use registry for any other reason than where it is
created, and adding stuff to IKEv1 IANA registry not for IPsec use,
but for use for some other protocols seems like quite funny.

My personal opinion about that is that it is IEEE 802.11-2012 problem
if they use IANA registry for some other purposes than what it is
intended for.
-- 
[email-masked]

---

From: "Dan Harkins" <[email-masked]>
Date: Wed, 18 Jul 2012 11:56:32 -0700 (PDT)

Hello,

> talking about the authentication method registry or the diffie-hellman

  The "diffie-hellman groups registry".

> but for use for some other protocols seems like quite funny.

  It was created to map an unsigned short to a complete domain parameter
set and that is exactly how it is being used.

> if they use IANA registry for some other purposes than what it is

  I think your opinion that this is "some other purpose" is wrong.

  Dan.

---

From: "Dan Harkins" <[email-masked]>
Date: Wed, 18 Jul 2012 12:22:04 -0700 (PDT)

On Wed, July 18, 2012 11:45 am, Tero Kivinen wrote:
[snip]
> on the fly. There is no need to add them to IKEv1.

  In spite of this designation IKEv1 is still widely used and I would posit
that it is used more than IKEv2.

  IKE already has the way to handle new domain parameter sets that are
publicly defined and that is through the IANA registry. Your suggestion to
use New Group Mode to use brainpool ECC groups would only hamstring
IKEv1 and make it harder to use. It would be a blunt club to force people
into doing something that they haven't decided to do on their own (to your
apparent chagrin).

  The IETF does not have a lot of success at forcing people to do things
they do not want to do on their own and I think this sort of thing is
somewhat inappropriate.

  Why there are two identical repositories to map unsigned shorts to
complete domain parameter sets is beyond me but there are. These
two repositories have been updated in concert in the past and and there
is no good reason to have them diverge now.

  Dan.

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 19 Jul 2012 00:59:04 +0300

> set and that is exactly how it is being used.

You forgot the "for IKEv1 use" in your reason why it was created. 

>   I think your opinion that this is "some other purpose" is wrong.

If they actually use IKEv1 and use that IANA registry to map group
numbers to parameters for that use, then it is fine. If they are using
it for some other purposes then I do not care, and I do not think we
should care what they do for that, and we should not add stuff to our
registry just because someone want some numbers there for some other
reasons than for the IPsec use.

There is no point of adding any new stuff to IKEv1 registries as it is
OBSOLETED protocol.
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 19 Jul 2012 01:12:36 +0300

> that it is used more than IKEv2.

It is widely used, but that does not mean we need to keep adding
everything there. I do not think that is that much more widely
implemented anymore. I would expect most of the implementations do
support both IKEv1 and IKEv2, thus adding features to IKEv2 is enough. 

> IKEv1 and make it harder to use.

I think otherwise, as using new group mode allows using them without
changing any single line of code, provided the IKEv1 implementation do
support ECP groups at all (and support the new group mode which is
SHOULD).

This is exactly why new group mode was made a SHOULD in the IKEv1,
i.e. to allow adding new groups without need to changing the
specification or the actual code.

I agree that there might be implementations which do not support it,
and for example I think we disabled it from our implementation when we
added IKEv2 support, as we wanted to keep the feature set provided by
our implemenation about the same regardless whether IKEv1 or IKEv2 is
used, and IKEv2 do not support such feature.

> It would be a blunt club to force people into doing something that
> they haven't decided to do on their own (to your apparent chagrin).

I agree on that. I do try to convince to switch to IKEv2, as it is
MUCH better protocol and works much more robustly and has standarized
features for things which IKEv1 only has multiple non-standardized
non-interoperable protocols.

> they do not want to do on their own and I think this sort of thing is

We do not need to keep adding features to the old obsoleted protocoles
either. 

> is no good reason to have them diverge now.

There is multiple repositories for diffie-hellman parameters. IKEv1,
IKEv2, EAP-EKE, and in addtion SSH, TLS etc have their repositories
etc. Registries are cheap, there is no point of reusing them for
completely different purposes.
-- 
[email-masked]

---

From: "Dan Harkins" <[email-masked]>
Date: Wed, 18 Jul 2012 16:06:56 -0700 (PDT)

> support both IKEv1 and IKEv2, thus adding features to IKEv2 is enough.

  Nobody said anything about "adding everything". That is a complete straw
man argument. In fact, it is decidedly not the case that "everything" is
being
added to IKEv1 and SPSK is proof of that. Perhaps if you weren't so quick
to leap to unfounded conclusions you would see this IANA update as the
innocuous event that it really is.

  This is allowing existing implementations to have more flexibility in the
ECDH operations they perform to comply with various requirements that
may exist in different locales or in different circumstances or situations.

> support ECP groups at all (and support the new group mode which is

  There is a capability in New Group Mode to accept or reject the proposal
and this is to allow the recipient to verify that the group is acceptable.
Enabling this in IKEv1 for the brainpool curves would be substantially more
code than just using the existing code point interface that all
implementation
have.

> specification or the actual code.

  Your recollection differs from the person who actually wrote the RFC.
And when that happens one should typically defer to the author. In fact,
your statement seems to differ from the RFC which says it SHOULD be
supported as a mechanism to define "private groups". The brainpool
groups are not private and there is no reason to treat them as such.

  Since groups added with New Group mode MUST be assigned private
code points it would result in a case of code bi-furcation because
the same domain parameter sets would be accessed using different
code points. That's unnecessary code complication for implementations
that support both IKEv1 and IKEv2.

> non-interoperable protocols.

  And bully for you! I wish you much success in your advocacy. Actively
trying to make people's programmatic lives worse because your advocacy
isn't as successful as you'd like is a completely different matter though and
is, I think, inappropriate.

  The fact that you admit you want a blunt club to force compliance
with your wishes speaks volumes.

> We do not need to keep adding features to the old obsoleted protocoles

  This is NOT a feature. ECDH already exists in IKEv1. This is allowing
existing implementations, of which they are legion, to use certain
domain parameter sets that may be required or desired in certain situations
and in certain locales.

> completely different purposes.

  There is no reason for different repositories for IKEv1 and IKEv2. They
are identical with the exception that the EC2N groups were removed in
the IKEv2 repository. Interestingly, the number space that is EC2N in
IKEv1 is "reserved" in IKEv2 and this is done, apparently, to have symmetry
in group definitions. This way implementations can share the same
mapping from code point to domain parameter set.

  The IKEv1 repository for Diffie-Hellman groups has been updated in
the past after its designation as "deprecated". We should follow precedent
and continue to keep these repositories in harmony.

  Dan.

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 19 Jul 2012 03:14:01 +0300

> innocuous event that it really is.

Not if you count the authentication methods in to it too. That do
require quite a bit of work to make sure everything is done correctly.

Especially as IKEv1 exchanges are quite different depending which
authentication method is used. Adding only the Diffie-Hellman groups
is much easier, but I understood that the idea was to add both.

And for SPSK there was also text for adding that to IKEv1 too, before
it was removed. Same is now with the ike-over-tcp, which again has
IKEv1 text in it. 

> may exist in different locales or in different circumstances or situations.

I would think the ECP groups we already have in the IKEv1 should be
enough for the most common case, i.e. the suite-b uses. Also I still
do not think that many implementations are going to update their IKEv1
implementations.

> code than just using the existing code point interface that all

If I remember those old times when our code actually could use new
group mode, I think there was two ways to use it, either accept any
group other end proposed (without any verification, very useful for
testing etc), or to allow the same groups defined in the configuration
file.

Of course if you were using the group for IKEv1 SA you can also
include all the parameters in the SA propsals from RFC2409:

   Groups may be directly negotiated in the SA proposal with Main Mode.
   To do this the component parts-- for a MODP group, the type, prime
   and generator; for a EC2N group the type, the Irreducible Polynomial,
   Group Generator One, Group Generator Two, Group Curve A, Group Curve
   B and Group Order-- are passed as SA attributes (see Appendix A).
   Alternately, the nature of the group can be hidden using New Group
   Mode and only the group identifier is passed in the clear during
   phase 1 negotiation.

So what is wrong with using the already existing mechanisms of using
groups directly in the SA for that already obsoleted protocol? It
seems the only reason to add numbers for them is to support non IPsec
use... 

> groups are not private and there is no reason to treat them as such.

Brainpool groups do not have number in the IANA registry, which makes
them private for IKEv1 use. There is nothing there claiming that you
can only use new group mode to negotiate groups that are not know for
anybody else. 

> that support both IKEv1 and IKEv2.

Or you can simply give all the parameters in the SA payload, and not
give it number at all. Then it does not matter what the number is.

The whole idea of that feature was to allow adding Diffie-Hellman
groups to existing implementations by just changing the configuration
without modifying the actual code.

Implementations supporting IKEv1 and IKEv2 already needs to keep track
of separate number spaces, as IANA registries for the IKEv1 and IKEv2
are separate. Also IKEv2 does not support this feature at all, so
there is no over the wire negotiated private groups there.

> with your wishes speaks volumes.

And it seems you want to get the Diffie-Hellman numbers there only for
the IEEE-802.11 uses as there is no reason to add them to IKEv1
registries as there is already standardized methods to use them in
IKEv1 without code line changes.

I have never tried to hide the fact that I think IKEv2 is much better
protocol than IKEv1. IKEv1 do have some security problems (not big
enough to cause it to fail completely, but they are there). IKEv1 does
not have standardized support for many things that are there for
IKEv2. Many IKEv1 implementations uses methods described in the
expired Internet-drafts for some things, and there are multiple of
those methods different implementations use.

I think IKEv1 needs to DIE. It is so broken I see no reason for it to
kept alive anymore. I do not want anybody to add anything to it for
two reasons:

1) I am the implementor who might need to implement them in our code.
   Up to this point I have been able to say we do not want to do any
   changes to IKEv1 code.
2) It might make people feel like IKEv1 could still be used.

This is my opinion and I do stick to it, and I do continue trying to
convince others to it too. I see no problem there.

Are you saying that I am not allowed to try to do what I belive is
right?

> domain parameter sets that may be required or desired in certain situations

Anything that changes the code in implementations needs to be
categorized in two ways, i.e. either they are:

1) Bugs
2) Enhancements / new features

I do not consider this to be bug, so it is new feature / enhancement
to the IKEv1.

Especially as there is already a way (actually 2 ways) to do the same
thing in the standard IKEv1 protocol. 

> mapping from code point to domain parameter set.

Check the other IANA registries for IKEv1 and IKEv2 too, and you will
find more changes. The reasons why the IKEv1 and IKEv2 registries are
mostly same is because the IKEv1 registry was copied to work as base
for IKEv2, and at that time we removed those groups which were not
defined by any RFCs (i.e. the groups 6-13 which were only defined in
already expired Internet-Draft).

Those 2 RFCs published after that both made same allocations in the
both IKEv1 and IKEv2 registries, so thats why it still stayed in sync.
There is no reason them to be in sync. 

> and continue to keep these repositories in harmony.

Yes, RFC4753 (which was replaced by 5903) was published in 2007 and
draft already existed before IKEv2 RFC was published, so it was
logical for it to add groups to both IKEv1 and IKEv2.

RFC5114 started around 2007 only 2 years after IKEv2 was out, and at
that point it might have been still useful to update IKEv1 protocol.
Now IKEv1 has been obsoleted now for 7 years, and I think situation is
bit different for now work starting now.

We might keep or might not keep those registeries in sync. For example
the authentication algorithm registry is completely different after
the initial allocation. The encryption algorithms registry is same
(even when IKEv1 cannot even use some of those algorithms described
there). On the other hand ISAKMP has completely different encryption
algorithm registry...

There is no point to make changes that on purpose make them out of
sync, but also there is no need to allocate every single item from
both registries, and we should still allocate first free number to new
allocations.

But I think we are quite far now from where this dicussion started,
and I am not sure if it is useful to continue this discussion as we
simply disagree whether IKEv1 should die or not.
-- 
[email-masked]

---

From: "Dan Harkins" <[email-masked]>
Date: Wed, 18 Jul 2012 17:53:08 -0700 (PDT)

> it was removed. Same is now with the ike-over-tcp, which again has

  EXACTLY!!! That is what I was saying. "everything" is not being added to
IKEv1 and we have documented evidence, you even provided another
example. So your statement that this innocuous addition of code points
to a registry is somehow "adding everything" is just hyperbole.

> do not think that many implementations are going to update their IKEv1

  The brainpool curves have been defined for a purpose that, apparently,
the NIST-defined curves does not satisfy.

  And your statement about "many implementations" is belied by your
behavior. Why would someone be such a vocal advocate of a law that
is not necessary?

[snip]
> seems the only reason to add numbers for them is to support non IPsec

  They are for the situations in which the brainpool curves are necessary.
That is not "to support non-IPsec use". That is not why the brainpool curves
were defined.

> can only use new group mode to negotiate groups that are not know for

  "Brainpool groups do not have a number in the IANA registry". What do you
think the topic of this thread is? Look at the subject above.

  You are arguing against doing something because it hasn't been done yet
and that is illogical.

  You know what? IKEv2 doesn't have any brainpool groups defined in its
IANA registry. Are you against such a code point allocation? If not, then
can I please ask you to be consistent in your positions?

[snip]
> Are you saying that I am not allowed to try to do what I belive is

  No, if  you read what I said I wished you luck in your advocacy that people
should stop using IKEv1. I'm not trying to stifle you, I'm saying that it is
inappropriate to make life a programmatic hell for other people just because
you, personally, want IKEv1 to die.

> I do not consider this to be bug, so it is new feature / enhancement

  If an implementation is well-written it would not require ANY changes to
the implementation. It would require a domain parameter set definition
(probably in a .h file) and an associated magic number. Recompile. Voila.

> thing in the standard IKEv1 protocol.

  Both of which are programmatically problematic and have security issues
(checking the brainpool curves if added to the SA payload or in New Group
Mode would, most likely, require changes to code.

  Furthermore, not all implementations support domain parameter sets
being passed in SA payloads (do any?) or New Group Mode so what you
are advocating for causes more of the problems you are trying to use to
justify your advocacy.

[snip]
> simply disagree whether IKEv1 should die or not.

  Regrettably, yes we are quite far from where this started. Straw men
and circular arguments tend to do that.

  IKEv1 can die, I just don't see a reason to suffocate it. People use it
every day (I'm using it right now!). Different people have different
requirements (hence the definition of brainpool curves). You want to
force people to do something they don't currently want to do by
making artificial impediments to code. It really is not appropriate to
use standards bodies in this manner.

  Dan.

---

From: Yoav Nir <[email-masked]>
Date: Thu, 19 Jul 2012 09:42:31 +0300

> payload immediately after the auth method. Perhaps we could use those. 

How about standardizing just one more authentication method?

Call it "public key signature" or some such, and make the signing algorithm depend on the public key in the CERT payload.

If it's RSA, go by bit strength:
 - <=1024 - SHA-1 with RSA
 - 1024<x<=2048 - SHA2-256 with RSA
 - 2048<x<=4096 - SHA2-384 with RSA
 - >4096 - SHA2-512 with RSA

DSA - always SHA-1

ECDSA will be defined by curve. The three NIST curves that everyone uses already have hashes associated with them. Any new curve would have to specify the signature algorithm in the same document.

Since the same certificate can be used with both the old authentication method and the new, we'd have to signal support in a Notify, and that Notify could have bits for indicating support for other signature algorithms such as those that go with SHA3.

Wouldn't this make adding future curves and other signature variants easier?

Yoav

---

From: Johannes Merkle <[email-masked]>
Date: Thu, 19 Jul 2012 12:43:15 +0200

> ECDSA will be defined by curve. The three NIST curves that everyone uses already have hashes associated with them. Any new curve would have to specify the signature algorithm in the same document.

Adding new methods giving more flexibility seems a good approach but, unfortunately, your proposal would not offer the
flexibility you aim at:

The Subject Public Key Algorithm OID typically used in certs are defined in RFC 3279 and these do not specify the
signature algorithm. For RSA, the RSAPublicKey OID allows both RSASSA-PKCS1-v1_5 and RSASSA-PSS (currently, only an
authentication method for the former is specified but the latter is definitely to be used in the future). For
RSASSA-PSS, more specific public key types are specified in RFC 4055 but use of the old key identifiers is still
permitted and very common. In case of ECC keys, the identifier id-ecPublicKey does also not specify the signature
algorithm.

Thus, unless you want to enforce usage of the id-RSASSA-PSS OID from RFC 4055 for (future) RSASA-PSS keys and restrict
ECC keys to ECDSA (thus, not allowing the future use any other EC-based signature algorithm apart from ECDSA), any new
authentication method should at least specify the signature algorithm (e.g. RSASSA-PKCS1-v1_5, RSASSA-PSS, ECDSA). As
Tero suggested, the specification of the domain parameters and hash function could possibly be required using the 3
bytes of reserved data in the authentication payload immediately after the auth method.

It appears to me that an enhanced flexibility is also needed for the existing RSASSA-PKCS1-v1_5 method as soon as other
hash functions than SH-1 are to be used. RFC 5996 is not very convincing in its description how this can be accomplished:

--- begin extract ---
      Implementations can use the
      certificates received from a given peer as a hint for selecting a
      mutually understood hash function for the AUTH payload signature.

      Note, however, that the hash algorithm used in the AUTH payload
      signature doesn't have to be the same as any hash algorithm(s)
      used in the certificate(s).
--- end extract ---

So implementations are supposed to use the hash algo used by the CA (!) as an indication on what the peer uses, although
this does not need to be reliable? This seems to me as a lack of proper specification.

Johannes

-- 

Mit freundlichen Grüßen,
Johannes Merkle
--
Dr. Johannes Merkle
Principal
Biometrie & Hoheitliche Dokumente
secunet Security Networks AG
Mergenthaler Allee 77
65760 Eschborn
Germany
Telefon +49 201 54 54-3091
Telefax +49 201 54 54-1325
Mobil   +49 175 2224439
[email-masked]
www.secunet.com

---

From: Yoav Nir <[email-masked]>
Date: Thu, 19 Jul 2012 14:01:22 +0300

> bytes of reserved data in the authentication payload immediately after the auth method.

As Tero said, the signature algorithms can be specified in the 3 reserved bytes, but support for such things should be indicated in the Notify payload.

Yoav

> Scanned by Check Point Total Security Gateway.

---

From: "David McGrew (mcgrew)" <[email-masked]>
Date: Thu, 19 Jul 2012 15:41:00 +0000

Hi Johannes,

>ipsec? And what category would be preferred, standard track or

I think it could be reasonable to define new IKE groups based on RFC 5639.
 We need to avoid adding complexity to the IPsec RFC family and its
implementations, so it would be important to align the use of new groups
as much as possible to the existing uses of ECC in IKE, and to clarify the
intended use of the new IKE groups.  For instance, when should the new IKE
groups be used?   Which of the new groups is recommended for use?   What
other crypto algorithms should be used with each of those groups, to form
an acceptable security policy?   What are the technical merits of these
new groups?  I encourage you to take up these questions in your draft.

Ideally, any new ECP ECC groups would retain as much of RFC 5903 as
possible, such as Section 7 of that RFC, would include test cases, and
would be compatible with RFC 6090.

>Brainpool curves only for IKEv2 would exclude these.

The important question here is: are the anticipated users of RFC 5639 in
IPsec able to use IKEv2?   Perhaps this could be considered in the draft
that you are planning.  I would guess that the answer for most would be
"yes".  

Currently, the main driver for the use of ECC in IPsec is RFC 6380, which
requires IKEv2.  

>being the ³quadratic twist² of the other  their algebraic structure (and
>hence, security level) is equivalent, but one

No objection, there are about 1000 values available, and using 14 seems
reasonable.  

>inclusion of this additional signature algorithm?

Adding a new algorithm brings a lot more complexity than adding a new
group, and there should be some considerable technical justification put
forward before new algorithms get adopted.

I understand how ECGDSA avoids the modular inverse, but I do not
understand how that is a significant advantage for a signature algorithm
used in IKE.   When ECDSA is used in IKE, the computational effort of the
ECDSA modular inverse is small relative to the overall amount of
computation that is done.   Also, compact implementations of IKE would
want to minimize the number of new algorithms that they support.

Is there an expectation that users of RFC 5639 based groups in IKE would
also use of ECGDSA?  If not, then I encourage you to take up the ECGDSA
issue in a separate draft, so that the new group work could advance
independently.

Are the car manufacturers that you mention potential adopters of RFC 5639
in IKE?

>(obsolete) draft-ietf-ipsec-ike-ecc-groups-10, RFC 5903

I think compatibility with existing standards would make both the
implementations and the standards simpler, and should be the preferred
direction.   

It is true that there are limited-bandwidth scenarios in which compact
representation for ECDH might be interesting, but I am somewhat skeptical
that the bandwidth savings would be worth the deviation from existing
RFCs.  If the draft that you are preparing includes an option for compact
representation, I suggest that these potential bandwidth savings be
quantified and compared to the overall bandwidth used by IKE.

Regards,

David

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 19 Jul 2012 19:35:04 +0300

>   You are arguing against doing something because it hasn't been done yet

No, I am arguing against it as Brainpool groups CAN ALREADY BE USED in
IKEv1 without any changes to the specifications, or to the
implementations.

IKEv1 does not require every single group to be coded in to every
implementation. 

> can I please ask you to be consistent in your positions?

IKEv2 cannot use groups which do not have number allocated. There is
no way to use brainpool groups in IKEv2 now. Thats why I do think
adding them to the IKEv2 IANA registry is something that should be
done.

IKEv1 and IKEv2 situation is completely different because of that, i.e
existing IKEv1 implementation can already use brainpool groups, IKEv2
implementations cannot.

> are advocating for causes more of the problems you are trying to use to

Our IKEv1 implemention 15 years ago did support both passing them in
SA payloads and inside new group mode. I do not know about others.
-- 
[email-masked]

---

From: Johannes Merkle <[email-masked]>
Date: Fri, 20 Jul 2012 13:13:11 +0200

Yoav,

> As Tero said, the signature algorithms can be specified in the 3 reserved bytes, but support for such things should be indicated in the Notify payload.

Yes, I agree.

> Call it "public key signature" or some such, and make the signing algorithm depend on the public key in the CERT payload.

After sleeping on your idea, I realize that it may work very well for ECDSA. The main problem with elliptic curve
signature schemes is that there are so many different domain parameters. Tero has pointed out that the authentication
methods registry for IKEv2 is only 8-bit, limiting the number of assignable methods. On the other hand, the domain
parameters are specified in the subject public key info in the certificate, either explicitly (listing all parameters)
or by reference (registered OID).

Thus, it is possible to define an authentication method ECDSA_generic where the domain parameters are read from the
certificate. One code point for an unlimited number of domain parameters.

For the hash function to be used, there are several options:
1. An RFC could specify the default for each domain parameter set, e.g. SHA-256 for Brainpool Curve p-256.
2. Alternatively or a means to override the default setting, a hash algo ID could be encoded in the 3 reserved bytes in
the authentication payload
3. Since the authentication payload has variable length, it could also include a leading byte specifying the hash
algorithm. Of course, this contradicts the current specification of the ECDSA authentication payload from RFC4754, but
RFC4754 specifies the encoding only for the specific NIST curves ECDSA authentication methods defined therein.

Johannes

---

From: Johannes Merkle <[email-masked]>
Date: Fri, 20 Jul 2012 18:20:24 +0200

Tero,

thank you for your valuable answers. Please find my responses below.

> interoperability problem just causes timeout on the initiator.

This is a good argument. Another one is that it is always advisable to have more than one curve per bit length just in
case that new cryptanalytic results point out weaknesses in one of them.  Moreover, the fact that the selection of the
seeds, from which the NIST curves have been generated, is not explained might also be considered as a missing link in
their property of being verifiably pseudo-random.

> on the fly. There is no need to add them to IKEv1.

I have followed your dispute with Dan and do not take a clear position here as I have not your experience with
standardization of protocols. For me, IKEv1 does not have high priority, and I mainly aim at using the Brainpool curves
with IKEv2.

> Hmm... So you are talking adding them for both Diffie-Hellman and
Yes, sorry for not stating this clearly. Why should an implementation use another parameter set for the signature as for
the key exchange unless the other peer doesn't support the primary parameters? In particular, implementations in
constraint environments would benefit from the option of using only a single set of domain parameters.

> Especially if someone later decides that they want to use all ECDSA

Today, I responded to Yoav's idea of taking algorithms details from the certificate. At least the EC domain parameters
could be taken from it, and for the hash function, a default could be defined per curve. So one new authentication
method ECDSA_generic or ECDSA_cert_defined could be sued for any EC domain parameters.

> payload immediately after the auth method. Perhaps we could use those. 

Adding hash algorithm flexibility is of course a more general topic concerning not only ECDSA but also RSA and DSA. This
is out-of-scope of our endeavor and should be discussed separately.

> also supports the authentication method that needs to be used to use
You touch the same point as Yoav, who pointed out that a generalized authentication method (e.g. ECDSA_generic) would
imply that the same certificate (for a key pair using one of the NIST curves listed in RFC 4754) could be used ith two
different authentication methods. Yoav has suggested to indicate support for the general method in the Notify payload,
another option could be to introduce a new transform type AUTH, so that support for this AUTH method is indicated in the
SA payload. Again, this is a protocol extension that exceeds our intended scope, and should be specified separately.

An alternative to avoid the interoperability problems with existing implementations of RFC 4754 could be to require that
ECDSA_generic MUST not be used for the curves listed in RFC 4754, or that implementations encountering authentication
failures by the other peer MUST re-try using the "old" authentication methods from RFC 4754.

> WG opposing to changing it.
After following your discussion with Dan I doubt that a WG consensus can be achieved on this issue. But as I said, IKEv1
is of minor importance for me.

> So adding support for authentication methods do require more work for
I think my proposal (based on Yoav's idea) of introducing a generalized ECDSA authentication method could do the trick,
as long as the potential conflict with existing RFC 4754 implementations are not considered a no-go.

> already used in those protocols.

This argument seems very reasonable.

> no reason to limit the number of groups. 

This issue would be solved by the generic ECDSA method.

> all 7 strengths with 2 formats and each with both ECDSA and ECGDSA).

Again, a generalizes ECGDSA method would achieve exactly what you indicate. Only one additional assignment.

> those items which are patented and that is the reason why it is not

This is not an issue. According to http://cr.yp.to/patents/us/6141420.html the patent is almost certainly invalid
because its authors revealed the (known) existence of prior art to the patent office, and furthermore, the patent
expires in 2014.

> because of licensing reasons they cannot talk to each other.

I am not talking about authentication but about key exchange. For authentication, no point compression can be applied,
as an ECDSA signature dies not represent a point on the curve but only to integers (mod the group order).

But I admit that there might be an issue when an implementation not supporting point compression receives a KE payload
of unexpected length. This might lead to undesired behavior. Thus, it might be necessary to use separate group
descriptions when using point compression. But I have not sufficient experience with implementations to assess that.

Johannes

---

From: Tero Kivinen <[email-masked]>
Date: Sat, 21 Jul 2012 18:56:59 +0300

Johannes Merkle writes:
> Today, I responded to Yoav's idea of taking algorithms details from
> the certificate. At least the EC domain parameters could be taken
> from it, and for the hash function, a default could be defined per
> curve. So one new authentication method ECDSA_generic or
> ECDSA_cert_defined could be sued for any EC domain parameters.

Hmm... so the EC domain parameters can be seen from the certificate? I
wonder why did the RFC4753 then made separate allocations for each EC
group?

> Adding hash algorithm flexibility is of course a more general topic
> concerning not only ECDSA but also RSA and DSA. This is out-of-scope
> of our endeavor and should be discussed separately.

We already have this same problem in the RSA, and we do assume that it
is not a problem in real life. I.e. every implementation will use hash
algorithm that is supported by other end. I.e. if some impementation
is SHA-1 only then certificates are also SHA-1 only and everybody uses
SHA-1, and if certificates uses SHA-2, then everybody using those
certificates do support both SHA-1 and SHA-2, and it does not really
matter which hash function is used... This is the reason why we do not
explictly define what hash function needs to be used with RSA.

> You touch the same point as Yoav, who pointed out that a generalized
> authentication method (e.g. ECDSA_generic) would imply that the same
> certificate (for a key pair using one of the NIST curves listed in
> RFC 4754) could be used ith two different authentication methods.
> Yoav has suggested to indicate support for the general method in the
> Notify payload, another option could be to introduce a new transform
> type AUTH, so that support for this AUTH method is indicated in the
> SA payload. Again, this is a protocol extension that exceeds our
> intended scope, and should be specified separately.
> 
> An alternative to avoid the interoperability problems with existing
> implementations of RFC 4754 could be to require that ECDSA_generic
> MUST not be used for the curves listed in RFC 4754, or that
> implementations encountering authentication failures by the other
> peer MUST re-try using the "old" authentication methods from RFC
> 4754.

I think the way forward is to take this WG and as whether WG would be
willing to recharter and add new items to its charter:

1) Add Brainpool curves to the IKEv2 IANA registry (this can also be
   done as individual draft, and does not need to be WG item, but if
   we are doing the rest in WG then I think this should also be WG
   item too). 
2) Define a way to use Brainpool curves in ECDSA (and perhaps ECGDSA)
   in the IKEv2. This may require new standard track RFC defining new
   generic ECDSA method, and might also need solutions how hash
   function is selected for each group. 

Then we can start thinking in the WG what would be the best way to
solve those problems. I think the correct solution would be to make
new ECDSA_generic method and specify where the domain parameters come
(both with certificates and with raw public keys), and we might want
to give some kind of implementation guidelines to the hash algorithm
selection, or we might even define a way to specify it.

> This is not an issue. According to
> http://cr.yp.to/patents/us/6141420.html the patent is almost
> certainly invalid because its authors revealed the (known) existence
> of prior art to the patent office, and furthermore, the patent
> expires in 2014.

We cannot really say whether some patent is invalid or not, but on the
other hand saying it will expire 2014 is something that will help... 

> I am not talking about authentication but about key exchange. For
> authentication, no point compression can be applied, as an ECDSA
> signature dies not represent a point on the curve but only to
> integers (mod the group order).

Ah, good. 

> But I admit that there might be an issue when an implementation not
> supporting point compression receives a KE payload of unexpected
> length. This might lead to undesired behavior. Thus, it might be
> necessary to use separate group descriptions when using point
> compression. But I have not sufficient experience with
> implementations to assess that.

With Diffie-Hellman groups things are easier, as they are negotiated
in the IKEv2, and if someone send KE payload which other end does not
support (i.e. uses point compression) but also proposes same group
without point compression, the receiver can send INVALID_KE_PAYLOAD
and tell the other end to fall back to common group.

So to support point compression we can allocate allocate separate
groups for compressed and non-compressed uses. I am not sure whether
that is best option, but that is something we can look at on item 1
above in the WG. 
-- 
[email-masked]

---

From: "Dan Harkins" <[email-masked]>
Date: Sat, 21 Jul 2012 09:28:31 -0700 (PDT)

> wonder why did the RFC4753 then made separate allocations for each EC

  The particular curve can be determined from the subjectPublicKeyInfo.
Section 4.1 of RFC 5639 gives the ASN.1 encodings to name the brainpool
curves.

  I'm not so sure it makes sense to define a new hash algorithm per curve
though. I would suggest just using the negotiated hash function. That is
going to be used for key derivation and will influence the level of security
that the exchange affords. That is, if you define SHA-384 to use with
brainpoolP384r1 but the two sides end up using SHA-1 for key derivation
then I'm not sure what using SHA-384 for authentication is buying you.

[snip]
>    function is selected for each group.

  If we're gonna recharter, maybe we should just work on an IKEv3 because
the problems in IKEv2 are becoming apparent. This "new authentication mode"
suggestion, or the need for a "generic ECDSA" algorithm are just hacks that
should not be necessary for a properly defined protocol. In addition, the
issues with the incorrect definition of representation of the result of an
ECDH (it's the x-coordinate, not the concatenation of the x- and
y-coordinates) that's lead to interoperability issues, and the inability to
handle point compression all lead one to the conclusion that this stuff
should all be fixed once and for all and fixed cleanly.

  Dan.

---

From: Yoav Nir <[email-masked]>
Date: Sat, 21 Jul 2012 20:50:40 +0300

> then I'm not sure what using SHA-384 for authentication is buying you.

Not much, but not all PRF functions are hashes. What hash will you use if your PRF is AES-XCBC? What if it's GHash?  Sure we could extend both those to be hash functions (just use AES-XCBC with a fixed key) but we've never done this before, and I don't have any idea if the cryptographers will approve.

> should all be fixed once and for all and fixed cleanly.

In 6 years IKEv2 has gained very little traction. All major vendors offer it, but it's still not the default setting for any of them. It would be as bad as saying that IPv6 has problems, so we should begin work on IPv8.

Yoav

---

From: "Scott Fluhrer (sfluhrer)" <[email-masked]>
Date: Sat, 21 Jul 2012 18:31:14 +0000

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Yoav Nir
Sent: Saturday, July 21, 2012 1:51 PM
To: Dan Harkins
Cc: [email-masked]; Johannes Merkle; Tero Kivinen
Subject: Re: [IPsec] Using ECC Brainpool curves with ipsec

> Not much, but not all PRF functions are hashes. What hash will you use if your PRF is AES-XCBC? What if it's GHash?
> Sure we could extend both those to be hash functions (just use AES-XCBC with a fixed key) but we've never done this
> before, and I don't have any idea if the cryptographers will approve.

Cryptographers would certainly not approve; it's easy to generate preimages for AES-XCBC or GHash with a public key.

---

From: "Dan Harkins" <[email-masked]>
Date: Sat, 21 Jul 2012 18:12:44 -0700 (PDT)

[snip]
> In 6 years IKEv2 has gained very little traction. All major vendors offer
> it, but it's still not the default setting for any of them. It would be as
> bad as saying that IPv6 has problems, so we should begin work on IPv8.

  We've been through nearly 40 revisions of this protocol (18 for IKEv2,
another
10 to "clarify" how to use it and then another 11 to do IKEv2v2)  and it
still
needs hacks to add some new elliptic curves-- either N new authentication
modes for N curves, or a new unified and general ECDSA in addition to the
existing 3 for ECDSA (!!!)-- and even still there will be interoperability
issues
because some people represent an ECDH shared secret as x||y and others
represent it as x.

  Notice how the Notify payload is becoming the overloaded payload of choice
to "fix" everything? It's hacked for EAP-only, it's hacked for secure
passwords, and it's the method of choice to hack in new curves. Yuck.

  It's not apparent to me that the reasons for lack of deployment of IKEv2
are in any way similar to those of IPv6 (and, frankly, I would tend to doubt
there is any relationship).

  It may be "bad" to say that we have a problem, but it's worse to deny that
the problem exists. The first step to actually addressing one's problems of
dysfunction is admitting to them. Let me begin:

   "Hello! My name is Dan. We have a problem."

  Dan.

---

From: Tero Kivinen <[email-masked]>
Date: Sun, 22 Jul 2012 15:30:26 +0300

> though. I would suggest just using the negotiated hash function. That is

We do not negotiate hash function in IKEv2. We do negotiate
Pseudo-random function (PRF) and Integrity Algorithm (MAC), but there
is no HASH function negotiated. 

> then I'm not sure what using SHA-384 for authentication is buying you.

IKEv2 do not use hash function for key deriviation it uses PRF for
that. 
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Sun, 22 Jul 2012 16:15:21 +0300

Dan Harkins writes:
> existing 3 for ECDSA (!!!)--

You forgot the IKEv1 drafts too, as IKEv1 does the ECDSA at the same
way than IKEv2 (they both come from the same RFC), so they should also
be counted as revisions.

And, no, I have no idea why the people who added ECDSA did add it that
way. I always assumed that there is no way to know the domain
parameters and hash from the cert / signature, and thats why they
needed to be encoded to the auth algorithm field. Now it seems my
assumption was incorrect.

But with the patent issues with elliptic curves, nobody really used
EC, thus nobody really cared... (at least for me the reason I did not
care about EC was those patent issues, and also as there was no real
customer demand for them, or to say that the customer demand usually
went away when they heard there are patent issues).

> and even still there will be interoperability issues because some
> people represent an ECDH shared secret as x||y and others represent
> it as x.

Yes, this just points how little people cared. Some people did notice
it, but just assumed that ok, they just wanted to things differently
and changed their code to do what original RFC4753 defined. Fixing
that kind of problem with errata, was really bad mistake. And I still
think fixing that problem without allocating new numbers were again
mistake, but I lost that fight.

Also it took several years before this issue was even noticed, that
tells how little EC groups are really used (either in IKEv1 or IKEv2,
as the same mistake was in both of them). 

> passwords, and it's the method of choice to hack in new curves. Yuck.

I do not think notify payload has "become the overloaded payload of
choice", it was originally defined in IKEV2 for that purposes also:

----------------------------------------------------------------------
3.10.  Notify Payload
   ...					in any other
   message to indicate sender capabilities or to modify the meaning of
   the request.
----------------------------------------------------------------------

The main reason why notify is used in the IKEv2, is that it is secure
(compared to IKEv1, where it cannot be used as it is not authenticated
in phase 1) and easy way to do capability indications.

I myself think notify payload is much better than using vendor ID
payloads which was normally done in IKEv1.
-- 
[email-masked]

---

From: Yoav Nir <[email-masked]>
Date: Sun, 22 Jul 2012 16:53:35 +0300

On Jul 22, 2012, at 4:15 PM, Tero Kivinen wrote:

> way. 

I don't know either, but I can guess. With RSA the hash is much smaller than the signature (128-512 bits vs 1024-4096 bits) so we use the PKCS#1 structure that also describes the hash. So you don't need to specify the hash up front - it's encoded in the signature itself.

With ECDSA, the hashes are the same sizes as the signatures, so there's no room within the signature to encode the hash algorithm. You need to know what it is by some other means. So they chose to encode it using the AUTH method. Not very economical in terms of protecting the scarce resource of auth methods.

My suggestion only improves this by making each curve go with a specific hash (specified in the document, not in the protocol). And you can probably replace the hashes with their SHA-3 (or GOST) equivalents by using the reserved fields in the AUTH payload. Regardless of what we do with the Brainpool curves, we also need to be ready for vanity curves, and there's no telling how many we're going to have. openssl/crypto/ec/ec_curve.c has several dozens of them, and I wouldn't want us to have to fight over allocation for each new curve.

Yoav

---

From: "Dan Harkins" <[email-masked]>
Date: Sun, 22 Jul 2012 11:55:10 -0700 (PDT)

On Sun, July 22, 2012 6:53 am, Yoav Nir wrote:
>
> With ECDSA, the hashes are the same sizes as the signatures, so there's no
> room within the signature to encode the hash algorithm. You need to know
> what it is by some other means. So they chose to encode it using the AUTH
> method. Not very economical in terms of protecting the scarce resource of
> auth methods.

  Actually that's not true. The length of the digest of the hash algorithm
is not
the same as the length of the prime of the curve (what I think you mean by
the
"same size as the signatures" since the the signature is R|S). X9.62 says
that
the length of the digest of the hash is a kind of low-water mark of the
desired
security level. If the digest is larger than the length of the prime then
you're
supposed to take the left-most length-of-prime bits of the digest and use
that to compute "s".

  And this points out to another unfortunate design decision of IKEv2.
Instead
of negotiating a fundamental cryptographic primitive like a hash function, it
negotiates a derivative construct like a PRF. So instead of being able to use
the negotiated hash function to compute an ECDSA signature we're forced
to eat through the "scarce resource" of the authentication method registry.
Very clumsy, very hackish, very unfortunate.

  Dan.

---

From: "Scott Fluhrer (sfluhrer)" <[email-masked]>
Date: Sun, 22 Jul 2012 19:52:49 +0000

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Yoav Nir
Sent: Sunday, July 22, 2012 9:54 AM
To: Tero Kivinen
Cc: [email-masked]; Johannes Merkle; Dan Harkins
Subject: Re: [IPsec] Using ECC Brainpool curves with ipsec

> I don't know either, but I can guess. With RSA the hash is much smaller than the signature (128-512 bits vs 1024-4096
> bits) so we use the PKCS#1 structure that also describes the hash. So you don't need to specify the hash up front -
> it's encoded in the signature itself.
>
> With ECDSA, the hashes are the same sizes as the signatures, so there's no room within the signature to encode the
> hash algorithm. You need to know what it is by some other means.

A comment from the pedants-R-us gallery: well, you've come to the correct conclusion (there's no way to determine from an ECDSA signature the hash used to generate the signature), however the reasoning you used to get there is incorrect.

The issue isn't the size of an ECDSA signature (for example, a signature based on the P256 curve is 512 bits long, and uses only 256 bits from the hash).  Instead, the way RSA works allows recovery of the padded hash; we can take advantage of that to signify the hash method in the padding bits.  In contrast, ECDSA does not allow the analogous operation; even if we padded the hash, we couldn't recover the padding anyways from the signature.  We can certainly test if a specific hash value is the one that goes with the signature (that's what the signature verification operation is); however, it is infeasible to recover information about that value (for example, any bits that might signify padding).

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 23 Jul 2012 12:19:39 +0300

Dan Harkins writes:
>   And this points out to another unfortunate design decision of
> IKEv2. Instead of negotiating a fundamental cryptographic primitive
> like a hash function, it negotiates a derivative construct like a
> PRF.

IKEv2 does not need hash function anywehere, and because of that it
does not define it. Also there are PRFs which are not derived from the
hash functions (PRF_AES128_XCBC and PRF_AES128_CMAC).

It is much better to negotiate the algorithm you are using (i.e. MAC
and PRF) instead of some other function which is not used anywhere
directly, and which may or may not be used to derive other functions
(hash).

> So instead of being able to use the negotiated hash function to
> compute an ECDSA signature we're forced to eat through the "scarce
> resource" of the authentication method registry. Very clumsy, very
> hackish, very unfortunate.

I disagree it being clumsy or hackish or unfortunate. It is just one
way of designing the system. Some peole do want to make sure there is
no way to mix algorithms of different strength. I myself think this
should be something that is restricted by policy, not by protocol, but
some people do disagree that and design systems differently. It is not
necessarely bad or good, it is just different.

Also there is no reason why the ECDSA RFC could not have added a new
transform type for HASH function, but it instead decided to use fixed
hash functions for the curves (just like we do for DSA in the IKEv1,
which always used SHA-1 as hash function when calculating signature,
regardless what was negotiated in the SA payloads for HASH).

I think RFC4754 aimed for the suite-B compatibility and it aimed to
support ECDSA levels suitable for AES-128, AES-192, and AES-256, thus
selecting matching EC groups and hash functions is what they decided
to do:

5. Security Considerations
...
   ECDSA-256, ECDSA-384, and ECDSA-521 are designed to offer security
   comparable with the AES-128, AES-192, and AES-256 respectively.
-- 
[email-masked]

---

From: Johannes Merkle <[email-masked]>
Date: Mon, 23 Jul 2012 13:31:56 +0200

> Section 4.1 of RFC 5639 gives the ASN.1 encodings to name the brainpool

Actually, this is not strictly correct:
ANSI X9.62 defies three ways to specify the curve (domain parameters) in a certificate (extracted from RFC 5480):
  ECParameters ::= CHOICE {
       namedCurve      OBJECT IDENTIFIER
       implicitCurve   NULL
       specifiedCurve  SpecifiedECDomain
     }
implicitCurve means that "the parameters are explicitly defined elsewhere".

So we can safely assume that the parameters are available to a pier receiving the certificate of the other one.

By the way: While RFC 5480 prohibits the use of implicitCurve and specifiedCurve, there are certainly still many
implementations of RFC 3279 out there which allowed all three methods.

> then I'm not sure what using SHA-384 for authentication is buying you.

Others have already pointed out that the PRF does not need to be a hash function. But even if it had to, the
requirements are different. For a digital signature, you need a hash function to be collision resistant, while for PRF
you need good mixing properties and, in some circumstances, one-wayness. The requirements for a PRF are much easier to
achieve, e.g. even MD5 is still considered one-way and has good mixing properties, while collisions have been found.

>>    we are doing the rest in WG then I think this should also be WG
I am not sure. If the rest is not specific for the Brainpool curves (e.g. defining a generic ECDSA auth method) it is
not so clear that both efforts should be bundled.

>>    function is selected for each group.
According to the policy of the IANA registry for ath methods, standard track is not required but only IETF consensus,
i.e. an informational WG document would suffice.

> should not be necessary for a properly defined protocol. In addition, the

I do not agree. The generic definition of the ECDSA auth method is analogous to the auth methods defined for RSA and DSA
keys, and thus, is rather the proper (canonical) way to define it than a hack.
Of course, the fact than there are already 3 specific auth methods for ECDSA (which are not canonically defined) makes
specification of a generic ECDSA method more cumbersome.

Johannes

---

From: Johannes Merkle <[email-masked]>
Date: Mon, 23 Jul 2012 13:57:17 +0200

> wonder why did the RFC4753 then made separate allocations for each EC

As I wrote to Dan, there is actually also the option of not specifying the parameters in the cert, but this method
(implicitCurve) is supposed to be used only if the parameters are known to the other pier by other means (e.g. by local
configuration)

> matter which hash function is used... This is the reason why we do not

Even if the pier supports both SHA-1 and all SHA-2 functions, it would require try-and-error to find out which one was
used for the signature.

Maybe in most cases the tier uses the same hash function as the CA, but this does not need to be the case. I know of
large-scale PKIs, where the CAs use longer hash functions than the end entities. This can be motivated by the
(indisputably) higher security requirements for CAs than for end users.

> willing to recharter and add new items to its charter:

Accidentally, I included by response to this in my reply to Dan. For completeness, I will repeat it here.

>From a cryptographic point of view, the correctness (and hence, the integrity and authenticity) of the domain parameters
is crucial, it is not a restriction to require that, if a raw (trusted) EC public key is used, the parameters must also
be available by trusted means (e.g. local configuration).

Johannes

---

From: Sean Turner <[email-masked]>
Date: Mon, 23 Jul 2012 08:57:37 -0400

> certificate. One code point for an unlimited number of domain parameters.

Just thought I'd point out here that in RFC 5480 the only option is 
namedCurve (i.e., OIDs).  But, the brainpool curves all have OIDs 
assigned in RFC 5639.

---

From: "Dan Harkins" <[email-masked]>
Date: Mon, 23 Jul 2012 10:39:26 -0700 (PDT)

On Mon, July 23, 2012 4:31 am, Johannes Merkle wrote:
> So we can safely assume that the parameters are available to a pier
> receiving the certificate of the other one.
>
>
> By the way: While RFC 5480 prohibits the use of implicitCurve and
> specifiedCurve, there are certainly still many

  For a guy who's always reminding everyone about how there are many
implementations of an older RFC I should keep that in mind. Thank you
for pointing that out. But, as you note, RFC 5480 prohibits implicitCurve
and specificCurve so all we have left is namedCurve which is, as I noted,
how the particular curve can be determined from the subjectPublicKeyInfo.

> I do not agree. The generic definition of the ECDSA auth method is
> analogous to the auth methods defined for RSA and DSA
> Of course, the fact than there are already 3 specific auth methods for
> ECDSA (which are not canonically defined) makes

  With RSA the hash algorithm is encoded into the padding so there is
no real need to independently agree on a hash algorithm. For DSA,
I disagree. The DSA algorithm definition is hash-specific so the hash-
specific ECDSA auth methods are the canonical way. Let me point
out, though, that canon law is not necessarily correct and this is an
example.

  FIPS 186-3 (The Digital Signature Algorithm) specifies that security
strength levels of DSA are a minimum of the security strength of the
hash algorithm and the (L,N) pair from the domain parameter set. If
one wished to achieve a security strength level with DSA that would
be valid, according to NIST, "beyond 2030" one would need to use
SHA-512 but IKEv2 only uses SHA-1 with "DSS Digital Signature"
(authentication method value of 3) so that wouldn't work.

  Given that SP 800-57 requires that 80 bits of strength only be used
through 2010 (and SHA-1 does not provide more than that) and it
is now 2012 it appears that IKEv2 is not capable of producing a
signature of sufficient strength for certain customers (they might not
be your's but they do exist, and there's probably more of them than
there are people clamoring for AES-XCBC MAC).

  So to actually address this in the hash-specific canonical way
requires new auth methods for different permutations of DSS with
SHA-224, SHA-256, SHA-384, and SHA-512 as well as different
permutations of ECDSA with brainpool curves using the 5 different
SHA varients. But this is getting, as you say, "cumbersome".

  Of course one can decide not to use the hash-specific canonical
technique and come up with "generic DSA" and "generic ECDSA" to
address this but then we have the unfortunate state of hash-specific
(EC)DSA methods and "generic" methods and now it's getting ugly
(and hack-ish).

  Instead of either negotiating a complete ciphersuite (the way TLS
does) or individual components (the way IKEv1 did), IKEv2 does both
and gets the worst of both worlds.

  Dan.

---

From: "Dan Harkins" <[email-masked]>
Date: Mon, 23 Jul 2012 11:01:44 -0700 (PDT)

> necessarely bad or good, it is just different.

  So some people want to do it one way and other's want to do it a
different way. What's hackish is to do both and that's what IKEv2 does.
For (EC)DSA the hash algorithm to use is determined by the auth
method (no way to mix algorithms) but the cipher and D-H group
are not (something restricted by policy).

  Doing it one way or the other might not necessarily be good or bad
but doing it both is.

> regardless what was negotiated in the SA payloads for HASH).

  And in IKEv2 you got rid of the hash negotiation but retained the
SHA-1 only nature of DSA regardless of the PRF being negotiated.
Section 3.8 of RFC 5996 says:

  "DSS Digital Signature                  3
      Computed as specified in Section 2.15 using a DSS private key
      (see [DSS]) over a SHA-1 hash."

  Dan.

---

From: Johannes Merkle <[email-masked]>
Date: Mon, 23 Jul 2012 21:15:55 +0200

> no real need to independently agree on a hash algorithm. For DSA,

No, in RSA PKCS#1v1.5 padding (which is currently the only supported padding in IKEv2), the hash algorithm is *not*
encoded in the padding. Only the length of the length of the hash value can be determined due to the reserved zero octet
leading the hash value. For SHA-1 and the SHA-2 hash functions, the length also determines the function, so your
assertion in in some way true for these functions. However, RFC 5996 does not restrict the hash function to these. As
soon as one of the SHA-3 contributions is used, the function can not be determined from the padding, as SHA-3
contributions were required support 224, 256, 384, and 512-bit message digests, exactly the lengths generated by the
SHA-2 functions.

> out, though, that canon law is not necessarily correct and this is an

By generic ECDSA methods, I did not mean hash-independent but only curve-independent.

At least for SHA-1/SHA-2, the mapping between size of the curve and hash function could be fixed in an RFC. The hash
length shall not be smaller than the bit length of curve parameters (FIPS-186-3), and there is no need to choose an
SHA-2 function longer than the minimum one meeting this requirement.

As I said in an earlier message, adding hash algorithm flexibility is a more general topic concerning not only ECDSA. It
probably requires much more than simply defining a new auth method and specifying a rule, which hash function to chose
for which ECDSA bit length.

> there are people clamoring for AES-XCBC MAC).
This is definitely an issue when using DSA with IKEv2, and I do not doubt that something should be done, but I don't
think that this needs to be coupled with an effort to specify a curve-independent ECDSA auth method.

> SHA varients. But this is getting, as you say, "cumbersome".
As said above, I don't see the need to allow, for instance, the Brainpool p256 curve to be used with any hash function
other than SHA-256.

> (EC)DSA methods and "generic" methods and now it's getting ugly
Such a co-existence of different approaches would also be the case if a curve-independent (but hash-specific) ECDSA
method was specified, and I agreee that this is a bit unfortunate. But this is not a major issue compared to alternative
of specifying separate methods for each curve in an 8 bit registry.

> and gets the worst of both worlds.

Means to negotiate the hash function could be specified as discussed earlier in this thread, but of course this is a
more significant change. And I am not sure if this is necessary, given the clear recommendations of FIPS 186-3.

Johannes

---

From: "Scott Fluhrer (sfluhrer)" <[email-masked]>
Date: Mon, 23 Jul 2012 20:15:10 +0000

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Johannes Merkle
Sent: Monday, July 23, 2012 3:16 PM
To: Dan Harkins
Cc: [email-masked]; Tero Kivinen
Subject: Re: [IPsec] Using ECC Brainpool curves with ipsec

>> no real need to independently agree on a hash algorithm.
>
> No, in RSA PKCS#1v1.5 padding (which is currently the only supported
> padding in IKEv2), the hash algorithm is *not* encoded in the padding.
> Only the length of the length of the hash value can be determined due
> to the reserved zero octet leading the hash value. For SHA-1 and the
> SHA-2 hash functions, the length also determines the function, so your
> assertion in in some way true for these functions. However, RFC 5996
> does not restrict the hash function to these. As soon as one of the
> SHA-3 contributions is used, the function can not be determined from
> the padding, as SHA-3 contributions were required support 224, 256,
> 384, and 512-bit message digests, exactly the lengths generated by the
> SHA-2 functions.

Actually, the hash type is indeed encoded in the signature in PKCS#1v1.5, aka RSASSA-PKCS1-v1_5; refer to the PKCS #1 version 2.1 or to RFC3447, section A.2.4 for both documents.

To summarize, when using PKCS#1v1.5, the padded message is of the format:
  00 02 FF FF FF FF ... FF 00 <OID> <Hash>
(where there are enough FF bytes to exactly fill the RSA block).

The byte string I marked as <OID> is a string that depends on the hash algorithm used; for SHA-256, it is:
    30 31 30 0d 06 09 60 86 48 01 65 03 04 02 01 05 00 04 20

For SHA-1, it is:
    30 21 30 09 06 05 2b 0e 03 02 1a 05 00 04 14

And there are other OIDs for a number of other hash functions.  This OID (when concatenated with the hash) is a DER string the means "The result of <Hash Function> is <Hash>".  And, yes, a signature verifier can use this OID string to figure out which hash function to use (by running the RSA public operation on the signature, looking through the resulting block, checking which OID it lists, and then running the appropriate hash on the data).

When SHA-3 comes out, they'll just allocate more OIDs (if they haven't already) to denote the various sizes of SHA-3; no confusion between SHA-256 and SHA-3-256 will be necessary.

Perhaps you have this confused with signatures in IKEv1; there, they do something nonstandard and don't include the OID (possibly because they are not actually using the hash function, but instead the HMAC version).

---

From: "Dan Harkins" <[email-masked]>
Date: Mon, 23 Jul 2012 15:22:35 -0700 (PDT)

On Mon, July 23, 2012 12:15 pm, Johannes Merkle wrote:
>>> keys, and thus, is rather the proper (canonical) way to define it than
>>> a
>>> hack.
> padding in IKEv2), the hash algorithm is *not*
> encoded in the padding. Only the length of the length of the hash value
> can be determined due to the reserved zero octet
> assertion in in some way true for these functions. However, RFC 5996 does
> not restrict the hash function to these. As
> contributions were required support 224, 256, 384, and 512-bit message
> digests, exactly the lengths generated by the
> SHA-2 functions.

  I see that Scott Fluhrer has already responded to this; I agree with Scott.

> At least for SHA-1/SHA-2, the mapping between size of the curve and hash
> function could be fixed in an RFC. The hash
> length shall not be smaller than the bit length of curve parameters
> (FIPS-186-3), and there is no need to choose an

  If the mapping between curve and hash function is fixed then I don't
see what you mean by "not hash-independent but only curve-independent".
Seems that there is nothing independent, it's all fixed.

> As said above, I don't see the need to allow, for instance, the Brainpool
> p256 curve to be used with any hash function
> other than SHA-256.

  And there are 7 new brainpool curves so that's 7 new auth methods
plus 4 new ones to deal with the non-EC version of DSA for a total
of 11 new auth methods to go along with the existing 4. 15 different
auth methods just for the digital signature standard!

> Such a co-existence of different approaches would also be the case if a
> curve-independent (but hash-specific) ECDSA
> method was specified, and I agreee that this is a bit unfortunate. But
> this is not a major issue compared to alternative

  Yes, it is unfortunate. What's also unfortunate is that the 11 auth
methods mentioned above (plus the 3 existing ECDSA auth methods)
will probably have to be duplicated for SHA-3 thereby eating into this
"scarce resource" of an 8-bit registry even further.

> Means to negotiate the hash function could be specified as discussed
> earlier in this thread, but of course this is a

  I am not advocating the mixing-and-matching of curves and hash
functions of different security levels (and therefore one could argue
to fix them) but it should be noted that IKEv2 allows all sorts of mixing
and matching of ciphers, hash algorithms, and D-H groups of different
security levels to be negotiated-- AES-256 with the 768-bit DH group
authenticated with ECDSA using NISTP384 with SHA-384 and key
derivation using SHA-1. Why would someone do this? I have no idea.
Can someone? Yes. Is there a reason to enforce a "no mix-and-match"
policy on some primitives and a "laissez faire negotiation" policy on
others? No, at least not a good one.

  The point is, that the IKEv2 design was quite myopic-- if there are
to be different permutations of curve-hash as separate auth methods
then it shouldn't have been made a "scarce resource" of an 8-bit
registry. You're right that fixing all this stuff that you describe as
"cumbersome" and "unfortunate" would be "a more significant
change". I think it might be worth trying and given the poor adoption
of IKEv2 now's the time to fix it with IKEv3 before it's too late.

  Dan.

---

From: Johannes Merkle <[email-masked]>
Date: Tue, 24 Jul 2012 11:34:06 +0200

>     30 31 30 0d 06 09 60 86 48 01 65 03 04 02 01 05 00 04 20

Right, I was mistaken, I had looked into the padding scheme of the PKCS#1v1.5 encryption scheme not signature.

Johannes

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 24 Jul 2012 13:16:06 +0300

Johannes Merkle writes:
> As I wrote to Dan, there is actually also the option of not
> specifying the parameters in the cert, but this method
> (implicitCurve) is supposed to be used only if the parameters are
> known to the other pier by other means (e.g. by local configuration)

So for IKEv2 use we can say that ECDSA MUST be used with certificates
which give domain parameters in the certificate? That should solve the
problem that we do not need separate auth methods for every different
EC curve. 

> Even if the pier supports both SHA-1 and all SHA-2 functions, it
> would require try-and-error to find out which one was used for the
> signature.

I now understand, when it was point out in some later emails, that in
the ECDSA signatures there is no way to know the hash algorithm from
the signature alone (compared to RSA, where is possible to extract the
hash algorithm from signature).

But there is still two different problems there. One is which
hash algorithm to use, and another is how the other end knows which
hash algorithm was used.

There are multiple solutions to the problems. 

One solution to both of the problems would be to add new transform
type for HASH algorithms and negotiate it. This would most likely be
the cleanest way, but would require more changes than other solutions.

Another option is to use method like or RSA to select which hash
algorithm to use, and encode the hash algorithm to the auth payload
reserved bytes.

Yet another option is to specify the mandatory hash algorithm to be
used for each specific curve, so hash function is known because of
specific group is used. This is bit like what existing ECDSA groups
are doing, i.e. each group defines hash function that must be used for
it. This option does not require that every group will be given
separate authentication method number.

> I am not sure. If the rest is not specific for the Brainpool curves
> (e.g. defining a generic ECDSA auth method) it is not so clear that
> both efforts should be bundled.

I do not think they need to be bundled. Thats why I proposed adding
two separate charter items for them. I.e. this first step is something
that can be done quickly and without any problems with just one
informational RFC. I do not also expect there to be too much
discussion whether this should be done or not, and how this should be
done.

> According to the policy of the IANA registry for ath methods,
> standard track is not required but only IETF consensus, 

Yes information draft would be enough, but if we are really making
generic ECDSA method, then we most likely do want to also say what we
are going to do for the old ECDSA methods. For example if we do want
to say that those methods are NOT RECOMMENDED then we need to update
the standard track document (RFC4754).

Also at least I would prefer that this kind of generic work should be
standard track document.

> From a cryptographic point of view, the correctness (and hence, the
> integrity and authenticity) of the domain parameters is crucial, it
> is not a restriction to require that, if a raw (trusted) EC public
> key is used, the parameters must also be available by trusted means
> (e.g. local configuration).

In my draft-kivinen-oob-pubkey-00.txt which adds raw EC public keys,
we did plan to use SubjectPublicKeyInfo part of the PKIX certificate,
thus that would have the domain parameters in there. The local
configuration would then indicate whether that raw key is trusted or
not. 
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 24 Jul 2012 13:29:35 +0300

> (authentication method value of 3) so that wouldn't work.

That SHA-1 text is leftover from the RFC4306 and from the IKEv1, i.e.
when the only supported DSS was the one using SHA-1. The RFC5996 did
update from the 1994 FIPS 186 to draft FIPS 186-3 but that comment
about SHA-1 did not get removed.

On the other hand I would expect most of the implementations ignore
that comment, and go with the actual DSS documentation when using DSS
signatures, and use the hashes defined in there.

This is one of those cases where, when that text was added it seemed
to help understanding the issue, as SHA-1 was the only allowed hash
function for DSS, but with updated documents with later references,
that comment came misleading but did not get removed..

> SHA varients. But this is getting, as you say, "cumbersome".

So you are saying that each DSS even with ECDSA do require to tell
what hash function is used separately? I have assume that when I do
get DSA public key in the certificate, and know the length of the DSA
key, I can know which hash function is used when using that key?

But if I am mistaken, then we might need to add extra DSS methods too
(but lets not add them to IKEv1, as I do not want new modifications to
IKEv1. IKEv1 does this same way than IKEv2 does, i.e. it assumes you
know which hash function is used with DSS and ignores the negotiated
hash function when using DSS).

Note, that there is no MUSTs or anything like that in the RFC5996
saying you MUST use SHA-1, it is just statement that DSS as defined in
year 1994 version used SHA-1.
-- 
[email-masked]

---

From: Johannes Merkle <[email-masked]>
Date: Tue, 24 Jul 2012 13:17:07 +0200

> Seems that there is nothing independent, it's all fixed.

I have the impression that we misunderstand each other. The solution that I propose is to define one new auth method
ECDSA_generic which indicates that
- the curve shall be taken from the certificate
- the hash function shall be the minimum SHA-1/2 function matching or exceeding the security level of the curve.

This method is flexible w.r.t the curve but not w.r.t the hash function, and that is what I called "not hash-independent
but only curve-independent". Maybe the term "curve-flexible but not hash-flexible" is better.

This approach is exactly the one followed for DSA (DSS Digital Signature), except that the latter one was limited to
SHA-1. Thus, a curve-independent ECDSA method would be more consistent with the existing DSA method. This is the reason
why I objected to your assertion of our approach being a "hack". But maybe you didn't refer to this approach at all?

> auth methods just for the digital signature standard!
Not with the approach I proposed: there is only one method ECDSA_generic.

Note, that for DSA (on EC), it would also be sufficient to specify a new auth method DSS_key_length_defined_hash
accompanied with the requirement to choose the hash function as the smallest SHA-2 function meeting the minimum
requirements of FIPS-186-3.

> "scarce resource" of an 8-bit registry even further.

We have the choice: Either spending many assignments out of the 256 available, or to specify a generic auth method
deviating from the approach previously tken for ECDSA (but being in accordance with the approach taken for DSA).

> others? No, at least not a good one.
I assume, the reason why the hash function is not negotiated is that at the time IKEv2 was specified there was mainly
one hash function giving adequate security in practical use.

> of IKEv2 now's the time to fix it with IKEv3 before it's too late.

I doubt that you can get a WG consensus on doing this.

I am more interested in a short term solution, and for this I am prepared to do without hash-flexibility.

Johannes

---

From: "Dan Harkins" <[email-masked]>
Date: Tue, 24 Jul 2012 09:56:44 -0700 (PDT)

On Tue, July 24, 2012 4:17 am, Johannes Merkle wrote:
> I have the impression that we misunderstand each other. The solution that
> I propose is to define one new auth method
> - the hash function shall be the minimum SHA-1/2 function matching or
> exceeding the security level of the curve.

  So the signer says "ECDSA_generic" and the curve is determined from the
subjectPublicKeyInfo and one infers the correct SHA-1/2 algorithm from
the curve. OK, so if the curve is the 320-bit brainpool curve then we always
use SHA-384. Got it.

> accompanied with the requirement to choose the hash function as the
> smallest SHA-2 function meeting the minimum

  Well FIPS 186-3 specifically refers to SP 800-57 for "information about
the selection of the appropriate (L,N) pair in accordance with a desired
security strength for a given time period for the generation of digital
signatures."  And SP 800-57 says that, for example, to produce a
signature valid "beyond 2030" it requires a minimum of 128 bits of
strength (table 4) and that when performing digital signatures of 128
bits of security the valid hash functions are SHA-256, SHA-384, and
SHA-512. You want to restrict such signatures to SHA-256 so it's
not really meeting the requirements of FIPS 186-3.

> We have the choice: Either spending many assignments out of the 256
> available, or to specify a generic auth method
> deviating from the approach previously tken for ECDSA (but being in
> accordance with the approach taken for DSA).

  But the "generic ECDSA" does not solve the problem with SHA-3. As
you said above, "the hash function shall be the minimum SHA-1/2 function
matching or exceeding the security level of the curve." So how do you
support SHA-3? I guess we could assign a bit (clear=SHA-1/2, set =
SHA-3) but that's getting pretty hackish. Or we could have 2 "generic
ECDSA", one for SHA-1/2 and another for SHA-3. Yuck.

  If only this protocol was designed better....

  Dan.

---

From: Dan Brown <[email-masked]>
Date: Tue, 24 Jul 2012 18:42:13 +0000

Hi all,

Just a technical question, not very IPSec-specific:   

Do the Brainpool curves comply with all the requirements (and ideally the recommendations too) that the ECDSA standards place on the elliptic curves?  The intent of the ECDSA standards and IPSec is to have a secure, interoperable signature algorithm, which ought to be the case for the Brainpool curves used with ECDSA.  So IPSec may choose to call various things "ECDSA", but IPSec may want to avoid saying something is ANSI X9.62-2005 unless if it is strictly compliant.  

The main ECDSA standards are ANSI X9.62-2005 and SEC1-v2.0 (which also specifies other ECC algorithms and syntax).  FIPS 186-3 specifies ECDSA mostly by reference to ANSI X9.62-2005.   ISO also specifies "EC-DSA".  IEEE 1363-2000 and IEEE 1363a-2004 specify ECDSA under a slightly different acronym.

As editor of ANSI X9.62-2005 and SEC1-v2.0, I ought able to help check compliance.  As I recall, both standards impose requirements on the elliptic curves in order to avoid weak curves, and perhaps also to encourage interoperability.  Maybe Johannes could contact me off-list to start this process.

Best regards,

Daniel Brown
Research In Motion Limited

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 24 Jul 2012 13:53:29 -0700

On Jul 24, 2012, at 11:42 AM, Dan Brown wrote:

> Do the Brainpool curves comply with all the requirements (and ideally the recommendations too) that the ECDSA standards place on the elliptic curves?

I'm confused by the question. "The ECDSA standards" (ANSI X9.62-2005 and SEC1-v2.0) list things that newer curves might not meet because, well, they're newer than the standards. Why should that be a limitation on what is used in IPsec?

--Paul Hoffman

---

From: Dan Brown <[email-masked]>
Date: Tue, 24 Jul 2012 21:21:26 +0000

> From: Paul Hoffman [mailto:[email-masked]]
> Sent: Tuesday, July 24, 2012 4:53 PM
> To: Dan Brown
> Cc: IPsecme WG
> > Do the Brainpool curves comply with all the requirements (and ideally the
> recommendations too) that the ECDSA standards place on the elliptic curves?
> 
> I'm confused by the question. "The ECDSA standards" (ANSI X9.62-2005 and SEC1-
> v2.0) list things that newer curves might not meet because, well, they're
> newer than the standards. Why should that be a limitation on what is used in
> IPsec?

The next text after the question tried to clarify that I was not suggesting any such limitation.  

Anyway, to answer your question: considerable thought was put into ECC parameters in ECDSA standards, so their requirements should make for a good sanity check on any newer curves.  (Are the Brainpool curves actually newer?)  It should be possible to devise newer curve that also adheres to the past ECDSA standards, but if not, there should be a good reason.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 24 Jul 2012 15:23:55 -0700

> The next text after the question tried to clarify that I was not suggesting any such limitation.  

Thank you: it was not clear.

> Anyway, to answer your question: considerable thought was put into ECC parameters in ECDSA standards, so their requirements should make for a good sanity check on any newer curves.  (Are the Brainp…

Of course. Anything we do here should have good reason, and it should be documented.

--Paul Hoffman

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 26 Jul 2012 16:21:51 +0300

> not really meeting the requirements of FIPS 186-3.

Few questions (I do not know enough about FIPS 186-3 or SP 800-57 etc
to know the answer myself).

When we have DSS signature in FIPS 186-3 format, I have understood
that there is no indication about whether the signature is ECDSA or
normal DSA, or what is the domain parameters for the ECDSA, and what
is the hash function used when generating the signature.

I.e. the signature just consist of some raw bits, and there is no
other information around it and all that other information must be
carried to the verifier over some other medium?

Is this correct?

If that is correct how does the PKIX solve this? I.e. when I have
certificate signed by the some other certificate using DSA? If my
reading of RFC5280 is correct there is this signatureAlgorithm ASN.1
blob in front of the signature itself and that gives all that
information (including the domain parameters and hash functions etc).

Is my understanding correct?

If so then I think we should use similar method in the IKEv2 too, and
fix both ECDSA and normal DSA at the same time, i.e. create one new
authentication method where the actual signature format that contains
both the signatureAlgorithm and signatureValue (4.1.1.2 and 4.1.1.3
from the RFC5280).

This will fix the problem for all DSA methods (EC or normal) and
allows using any hash function allowed by signers policy. It also
allows responder to immediately know the domain parameters and hash
function even when certificate of the public key was not delivered
inband of the IKEv2.

If we define one new authentication method then we can also deprecate
old DSA methods (DSS Digital Signature - 3, ECDSA with * on the P-*
curve - 9-11), and recommend that new implementations will use this
new method. Or we can still say that for SHA-1 DSS and SHA-2 with
those curves still use the old methods.

This same method could also be used for RSA, but as this problem of
not knowing hash-function / parameters do not exists in RSA there is
no point of changing the current RSA method.

This would also make it so that we could use any public key method the
PKIX decideds to define in the future without any changes to the IKEv2
document.

>   If only this protocol was designed better....

True, we can only blame ourselves. This same problem was already there
for IKEv1, but nobody noticed that we should fix this when we were
defining IKEv2.
-- 
[email-masked]

---

From: Johannes Merkle <[email-masked]>
Date: Thu, 26 Jul 2012 16:55:07 +0200

> carried to the verifier over some other medium?

Yes, in both cases (DSA, ECDSA) the signature consists of two integers. RFC 3279 defines:
 Dss-Sig-Value  ::=  SEQUENCE  {
              r       INTEGER,
              s       INTEGER  }

 Ecdsa-Sig-Value  ::=  SEQUENCE  {
           r     INTEGER,
           s     INTEGER  }

And the bit length is typically comparable.

> Is my understanding correct?
Almost. The signature scheme and hash are specified in the signatureAlgorithm identifier, e.g. id-dsa-with-sha256 and
ecdsa-with-SHA256. The parameters (DSA parameters and ECC domain parameters) are stored in subjectPublicKey. But this is
specified in the certificate.

Note: for DSA is is admissible (according to RFC 3279) to omit the patrameters and then the parameters of the CA key
apply, which are specified in the CA certificate. So it an be necessary to parse the CA certificate as well to obtain
them.

> function even when certificate of the public key was not delivered

That would work but would expand the auth payload by more than two or three bytes. For instance the OID
ecdsa-with-SHA256 is 1.2.840.10045.4.3.2.
While this is still limited, for the new RSA-PSS scheme (see my response regarding RSA below)

> those curves still use the old methods.
Deprecation is the cleaner method but I fear that existing implementation will not quickly adpat to the new rule, so
still allowing the old methods is more safe.

> no point of changing the current RSA method.
This may change. Since 2005, PKIX supports through RFC 4055 the signature scheme RSASA-PSS which provides provable
security (in a certain mathematical model) and is generally considered the better padding method as compared to the old
padding PKCS#1v1.5.

However, in RSASA-PSS, the encoding of the PKIX signature algorithm identifier may be quite large as it has several
parameters:
RSASSA-PSS-params ::= SEQUENCE {
    hashAlgorithm      [0] HashAlgorithm      DEFAULT sha1,
    maskGenAlgorithm   [1] MaskGenAlgorithm   DEFAULT mgf1SHA1,
    saltLength         [2] INTEGER            DEFAULT 20,
    trailerField       [3] TrailerField       DEFAULT trailerFieldBC
}

-- 
Johannes

---

From: Yoav Nir <[email-masked]>
Date: Thu, 26 Jul 2012 21:06:28 +0300

> Is my understanding correct?

Yes. If you print out a certificate signed with ECDSA with OpenSSL, it looks like this:
MBA:tmp ynir$ openssl x509 -in the_ca_cert.crt -text
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 1 (0x1)
    Signature Algorithm: ecdsa-with-SHA1
        Issuer: 
        Validity
            Not Before: Jul 26 17:56:00 2012 GMT
            Not After : Jul 26 17:56:00 2022 GMT
        Subject: 
        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey
                Public-Key: (256 bit)
                pub: 
                    04:b9:36:b6:65:ee:65:27:70:f0:f9:16:67:78:53:
                    b8:be:14:29:c5:36:09:a7:3b:0a:f0:0d:59:4d:31:
                    6d:9a:f3:be:fd:bf:e3:6e:0e:39:69:96:c9:d8:ae:
                    74:79:3d:f8:af:b5:5a:65:44:fe:76:c1:8c:52:18:
                    f3:6e:49:43:23
                ASN1 OID: prime256v1
        X509v3 extensions:
            X509v3 Basic Constraints: critical
                CA:TRUE
            X509v3 Subject Key Identifier: 
                9B:D6:1D:1A:9B:B8:CE:2D:46:FD:B1:A5:6E:7D:35:E6:05:04:F0:36
            X509v3 Key Usage: 
                Certificate Sign, CRL Sign
            Netscape Cert Type: 
                SSL CA, S/MIME CA, Object Signing CA
            Netscape Comment: 
                xca certificate
    Signature Algorithm: ecdsa-with-SHA1
         30:45:02:20:61:68:e4:5e:9c:47:2d:d6:49:f6:6b:24:cb:43:
         cd:20:2e:c4:5d:bb:1a:45:d9:95:09:6b:89:93:5b:00:d2:cb:
         02:21:00:b9:c4:d3:d4:4a:98:e0:d6:20:45:b2:95:8b:4a:06:
         d5:6b:3d:90:f6:a7:81:be:1f:d0:c5:f1:a8:b5:6a:d0:b9

See the "Signature Algorithm" field before the signature itself?  If we dump the ASN.1 the signature is a sequence of an OID and a bitstring:
MBA:tmp ynir$ openssl asn1parse -in the_ca_cert.crt -i -dump
    0:d=0  hl=4 l= 351 cons: SEQUENCE          
…
  270:d=1  hl=2 l=   9 cons:  SEQUENCE          
  272:d=2  hl=2 l=   7 prim:   OBJECT            :ecdsa-with-SHA1
  281:d=1  hl=2 l=  72 prim:  BIT STRING        
      0000 - 00 30 45 02 20 61 68 e4-5e 9c 47 2d d6 49 f6 6b   .0E. ah.^.G-.I.k
      0010 - 24 cb 43 cd 20 2e c4 5d-bb 1a 45 d9 95 09 6b 89   $.C. ..]..E...k.
      0020 - 93 5b 00 d2 cb 02 21 00-b9 c4 d3 d4 4a 98 e0 d6   .[....!.....J...
      0030 - 20 45 b2 95 8b 4a 06 d5-6b 3d 90 f6 a7 81 be 1f    E...J..k=......
      0040 - d0 c5 f1 a8 b5 6a d0 b9-                          .....j..

In IKE we only have the bitstring, so we must infer the OID from something else.

---

From: Yaron Sheffer <[email-masked]>
Date: Thu, 26 Jul 2012 23:59:55 +0300

Hi Tero,

the fact that we need to study the protocol details and go into the 
ASN.1 bits to ascertain that we have a problem, strongly suggests to me 
that non-EC DSA is not terribly important. So if we can have a *simple* 
solution that also deals with this problem, fine. Otherwise, let's just 
focus on ECDSA.

Thanks,
	Yaron

---

From: "Dan Harkins" <[email-masked]>
Date: Thu, 26 Jul 2012 14:21:10 -0700 (PDT)

> In IKE we only have the bitstring, so we must infer the OID from something

  Which is why I suggested we take some of the second bunch of RESERVED
bits in the AUTH payload. Not to indicate an OID (not enough bits) but to
just enumerate the valid hash algorithms that can be used with ECDSA.

  That way we know the curve from the subjectPublicKeyInfo (in either
the signer's certificate or raw public key) and the hash algorithm used (from
the 2nd bunch of RESERVED bits). There is nothing to infer. When more
hash algorithms (like SHA3) get defined we just populate the registry that
gets represented in the 2nd bunch of RESERVED bits.

  Dan.

---

From: "Dan Harkins" <[email-masked]>
Date: Thu, 26 Jul 2012 14:22:50 -0700 (PDT)

> solution that also deals with this problem, fine. Otherwise, let's just

  How does one currently indicate the hash algorithm used for non-EC DSA
in IKEv2 today?

  Dan.

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 27 Jul 2012 06:07:15 +0300

>   How does one currently indicate the hash algorithm used for non-EC DSA

Same way than IKEv1 does it, meaning it is assumed to be SHA-1.

Also I would be more happy to reuse the stuff from PKIX than adding
new registy for hashes. This would simplify the auth payload
processing too as the domain parameters and hash both could be seen
from the same place (i.e. from the auth payload) and then we do not
need to add stuff to this registry when new hash functions are added,
we can just assume someone will allocate oids for them.
-- 
[email-masked]

---

From: "Dan Harkins" <[email-masked]>
Date: Thu, 26 Jul 2012 23:30:51 -0700 (PDT)

> Same way than IKEv1 does it, meaning it is assumed to be SHA-1.

  OK, so you're admitting that there's a problem with non-EC DSA in
IKEv2. Good, I agree. I would say the inability for IKEv2 to construct
a signature that is valid today according to FIPS 186-3 is a problem
and we should address it.

> we can just assume someone will allocate oids for them.

  The domain parameter comes from the CERT payload not the AUTH
payload. In any event there's 1 bunch of 8 RESERVED bits and then on the
next aligned ulong there's another 24, that's 32 available but disjoint
bits. How do you propose encoding an OID into the AUTH payload?

  Dan.

---

From: Yoav Nir <[email-masked]>
Date: Fri, 27 Jul 2012 10:13:37 +0300

> and we should address it.

Is that "we" as in the IPsecME group, or "we" the design team? Either way, non-EC DSA is hardly used. There are effectively zero certificates on https servers using it. People preferred RSA even in the days when RSA had to be licensed and DSA was free. Why do we need to fix it now?

> bits. How do you propose encoding an OID into the AUTH payload?

One way is to just place the ASN.1 structure similar to a certificate signature: a sequence containing an OID and a bitstring. That structure can be placed there as the "Authentication Data" field. The only issue I have with that is that there is no negotiation about support for the algorithm, so the OID may turn out to be ECDSA-with-SHA2-224 when the receiver does not even support SHA2-224, but that problem exists also with encoding the SHA2-224 in the currently reserved fields. 

The advantage is that no specification would need to be updated when a new hash function is defined. As long as it has an OID, the spec supports it with no change.

Yoav

---

From: Yaron Sheffer <[email-masked]>
Date: Fri, 27 Jul 2012 11:19:52 +0300

Hi Yoav,

I would take a new IANA registry over embedded ASN.1 snippets any time. 
Just my personal opinion, of course.

Thanks,
	Yaron

---

From: "Dan Harkins" <[email-masked]>
Date: Fri, 27 Jul 2012 08:51:32 -0700 (PDT)

On Fri, July 27, 2012 12:13 am, Yoav Nir wrote:
> Is that "we" as in the IPsecME group, or "we" the design team? Either way,
> non-EC DSA is hardly used. There are effectively zero certificates on
> https servers using it. People preferred RSA even in the days when RSA had
> to be licensed and DSA was free. Why do we need to fix it now?

  I meant "we" as the WG. I think this design team is working at the
pleasure of the WG anyway.

  I'm not sure why a survey of https servers can accurately gauge the use
of DSA in IKEv2. One could also look at it in the light that the SHA-1-only
nature of DSA in IKEv2 only became a problem recently (as FIPS 186-3
and SP 800-57 say such signatures were valid only through 2010). The
reason we need to fix it now is that IKEv2 cannot produce a valid DSA
signature today and unless IKEv3 is just around the corner I'd say we
should fix it in IKEv2 (and given the sound of crickets I hear every time
I bring up IKEv3 I'm less inclined to think it's just around the corner).

> One way is to just place the ASN.1 structure similar to a certificate
> signature: a sequence containing an OID and a bitstring. That structure
> can be placed there as the "Authentication Data" field. The only issue I
> have with that is that there is no negotiation about support for the
> algorithm, so the OID may turn out to be ECDSA-with-SHA2-224 when the
> receiver does not even support SHA2-224, but that problem exists also with
> encoding the SHA2-224 in the currently reserved fields.
>
> The advantage is that no specification would need to be updated when a new
> hash function is defined. As long as it has an OID, the spec supports it
> with no change.

  Yes that would work. Since there would be a new AUTH method we could
overload the Authentication Data field. It seems sort of a "6 of one; half
dozen of the other" kind of thing but I guess "we" can decide that.

  Dan.

---

From: Tero Kivinen <[email-masked]>
Date: Sun, 29 Jul 2012 00:17:30 +0300

> and we should address it.

Yes, and no. I agree there is spefication problem as the RFC5996 says
SHA-1, when it should not say anything about has algorithm and left
that to the FIPS 186-3.

I would expect most implementations which support longer non-EC DSA
keys than what SHA-1 is enough for, most likely already do use SHA-2
for those regardless what RFC5996 says (i.e. they uses fips
specification as more authorative when selecting the hash algorithm
than the example in the RFC5996).

I do agree we should solve this now.

----------------------------------------------------------------------
Using following payload format:

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Next Payload  |C|  RESERVED   |         Payload Length        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Auth Method   |                RESERVED                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                      Authentication Data                      ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

and adding new auth method Generic DSA and say that the authentication
data field of the auth payload will have following format:

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                      Signature Algorithm                      ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                         Signature Data                        ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Where

   * Signature Algorithm is AlgorithmIdentifier ASN.1 blob from the
     RFC5280 section 4.1.1.2
   * Signature Data will be the actual signature value as specified in
     the FIPS-186-3 section 4.6, i.e. (r,s). 

Note, that the Signature Algorithm is ASN.1 SEQUENCE containing the
OID and optional parameters, and its length can be seen from the
SEQUENCE ASN.1 part. There is no padding between the Signature
Algorithm and Signature Data field, the Signature Data field is
directly concatenated to the Signature Algorithm field.
----------------------------------------------------------------------

In normal case that will add around 13-16 bytes to the Auth payload,
and it will solve the problem for both non-EC DSA and ECDSA.

The ASN.1 object of Signature Algorithm will usually be something
like:

0x30 0x0b         - SEQUENCE
  0x06 0x07       - OBJECT IDENTIFIER
    0x2a 0x86 0x48 0xce 0x38 0x04 0x03 - 1.2.840.10040.4.3 dsa-with-sha1
  0x05 0x00       - NULL

or

0x30 0x0c         - SEQUENCE
  0x06 0x08       - OBJECT IDENTIFIER
    0x2a 0x86 0x48 0xce 0x3d 0x04 0x03 0x02 -
    1.2. 840.      10045.    4.   3    2 ecdsa-with-SHA256(2)
  0x05 0x00       - NULL

(Not sure if the ecdsa-with-SHA256(2) is correct oid for this, just
grabbing some random oid from google, also the asn1 encoding might be
wrong as was just manually doing it while writing the email).

Another option would be to use bit more asn.1, i.e. say that
authentication data is:

   authenticationData  ::=  SEQUENCE  {
        signatureAlgorithm   AlgorithmIdentifier,
        signatureValue       BIT STRING  }

which would add 2 for initial sequence + 2 bytes for bit string header
for before the signature value, but I think the first version is
better, as the implementation can simply compare the initial bytes
against internal table if it does not want do asn.1 parsing here.
-- 
[email-masked]

---

From: Johannes Merkle <[email-masked]>
Date: Mon, 30 Jul 2012 11:28:22 +0200

> The advantage is that no specification would need to be updated when a new hash function is defined. As long as it has an OID, the spec supports it with no change.

This is a good solution, which can be used not only for ECDSA but for any signature method. So the question is if the
new auth method should be defined for ECDSA only (generic_ECDSA) or for a broader scope (generic_ECC_signature,
generic_signature).

Johannes