> I think we can make things better with a simple addition and I just > want to be able to do that.
To ask bluntly - what is the problem with soliciting AD sponsorship for the simple addition? IMHO, "Specification Required" by itself is entirely too weak for security protocols. Thanks, --David > -----Original Message----- > From: Dan Harkins [mailto:dhark...@lounge.org] > Sent: Tuesday, March 27, 2012 12:23 PM > To: Black, David > Cc: dhark...@lounge.org; kivi...@iki.fi; ipsec@ietf.org > Subject: Re: [IPsec] ipsec-registry change for IPSEC Authentication Methods > (Value 3) registration > policy > > > Hi David, > > On Tue, March 27, 2012 7:39 am, david.bl...@emc.com wrote: > > Hi Dan, > > > > One process note: > > > >> It appears that all the PAKE drafts got one "yes" from the sponsoring > >> AD and the remaining votes were "no objection" so it doesn't seem like > >> the IESG is really interested in this topic and, frankly, I think the > >> majority think "that stuff is out of my field of expertise". So my only > >> option is to cajole an AD into sponsoring my draft and hoping that no > >> one > >> else on the IESG objects by saying, "didn't we just do this?" > > > > Speaking from long experience as a chair of many WGs, that sort of IESG > > vote tally is typical, even for WG docs (although usually both of the > > responsible Area ADs vote yes, as they're both "sponsoring"). IMHO, > > you're being overly pessimistic. > > > >> So let me turn it around, what's wrong with "Specification Required"? > > > > While I know that you're competent to design a solid protocol, who does > > the security review of the next 5 j-random authentication mechanisms to > > make sure that they don't have security flaws? I'd prefer something like > > IESG approval that puts the Security Area in the loop to the notion of > > deferring to some form of Expert Review (this is not a slam against Tero > > as the expert - wider review usually produces better results). > > That's a really good point. Had it been "Specification Required" all > along XAUTH might've gotten an official code point. And who knows maybe > one of the j-random proposals might be just that. But IKEv1 really is > pretty done. At this point I'm pretty sure that j would be zero. > > I know IKE's being used wrong and I know the people who are using it > wrong don't want to go to IKEv2. They understand what they're doing is > broken (a shared PSK for everyone followed by PAP in XAUTH) but they > don't want to go to IKEv2 and use EAP to "fix" it, and it doesn't sound > like going to IKEv2 with SPSK is much more attractive. > > I think we can make things better with a simple addition and I just > want to be able to do that. > > regards, > > Dan. > > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
