Melinda, We clearly have different views on what it means to "[deal] with this like an adult". I would like to address what I *think* were your two main points: the lack of civility in addressing the feedback provided by Mr. Thomas, and the alleged IETF process violation by me as editor. I have not seen any actual technical argument coming from you in support of this change other than 'why not'.
While the 11 people who replied to this thread did dismiss the claim and the need to address it, the conversation was pretty calm and polite. I suggest you go back and read the entire thread: http://www.ietf.org/mail-archive/web/oauth/current/maillist.html Any hints of hostility you find can be justly explained by the frustration of trying to talk to someone who refuses to listen and insists on making a change that everyone else objects to. Given that this is a technical working group, I can safely state that this objection was unanimous based on technical arguments. Process-wise, we are operating under clear and explicit directions from the chairs to only consider changes to the document based on *proposed text* and consensus. As editor, it is completely within my authority to dismiss proposals and changes not matching the criteria set by the chairs, and it is my stated responsibility to reject changes where there clearly is no consensus. While the chairs can change their instructions, someone still has to provide text, which is the only way you can reach consensus. And for the record, in this case, there is clear cut IETF consensus not to make any changes (1 in support, 11 against, and 1 'why not'). That's a close as the IETF gets to unanimity. I agree that the editor is not empowered to make such final declarations, but everyone is free to make that observation, including the editor. I have never refused to make a change in face of clear guidance from the chairs, nor have I ever suggested I have the authority to make such final calls. I find that suggestion disrespectful to my unparalleled contribution to this work over 4 years. Your entire argument is basically 'why not, it's only a few lines in the introduction'. I find this both counter-productive and harmful. The suggested change boils down to explaining to the reader that installing untrusted clients on a user device can have wide repercussions to the security properties of this protocol. But such a claim is both obvious (to everyone but one) and incomplete. It is the incompleteness part that most people objected to, and the fact that any attempt at a comprehensive text would mean significant and open-ended delay. The number of potential ways for malicious code to find its way onto a user device are practically unlimited, and every single one of them will lead to the same security degradation described in this thread. There are certain things we have to take for granted when writing a specification like this. One of them is the reader's understanding that there are many factors outside the scope of the protocol, and malware is one of the most obvious factors. I am completely serious when I say that earthquakes (as suggested jokingly by others) present equal thread to the security model of this protocol because the user hand might shake when trying to deny client access and hitting the approve button instead. So following your login, why not discuss the potential impact of a physical disruption to the user interaction with the authorization endpoint? I am dead serious as I consider the two threats to be of equal relevance to this document. There are many examples of over-specification causing more harm than good and this is clearly one of those cases. 'Why not' is never an acceptable argument for making changes, especially at this stage and for a security protocol. I would also note that every example you tried to give for why accommodating this is the right thing based on past protocols was proved to be misleading or misguided. I would also note that the proposed changes (guessing based on the information provided in lieu of actual text) will not result in *any* actionable result by anyone, if only because there is nothing to do about it other than educate users not to install untrusted software of any kind on any device. Trying to portray the answer below as a more adult response is interesting. If you note, no one actually suggested we change the security thread model document, only that it provides a comprehensive description of the protocol. I am pretty sure most WG participants will still object to this change made in that document for the same reasons. As editor, I consider this matter closed and will not make any changes based on the information presented. You are free ask the chairs to open an issue block the progress of the draft until this is resolved to your satisfaction. EHL > -----Original Message----- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > Of Melinda Shore > Sent: Wednesday, September 07, 2011 11:35 AM > To: oauth@ietf.org > Subject: Re: [OAUTH-WG] problem statement > > On 09/07/2011 10:22 AM, Phil Hunt wrote: > > You should read the threat model document. This document has more > editorial on these kinds of issues. > > This seems reasonable to me, and thank you so much for departing from > what seems to be standard working group mode by dealing with this like an > adult. > > It seems to me that there are some usability problems that while not being > unique to oauth, really aren't that much like what we usually run into with > on-the-wire protocols. Documents in the security area have typically not > dealt with usability issues even when, perhaps, they should, given their > impact on how secure a technology is in the field. Getting that into a threat > model document sounds about right to me. > > Melinda > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
