For the record, I can except SHOULD. But my very strong feeling is this leads to much more lengthy and complicated language.
I believe we have already crossed the line where it is no longer easy for deployers to figure out if deployments are secure. It is now a spec challenging to even subject matter experts. If we take the current implementers as evidence it shows we have little or no security either due to misunderstandings or business decisions to accept risk for flexibility. It is not time to be idealistic but rather realistic. It looks to me that it is time to either redo authorization to avoid TLS (somehow) or consider splitting into secure/non-secure profiles to satisfy everyone's needs. (not my preference) Any other ideas? Phil Sent from my phone. On 2011-04-02, at 11:46, Eran Hammer-Lahav <e...@hueniverse.com> wrote: > I don’t think your statement that ‘the IETF should endorse lack of security’ > is accurate or helpful. > > > > I completely rejects the notion that a SHOULD with strong language explaining > the risk is any less “secure” than a MUST. > > > > The only impact of using a MUST vs. a SHOULD is that companies deploying it > without requiring TLS on the redirection endpoint will not be able to claim > full compliance if we use a MUST, but will be able to if we use a SHOULD. > > > > RFC 2616 defines compliance as follows: > > > > An implementation is not compliant if it fails to satisfy one or more > > of the MUST or REQUIRED level requirements for the protocols it > > implements. An implementation that satisfies all the MUST or REQUIRED > > level and all the SHOULD level requirements for its protocols is said > > to be "unconditionally compliant"; one that satisfies all the MUST > > level requirements but not all the SHOULD level requirements for its > > protocols is said to be "conditionally compliant." > > > > If we used a SHOULD for TLS, and added such a language, it will enable the > definition of three classes of implementations: non-compliant, > unconditionally compliant (your definition of secure), and conditionally > compliant (what Facebook, Yahoo, Google, and Kiva are likely to deploy). > > > > But my point is that trying to paint the SHOULD option with strong security > guidance as ‘the IETF endorsing an insecure protocol’ or ‘destroy the > credibility of OAuth outside the silly social networking circle’ (I’m > paraphrasing but the spirit of the comments is accurate) is just an overblown > reaction and scare tactic. > > > > Both options are legitimate and produce the same deployment reality. They > only differ in how the spec talks about security and how implementers can > talk about their conformance. > > > > EHL > > > > > > > > From: Francisco Corella [mailto:fcore...@pomcor.com] > Sent: Saturday, April 02, 2011 10:49 AM > To: Skylar Woodward; Phil Hunt; Eran Hammer-Lahav > Cc: Oleg Gryb; OAuth WG; Karen P. Lewison > Subject: Re: [OAUTH-WG] Authorization code security issue (reframed) > > > > Eran, > > > Google, Facebook, and Yahoo! already indicated they will not enforce > > such a MUST. I could not get a clear answer from Twitter. > > > > However, no one representing this companies has bothered to express > > this view on the list, and to express how they would like the > > specification to handle this case. This is why I stopped advocating > > for it (personally, my own product is already end-to-end TLS, and when > > we open it up for developers, will not enforce it for personal > > installations). > > Good. The IETF is not a consortium of companies. What the WG should > debate is whether the IETF should endorse lack of security. > > Francisco > >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
