I think it's overkill, but I don't think it causes any problems.
________________________________
From: Rob Richards <rricha...@cdatazone.org>
To: Mike Jones <michael.jo...@microsoft.com>
Cc: Barry Leiba <barryle...@computer.org>; oauth WG <oauth@ietf.org>
Sent: Saturday, December 10, 2011 11:26 AM
Subject: Re: [OAUTH-WG] TLS version requirements in OAuth 2.0 base
I am fine with it
Rob
On 12/9/11 1:30 PM, Mike Jones wrote:
> It looks to me like there is consensus for Barry's text (below). Agreed?
>
> -- Mike
>
> 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.
> --------------------------------------------
>
> -----Original Message-----
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
> Peter Saint-Andre
> Sent: Thursday, December 01, 2011 12:59 PM
> To: Stephen Farrell
> Cc: Barry Leiba; oauth WG
> Subject: Re: [OAUTH-WG] TLS version requirements in OAuth 2.0 base
>
> On 12/1/11 1:57 PM, Stephen Farrell wrote:
>>
>> On 12/01/2011 08:10 PM, Peter Saint-Andre wrote:
>>> On 12/1/11 1:09 PM, Rob Richards wrote:
>>>> On 11/28/11 10:39 PM, Barry Leiba wrote:
>>>>>> 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.
>>>>> 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
>>>>>
>>>> Text is neutral enough for me as it's not mandating anything that
>>>> isn't readily available. Only comment is whether or not there is a
>>>> need to even talk about the specific versions or if just the
>>>> following is
>>>> enough:
>>>>
>>>> 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.
>>>>
>>>> Servers MAY also implement additional transport-layer mechanisms
>>>> that meet their security requirements.
>>> That seems fine to me.
>> FWIW, I think I'd prefer Barry's as Rob's would be more likely to
>> generate discusses and we do know that there are some security
>> advantages to TLS 1.2 vs. 1.0. (BTW, has anyone considered how or if
>> the BEAST attack might affect oauth? Be good to know if someone's done
>> that analysis.)
>>
>> However, as AD, I could live with either, since lots of other specs
>> just say TLS. (But you need to point to the latest RFC as normative or
>> that will I bet generate discusses.)
> Agreed.
>
> Peter
>
> --
> Peter Saint-Andre
> https://stpeter.im/
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
