Subject: [OAUTH-WG] TLS version requirements in OAuth 2.0 base

From: Barry Leiba <[email-masked]>
Date: Thu, 17 Nov 2011 16:41:26 +0800

The OAuth base doc refers in two places to TLS versions (with the same
text in both places:

OLD
The authorization server MUST support TLS 1.0 ([RFC2246]), SHOULD
support TLS 1.2 ([RFC5246]) and its future replacements, and MAY
support additional transport-layer mechanisms meeting its security
requirements.

In both the shepherd review and the AD review, this was called into question:
1. MUST for an old version and SHOULD for the current version seems wrong.
2. Having specific versions required locks us into those versions (for
example, all implementations will have to support TLS 1.0, even long
after it becomes obsolete, unless we rev the spec.

I have suggested the following change, as doc shepherd:

NEW
The authorization server MUST implement the current version of TLS
(1.2 [RFC5246] at the time of this writing), and SHOULD implement the
most widely deployed previous version (1.0 [RFC2246] at the of this
writing), unless that version is deprecated due to security
vulnerabilities.  It MAY also implement additional transport-layer
mechanisms that meet its security requirements.

I believe this also gives us the effect we want, without the two
problems above.  There was consensus in the meeting for accepting this
text.  Confirming on the list:

Please respond to this thread if you *object* to this change, and say
why.  Please respond by 2 Dec 2011.

Barry, as document shepherd

---

From: Rob Richards <[email-masked]>
Date: Thu, 17 Nov 2011 06:07:18 -0500

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

Rob

On 11/17/11 3:41 AM, Barry Leiba wrote:
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: Anthony Nadalin <[email-masked]>
Date: Thu, 17 Nov 2011 11:15:38 +0000

I would agree as we ran into this from some of deployment we had. What is the driving factor here for 1.2 over 1.0?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Rob Richards
Sent: Thursday, November 17, 2011 3:07 AM
To: Barry Leiba
Cc: oauth WG
Subject: Re: [OAUTH-WG] TLS version requirements in OAuth 2.0 base

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

Rob

---

From: Barry Leiba <[email-masked]>
Date: Thu, 17 Nov 2011 19:18:39 +0800

> Please refer to this thread about the problem with requiring anything more
> than TLS 1.0
> 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

---

From: Anthony Nadalin <[email-masked]>
Date: Thu, 17 Nov 2011 11:32:04 +0000

And if the servers don't implement the "should" on 1.0 how do we get deployments for the other actors that can't talk to 1.2

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Barry Leiba
Sent: Thursday, November 17, 2011 3:19 AM
To: Rob Richards
Cc: oauth WG
Subject: Re: [OAUTH-WG] TLS version requirements in OAuth 2.0 base

> 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

---

From: Barry Leiba <[email-masked]>
Date: Thu, 17 Nov 2011 19:34:52 +0800

> And if the servers don't implement the "should" on 1.0 how do we get
> deployments for the other actors that can't talk to 1.2

1. Do you think we'll really see implementations that don't work with
what's out there?

2. SHOULD doesn't mean MAY.  SHOULD means "MUST, unless you have a
really good reason to do otherwise, and understand the implications."

Barry

---

From: Rob Richards <[email-masked]>
Date: Thu, 17 Nov 2011 06:51:20 -0500

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

---

From: Justin Richer <[email-masked]>
Date: Thu, 17 Nov 2011 10:28:26 -0500

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

---

From: Phil Hunt <[email-masked]>
Date: Thu, 17 Nov 2011 10:27:49 -0800

Are there any features of TLS 1.2 that are specifically needed for OAuth2? Can you identify a technical reason other then 'we gotta move the market forward'? 

Given past history in the WG where having any transport security was contentious, I suspect there would be significant objection to 1.2.

Phil

@independentid
www.independentid.com
[email-masked]

---

From: Barry Leiba <[email-masked]>
Date: Mon, 28 Nov 2011 22:39:45 -0500

> after it becomes obsolete, unless we rev the spec.

The comments I've gotten on this show a clear consensus against the
change I suggest, and against any attempt to require a version of TLS
other than 1.0.  I still, though, am concerned that locking this spec
into TLS 1.0 is limiting.  So let me propose an alternative wording,
which again tries to make the version(s) non-normative, while making
it clear which version(s) need to be implemented to get
interoperability:

NEW
--------------------------------------------
The authorization server MUST implement TLS.  Which version(s)
ought to be implemented will vary over time, and depend on
the widespread deployment and known security vulnerabilities at
the time of implementation.  At the time of this writing, TLS version
1.2 [RFC5246] is the most recent version, but has very limited
actual deployment, and might not be readily available in
implementation toolkits.  TLS version 1.0 [RFC2246] is the
most widely deployed version, and will give the broadest
interoperability.

Servers MAY also implement additional transport-layer
mechanisms that meet their security requirements.
--------------------------------------------

Comments on this version?

Barry