<chair> DO NOT REPLY TO THIS EMAIL.
To Eran's point, before reaching the end of this thread after limited access to email over the weekend, I was going to shut this thread down anyways. I'm not going to issue a call for consensus on this issue, because I don't believe anyone on the list (except for a small handful of active participants) have read even a fraction of the thread. Furthermore, I'm sure that we understand this threat, and we will ensure that it is properly documented in the Security Considerations. If you are reading this, have not had your voice heard on this matter, and think that this issue is unrepresented in the Security Considerations, please email the chairs directly. b. nb: The OAuth working group's job is to ship OAuth 2.0; while this is includes ensuring a secure protocol, "secure" does not equal "impenetrable". If you believe that cookies and security in HTTP is flawed, please go talk to the HTTP working group and lobby for a MUST of TLS over all HTTP connections. I also urge you to consider the implications of Comodogate – $100 certs ain't what they used to be. </chair> On 5 April 2011 06:59, Eran Hammer-Lahav <e...@hueniverse.com> wrote: > Blaine, Hannes, > > This thread has gone as far as it can. We need to shut it down and move this > item to the chairs (and potentially the AD) to resolve, given that this is > not a technical issue, but a political/procedural one. I'm asking the chairs > to make a decision about this, given that the working group is unable to > reach a conclusion. > > Rant inline below... > > EHL > > >> -----Original Message----- >> From: Francisco Corella [mailto:fcore...@pomcor.com] >> Sent: Monday, April 04, 2011 5:46 PM > >> If the IETF endorsed a protocol such that a compliant implementation allows >> user impersonation and unauthorized access to protected resource, then the >> IETF would be endorsing lack of security. How is that inaccurate? > > Because there is no such thing as an IETF endorsement, and a publication of > an RFC only means that the community has reviewed a document and it represent > as full picture as possible (at that time). There is nothing about an IETF > standard that requires it to always pick security over usability, *as long > as* the security issues are well documented, explained, and given the proper > context and warnings. > > Documenting a security issue and recommending a solution is well within IETF > practice. The point of the security consideration section is to make sure > those implementing the standard understand the security issues involved. No > IETF RFC claims to be 100% secure and that any implementation of it can be > 'trusted'. The IETF should *promote* best security practices, as long as they > are practical. > >> The statement is helpful from the point of view of the users who would be >> the victims of the attacks. You seem to be concerned about companies and >> developers but not about users. > > That's crap. The user has no way of gaging anything with regard to the client > or server implementation. It cannot tell if the server has implemented > anything correctly. The user will never even know OAuth exists. Since when > does a standard protect users? There is no enforcement. No IETF police. I am > not even sure the IETF organization can say anything publically about any > particular implementation without opening itself to litigation. > > Users vote with their feet. How many people stopped using webmail services > once they learned about the danger of FireSheep? Practically none. Our job is > to produce technical documents that improve interoperability and abide by the > best security practices possible. Our only audience are the people > implementing the standard. The only question is, will an average developer > reading the document understand the issue and do as much as possible to > address it? > > I'm in the business of building consumer web products. Who do you think are > my customers? We are all here to serve the needs of the end user. But we also > live in the real world where the web is insecure and we have to work with > what we've got. Your position is that it is better to make a stand and force > almost every consumer web company to violate the specification (since you > can't force them to abide by it). My position is that more people will pay > attention to the issue if we explain it and not give them an excuse to ignore > other security related MUSTs (once you ignore the first, the 2nd, 3rd, 10th > come easy). > > If we make this a MUST, we know Facebook is going to ignore it because they > have no other options at this point in time. They are not going to write > 'Almost OAuth 2.0 compliant' on their site. They are not going to even > mention OAuth to their users. But on their developer site they will say they > support OAuth 2.0. Then you will come and write a long blog post about how > they are not really OAuth 2.0 compliant. Great. Now what? 600 million people > will stop using Facebook? > > You've been told clearly that the three largest consumer web companies (by > audience): Yahoo!, Facebook, and Google, are all going to ignore a MUST if > this is what we are going to specify. Either you just don't care producing a > document that the three biggest players on the web ignore, or you kidding > yourself that they will all commit business suicide and enforce it - forcing > their developers to produce unusable client applications (and that client > developers will go along with it, wasting time on unusable products). > > The world doesn't get any safer with this language, but the spec gets further > away from reality and we all know what a slippery slope that is when > implementation and standards start drifting apart. > > Our job is to fully document any security shortcoming we are aware of. A > SHOULD does just that and is perfectly reasonable. > > EHL > > > > > > > > > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
