Re: [Unbearable] Referencing ETLD+1.

Richard Gibson <richard.j.gibson@oracle.com> Thu, 10 May 2018 15:35 UTC

Return-Path: <richard.j.gibson@oracle.com>
X-Original-To: unbearable@ietfa.amsl.com
Delivered-To: unbearable@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6748212EB3E for <unbearable@ietfa.amsl.com>; Thu, 10 May 2018 08:35:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.72
X-Spam-Level:
X-Spam-Status: No, score=-0.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vq2miW6t-tRy for <unbearable@ietfa.amsl.com>; Thu, 10 May 2018 08:35:26 -0700 (PDT)
Received: from userp2120.oracle.com (userp2120.oracle.com [156.151.31.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F26CD12EB3C for <unbearable@ietf.org>; Thu, 10 May 2018 08:35:25 -0700 (PDT)
Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w4AFPq9x109714; Thu, 10 May 2018 15:35:20 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type; s=corp-2017-10-26; bh=FGRwUaTCYn2xCYH2r0qgIjOTl50pGUiNZVIvgKh37Uo=; b=KM53AP8bR1fHwqpD3K4iBrq22Pl+r1+/+VUM1d4cRCcEWEswAqlkiJtTe7AspGmgMDtz 9ysJwoFLMaFTdbTSsjNISGiO7gS/BEqHO3ctzIKt1hHzVlTZ/WqzP57twgqChBLkmQEY LeCMfuGsrV9yvZF3E7SNK2dvHU0mi/QnIbOEkotBkC/O4/ey20b2PnsFDPZO6bpRwKsh AtGlddiOEo9K1AliIBLh1VkeR2C0fFTqSSmgUSuatI32F9HCvKpSYbnKQTwGB2pCsF1b pGj+f7sbGs4OXf83dstCxRXpEOxCckc9IaQEFRX92ZeBTZffPQkuHVjSK1Erh4/uRIfb tA==
Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp2120.oracle.com with ESMTP id 2hv6kp487p-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 10 May 2018 15:35:20 +0000
Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id w4AFZJDm018095 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 10 May 2018 15:35:19 GMT
Received: from abhmp0011.oracle.com (abhmp0011.oracle.com [141.146.116.17]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id w4AFZIHp010023; Thu, 10 May 2018 15:35:18 GMT
Received: from [172.16.4.199] (/216.146.45.242) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 10 May 2018 08:35:18 -0700
To: Patrick McManus <mcmanus@ducksong.com>
Cc: Eric Rescorla <ekr@rtfm.com>, HTTP Working Group <ietf-http-wg@w3.org>, IETF Tokbind WG <unbearable@ietf.org>, Alissa Cooper <alissa@cooperw.in>
References: <CABcZeBOe7NrKYF6f-vi6HcETFM9w4Sav=0qjQQBCXXo_P+FO-g@mail.gmail.com> <CAOdDvNrvkiQUgRZ=Ot00Zh4_iW=CNTVKeYTgoNuo7FvUYA-T3g@mail.gmail.com> <CAOdDvNq=mLbKERze02z1MZh7j0h6sMV5WC+3ozwY1h7fK_muSg@mail.gmail.com>
From: Richard Gibson <richard.j.gibson@oracle.com>
Message-ID: <88480b28-97bf-f152-4a5b-f4d33eb89934@oracle.com>
Date: Thu, 10 May 2018 11:35:16 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <CAOdDvNq=mLbKERze02z1MZh7j0h6sMV5WC+3ozwY1h7fK_muSg@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------38591E905DB8A6D06D1F40C4"
Content-Language: en-US
X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8888 signatures=668698
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1805100146
Archived-At: <https://mailarchive.ietf.org/arch/msg/unbearable/KQrQK5PhgWxmrZwn1IvotlNiKIY>
Subject: Re: [Unbearable] Referencing ETLD+1.
X-BeenThere: unbearable@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" <unbearable.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/unbearable>, <mailto:unbearable-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/unbearable/>
List-Post: <mailto:unbearable@ietf.org>
List-Help: <mailto:unbearable-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/unbearable>, <mailto:unbearable-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 10 May 2018 15:35:28 -0000

There may also be an opportunity to align with the DNS specifications, 
which have the analogous concept of "delegation-centric zone" (cf. 
https://tools.ietf.org/html/rfc7719#page-16 ).


On 05/10/2018 11:19 AM, Patrick McManus wrote:
> A further refinement if you just want to define etld+1, (but I think 
> you need the previous one for 'how to bind cookies' - but that might 
> just be a distraction for you.)
> https://httpwg.org/http-extensions/draft-ietf-httpbis-rfc6265bis.html#terminology 
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__httpwg.org_http-2Dextensions_draft-2Dietf-2Dhttpbis-2Drfc6265bis.html-23terminology&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=-o8MJF7i0TzXAJRB0ncfTVfWKSyTG7nl_iTLU_A2B7c&m=yzrLlKRxElIcQkuxiEY3pvQZ3pbY0S-TG1OKbsNhYLQ&s=Qj8OTv1qz-idFYIn2uzeNNOzyPvQvw502q4GKNUmQNE&e=>
>
> "The term “public suffix” is defined in a note in Section 5.3 of 
> [RFC6265] 
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__httpwg.org_http-2Dextensions_draft-2Dietf-2Dhttpbis-2Drfc6265bis.html-23RFC6265&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=-o8MJF7i0TzXAJRB0ncfTVfWKSyTG7nl_iTLU_A2B7c&m=yzrLlKRxElIcQkuxiEY3pvQZ3pbY0S-TG1OKbsNhYLQ&s=cf5d9JvDL4XR2S_dh6YUyLoFhrAp3dKQHbFUFuSMTfo&e=> 
> as “a domain that is controlled by a public registry”, and are also 
> know as “effective top-level domains” (eTLDs). For example, 
> example.com <http://example.com>’s public suffix is com. User agents 
> SHOULD use an up-to-date public suffix list, such as the one 
> maintained by Mozilla at [PSL] 
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__httpwg.org_http-2Dextensions_draft-2Dietf-2Dhttpbis-2Drfc6265bis.html-23PSL&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=-o8MJF7i0TzXAJRB0ncfTVfWKSyTG7nl_iTLU_A2B7c&m=yzrLlKRxElIcQkuxiEY3pvQZ3pbY0S-TG1OKbsNhYLQ&s=JTwXYs4coubIOQzP7nVBzy43CP-YkTMCyEWZyV7cq7c&e=>. 
>
>
> An origin’s “registered domain” is the origin’s host’s public suffix 
> plus the label to its left. That is, for https://www.example.com, the 
> public suffix is com, and the registered domain is example.com 
> <http://example.com>. This concept is defined more rigorously in [PSL] 
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__httpwg.org_http-2Dextensions_draft-2Dietf-2Dhttpbis-2Drfc6265bis.html-23PSL&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=-o8MJF7i0TzXAJRB0ncfTVfWKSyTG7nl_iTLU_A2B7c&m=yzrLlKRxElIcQkuxiEY3pvQZ3pbY0S-TG1OKbsNhYLQ&s=JTwXYs4coubIOQzP7nVBzy43CP-YkTMCyEWZyV7cq7c&e=>, 
> and is also know as “effective top-level domain plus one” (eTLD+1)."
>
>
>
>
> On Thu, May 10, 2018 at 5:01 PM, Patrick McManus <mcmanus@ducksong.com 
> <mailto:mcmanus@ducksong.com>> wrote:
>
>     Perhaps Mark or Mike West will have a better idea, but I think
>     what you need is in the active 6265bis work:
>     https://httpwg.org/http-extensions/draft-ietf-httpbis-rfc6265bis.html#storage-model
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__httpwg.org_http-2Dextensions_draft-2Dietf-2Dhttpbis-2Drfc6265bis.html-23storage-2Dmodel&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=-o8MJF7i0TzXAJRB0ncfTVfWKSyTG7nl_iTLU_A2B7c&m=yzrLlKRxElIcQkuxiEY3pvQZ3pbY0S-TG1OKbsNhYLQ&s=JhUKutYkjHg6Hhfxm__XggYezkp5cNwuIX8zd3o5tFQ&e=>
>
>     6265bis is making very slow (but steady) progress - taking a
>     normative dependency on its completion would have, imo, a
>     predictable consequence of blocking publication of token binding
>     for quite a while. While there hasn't been a consensus call on the
>     language in that section of 6265bis there is no controversy around
>     it (other than the normal iterative vs declarative style
>     questions)- so my advice would be to use it as a template for
>     describing what you need and engaging the author and http wg for
>     review and any updates that might be required.
>
>     Sorry I don't have a better pointer at hand. Perhaps someone will
>     come up with a normative source.
>
>     -P
>
>
>
>
>     On Thu, May 10, 2018 at 4:26 PM, Eric Rescorla <ekr@rtfm.com
>     <mailto:ekr@rtfm.com>> wrote:
>
>         Hi HTTP WG members,
>
>         https://tools.ietf.org/html/draft-ietf-tokbind-https-15
>         <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dtokbind-2Dhttps-2D15&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=-o8MJF7i0TzXAJRB0ncfTVfWKSyTG7nl_iTLU_A2B7c&m=yzrLlKRxElIcQkuxiEY3pvQZ3pbY0S-TG1OKbsNhYLQ&s=I3FBbAaHs50ovXXf_o_YdfHiq_y2X0-rKRSzSV8oRtE&e=>
>         says:
>
>            The scoping of Token Binding key pairs generated by Web
>         browsers for
>            use in first-party and federation use cases defined in this
>            specification (Section 5), and intended for binding HTTP
>         cookies,
>            MUST be no wider than the granularity of "effective
>         top-level domain
>            (public suffix) + 1" (eTLD+1).  I.e., the scope of Token
>         Binding key
>            pairs is no wider than the scope at which cookies can be
>         set (see
>            [RFC6265]), but MAY be more narrow if cookies are scoped more
>            narrowly.
>
>         Alissa points out that somewhat surprisingly 6265 doesn't actually
>         say this. We obviously want the binding to be tied to eTLD+1, so
>         the question is really how we write this up. Could the HTTP WG
>         provide
>         some guidance here?
>
>         -Ekr
>
>
>
>