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: [email protected] [mailto:[email protected]] On Behalf Of Sean Turner Sent: Monday, October 22, 2012 5:56 PM To: Dan Harkins Cc: [email protected] 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 of everyone's time. >>> >>> regards, >>> >>> Dan. >>> >>> >>> >> > > > _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
