Hi ,
If the initiator proposes three algorithms say alg1, alg2. Alg3 for encryption
in SA1.
And responders choice is in the order as alg3,alg2,alg1, then finally in
SA_INIT response what should be sent as the algorithm.
From the RFC I felt that it is the initiator choice that should be given
preference and so responder MUST send alg1 in response.
Or is it that responder MUST be given preference and it MUST send alg3 in
response ?
I could not locate any paras in RFC which gives clear guidelines on this.
Please let me know if anything like this is already mentioned otherwise I think
it should be added in clarifications.
Regards,
Kalyani
-Original Message-
From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Sean
Turner
Sent: Monday, October 22, 2012 5:56 PM
To: Dan Harkins
Cc: ipsec@ietf.org
Subject: Re: [IPsec] brainpool summary, suggested way ahead, and comments on
draft
Dan,
I've exchange some emails with with Johannes Merkle about adding cipher suites
to TLS. What he's agreed to do is to include only three points
(BrainpoolP256r1, BrainpoolP384r1, and BrainpoolP512r1) in the draft.
spt
On 10/19/12 3:20 AM, Dan Harkins wrote:
Sean,
It was a two-part request. I'd like the IESG to follow the same
process they followed for what became RFC 5114.
Is there a way to get an RFC published to update this registry that
does not need to go through the IESG? If not then the 2nd part is the
critical one; if so then we can just end this fiasco now.
regards,
Dan.
On Thu, October 18, 2012 7:58 am, Sean Turner wrote:
Dan,
There's not need to ask the IESG about the process to update the
registry in question it's clear: RFC required. You can get an RFC
through a WG, through an AD, or through the ISE.
spt
On 10/15/12 10:54 PM, Dan Harkins wrote:
Hi Sean,
On Mon, October 15, 2012 5:00 pm, Sean Turner wrote:
On 10/12/12 2:32 AM, Dan Harkins wrote:
On Thu, October 11, 2012 5:47 pm, Sean Turner wrote:
I'm going to run my proposal and Michael's by the IESG on an
informal telechat to see which one's got the best chance of
getting through the process to resolve the IEEE's request.
Can you ask the IESG to just do what it has done in the past?
That is, just update the registry to include code points for new
curves without any bizarre notes or pointers? No fuss, no mess,
just a few new rows in a table.
The worst that could happen if the IESG agrees to do that is
that someone somewhere might use a brainpool curve with IKEv1. The
odds are slim, but they're not zero. And if that happens then so
what? Really. So what?
The RFC 5114 example wasn't published to address another SDO
request for a code point so I don't think it's the same situation.
That's certainly a distinction but I don't see how that matters.
You could also note that RFC 5114 added MODP groups as well as ECP
groups. Also a distinction that really doesn't matter.
Again, the SDO request is a _by-product_ of the opposition to
just letting Johannes' draft update the registry. It is this same
opposition that is creating these problems about notes and pointers
and the concern over whether they will have the desired effect and
what we should do to ensure they do. If this opposition had not
materialized there never would've been another SDO request.
It is the same situation, indulge me here a bit:
What we had was another organization (NIST) came up with some
new DH groups and there was a proposal to add them to both IKEv1 and
IKEv2 registries. And now, quite similarly, there's another
organization (the ECC
Brainpool) that came up with some new DH groups and there was a
proposal to add them to both IKEv1 and IKEv2 registries.
When the proposal was made to add the NIST groups to the IKEv1
registry there was no hullabaloo over updating a deprecated
protocol's registry and there was no concern that someone somewhere
might use the NIST groups with IKEv1.
But when Johannes made his proposal to add the ECC Brainpool
curves to the IKEv1 registry there was all of a sudden a hullabaloo
and much concern that someone somewhere might use the ECC Brainpool
groups with IKEv1.
So my request to you is to ask that the IESG consider what the
process defined for updating this registry is (it's RFC required)
and to note that there is precedence to update the registry of this
deprecated protocol.
So please ask the IESG to just approve a draft (either Johannes' or
mine)
for publication as an RFC to update this registry in the same manner
that RFC 5114 updated it (i.e. no notes, no pointers, no nonsense).
Then there'd be no need for the IESG to have a discussion about
the (de)merits of notes and pointers in registries and how best to
ensure that no one nowhere ever even thinks about using an ECC
Brainpool curve in
IKEv1 and that certainly sounds like a better use
