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

Justin Richer <jricher@mitre.org> Mon, 12 December 2011 15:41 UTC

Return-Path: <jricher@mitre.org>
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 B2D1A21F8B65 for <oauth@ietfa.amsl.com>; Mon, 12 Dec 2011 07:41:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.473
X-Spam-Level:
X-Spam-Status: No, score=-6.473 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 FkVlekgz+4Py for <oauth@ietfa.amsl.com>; Mon, 12 Dec 2011 07:41:08 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 2076A21F87E2 for <oauth@ietf.org>; Mon, 12 Dec 2011 07:41:08 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 479CB21B0F57 for <oauth@ietf.org>; Mon, 12 Dec 2011 10:41:07 -0500 (EST)
Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 3002B21B0F53 for <oauth@ietf.org>; Mon, 12 Dec 2011 10:41:07 -0500 (EST)
Received: from [129.83.50.8] (129.83.31.51) by IMCCAS01.MITRE.ORG (129.83.29.78) with Microsoft SMTP Server (TLS) id 14.1.339.1; Mon, 12 Dec 2011 10:41:06 -0500
Message-ID: <4EE6207C.9010002@mitre.org>
Date: Mon, 12 Dec 2011 10:40:44 -0500
From: Justin Richer <jricher@mitre.org>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20111124 Thunderbird/8.0
MIME-Version: 1.0
To: oauth@ietf.org
References: <CALaySJJcPPSU5PAtk9GNL9iFBXj1HfWjkN32GeHsV_Ry2t+o=A@mail.gmail.com> <CAC4RtVABZSo2VXZ4pTGw9P+fdRrUWQajXm+SngQw6Ng9qK+NNQ@mail.gmail.com> <4ED7DF0C.4000701@cdatazone.org> <4ED7DF3B.5010107@stpeter.im> <4ED7EA1C.1040208@cs.tcd.ie> <4ED7EAA2.40402@stpeter.im> <4E1F6AAD24975D4BA5B16804296739435F75C320@TK5EX14MBXC283.redmond.corp.microsoft.com> <4EE3B24D.6000907@cdatazone.org> <1323624493.42216.YahooMailNeo@web31812.mail.mud.yahoo.com>
In-Reply-To: <1323624493.42216.YahooMailNeo@web31812.mail.mud.yahoo.com>
Content-Type: multipart/alternative; boundary="------------050103020804080106070409"
X-Originating-IP: [129.83.31.51]
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: Mon, 12 Dec 2011 15:41:09 -0000

Agreed -- I think that this text addresses the concerns of those who had 
them without getting in too deep to things that are, quite frankly, 
ancillary to OAuth. I still contend that the vast majority of 
implementors reading this will see that line and say "Oh, I need an 
https there instead of an http" and call it a day, but the proposed text 
doesn't *hurt* that case, so I'm relatively fine with it.

  -- Justin

On 12/11/2011 12:28 PM, William Mills wrote:
> I think it's overkill, but I don't think it causes any problems.
>
> ------------------------------------------------------------------------
> *From:* Rob Richards <rrichards@cdatazone.org>
> *To:* Mike Jones <Michael.Jones@microsoft.com>
> *Cc:* Barry Leiba <barryleiba@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-bounces@ietf.org <mailto:oauth-bounces@ietf.org> 
> [mailto:oauth-bounces@ietf.org <mailto:oauth-bounces@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 <mailto:OAuth@ietf.org>
> > https://www.ietf.org/mailman/listinfo/oauth
> >
> >
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org <mailto:OAuth@ietf.org>
> > https://www.ietf.org/mailman/listinfo/oauth
> >
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org <mailto:OAuth@ietf.org>
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth