IETF Logo Mail Archive

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

Phil Hunt <phil.hunt@oracle.com> Thu, 17 November 2011 18:28 UTC

Return-Path: <phil.hunt@oracle.com>
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 A8E5A11E80C8 for <oauth@ietfa.amsl.com>; Thu, 17 Nov 2011 10:28:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.511
X-Spam-Level:
X-Spam-Status: No, score=-6.511 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 IzGVH8beAeRU for <oauth@ietfa.amsl.com>; Thu, 17 Nov 2011 10:28:01 -0800 (PST)
Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by ietfa.amsl.com (Postfix) with ESMTP id F3C1711E8086 for <oauth@ietf.org>; Thu, 17 Nov 2011 10:28:00 -0800 (PST)
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id pAHIRv4e004036 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 17 Nov 2011 18:27:58 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id pAHIRu9Y012835 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Nov 2011 18:27:57 GMT
Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id pAHIRp9C012202; Thu, 17 Nov 2011 12:27:51 -0600
Received: from [192.168.1.8] (/24.85.235.164) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 17 Nov 2011 10:27:51 -0800
Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: text/plain; charset="us-ascii"
From: Phil Hunt <phil.hunt@oracle.com>
In-Reply-To: <CALaySJJcPPSU5PAtk9GNL9iFBXj1HfWjkN32GeHsV_Ry2t+o=A@mail.gmail.com>
Date: Thu, 17 Nov 2011 10:27:49 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <6C11A833-1B70-43E6-9ABE-B8C7817B8EF5@oracle.com>
References: <CALaySJJcPPSU5PAtk9GNL9iFBXj1HfWjkN32GeHsV_Ry2t+o=A@mail.gmail.com>
To: Barry Leiba <barryleiba@computer.org>
X-Mailer: Apple Mail (2.1251.1)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090205.4EC5522E.00D5,ss=1,re=0.000,fgs=0
Cc: 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, 17 Nov 2011 18:28:01 -0000

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
phil.hunt@oracle.com





On 2011-11-17, at 12:41 AM, 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.
> 
> 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
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

v2.23.0 | Report a Bug | By Email