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

Stephen Farrell <stephen.farrell@cs.tcd.ie> Thu, 01 December 2011 20:57 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C1B221F9473 for <oauth@ietfa.amsl.com>; Thu, 1 Dec 2011 12:57:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r5M4RfO4u2IK for <oauth@ietfa.amsl.com>; Thu, 1 Dec 2011 12:57:03 -0800 (PST)
Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 96D2021F9472 for <oauth@ietf.org>; Thu, 1 Dec 2011 12:57:03 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 5E4741541AF; Thu, 1 Dec 2011 20:57:02 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1322773022; bh=r0NKHjyWwbq2iO hxwXb6LBjj47+N90GA+PYWd1x+1/U=; b=e3j5WU9COxYMUGr6UBaibFXzAJv3b+ IOmLOhJ21FDVn3gcZ5Opxgjspi4GB4kws+ALZg7pjx1vgUGPHUfLRqnxqVtQ3ZOe P4IOBXoI+/+QD8sJ70M2vhwDfa/bOLkUNwKsXoFdoNXGS2cDBQS3wL0XRbtRTO+u MrAFxYYDDocrQarbIDnJG4B+HCImQHt5eFnYluXz1f3c9yiiCptRTurduBMHlZAO NmI3K5d7McalnRAmEzFF0t1B6h001vOlaltzIfBWYw7yjTQo8F8KrO1FInckcHzU 7gQVBQ6jDkEnUoomQiFY7Fr868WU7mZR/34gEXsky5ipeS2E75656yzQ==
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id 9Z57Bc151wmm; Thu, 1 Dec 2011 20:57:02 +0000 (GMT)
Received: from [10.87.48.9] (unknown [86.41.14.223]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 11A2E153C7E; Thu, 1 Dec 2011 20:57:00 +0000 (GMT)
Message-ID: <4ED7EA1C.1040208@cs.tcd.ie>
Date: Thu, 01 Dec 2011 20:57:00 +0000
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Peter Saint-Andre <stpeter@stpeter.im>
References: <CALaySJJcPPSU5PAtk9GNL9iFBXj1HfWjkN32GeHsV_Ry2t+o=A@mail.gmail.com> <CAC4RtVABZSo2VXZ4pTGw9P+fdRrUWQajXm+SngQw6Ng9qK+NNQ@mail.gmail.com> <4ED7DF0C.4000701@cdatazone.org> <4ED7DF3B.5010107@stpeter.im>
In-Reply-To: <4ED7DF3B.5010107@stpeter.im>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: Barry Leiba <barryleiba@computer.org>, oauth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] TLS version requirements in OAuth 2.0 base
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Dec 2011 20:57:05 -0000

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.)

Cheers,
S.


> Peter
>