Agree with Rob here. Also, from an application and service developer's perspective, the check for "TLS compliance" is going to go something like this:
1) Does that url start with "https"? 2) If yes, I'm compliant! 3) If no, make the url start with "https" 4) Done! Which will put us in exactly the position Rob outlines here. What we really want is for people to use suitable socket encryption, whatever that means at the time of deployment. -- Justin On Thu, 2011-11-17 at 06:51 -0500, Rob Richards wrote: > I'm saying that it's very difficult for someone to implement an AS that > implements TLS 1.2. TLS 1.2 is not supported in the a good number of > systems people deploy on. For example, the use of Apache and OpenSSL > accounts for a good number of web servers out there. The only way to > deploy a conforming AS is to use a not yet released version of openssl, > 1.0.1, and rebuild or use a different crypto library and rebuild. The > barrier for entry to use OAuth 2.0 has just became to high for the > majority of people out there. I have already hit a scenario where the > security group for a company has balked at OAuth 2.0, prior to the > change relaxing TLS 1.2 usage, because the deployed system did not > support TLS 1.2 and it's against policy to use non-vendor approved > versions of packages. Requiring TLS 1.2 is going to cause the majority > to release non-conforming deployments of OAuth 2, just as it was before > the previous change. > > Rob > > On 11/17/11 6:18 AM, Barry Leiba wrote: > >> Please refer to this thread about the problem with requiring anything more > >> than TLS 1.0 > >> http://www.ietf.org/mail-archive/web/oauth/current/msg07234.html > >> > >> You will end up with a spec that virtually no one can implement and be in > >> conformance with. I still have yet to find an implementation out in the > >> wild > >> that supports anything more than TLS 1.0 > > Are you saying that there's some difficulty in *implementing* TLS 1.2 > > ? If so, please explain what that difficulty is. > > > > If you're saying that TLS 1.2 is not widely deployed, and so it's hard > > to find two implementations that will actually *use* TLS 1.2 to talk > > to each other, I have no argument with you. But that's not the point. > > If everyone implements only TLS 1.0, we'll never move forward. And > > when TLS 1.2 (or something later) does get rolled out, OAuth > > implementations will be left behind. If everyone implements 1.2 AND > > 1.0, then we'll be ready when things move. > > > > I'm pretty sure there'll be trouble getting through the IESG with a > > MUST for something two versions old, and a SHOULD for the current > > version. > > > > Barry > > > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
