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
- [OAUTH-WG] TLS version requirements in OAuth 2.0 … Barry Leiba
- Re: [OAUTH-WG] TLS version requirements in OAuth … Rob Richards
- Re: [OAUTH-WG] TLS version requirements in OAuth … Anthony Nadalin
- Re: [OAUTH-WG] TLS version requirements in OAuth … Barry Leiba
- Re: [OAUTH-WG] TLS version requirements in OAuth … Anthony Nadalin
- Re: [OAUTH-WG] TLS version requirements in OAuth … Barry Leiba
- Re: [OAUTH-WG] TLS version requirements in OAuth … Rob Richards
- Re: [OAUTH-WG] TLS version requirements in OAuth … Justin Richer
- Re: [OAUTH-WG] TLS version requirements in OAuth … Phil Hunt
- Re: [OAUTH-WG] TLS version requirements in OAuth … Barry Leiba
- Re: [OAUTH-WG] TLS version requirements in OAuth … Rob Richards
- Re: [OAUTH-WG] TLS version requirements in OAuth … Peter Saint-Andre
- Re: [OAUTH-WG] TLS version requirements in OAuth … Stephen Farrell
- Re: [OAUTH-WG] TLS version requirements in OAuth … Peter Saint-Andre
- Re: [OAUTH-WG] TLS version requirements in OAuth … Zeltsan, Zachary (Zachary)
- Re: [OAUTH-WG] TLS version requirements in OAuth … Mike Jones
- Re: [OAUTH-WG] TLS version requirements in OAuth … Stephen Farrell
- Re: [OAUTH-WG] TLS version requirements in OAuth … Rob Richards
- Re: [OAUTH-WG] TLS version requirements in OAuth … William Mills
- Re: [OAUTH-WG] TLS version requirements in OAuth … Justin Richer
- Re: [OAUTH-WG] TLS version requirements in OAuth … Barry Leiba
- Re: [OAUTH-WG] TLS version requirements in OAuth … Eran Hammer
- Re: [OAUTH-WG] TLS version requirements in OAuth … Barry Leiba
- Re: [OAUTH-WG] TLS version requirements in OAuth … Igor Faynberg