From nobody Mon Feb 2 11:33:59 2015 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6E161A1A6A; Mon, 2 Feb 2015 11:33:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.621 X-Spam-Level: X-Spam-Status: No, score=0.621 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no 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 N0nzLjBITkqb; Mon, 2 Feb 2015 11:33:53 -0800 (PST) Received: from mail-qc0-x22c.google.com (mail-qc0-x22c.google.com [IPv6:2607:f8b0:400d:c01::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB64C1A1A3D; Mon, 2 Feb 2015 11:33:53 -0800 (PST) Received: by mail-qc0-f172.google.com with SMTP id x3so7942434qcv.3; Mon, 02 Feb 2015 11:33:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=uI8/DrqOr4aHSMHoLzFQ2CETLu0c/QhJ75TE1YVmcOM=; b=Usk2m3GoiDHmmFiF4T3jNtQaEdO1hrBwDD6oQHN51N233uormYyAxB2HLnZ0EtqZlw /rwC2IEw++hgi8ykCYTUpcRc7G9FPq9yt2MDvttDETUFrnHbAe7sKU7QhS3u3H7Bvcts 9ZkJyIRu91uujEckXhoNjrnuAAoJvCzkzSZzx1S0k5EX2F8ecI0CuLh8Ywt/7oLeL7Yf OOUAvuFqCYA4NLN7xpWrUZOd5AjNqHirAxZIgbTbj9JQziOUlkq3RToypdgcdMp/5Hfr 7HMzQ9ggWzGm0LiCR/vLTv5qPPwYwzxymxyiH35E6unUvsRxtM+8YwslQSKk0vkMaFKS SG5w== MIME-Version: 1.0 X-Received: by 10.229.80.3 with SMTP id r3mr1476369qck.23.1422905632966; Mon, 02 Feb 2015 11:33:52 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.140.39.163 with HTTP; Mon, 2 Feb 2015 11:33:52 -0800 (PST) In-Reply-To: References: <20150122064842.15577.18463.idtracker@ietfa.amsl.com> <20150122153730.GB75671@mx1.yitter.info> <20150122165021.GH75671@mx1.yitter.info> <20150127162722.GE1428@mx1.yitter.info> <20150127170006.GF1428@mx1.yitter.info> Date: Mon, 2 Feb 2015 14:33:52 -0500 X-Google-Sender-Auth: bnC4Nrl7Te2A3CjJ4-F4eTuodyU Message-ID: From: Barry Leiba To: Richard Barnes , Andrew Sullivan Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: The IESG , Eliot Lear , "dbound@ietf.org" Subject: Re: [Dbound] Richard Barnes' Block on charter-ietf-dbound-00-01: (with BLOCK) X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2015 19:33:55 -0000 >>> I think it would be sufficient to just say, that "related" is not a >>> unitary concept, and that there will be different flavors of >>> relationship. >> >> Excellent. I think this was exactly the difference we were having >> before, and I'm glad we now agree that it's part of the work for the >> WG, not pre-WG. Thanks! > > Great. I do think some text refactoring is necessary here, though. Let me > know when you've got a proposal. It's been almost a week since this exchange... Any text coming? Andrew, are you the one on the hook for proposing text? Barry From nobody Mon Feb 2 12:10:59 2015 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92F811A1AE1; Mon, 2 Feb 2015 12:10:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.559 X-Spam-Level: ** X-Spam-Status: No, score=2.559 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] autolearn=no 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 KRuoF7IjlNzb; Mon, 2 Feb 2015 12:10:48 -0800 (PST) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 552571A1ADB; Mon, 2 Feb 2015 12:10:48 -0800 (PST) Received: from mx1.yitter.info (mobile-166-171-187-166.mycingular.net [166.171.187.166]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 242448A031; Mon, 2 Feb 2015 20:10:46 +0000 (UTC) Date: Mon, 2 Feb 2015 15:10:43 -0500 From: Andrew Sullivan To: Barry Leiba Message-ID: <20150202201042.GB685@mx1.yitter.info> References: <20150122153730.GB75671@mx1.yitter.info> <20150122165021.GH75671@mx1.yitter.info> <20150127162722.GE1428@mx1.yitter.info> <20150127170006.GF1428@mx1.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: Richard Barnes , The IESG , Eliot Lear , "dbound@ietf.org" Subject: Re: [Dbound] Richard Barnes' Block on charter-ietf-dbound-00-01: (with BLOCK) X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2015 20:10:52 -0000 I suppose I am. I'm having a shortage of tuits of the appropriate shape. A On Mon, Feb 02, 2015 at 02:33:52PM -0500, Barry Leiba wrote: > >>> I think it would be sufficient to just say, that "related" is not a > >>> unitary concept, and that there will be different flavors of > >>> relationship. > >> > >> Excellent. I think this was exactly the difference we were having > >> before, and I'm glad we now agree that it's part of the work for the > >> WG, not pre-WG. Thanks! > > > > Great. I do think some text refactoring is necessary here, though. Let me > > know when you've got a proposal. > > It's been almost a week since this exchange... Any text coming? > Andrew, are you the one on the hook for proposing text? > > Barry -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Mon Feb 2 12:47:16 2015 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 906E31A8F3B; Mon, 2 Feb 2015 12:47:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 unCa1BFWu_gP; Mon, 2 Feb 2015 12:47:13 -0800 (PST) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF2741A8F40; Mon, 2 Feb 2015 12:46:47 -0800 (PST) Received: by mail-ig0-f179.google.com with SMTP id l13so19823322iga.0; Mon, 02 Feb 2015 12:46:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=MrmDNW66czKZTFHOKiMiHX4ev1+czeIGaSAT3ZlTikU=; b=qgNtf0k6Ttxpv0MmeyW6Yej8RG42r8UiJZyz/+ks+KCyyuUs40AK9l9kVcaITYr1cB 1bJjy/gi8fUvPHjFljZWAM5STUge8iR09OBAwnsde0NJag+iGu+Nafh/JSyUXb0Qj8e2 ajLf3c3JdpjiO+MbX/iufK339Jc4DwFfAEc7653Nx6QlHCkXWhNV5kFTqfVjGG7UzDKV /k5xnE02RtzO0NdcBkLDfSJUWK7MYL4BoxVNKdeNBZ4TJALlFWHcN+25dPVqjFM4eMdP fLdBdaXkYWc7KFUY9hKsehqlX5Y8p4b+3OvB74iHzPqubkYmslyq/ic2U2ITgjauigcR /5Pg== X-Received: by 10.107.14.131 with SMTP id 125mr24514657ioo.53.1422910006933; Mon, 02 Feb 2015 12:46:46 -0800 (PST) Received: from [172.29.78.168] ([198.202.203.177]) by mx.google.com with ESMTPSA id i2sm6631206ioi.41.2015.02.02.12.46.45 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 02 Feb 2015 12:46:45 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Suzanne Woolf In-Reply-To: Date: Mon, 2 Feb 2015 14:41:08 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <7D65D273-10B6-4FE7-B753-B2A19A516C8A@gmail.com> References: <20150122064842.15577.18463.idtracker@ietfa.amsl.com> <20150122153730.GB75671@mx1.yitter.info> <20150122165021.GH75671@mx1.yitter.info> <20150127162722.GE1428@mx1.yitter.info> <20150127170006.GF1428@mx1.yitter.info> To: Barry Leiba X-Mailer: Apple Mail (2.1510) Archived-At: Cc: Richard Barnes , IESG IESG , Eliot Lear , Andrew Sullivan , "dbound@ietf.org" Subject: Re: [Dbound] Richard Barnes' Block on charter-ietf-dbound-00-01: (with BLOCK) X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2015 20:47:14 -0000 Hi, I'm not sure anyone is formally "on the hook". I'm happy to take a shot = at it if no one better qualified (a set definitely including but = definitely not limited to Andrew) is able, especially as I'm about to be = stuck in transit for a day or so with nothing to do but homework. thanks, Suzanne On Feb 2, 2015, at 2:33 PM, Barry Leiba wrote: >>>> I think it would be sufficient to just say, that "related" is not a >>>> unitary concept, and that there will be different flavors of >>>> relationship. >>>=20 >>> Excellent. I think this was exactly the difference we were having >>> before, and I'm glad we now agree that it's part of the work for the >>> WG, not pre-WG. Thanks! >>=20 >> Great. I do think some text refactoring is necessary here, though. = Let me >> know when you've got a proposal. >=20 > It's been almost a week since this exchange... Any text coming? > Andrew, are you the one on the hook for proposing text? >=20 > Barry >=20 > _______________________________________________ > Dbound mailing list > Dbound@ietf.org > https://www.ietf.org/mailman/listinfo/dbound From nobody Tue Feb 3 10:46:01 2015 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B13EF1A87E2 for ; Tue, 3 Feb 2015 10:45:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 83ahrUttQDRu for ; Tue, 3 Feb 2015 10:45:57 -0800 (PST) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C0631A8787 for ; Tue, 3 Feb 2015 10:45:57 -0800 (PST) Received: by mail-ie0-f173.google.com with SMTP id tr6so27352548ieb.4 for ; Tue, 03 Feb 2015 10:45:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=2Ox8q15oftE2J/XOF0N8w72dvovkXrsPxFHz5tswncU=; b=ca5rpPAZM96uKEC+w70GS6QEfMFzK6sOnsQ7F5F3xLaYLK8afwdAwEKcBgVX0rlmVJ rDyjXcgH+kU3jgijdvGu1TsMOVGf/UCFsMdd9CHt8J9gwwYmkjgSfTdCkMKUT+MXm6f3 mWDyit2wDH5f50+NxiZySeSvQDr96mk3hMzYMgKtrbIO1Yza1vxSWr+phEcqKUHH81ye rfJu1IouVyS5lxfIEj/JKKJorXKoCHKd8m3lkld0kh7t6aG7Esi0kEfAmjVSAheSIsWm n1AFsCiKQtgQCv6m+cVsLnDXLazRQaYtf79tdW17xxvZeYT3T3P3OCKfalJlCc+e5UaW nKBg== MIME-Version: 1.0 X-Received: by 10.50.137.99 with SMTP id qh3mr19820474igb.9.1422989156700; Tue, 03 Feb 2015 10:45:56 -0800 (PST) Received: by 10.64.77.97 with HTTP; Tue, 3 Feb 2015 10:45:56 -0800 (PST) Date: Tue, 3 Feb 2015 10:45:56 -0800 Message-ID: From: Chris Hartmann To: dbound@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [Dbound] Can/should organizational boundaries include URIs? [x-post from websec] X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2015 18:45:59 -0000 Hello All, A few weeks back a posed a problem statement to the websec list for what I believe to be a fairly universal security/trust problem. I was referred to dbound as a potential home for it. In some ways the problem aligns with trying to better define and discover 'organizational boundaries', and resonates very well with the 'About Dbound' blurb: "Both users and applications make inferences from domain names, usually in an effort to make some determination about identity or the correct security stance to take." However I was going down the path of including URI's as part of the boundary definitions because I'm thinking these types of, perhaps lesser formal but abundant, relationships wouldn't be integrated through DNS, as they seem to not be today - consistently (ie: SaaS). Which raises the question of how do we define an organizations boundaries in "the cloud" (sorry had to say it) and importantly, how can they be authenticated ? Anyway, just wanted to toss this over the fence to confirm if: a) Is this a valid problem ? b) Appropriate and/or intersecting with dbound ? Keep in mind I was unaware of dbound at the time. Here is my problem statement snippet and thread: https://www.ietf.org/mail-archive/web/websec/current/msg02286.html 1) Bob trusts and does personal business with a.com. 2) a.com forms a business relationship with b.com to perform a business function on its behalf (payment processor, blog, whatever). The landing page is b.com/a 3) Bob visits b.com/a and notices that the page claims to be affiliated and owned by a.com 4) How can Bob, in absolute terms, trust that b.com/a is affiliated and a delegated service by a.com? (say, prior to submitting sensitive information) Is this a security problem? I think so. Cheers, Chris From nobody Tue Feb 3 11:26:25 2015 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A76851A1B39 for ; Tue, 3 Feb 2015 11:26:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 8L--_5Yx1Pm8 for ; Tue, 3 Feb 2015 11:26:21 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 8028B1A1A2F for ; Tue, 3 Feb 2015 11:26:19 -0800 (PST) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id E9E75F984; Tue, 3 Feb 2015 14:26:16 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id D2F7B201D1; Tue, 3 Feb 2015 14:26:25 -0500 (EST) From: Daniel Kahn Gillmor To: Chris Hartmann , dbound@ietf.org In-Reply-To: References: User-Agent: Notmuch/0.18.2 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu) Date: Tue, 03 Feb 2015 14:26:25 -0500 Message-ID: <877fvyaja6.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [Dbound] Can/should organizational boundaries include URIs? [x-post from websec] X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2015 19:26:23 -0000 On Tue 2015-02-03 13:45:56 -0500, Chris Hartmann wrote: > "Both users and applications make inferences from domain names, usually > in an effort to make some determination about identity or the correct > security stance to take." > > However I was going down the path of including URI's as part of the > boundary definitions because I'm thinking these types of, perhaps > lesser formal but abundant, relationships wouldn't be integrated > through DNS, as they seem to not be today - consistently (ie: SaaS). > Which raises the question of how do we define an organizations > boundaries in "the cloud" (sorry had to say it) and importantly, how > can they be authenticated ? > > Anyway, just wanted to toss this over the fence to confirm if: > a) Is this a valid problem ? > b) Appropriate and/or intersecting with dbound ? You say URIs, but i think you mean http or https URIs in particular, and not all possible URIs. All possible URIs would wildly complicate the arguments you're trying to make. And even bringing in only http or https URIs to dbound would wildly complicate the dbound problem space, which is already difficult enough. Several of the dbound use cases involve things that have nothing to do with http or https (e.g. choice of names in an X.509 certificate; e-mail domain policies) which wouldn't be enriched at all by this expansion. And dragging in http or https URIs inevitably starts picking at the edges of the (conceptual) web browser itself, which is such a larger problem space than DNS alone that i can't imagine the discussion process terminating. The place to set https URI-to-URI relationship policy is via http mechanisms themselves -- see for example the ongoing discussion about content-security-policy and CORS headers over in the w3c. I'd really like to see dbound itself limited in scope to DNS. --dkg From nobody Tue Feb 3 13:59:43 2015 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E76EF1A036B for ; Tue, 3 Feb 2015 13:59:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.141 X-Spam-Level: X-Spam-Status: No, score=-0.141 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] autolearn=no 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 2YUr8HvaR-4E for ; Tue, 3 Feb 2015 13:59:41 -0800 (PST) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6AFC1A1AB0 for ; Tue, 3 Feb 2015 13:59:41 -0800 (PST) Received: from mx1.yitter.info (unknown [50.189.173.0]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 9C1E18A035 for ; Tue, 3 Feb 2015 21:59:40 +0000 (UTC) Date: Tue, 3 Feb 2015 16:59:39 -0500 From: Andrew Sullivan To: dbound@ietf.org Message-ID: <20150203215939.GF1018@mx1.yitter.info> References: <877fvyaja6.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <877fvyaja6.fsf@alice.fifthhorseman.net> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [Dbound] Can/should organizational boundaries include URIs? [x-post from websec] X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2015 21:59:43 -0000 On Tue, Feb 03, 2015 at 02:26:25PM -0500, Daniel Kahn Gillmor wrote: > You say URIs, but i think you mean http or https URIs in particular, > and not all possible URIs. All possible URIs would wildly complicate > the arguments you're trying to make. > > And even bringing in only http or https URIs to dbound would wildly > complicate the dbound problem space, which is already difficult enough. Indeed, when I produced my first draft on this topic (now 3 or 4 years ago, IIRC), I asked some web security people about it, because of the single origin policy. I got quite brusque responses to the effect that it was useless and stupid because it didn't contain scheme and port, and you coouldn't do anything without that. Well, I tried. Boy, that sucked. (I am not afraid of putting my bad ideas in public repositories, it turns out.) Also, it received the somewhat plausible feedback that we had pretty much always (pace NAPTR) kept those kinds of things out of the DNS and used the DNS to describe the thing to connect to, not the details of the service there. And none of the people who'd commented so strongly about the first proposal would say boo about the second. Finally, the more I thought about this, the more I realised that the existing arrangements _already_ all depend on the name, and only the name. Therefore, it seems to me, to get something that anyone has a hope of understanding, we need to follow the same approach. Really, if you need to differentiate so strongly, then there's an available answer: use a new host-part in your URI. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Tue Feb 3 14:09:46 2015 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 902F91A1A46 for ; Tue, 3 Feb 2015 14:09:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham 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 eNgnGdoKkJqK for ; Tue, 3 Feb 2015 14:09:37 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D95941A1A88 for ; Tue, 3 Feb 2015 14:09:37 -0800 (PST) Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net [76.218.8.156]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id t13M9Xnx029644 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Tue, 3 Feb 2015 14:09:37 -0800 Message-ID: <54D14718.3050805@dcrocker.net> Date: Tue, 03 Feb 2015 14:09:28 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: dbound@ietf.org References: <877fvyaja6.fsf@alice.fifthhorseman.net> <20150203215939.GF1018@mx1.yitter.info> In-Reply-To: <20150203215939.GF1018@mx1.yitter.info> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Tue, 03 Feb 2015 14:09:37 -0800 (PST) Archived-At: Subject: Re: [Dbound] Can/should organizational boundaries include URIs? [x-post from websec] X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2015 22:09:39 -0000 >> You say URIs, but i think you mean http or https URIs in particular, >> and not all possible URIs. All possible URIs would wildly complicate >> the arguments you're trying to make. >> >> And even bringing in only http or https URIs to dbound would wildly >> complicate the dbound problem space, which is already difficult enough. > > Indeed, when I produced my first draft on this topic (now 3 or 4 years > ago, IIRC), ... > Finally, the more I thought about this, the more I realised that the > existing arrangements _already_ all depend on the name, and only the > name. Therefore, it seems to me, to get something that anyone has a > hope of understanding, we need to follow the same approach. Really, > if you need to differentiate so strongly, then there's an available > answer: use a new host-part in your URI. I don't recall seeing a non-technical, non-acronym description of what the desired user-level functionality is, that drives wanting to store URIs or the like. Can someone either proffer or point to some text of that sort? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue Feb 3 14:38:45 2015 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 131561A887D for ; Tue, 3 Feb 2015 14:38:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.141 X-Spam-Level: X-Spam-Status: No, score=-0.141 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] autolearn=no 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 V6C6c_o2qN8o for ; Tue, 3 Feb 2015 14:38:43 -0800 (PST) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 450661A8720 for ; Tue, 3 Feb 2015 14:38:43 -0800 (PST) Received: from mx1.yitter.info (unknown [50.189.173.0]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 3A7D38A035; Tue, 3 Feb 2015 22:38:42 +0000 (UTC) Date: Tue, 3 Feb 2015 17:38:40 -0500 From: Andrew Sullivan To: dcrocker@bbiw.net Message-ID: <20150203223840.GI1018@mx1.yitter.info> References: <877fvyaja6.fsf@alice.fifthhorseman.net> <20150203215939.GF1018@mx1.yitter.info> <54D14718.3050805@dcrocker.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54D14718.3050805@dcrocker.net> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: dbound@ietf.org Subject: Re: [Dbound] Can/should organizational boundaries include URIs? [x-post from websec] X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2015 22:38:44 -0000 On Tue, Feb 03, 2015 at 02:09:28PM -0800, Dave Crocker wrote: > I don't recall seeing a non-technical, non-acronym description of what > the desired user-level functionality is, that drives wanting to store > URIs or the like. Can someone either proffer or point to some text of > that sort? > I doubt it. I tried, though not hard enough, in https://tools.ietf.org/html/draft-sullivan-domain-origin-assert-02. The history of that document might be useful (and I freely admit might not be). A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Tue Feb 3 14:54:05 2015 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EB111A1AA6 for ; Tue, 3 Feb 2015 14:54:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.559 X-Spam-Level: ** X-Spam-Status: No, score=2.559 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] autolearn=no 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 o6DTvfeUfz1q for ; Tue, 3 Feb 2015 14:54:00 -0800 (PST) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 349531A1A2F for ; Tue, 3 Feb 2015 14:54:00 -0800 (PST) Received: from mx1.yitter.info (unknown [50.189.173.0]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 115D58A035 for ; Tue, 3 Feb 2015 22:53:59 +0000 (UTC) Date: Tue, 3 Feb 2015 17:53:57 -0500 From: Andrew Sullivan To: dbound@ietf.org Message-ID: <20150203225357.GJ1018@mx1.yitter.info> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="3uo+9/B/ebqu+fSQ" Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: [Dbound] Another go at the charter X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2015 22:54:02 -0000 --3uo+9/B/ebqu+fSQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi all, Because I had a couple unscheduled minutes, to my surprise, I thought I'd try banging away on the charter to address the issues that came up during IESG review. Here's a go at it. Shred as appropriate. A -- Andrew Sullivan ajs@anvilwalrusden.com --3uo+9/B/ebqu+fSQ Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="charter-ajs-20150203.txt" Various Internet protocols and applications require some mechanism for determining whether two domain names are related. The meaning of "related" in this context is not a unitart concept. The DBOUND working group will develop one or more solutions to this family of problems, and will clarify the types of relations relevant. For example, it is often necessary or useful to determine whether example.com and foo.example.com, or even example.net, are subject to the same administrative control. To humans, the answer to this may be obvious. However, the Domain Name System (DNS), which is the service that handles domain name queries, does not provide the ability to mark these sorts of relationships. This makes it impossible to discern relationships algorithmically. The right answer is not always "compare the rightmost two labels". Applications and organizations impose policies and procedures that create additional structure in their use of domain names. This creates many possible relationships that are not evident in the names themselves or in the operational, public representation of the names. Prior solutions for identifying relationships between domain names have sought to use the DNS namespace and protocol to extract that information when it isn't actually there. See the "Additional Background Information" section, below, for more details. For the purpose of this work, domain names are identifiers used by organizations and services, independent of underlying protocols or mechanisms. We define an "organizational domain" to be a name that is at the top of an administrative hierarchy, defining transition from one "outside" administrative authority to another that is "inside" the organization. There are two broad use cases that seem to be common. The first is a "top ancestor organization" case. In this case, the goal is to find a single superordinate name in the DNS tree that can properly make assertions about the policies and procedures of subordinate names. The second is to determine, given two different names, whether they are governed by the same administrative authority. The goal of the DBOUND working group will develop a unified solution, if possible, for determining organizational domain boundaries. However, the working group may discover that the use cases require different solutions. Should that happen, the working group will develop those different solutions, using as many common pieces as it can. Solutions will not involve the proposal of any changes to the DNS protocol. They might involve the creation of new resource record types. This working group will not seek to amend the consuming protocols themselves (standards for any web, email, or other such protocols) without rechartering, and such rechartering will only be considered after completion of the base work. The working group has a pre-IETF draft to consider as a possible starting point: draft-sullivan-dbound-problem-statement Milestones: - TBD [I think the stuff below gets trimmed and moved into problem-statement or something, right?] Additional Background Information --------------------------------- The concept of an administrative boundary is by definition not present in the DNS. Relying on the DNS to divine administrative structure thus renders such solutions unreliable and unnecessarily constrained. For example, confirming or dismissing a relationship between two domain names based on the existence of a zone cut or common ancestry is often unfounded, and the notion of an upward "tree walk" as a search mechanism is, therefore, unacceptable. Currently, the most well known solution in existence is the Public Suffix List (PSL). The PSL is maintained by a web browser producer and is kept current by volunteers on a best-effort basis. It contains a list of points in the hierarchical namespace at which registrations take place, and is used to identify the boundary between so-called "public" names (below which registrations can occur, such as ".com" or ".org.uk") and the private names (organizational names) that domain registrars create within them. When this list is inaccurate, it exposes a deviation from reality that degrades service to some and can be exploited by others. As the PSL is the de-facto resource, and as there is not a more comprehensive, alternative solution for relationship identification, the PSL has often been misused to accomplish things beyond its capabilities. For example, there is no way to confirm the relationship between two domain names -- the PSL may only signal that there is or is not a public boundary between the two. Additionally, there are questions about the scalability, central management, and third-party management of the PSL as it currently exists. In terms of specific use cases, within the realm of email there is a desire to link an arbitrary fully-qualified domain name (FQDN) to the organizational domain name (at some point in the namespace above it), in order to identify a deterministic location where some sort of statement of policy regarding that FQDN can be found. With respect to the web, there is a similar need to identify relationships between different FQDNs, currently accomplished by comparing ancestries. However, there is also desire to reliably identify relationships outside of the realm and constraints of the namespace tree. Work such as DMARC (draft-kucherawy-dmarc-base), will certainly benefit from having this capability. --3uo+9/B/ebqu+fSQ-- From nobody Tue Feb 3 15:23:34 2015 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E64A51A1A17 for ; Tue, 3 Feb 2015 15:23:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 2YnSm3tFYOrt for ; Tue, 3 Feb 2015 15:23:31 -0800 (PST) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 721981A1A15 for ; Tue, 3 Feb 2015 15:23:31 -0800 (PST) Received: by mail-ie0-f175.google.com with SMTP id ar1so29196738iec.6 for ; Tue, 03 Feb 2015 15:23:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6cM0d/5FvslS+kuXoSCTwarB7/i2h9LFlilNwJ+tyNk=; b=p3wZs/+kkkKDrWif+vKkNau6STwk8kGPM2vBmLQ4moqpqborBMy5/9+SFwAMfHeem3 joNylYBZUUqqzrBIwv32YNf6jmye+HoC+PTarLBC5GNXK7KFT+MSwcpcQPRvOLYCOAEh I1E03GDBhznIJjxD367mgfZvbEFZI1QPluTWGzLQXs4ozbi/PNf6F05vy+joJtILtWBM ZVu0j+1MfmEPHm7zZ/TMRJvwSACazCOdow4Mu+OjFS8k6IyatZJ0h4+P+p3VumRD79fk +Fy6Z5qMkDWlo3iRLUdkPdruMJZDzik+NM3ppVFVv2tO+016Gakte2jnIxwC3pyujAQF QKJA== MIME-Version: 1.0 X-Received: by 10.50.142.38 with SMTP id rt6mr20977415igb.17.1423005810650; Tue, 03 Feb 2015 15:23:30 -0800 (PST) Received: by 10.64.77.97 with HTTP; Tue, 3 Feb 2015 15:23:30 -0800 (PST) In-Reply-To: <877fvyaja6.fsf@alice.fifthhorseman.net> References: <877fvyaja6.fsf@alice.fifthhorseman.net> Date: Tue, 3 Feb 2015 15:23:30 -0800 Message-ID: From: Chris Hartmann To: Daniel Kahn Gillmor Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: dbound@ietf.org Subject: Re: [Dbound] Can/should organizational boundaries include URIs? [x-post from websec] X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2015 23:23:33 -0000 On Tue, Feb 3, 2015 at 11:26 AM, Daniel Kahn Gillmor wrote: > On Tue 2015-02-03 13:45:56 -0500, Chris Hartmann wrote: > >> "Both users and applications make inferences from domain names, usually >> in an effort to make some determination about identity or the correct >> security stance to take." >> >> However I was going down the path of including URI's as part of the >> boundary definitions because I'm thinking these types of, perhaps >> lesser formal but abundant, relationships wouldn't be integrated >> through DNS, as they seem to not be today - consistently (ie: SaaS). >> Which raises the question of how do we define an organizations >> boundaries in "the cloud" (sorry had to say it) and importantly, how >> can they be authenticated ? >> >> Anyway, just wanted to toss this over the fence to confirm if: >> a) Is this a valid problem ? >> b) Appropriate and/or intersecting with dbound ? > > You say URIs, but i think you mean http or https URIs in particular, > and not all possible URIs. All possible URIs would wildly complicate > the arguments you're trying to make. > > And even bringing in only http or https URIs to dbound would wildly > complicate the dbound problem space, which is already difficult enough. > Several of the dbound use cases involve things that have nothing to do > with http or https (e.g. choice of names in an X.509 certificate; e-mail > domain policies) which wouldn't be enriched at all by this expansion. > > And dragging in http or https URIs inevitably starts picking at the > edges of the (conceptual) web browser itself, which is such a larger > problem space than DNS alone that i can't imagine the discussion process > terminating. > > The place to set https URI-to-URI relationship policy is via http > mechanisms themselves -- see for example the ongoing discussion about > content-security-policy and CORS headers over in the w3c. > > I'd really like to see dbound itself limited in scope to DNS. > > --dkg I agree with your points here. The problem perhaps aligns in spirit (somewhat), but by definition it doesn't fit entirely in DNS either. Thanks for the feedback. Any feedback on the problem by itself would be appreciated as well (perhaps off thread if that is more appropriate) Thanks, Chris From nobody Tue Feb 3 17:26:38 2015 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0D1D1A88A6 for ; Tue, 3 Feb 2015 17:26:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.663 X-Spam-Level: * X-Spam-Status: No, score=1.663 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no 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 jf8xMR8wtLiz for ; Tue, 3 Feb 2015 17:26:32 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 672341A8725 for ; Tue, 3 Feb 2015 17:26:32 -0800 (PST) Received: (qmail 86426 invoked from network); 4 Feb 2015 01:26:31 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 4 Feb 2015 01:26:31 -0000 Date: 4 Feb 2015 01:26:09 -0000 Message-ID: <20150204012609.18710.qmail@ary.lan> From: "John Levine" To: dbound@ietf.org In-Reply-To: <20150203225357.GJ1018@mx1.yitter.info> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: ajs@anvilwalrusden.com Subject: Re: [Dbound] Another go at the charter X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 01:26:34 -0000 >There are two broad use cases that seem to be common. The first is a >"top ancestor organization" case. In this case, the goal is to find a >single superordinate name in the DNS tree that can properly make >assertions about the policies and procedures of subordinate names. The >second is to determine, given two different names, whether they are >governed by the same administrative authority. ... Where does the CA use case asking whether it's OK to put a wildcard under a name, a/k/a is this a public or private name, fit in? I realize we may have to add language to mollify people, but I continue to believe that attempting to enumerate the use cases in the charter other than perhaps "whatever people use the PSL for" is a mistake. R's, John From nobody Tue Feb 3 17:34:21 2015 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F8AF1A88C3 for ; Tue, 3 Feb 2015 17:34:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.141 X-Spam-Level: X-Spam-Status: No, score=-0.141 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] autolearn=no 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 sOnp0Y9-MAoH for ; Tue, 3 Feb 2015 17:34:17 -0800 (PST) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB4211A88B4 for ; Tue, 3 Feb 2015 17:34:16 -0800 (PST) Received: from mx1.yitter.info (unknown [50.189.173.0]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 824138A035 for ; Wed, 4 Feb 2015 01:34:15 +0000 (UTC) Date: Tue, 3 Feb 2015 20:34:14 -0500 From: Andrew Sullivan To: dbound@ietf.org Message-ID: <20150204013413.GC1583@mx1.yitter.info> References: <20150203225357.GJ1018@mx1.yitter.info> <20150204012609.18710.qmail@ary.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150204012609.18710.qmail@ary.lan> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [Dbound] Another go at the charter X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 01:34:18 -0000 On Wed, Feb 04, 2015 at 01:26:09AM -0000, John Levine wrote: > Where does the CA use case asking whether it's OK to put a wildcard > under a name, a/k/a is this a public or private name, fit in? "Problem for the WG to sort out"? > I realize we may have to add language to mollify people, but I > continue to believe that attempting to enumerate the use cases in the > charter other than perhaps "whatever people use the PSL for" is a > mistake. We'll never get chartered unless we make this change, so let's just do it. If we added more text (before the new sentences I added) that said basically, "The current way most of this is handled is via a list published at publicsuffix.org, and the general goal is to accommodate anything people are using that for today. However, there are broadly speaking two use patterns," or something like that, would it work? A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Tue Feb 3 17:46:36 2015 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A7971A88CF for ; Tue, 3 Feb 2015 17:46:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 tRuGKXfPZZoZ for ; Tue, 3 Feb 2015 17:46:31 -0800 (PST) Received: from mail-la0-f41.google.com (mail-la0-f41.google.com [209.85.215.41]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F6271A88CC for ; Tue, 3 Feb 2015 17:46:31 -0800 (PST) Received: by mail-la0-f41.google.com with SMTP id gm9so55706437lab.0 for ; Tue, 03 Feb 2015 17:46:29 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=V/gp2iUBx7SuP+TJN5I4+aq6sWy6miFfKi68hdX5rb4=; b=ciMYQo+WDPpnm3NlPQmWd4lKexzKpuEI5s4lLhJzaWnBpM9KoKGYB7aD2s0/r2kgj+ shGTP0+pNXpgxKas34E8YNeiqf534lObYbiOPUaZ2MHu8vexO9Ceu65zel5lc7QzjEZS IostZcTc397Xa3piAz+ikcb1GT49aEi9ttcJqR/TXXx03z2tb5Nwno23qurwlvw7T27e 0RTJgUxa2iTuhlQAl2LLcmpnlUSOXePC6qFM5Iy03HgkUjN1E1WU0JFU3IiszRrrm0bi cOmHXrLagqlmuEq+7KL83iomp6xKL5ATrtxc9L59EEDcsqff9Li6q9NRxn3cevR9sI6r 7ggg== X-Gm-Message-State: ALoCoQl9VJBWjP9He7RQr0fnNfCtWKp8453T8WKzpTJysOu663NiAUJnYKxxHj0xxnnTCLi5mP1y X-Received: by 10.112.26.110 with SMTP id k14mr12919841lbg.29.1423014389499; Tue, 03 Feb 2015 17:46:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.12.8 with HTTP; Tue, 3 Feb 2015 17:45:58 -0800 (PST) In-Reply-To: <20150204013413.GC1583@mx1.yitter.info> References: <20150203225357.GJ1018@mx1.yitter.info> <20150204012609.18710.qmail@ary.lan> <20150204013413.GC1583@mx1.yitter.info> From: Jothan Frakes Date: Tue, 3 Feb 2015 17:45:58 -0800 Message-ID: To: Andrew Sullivan Content-Type: multipart/alternative; boundary=001a1133ad5c325c29050e395b38 Archived-At: Cc: "dbound@ietf.org" Subject: Re: [Dbound] Another go at the charter X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 01:46:34 -0000 --001a1133ad5c325c29050e395b38 Content-Type: text/plain; charset=UTF-8 Throwing this in if it is helpful. Treat it like a buffet - take what you want and leave the rest... There is an enumeration of some of the use cases of PSL at this URL: https://publicsuffix.org/learn/ and I suspect part of what this group would want to do is identify which of those use cases would / could be better served, more authoritatively served, or otherwise handled through what is defined in DBOUND. There is a lot there, very broadly defined in some cases. For example, it lists programming languages that are using PSL but not necessarily how or what the derivative use those libraries might make of PSL. BUT, there are use cases like the Document Object, cookies, document.domain, or certs that might be ripe candidates for attention. Perhaps referencing the URL as part of it? Sample: "The current way most of this is handled is via a list published at publicsuffix.org, and the general goal is to accommodate those use cases (as defined at https://publicsuffix.org/learn/) of how people are using that today." Jothan Frakes Tel: +1.206-355-0230 On Tue, Feb 3, 2015 at 5:34 PM, Andrew Sullivan wrote: > On Wed, Feb 04, 2015 at 01:26:09AM -0000, John Levine wrote: > > Where does the CA use case asking whether it's OK to put a wildcard > > under a name, a/k/a is this a public or private name, fit in? > > "Problem for the WG to sort out"? > > > I realize we may have to add language to mollify people, but I > > continue to believe that attempting to enumerate the use cases in the > > charter other than perhaps "whatever people use the PSL for" is a > > mistake. > > We'll never get chartered unless we make this change, so let's just do > it. If we added more text (before the new sentences I added) that > said basically, "The current way most of this is handled is via a list > published at publicsuffix.org, and the general goal is to accommodate > anything people are using that for today. However, there are broadly > speaking two use patterns," or something like that, would it work? > > A > > -- > Andrew Sullivan > ajs@anvilwalrusden.com > > _______________________________________________ > Dbound mailing list > Dbound@ietf.org > https://www.ietf.org/mailman/listinfo/dbound > --001a1133ad5c325c29050e395b38 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Throwing this in if it is helpful.=C2=A0 Treat it like a b= uffet - take what you want and leave the rest...

There i= s an enumeration of some of the use cases of PSL at this URL:=C2=A0https://publicsuffix.org/learn/ an= d I suspect part of what this group would want to do is identify which of t= hose use cases would / could be better served, more authoritatively served,= or otherwise handled through what is defined in DBOUND.

There is a lot there, very broadly defined in some cases.=C2=A0 For exampl= e, it lists programming languages that are using PSL but not necessarily ho= w or what the derivative use those libraries might make of PSL.
<= br>
BUT, there are use cases like the Document Object, cookies, d= ocument.domain, or certs that might be ripe candidates for attention.
Perhaps referencing the URL as part of it?

Sample:
"The current way most of this is han= dled is via a list=C2=A0published at=C2=A0publicsuffix.org, and the general goal is to accommodate= those use cases (as defined at=C2=A0https://publicsuffix.org/learn/)=C2=A0of how people are using that today."

<= /span>




Jotha= n Frakes
Tel: +1.206-355-0230


On Tue, Feb 3, 2015 at 5:34 PM, Andrew Sulli= van <ajs@anvilwalrusden.com> wrote:
On Wed, Feb 04, 2015 at 01:26:09AM -0000, = John Levine wrote:
> Where does the CA use case asking whether it's OK to put a wildcar= d
> under a name, a/k/a is this a public or private name, fit in?

"Problem for the WG to sort out"?

> I realize we may have to add language to mollify people, but I
> continue to believe that attempting to enumerate the use cases in the<= br> > charter other than perhaps "whatever people use the PSL for"= is a
> mistake.

We'll never get chartered unless we make this change, so let'= ;s just do
it.=C2=A0 If we added more text (before the new sentences I added) that
said basically, "The current way most of this is handled is via a list=
published at publicsu= ffix.org, and the general goal is to accommodate
anything people are using that for today.=C2=A0 However, there are broadly<= br> speaking two use patterns," or something like that, would it work?

A

--
Andrew Sullivan
ajs@anvilwalrusden.com

____________________________= ___________________
Dbound mailing list
Dbound@ietf.org
= https://www.ietf.org/mailman/listinfo/dbound

--001a1133ad5c325c29050e395b38-- From nobody Tue Feb 3 22:11:38 2015 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8EFC1A1F16 for ; Tue, 3 Feb 2015 22:11:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.663 X-Spam-Level: * X-Spam-Status: No, score=1.663 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no 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 CFU1YFzUMUQo for ; Tue, 3 Feb 2015 22:11:36 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0F811A1EF9 for ; Tue, 3 Feb 2015 22:11:35 -0800 (PST) Received: (qmail 23443 invoked from network); 4 Feb 2015 06:11:34 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 4 Feb 2015 06:11:34 -0000 Date: 4 Feb 2015 06:11:12 -0000 Message-ID: <20150204061112.19440.qmail@ary.lan> From: "John Levine" To: dbound@ietf.org In-Reply-To: <20150204013413.GC1583@mx1.yitter.info> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: ajs@anvilwalrusden.com Subject: Re: [Dbound] Another go at the charter X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 06:11:37 -0000 >We'll never get chartered unless we make this change, so let's just do >it. If we added more text (before the new sentences I added) that >said basically, "The current way most of this is handled is via a list >published at publicsuffix.org, and the general goal is to accommodate >anything people are using that for today. However, there are broadly >speaking two use patterns," or something like that, would it work? Personally, I think there are at least three and possibly more, but I agree with you that in this case political expediency trumps accuracy. R's, John From nobody Wed Feb 4 01:37:07 2015 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47C651A86EF for ; Wed, 4 Feb 2015 01:37:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 0BWbgNg8duI5 for ; Wed, 4 Feb 2015 01:37:02 -0800 (PST) Received: from smtp.mozilla.org (mx1.corp.phx1.mozilla.com [63.245.216.69]) (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 DCD8C1A1DBC for ; Wed, 4 Feb 2015 01:37:02 -0800 (PST) Received: from [192.168.0.103] (93.243.187.81.in-addr.arpa [81.187.243.93]) (Authenticated sender: gerv@mozilla.org) by mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 2CA97F2271; Wed, 4 Feb 2015 01:37:00 -0800 (PST) Message-ID: <54D1E83B.20604@mozilla.org> Date: Wed, 04 Feb 2015 09:36:59 +0000 From: Gervase Markham User-Agent: Mozilla/5.0 (X11; Linux i686; rv:34.0) Gecko/20100101 Thunderbird/34.0 MIME-Version: 1.0 To: John Levine , dbound@ietf.org References: <20150204012609.18710.qmail@ary.lan> In-Reply-To: <20150204012609.18710.qmail@ary.lan> OpenPGP: id=9DF43DBB Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: ajs@anvilwalrusden.com Subject: Re: [Dbound] Another go at the charter X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 09:37:05 -0000 On 04/02/15 01:26, John Levine wrote: > Where does the CA use case asking whether it's OK to put a wildcard > under a name, a/k/a is this a public or private name, fit in? Note that the PSL's role in CA wildcard determination is _advisory_, not normative. That is to say, CAs are not forbidden from issuing *.publicsuffix, but they have to use a "high risk" procedure for doing so, which would involve more manual checks. This is intentional. However, it does mean that a solution which produces the right answer "most of the time" would be good enough for this use case, because that's what the PSL does at the moment. Gerv From nobody Wed Feb 4 01:38:35 2015 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95DC91A86EF for ; Wed, 4 Feb 2015 01:38:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.279 X-Spam-Level: X-Spam-Status: No, score=-3.279 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 nvOKQWvA29ki for ; Wed, 4 Feb 2015 01:38:32 -0800 (PST) Received: from smtp.mozilla.org (mx1.corp.phx1.mozilla.com [63.245.216.69]) (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 007921A86E9 for ; Wed, 4 Feb 2015 01:38:31 -0800 (PST) Received: from [192.168.0.103] (93.243.187.81.in-addr.arpa [81.187.243.93]) (Authenticated sender: gerv@mozilla.org) by mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id B02B4F27EB; Wed, 4 Feb 2015 01:38:30 -0800 (PST) Message-ID: <54D1E895.5060907@mozilla.org> Date: Wed, 04 Feb 2015 09:38:29 +0000 From: Gervase Markham User-Agent: Mozilla/5.0 (X11; Linux i686; rv:34.0) Gecko/20100101 Thunderbird/34.0 MIME-Version: 1.0 To: Jothan Frakes , Andrew Sullivan References: <20150203225357.GJ1018@mx1.yitter.info> <20150204012609.18710.qmail@ary.lan> <20150204013413.GC1583@mx1.yitter.info> In-Reply-To: OpenPGP: id=9DF43DBB Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "dbound@ietf.org" Subject: Re: [Dbound] Another go at the charter X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 09:38:34 -0000 On 04/02/15 01:45, Jothan Frakes wrote: > There is an enumeration of some of the use cases of PSL at this > URL: https://publicsuffix.org/learn/ A better URL is this one: https://wiki.mozilla.org/Public_Suffix_List/Uses Edits welcome. > There is a lot there, very broadly defined in some cases. For example, > it lists programming languages that are using PSL but not necessarily > how or what the derivative use those libraries might make of PSL. Indeed; we have little insight into how people are using various PSL-wrapping libraries. Gerv From nobody Wed Feb 4 12:38:31 2015 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26FF01A1A22 for ; Wed, 4 Feb 2015 12:38:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.663 X-Spam-Level: * X-Spam-Status: No, score=1.663 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no 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 DUP_fbBGvt7B for ; Wed, 4 Feb 2015 12:38:30 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A3E21A1B37 for ; Wed, 4 Feb 2015 12:38:29 -0800 (PST) Received: (qmail 78341 invoked from network); 4 Feb 2015 20:38:29 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 4 Feb 2015 20:38:29 -0000 Date: 4 Feb 2015 20:38:07 -0000 Message-ID: <20150204203807.19625.qmail@ary.lan> From: "John Levine" To: dbound@ietf.org In-Reply-To: <54D1E83B.20604@mozilla.org> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: gerv@mozilla.org Subject: Re: [Dbound] Another go at the charter X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 20:38:31 -0000 In article <54D1E83B.20604@mozilla.org> you write: >On 04/02/15 01:26, John Levine wrote: >> Where does the CA use case asking whether it's OK to put a wildcard >> under a name, a/k/a is this a public or private name, fit in? > >Note that the PSL's role in CA wildcard determination is _advisory_, not >normative. Well, sure. Other than what you code into Mozilla products, the PSL's role in everything is advisory. From nobody Thu Feb 5 02:23:57 2015 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DB9B1A01F4 for ; Thu, 5 Feb 2015 02:23:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.279 X-Spam-Level: X-Spam-Status: No, score=-3.279 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 b7mc7D31cIv5 for ; Thu, 5 Feb 2015 02:23:52 -0800 (PST) Received: from smtp.mozilla.org (mx1.corp.phx1.mozilla.com [63.245.216.69]) (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 7F0B41A01BA for ; Thu, 5 Feb 2015 02:23:52 -0800 (PST) Received: from [192.168.0.103] (93.243.187.81.in-addr.arpa [81.187.243.93]) (Authenticated sender: gerv@mozilla.org) by mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 17F6AF2345; Thu, 5 Feb 2015 02:23:50 -0800 (PST) Message-ID: <54D344B4.8000607@mozilla.org> Date: Thu, 05 Feb 2015 10:23:48 +0000 From: Gervase Markham User-Agent: Mozilla/5.0 (X11; Linux i686; rv:34.0) Gecko/20100101 Thunderbird/34.0 MIME-Version: 1.0 To: John Levine , dbound@ietf.org References: <20150204203807.19625.qmail@ary.lan> In-Reply-To: <20150204203807.19625.qmail@ary.lan> OpenPGP: id=9DF43DBB Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dbound] [Dbound] Another go at the charter X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 10:23:55 -0000 On 04/02/15 20:38, John Levine wrote: > Well, sure. Other than what you code into Mozilla products, the PSL's > role in everything is advisory. Well, yes and no. What I meant by this is that the CAB Forum Baseline Requirements (which CAs must follow to be in Mozilla's root program) say: "Before issuing a certificate with a wildcard character (*) in a CN or subjectAltName of type DNS-ID, the CA MUST establish and follow a documented procedure† that determines if the wildcard character occurs in the first label position to the left of a “registry-controlled” label or “public suffix” (e.g. “*.com”, “*.co.uk”, see RFC 6454 Section 8.2 for further explanation). If a wildcard would fall within the label immediately to the left of a registry-controlled† or public suffix, CAs MUST refuse issuance unless the applicant proves its rightful control of the entire Domain Namespace." That is, they do not say MUST NOT ISSUE under any circumstances. They could have said that, in which case I would not describe their role as "advisory". But they don't. In practice, what happens is that CAs put such requests into their "higher risk" process. Gerv From nobody Mon Feb 23 10:15:09 2015 Return-Path: X-Original-To: dbound@ietfa.amsl.com Delivered-To: dbound@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A43B91A1E0B for ; Mon, 23 Feb 2015 10:15:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.599 X-Spam-Level: X-Spam-Status: No, score=-0.599 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 yv81wYH0vMsX for ; Mon, 23 Feb 2015 10:14:56 -0800 (PST) Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC64B1A1B87 for ; Mon, 23 Feb 2015 10:14:55 -0800 (PST) Received: by wevl61 with SMTP id l61so16289800wev.2 for ; Mon, 23 Feb 2015 10:14:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ReQMXsajsdl/g0/e7OOvlXRtypdj/yuRddJ7zZeV7HY=; b=WLCedbS9CayrnPAYu21Wldx6KpS4uQbtb9SAxIvgggVR8F735dPfMy0SdcRiz96X/i dCDSdXkwzZIQF5by4YQB3BnBCzcOw0Nes964aCJiCufZnk0I1M7l7WiE+8AdLe/p88Ko hO0lWBYiEMCy0iBNodzO7r42EfMBuPo3AIKo/0vXqGH6e9fg6iCUeUExu35MvHbWDnN2 CJttDInIXoac9e/dM2RcD6xbsLFhxSva2mxVAJOvhzWkyyUOp6CT+xgNHrxUYtf/ch5b jLjTAqUUKQ1aTM7kzzxu7UKVjCl1g+iYdf3yeSCAyxw75/lJnDS2kMPbleeAi7Xs7f3x CfFA== MIME-Version: 1.0 X-Received: by 10.194.185.9 with SMTP id ey9mr25171017wjc.135.1424715294406; Mon, 23 Feb 2015 10:14:54 -0800 (PST) Received: by 10.27.179.146 with HTTP; Mon, 23 Feb 2015 10:14:54 -0800 (PST) In-Reply-To: <20150204061112.19440.qmail@ary.lan> References: <20150204013413.GC1583@mx1.yitter.info> <20150204061112.19440.qmail@ary.lan> Date: Mon, 23 Feb 2015 13:14:54 -0500 Message-ID: From: "Murray S. Kucherawy" To: Richard Barnes Content-Type: multipart/alternative; boundary=047d7bd6adce077e64050fc561b5 Archived-At: Cc: "dbound@ietf.org" Subject: Re: [dbound] [Dbound] Another go at the charter X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2015 18:15:07 -0000 --047d7bd6adce077e64050fc561b5 Content-Type: text/plain; charset=UTF-8 On Wed, Feb 4, 2015 at 1:11 AM, John Levine wrote: > >We'll never get chartered unless we make this change, so let's just do > >it. If we added more text (before the new sentences I added) that > >said basically, "The current way most of this is handled is via a list > >published at publicsuffix.org, and the general goal is to accommodate > >anything people are using that for today. However, there are broadly > >speaking two use patterns," or something like that, would it work? > > Personally, I think there are at least three and possibly more, but I > agree with you that in this case political expediency trumps accuracy. > In the interests of keeping this moving, and given that Richard met with Eliot and he seems to have a better understanding of what's going on here, I've updated the charter as per Andrew's suggestion at the top and middle of this thread, which is now visible here: https://github.com/mskucherawy/docs/blob/master/charter-dbound Richard, is this unblockable or do you still have issues for us to consider? -MSK --047d7bd6adce077e64050fc561b5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Feb 4, 2015 at 1:11 AM, John Levine <johnl@taugh.co= m> wrote:
&g= t;We'll never get chartered unless we make this change, so let's ju= st do
>it.=C2=A0 If we added more text (before the new sentences I added) that=
>said basically, "The current way most of this is handled is via a = list
>published at publ= icsuffix.org, and the general goal is to accommodate
>anything people are using that for today.=C2=A0 However, there are broa= dly
>speaking two use patterns," or something like that, would it work?=

Personally, I think there are at least three and possibly more, but = I
agree with you that in this case political expediency trumps accuracy.
<= /blockquote>

In the interests of keeping this moving, an= d given that Richard met with Eliot and he seems to have a better understan= ding of what's going on here, I've updated the charter as per Andre= w's suggestion at the top and middle of this thread, which is now visib= le here:

https://github.com/mskucherawy/docs/blob/master/charter-dbo= und

Richard, is this unblockable or do you still have= issues for us to consider?

-MSK
--047d7bd6adce077e64050fc561b5--