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). Thanks, --David > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of Dan > Harkins > Sent: Tuesday, March 27, 2012 10:14 AM > To: Tero Kivinen > Cc: [email protected]; Dan Harkins > Subject: Re: [IPsec] ipsec-registry change for IPSEC Authentication Methods > (Value 3) registration > policy > > > On Tue, March 27, 2012 2:35 am, Tero Kivinen wrote: > > Dan Harkins writes: > >> I guess I'd like to register an objection. I wrote a draft a few > >> months > >> ago to address this: > >> > >> http://www.ietf.org/id/draft-harkins-ike-iana-update-00.txt > >> > >> That suggested making it "Specification Required". You mentioned that > >> someone was opposed to it being "Specification Required" but didn't say > >> who or what the rationale was behind that opposition. > >> > >> So I'd like to discuss this a bit. I prefer "Specification Required" > >> and would like to know what the problem someone has with it is. > > > > See the orignal thread in the ipsec-list: > > > > http://www.ietf.org/mail-archive/web/ipsec/current/msg07428.html > > OK, but that says "'Specification Required' or 'IETF Review'", it's > not opposition to "Specification Required". > > > What is your objection to the IETF Review? > > Well, I feel it is setting the bar too high for what I want to do. > I had to remove a chunk of text from my PAKE draft fixed a significant, > know, serious, and continuing problem with IKEv1. I was told that > I should write another I-D that includes that text and try to see > what happens. The issue is that requiring IESG review and AD sponsorship > will likely result in me not getting over that bar and getting a code > point assigned. > > 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?" > > I don't want to burn up what remaining goodwill I might have with > our ADs by continuing to push this topic. > > That said, the problem I want to fix-- IKEv1's susceptibility to > dictionary attack, it's binding of a PSK to an IP address, and the > prevalence of XAUTH because there's no other option-- should be fixed. > We can say, "stop using IKEv1" but giving someone the option of > implementing PAKE + IKEv2 versus just implementing PAKE, or more likely > just continuing on with a broken XAUTH deployment, we all know what > they'll do and it's not doing PAKE + IKEv2. It would be a service to > the Internet to provide a fix for this. The IETF has not been successful > in forcing people to do things against their will (viz, the history of > IPv6) and if we tried here we'd likely fail again. > > So let me turn it around, what's wrong with "Specification Required"? > > thanks, > > Dan. > > >> > IETF Review - (Formerly called "IETF Consensus" in > >> > [IANA-CONSIDERATIONS]) New values are assigned only > >> through > >> > RFCs that have been shepherded through the IESG as AD- > >> > Sponsored or IETF WG Documents [RFC3932] [RFC3978]. The > >> > intention is that the document and proposed assignment > >> will > >> > be reviewed by the IESG and appropriate IETF WGs (or > >> > experts, if suitable working groups no longer exist) to > >> > ensure that the proposed assignment will not negatively > >> > impact interoperability or otherwise extend IETF protocols > >> > in an inappropriate or damaging manner. > >> > > >> > To ensure adequate community review, such documents are > >> > shepherded through the IESG as AD-sponsored (or WG) > >> > documents with an IETF Last Call. > >> > > >> > Examples: IPSECKEY Algorithm Types [RFC4025], > >> > Accounting-Auth-Method AVP values in DIAMETER [RFC4005], > >> TLS > >> > Handshake Hello Extensions [RFC4366]. > > -- > > [email protected] > > _______________________________________________ > > IPsec mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/ipsec > > > > > _______________________________________________ > IPsec mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
