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
