Hi Yoav,
please see below.
Thanks,
Yaron
On 07/24/2012 09:04 PM, Yoav Nir wrote:
Hi Yaron
I would like to participate.
A few comments on the proposed "charter":
- Flexibility in associating hash functions should not a unlimited. There is
no reason to allow a 521-bit EC group with MD4 as the hash function, or even
with SHA2-256 as the hash function. I'm perfectly happy to limit that curve to
SHA2-512 and SHA3-512.
This is for the group to decide, of course. Personally I'm fine with a
fully flexible or with a somewhat flexible solution. But not with a
solution where we invent a mapping from curve to hash, and the next
curve to come along disproves our theory.
- I don't think "ECDSA" as opposed to "ECGDSA" or "DSA" or "RSA" should be an authentication
method. It seems much more intuitive to me to expand that to "certificate authentication" or "public key signatures".
The user gets a certificate by some method, installs it on their IKE endpoint, and then proceeds to use it. The public key in the
certificate is suitable for verifying one or more kinds of signature, so it does influence the content of the AUTH payloads, but whatever
kind of certificate you use, the method IMO should be the same. Since we're taking the public key from a SPKI structure in a certificate
anyway (or from Tero's OOB draft that uses the same SPKI structure), the type of signature possible is already determined. Or if there is
more than one possibility (as in ECDSA and ECGDSA) this can be signaled in the same way as the hash algorithm.
I would agree if we were designing a new protocol. In this case, we are
solving a problem and I'd like to focus on it. I am sure modular DSA or
RSA have their own challenges, and I see no reason to tackle these
challenges, seeing that the existing solutions work just fine.
As to ECGDSA, I would prefer to leave it out for now. My feeling is that
its constituency is too small to justify the effort. Plus, it can be
tacked on later as an Informational RFC.
Yoav
On Jul 24, 2012, at 7:08 PM, Yaron Sheffer wrote:
Hi,
recent discussion on the list has indicated that there is some interest
in better supporting ECDSA certificates in IKEv2, and that the existing
solutions are not very extensible. The discussion was very useful in
outlining the existing issues and pointing to some possible ways forward.
Paul and I would like to propose setting up a design team with the goal
of proposing a long-term solution to this problem. Some of the
attributes of a reasonable solution include:
- Supports currently used and proposed ECDSA certificates.
- Allows flexibility in defining EC domain parameters.
- Allows flexibility in associating hash functions with EC groups.
- Is not limited to 256 values
- ECDH is out of scope.
- Non-certificate authentication using raw public keys is out of scope,
unless it is trivially supported by the proposal.
The solution should be an extension to IKEv2, and should not break the
protocol. Some of the ideas in
http://www.ietf.org/mail-archive/web/ipsec/current/msg07828.html can be
used as a starting point.
Please respond to us privately or to the list, indicating if you would
like to participate in the design team, or if you only support the
effort and would be willing to review the ensuing I-D.
Thanks,
Yaron
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
