From nobody Thu Jun 4 09:34:23 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 909301A9066 for ; Thu, 4 Jun 2015 09:34:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5] 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 ZmjO0M4osg8B for ; Thu, 4 Jun 2015 09:34:06 -0700 (PDT) Received: from mx2.yitter.info (mx2.yitter.info [50.116.54.116]) by ietfa.amsl.com (Postfix) with ESMTP id 11CE01A8FD5 for ; Thu, 4 Jun 2015 09:33:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx2.yitter.info (Postfix) with ESMTP id 8726D106B1 for ; Thu, 4 Jun 2015 16:33:01 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx2.yitter.info ([127.0.0.1]) by localhost (mx2.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QOqiBQN05KZ9 for ; Thu, 4 Jun 2015 16:32:59 +0000 (UTC) Received: from mx2.yitter.info (unknown [IPv6:2601:18d:8600:22:b9c0:22ed:7883:c3e4]) by mx2.yitter.info (Postfix) with ESMTPSA id C57FA10636 for ; Thu, 4 Jun 2015 16:32:59 +0000 (UTC) Date: Thu, 4 Jun 2015 12:33:11 -0400 From: Andrew Sullivan To: dbound@ietf.org Message-ID: <20150604163311.GN94969@mx2.yitter.info> References: 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: Subject: Re: [dbound] Some work that will probably hit dbound sooner rather than later 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, 04 Jun 2015 16:34:14 -0000 On Fri, May 29, 2015 at 05:08:24PM -0400, Jeffrey Walton wrote: > > By the way, the IETF appears to claim *.COM, *.NET etc is valid. They're perfectly legitimate wildcard names. That's at bottom the problem we have to solve: DNS names do not carry semantics. A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Thu Jun 4 11:39:50 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 E4DB11A8865 for ; Thu, 4 Jun 2015 11:39:41 -0700 (PDT) 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 C9RuZlo4lp9B for ; Thu, 4 Jun 2015 11:39:36 -0700 (PDT) Received: from mail-ie0-f175.google.com (mail-ie0-f175.google.com [209.85.223.175]) (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 9F9611A8864 for ; Thu, 4 Jun 2015 11:39:36 -0700 (PDT) Received: by iesa3 with SMTP id a3so42393900ies.2 for ; Thu, 04 Jun 2015 11:39:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:content-type; bh=xx9KBtMEbrHmkTBlldXlUKfBeXzGosMPKWeYZTbQmn8=; b=FYdGOV7+PEO1SF3lNAuhrDojggYRKCidPgvsegTw54dLkVAfdoeTLUyVbkyN48QJzM MfzzJAPTBbsa4av4eoWLE/YgdPbtBeX+NAUKNY+3lvOtUPiOXBJZZTQ/3aDeHVDSRq29 n4wsQJhOz/hWsf0L2GALCyjbIS2yYu1ut7jobzWqDThplDxen0bdKX7kWJ+YEeVVlV86 s/1KyBJ1G0F795Bl/Vxh0F12fF5ArFAnrJdeW20eoQNrGIA8g8dKFUz+YbY4Nb4PJGYc K+hpOwrTRep/D+HzERqnQVUDGN1WPf3r2K/sDv9SKFkmCOqqTjQAogJfmzTWKWNQBvtB fu/A== X-Gm-Message-State: ALoCoQmqTIzxS7FIKcqtEXPYJo67e2yz4VnzfzyrS1gEEYLxQeHz3n2GUfj1JRGd59bodSSQlwJh X-Received: by 10.107.136.38 with SMTP id k38mr49150930iod.56.1433443176042; Thu, 04 Jun 2015 11:39:36 -0700 (PDT) MIME-Version: 1.0 References: <20150604163311.GN94969@mx2.yitter.info> In-Reply-To: <20150604163311.GN94969@mx2.yitter.info> From: Warren Kumari Date: Thu, 04 Jun 2015 18:39:25 +0000 Message-ID: To: Andrew Sullivan , dbound@ietf.org Content-Type: multipart/alternative; boundary=001a113ece26506d7e0517b57fff Archived-At: Subject: Re: [dbound] Some work that will probably hit dbound sooner rather than later 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, 04 Jun 2015 18:39:42 -0000 --001a113ece26506d7e0517b57fff Content-Type: text/plain; charset=UTF-8 On Thu, Jun 4, 2015 at 12:34 PM Andrew Sullivan wrote: > On Fri, May 29, 2015 at 05:08:24PM -0400, Jeffrey Walton wrote: > > > > By the way, the IETF appears to claim *.COM, *.NET etc is valid. > > They're perfectly legitimate wildcard names. That's at bottom the > problem we have to solve: DNS names do not carry semantics. > True -- but people are going to /continue/ to assume that they do, and we are going to have to keep reminding them, and ourselves, that they do not. A bunch of logical people recently paid surprisingly large amounts of money for certain strings, like .baby and .app when they could have saved much of this by instead using e.g wefddewrwtygf.net and h5y64tegh.org. Yes, this isn't actually whether or not the names carry semantics or not, but humans seem to naturally assume things from the labels, and it is hard to stop this... W > > A > > -- > Andrew Sullivan > ajs@anvilwalrusden.com > > _______________________________________________ > dbound mailing list > dbound@ietf.org > https://www.ietf.org/mailman/listinfo/dbound > --001a113ece26506d7e0517b57fff Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu= , Jun 4, 2015 at 12:34 PM Andrew Sullivan <ajs@anvilwalrusden.com> wrote:
On Fri, May 29, 2015 at 05:08:24PM -0400, Jeffrey Walton wr= ote:
>
> By the way, the IETF appears to claim *.COM, *.NET etc is valid.

They're perfectly legitimate wildcard names.=C2=A0 That's at bottom= the
problem we have to solve: DNS names do not carry semantics.

True -- but people are going to /continue/ to assume t= hat they do, and we are going to have to keep reminding them, and ourselves= , that they do not.

A bunch of logical people rece= ntly paid surprisingly large amounts of money for certain strings, like .ba= by and .app when they could have saved much of this by instead using e.g wefddewrwtygf.net and h5y64tegh.org.=C2=A0

Yes, t= his isn't actually whether or not the names carry semantics or not, but= humans seem to naturally assume things from the labels, and it is hard to = stop this...=C2=A0

W
=C2=A0

A

--
Andrew Sullivan
ajs@anvilwalrus= den.com

_______________________________________________
dbound mailing list
dbound@ietf.org = https://www.ietf.org/mailman/listinfo/dbound
--001a113ece26506d7e0517b57fff-- From nobody Thu Jun 4 12:38:40 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 730721A8BBD for ; Thu, 4 Jun 2015 12:38:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.762 X-Spam-Level: X-Spam-Status: No, score=0.762 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 gZ81CFzGl7Cl for ; Thu, 4 Jun 2015 12:38:38 -0700 (PDT) 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 54C361A8BB0 for ; Thu, 4 Jun 2015 12:38:38 -0700 (PDT) Received: (qmail 19223 invoked from network); 4 Jun 2015 19:38:45 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:mime-version:content-type:user-agent; s=4b16.5570a945.k1506; bh=/itfGfrkpjj6ul0ivnwzK+uD+FKaXimv5uFsOj2Ol1o=; b=hfVoDukD5SGn3xrVOK45o2HG7U3fFxnT7irgwxVZ3OPe3FYzWDjhmXt7iIdYX8fgIYZUfBsg440AV+teX+2D7kl1BfJa1YjRB7WPt8Ty2kffkhohm9r7+R15QVsdjGLp4azP1I/VPFSRWJL7T2G4Kf5JScyg8Ne8d2GTZ78/nin1WOZziSC2Y+0u02oJhzQaMmQWl6EeMdTaOg4RHsMYIoD1DOnriwpzA4Q0s+Shbvc/reifAqnXNNECyTHvxjNE DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:mime-version:content-type:user-agent; s=4b16.5570a945.k1506; bh=/itfGfrkpjj6ul0ivnwzK+uD+FKaXimv5uFsOj2Ol1o=; b=rfHyYxlQ4CjZNiGSPzs18KEryz0CNGLmQSJr1DwLpuIY0+WuGFUYTu5CsKOdT713AtFJwQDMJdJ2dYIfGNeVNWM80koZSM7wKotCPyiNZtPErIB80T4fTeVENNWacePn6WvZiWhDmyxBksnmZZUU1XMPBpdzkD+WDOkcG73nB2uJZCEHKevZVRXwP+OWM5agvrL+9Cdk/aiEPcJBs1vJfXUztzpDVNQ6CpHTaMgoZAN7ZSM5r1wjUu0ElrkpcO9p Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 04 Jun 2015 19:38:45 -0000 Date: 4 Jun 2015 15:38:36 -0400 Message-ID: From: "John R Levine" To: dbound@ietf.org User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dbound] Some work that will probably hit dbound sooner rather than later (fwd) 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, 04 Jun 2015 19:38:39 -0000 >>> By the way, the IETF appears to claim *.COM, *.NET etc is valid. >> >> They're perfectly legitimate wildcard names. That's at bottom the >> problem we have to solve: DNS names do not carry semantics. Well, yeah. Those two names were live in the DNS for a while during the Sitefinder fiasco. > True -- but people are going to /continue/ to assume that they do, and we > are going to have to keep reminding them, and ourselves, that they do not. People assume all sorts of stuff. I would be surprised if as many as half of them could tell you what names *.COM actually matched in the DNS. As I've said too many times already, the hardest problem with DBOUND is people wrongly assuming they understand the problem and jumping ahead to an approach that addresses part of it but utterly fails for the other 80%. R's, John From nobody Thu Jun 4 13:05:49 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 B9B2C1A1B5A for ; Thu, 4 Jun 2015 13:05:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.208 X-Spam-Level: X-Spam-Status: No, score=-4.208 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 ZMljnlL30Qia for ; Thu, 4 Jun 2015 13:05:47 -0700 (PDT) Received: from out.west.pexch112.icann.org (pfe112-ca-1.pexch112.icann.org [64.78.40.7]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F72D1A0121 for ; Thu, 4 Jun 2015 13:05:47 -0700 (PDT) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Thu, 4 Jun 2015 13:05:44 -0700 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1044.021; Thu, 4 Jun 2015 13:05:44 -0700 From: Steve Sheng To: "dbound@ietf.org" Thread-Topic: SSAC Advisory on the use of Static TLD / Suffix Lists Thread-Index: AQHQnwHX/DC6/mvkx0CqBlTZz1YyrA== Date: Thu, 4 Jun 2015 20:05:44 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.1.150515 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.32.234] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3516278738_15486860" MIME-Version: 1.0 Archived-At: Subject: [dbound] SSAC Advisory on the use of Static TLD / Suffix Lists 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, 04 Jun 2015 20:05:48 -0000 --B_3516278738_15486860 Content-type: multipart/alternative; boundary="B_3516278738_15472276" --B_3516278738_15472276 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Dear Dbound Working Group, The Security and Stability Advisory Committee at ICANN recently issued an advisory concerning the use of static TLD / Suffix lists. Some of the findings and recommendations in this report maybe of use to the working group. The reports is available at: https://www.icann.org/en/system/files/files/sac-070-en.pdf Comments welcome as well. Steve --B_3516278738_15472276 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
Dear Dbound Working Group,&nb= sp;

   The Security and Stability Advisor= y Committee at ICANN recently issued an advisory concerning the use of stati= c TLD / Suffix lists. Some of the findings and recommendations in this repor= t maybe of use to the working group. 

  &= nbsp;The reports is available at: https://www.icann.org/en/system/files/files/= sac-070-en.pdf

   Comments welcome as= well.  

Steve
--B_3516278738_15472276-- --B_3516278738_15486860 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIRtAYJKoZIhvcNAQcCoIIRpTCCEaECAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC D30wggVsMIIEVKADAgECAhAOUlMjDnDIPB4oZ7y9klgpMA0GCSqGSIb3DQEBCwUAMGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTAeFw0xNTA2MDQw MDAwMDBaFw0xODA2MDQxMjAwMDBaMIGMMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZv cm5pYTEUMBIGA1UEBxMLTG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEUMBIGA1UEAxMLU3RldmUgU2hl bmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDfZ+/wkqf1Ut/1K4j3tGzPlr71 LR3u+FclxpPRAut6WLHjCDhPUTuaiGZKsS72CT4dxfCFiXvx2QXyuDm/houjQHRKcohR5bJz rnt05NO/hBWT1nXdB/ZLo6wgwi5j2TdiWIzvx7ZV773vwPJgkLzM5KJZvlO3xQe8mcPjlCXh ux3k8q9te9nOb8S6rW06Rfn0TWooDZr6n9jRoEY5CwRn/2cISTRZXStYYUkwBsh3zkIDtXIX mq1GgyVuzibCbWsQa0reUMeqHTy2daBfjLqg2POKZ0yaWNbJM+aUJdj+gZGFFVM5rUK68gNT YS4zRifO/KcOzoirlI0FAYXAzLzhAgMBAAGjggHuMIIB6jAfBgNVHSMEGDAWgBTnAiOAAE/Y 17yUC9k/dDlJMjyKeTAdBgNVHQ4EFgQUTgac44SlC7rSIfiePUE/zByuutMwDAYDVR0TAQH/ BAIwADAgBgNVHREEGTAXgRVzdGV2ZS5zaGVuZ0BpY2Fubi5vcmcwDgYDVR0PAQH/BAQDAgWg MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDBDBgNVHSAEPDA6MDgGCmCGSAGG/WwE AQIwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCBiAYDVR0f BIGAMH4wPaA7oDmGN2h0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydFNIQTJBc3N1 cmVkSURDQS1nMS5jcmwwPaA7oDmGN2h0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2Vy dFNIQTJBc3N1cmVkSURDQS1nMS5jcmwweQYIKwYBBQUHAQEEbTBrMCQGCCsGAQUFBzABhhho dHRwOi8vb2NzcC5kaWdpY2VydC5jb20wQwYIKwYBBQUHMAKGN2h0dHA6Ly9jYWNlcnRzLmRp Z2ljZXJ0LmNvbS9EaWdpQ2VydFNIQTJBc3N1cmVkSURDQS5jcnQwDQYJKoZIhvcNAQELBQAD ggEBAKoWdmAmhrlZrAeyQxqPI5MvJq1QYEdpPFB5guPmqj1ndvQt/eEukN18t7VqX/XkTo/a jIsUi+5me0x7OC5nGxR3Tj45VNoohC2pRJhhbXikqIXYOKgsFdaGQkN3wFafWYOuuUEL3ve1 O7Gc4j7CzuzuOQqUtbgj3EDzN1dIB5AfB6mzFJoMzVFrqCJqDf7vqEyHj7CS0nH8zWcyYzY8 O9bTQ1VitpF1E7Zpc45D1W6n5VkJK0YSXaF+cFeBc0zlJUF/YO7231f6BDxkRFs04NsHiQM9 UlzqCITxt4sZ3ZKPLE1tHuIF44nU7JGs3NQuJYDmAX7dc0V5R/hogMyu8DYwggZOMIIFNqAD AgECAhAErnlgZmaQGrnFf6ZsW9zNMA0GCSqGSIb3DQEBCwUAMGUxCzAJBgNVBAYTAlVTMRUw EwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNV BAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0xMzExMDUxMjAwMDBaFw0yODEx MDUxMjAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNV BAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJ RCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANz4ESM/arXvwCd5Gy0Fh6IQ QzHfDtQVG093pCLOPoxw8L4Hjt0nKrwBHbYsCsrdaVgfQe1qBR/aY3hZHiIsK/i6fsk1O1bx H3xCfiWwIxnGRTjXPUT5IHxgrhywWhgEvo8796nwlJqmDGNJtkEXU0AyvU/mUHpQHyVF6PGJ r83/Xv9Q8/AXEf+9xYn1vWK52PuORQSFbZnNxUhN/SarAjZF6jbXX2riGoJBCtzp2fWRF47G Ia04PBPmHn9mnNVN2Uba9s9Sp307JMO0wVE1xpvr1O9+5HsD4US9egs34E/LgooNcRjkpuCJ LBvzsnM8wbCSnhh9vat9xX0IoSzCn3MCAwEAAaOCAvgwggL0MBIGA1UdEwEB/wQIMAYBAf8C AQAwDgYDVR0PAQH/BAQDAgGGMDQGCCsGAQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0cDov L29jc3AuZGlnaWNlcnQuY29tMIGBBgNVHR8EejB4MDqgOKA2hjRodHRwOi8vY3JsNC5kaWdp Y2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURSb290Q0EuY3JsMDqgOKA2hjRodHRwOi8vY3Js My5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURSb290Q0EuY3JsMB0GA1UdJQQWMBQG CCsGAQUFBwMCBggrBgEFBQcDBDCCAbMGA1UdIASCAaowggGmMIIBogYKYIZIAYb9bAACBDCC AZIwKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LmRpZ2ljZXJ0LmNvbS9DUFMwggFkBggrBgEF BQcCAjCCAVYeggFSAEEAbgB5ACAAdQBzAGUAIABvAGYAIAB0AGgAaQBzACAAQwBlAHIAdABp AGYAaQBjAGEAdABlACAAYwBvAG4AcwB0AGkAdAB1AHQAZQBzACAAYQBjAGMAZQBwAHQAYQBu AGMAZQAgAG8AZgAgAHQAaABlACAARABpAGcAaQBDAGUAcgB0ACAAQwBQAC8AQwBQAFMAIABh AG4AZAAgAHQAaABlACAAUgBlAGwAeQBpAG4AZwAgAFAAYQByAHQAeQAgAEEAZwByAGUAZQBt AGUAbgB0ACAAdwBoAGkAYwBoACAAbABpAG0AaQB0ACAAbABpAGEAYgBpAGwAaQB0AHkAIABh AG4AZAAgAGEAcgBlACAAaQBuAGMAbwByAHAAbwByAGEAdABlAGQAIABoAGUAcgBlAGkAbgAg AGIAeQAgAHIAZQBmAGUAcgBlAG4AYwBlAC4wHQYDVR0OBBYEFOcCI4AAT9jXvJQL2T90OUky PIp5MB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqGSIb3DQEBCwUAA4IB AQBO1Iknuf0dh3d+DygFkPEKL8k7Pr2TnJDGr/qRUYcyVGvoysFxUVyZjrX64GIZmaYHmnwT J9vlAqKEEtkV9gpEV8Q0j21zHzrWoAE93uOC5EVrsusl/YBeHTmQvltC9s6RYOP5oFYMSBDO M2h7zZOr8GrLT1gPuXtdGwSBnqci4ldJJ+6Skwi+aQhTAjouXcgZ9FCATgLZsF2RtJOH+ZaW gVVAjmbtgti7KF/tTGHtBlgoGVMRRLxHICmyBGzYiVSZO3XbZ3gsHpJ4xlU9WBIRMm69QwxN NNt7xkLb7L6rm2FMBpLjjt8hKlBXBMBgojXVJJ5mNwlJz9X4ZbPg4m7CMIIDtzCCAp+gAwIB AgIQDOfg5RfYRv6P5WD8G/AwOTANBgkqhkiG9w0BAQUFADBlMQswCQYDVQQGEwJVUzEVMBMG A1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQD ExtEaWdpQ2VydCBBc3N1cmVkIElEIFJvb3QgQ0EwHhcNMDYxMTEwMDAwMDAwWhcNMzExMTEw MDAwMDAwWjBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQL ExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBBc3N1cmVkIElEIFJvb3Qg Q0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCtDhXO5EOAXLGH87dg+XESpa7c JpSIqvTO9SA5KFhgDPiA2qkVlTJhPLWxKISKityfCgyDF3qPkKyK53lTXDGEKvYPmDI2dsze 3Tyoou9q+yHyUmHfnyDXH+Kx2f4YZNISW1/5WBg1vEfNoTb5a3/UsDg+wRvDjDPZ2C8Y/igP s6eD1sNuRMBhNZYW/lmci3Zt1/GiSw0r/wty2p5g0I6QNcZ4VYcgoc/lbQrISXwxmDNsIumH 0DJaoroTghHtORedmTpyoeb6pNnVFzF1roV9Iq4/AUaG9ih5yLHa5FcXxH4cDrC0kqZWs72y l+2qp/C3xag/lRbQ/6GW6whfGHdPAgMBAAGjYzBhMA4GA1UdDwEB/wQEAwIBhjAPBgNVHRMB Af8EBTADAQH/MB0GA1UdDgQWBBRF66Kv9JLLgjEtUYunpyGd823IDzAfBgNVHSMEGDAWgBRF 66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG9w0BAQUFAAOCAQEAog683+Lt8ONyc3pklL/3 cmbYMuRCdWKuh+vy1dneVrOfzM4UKLkNl2BcEkxY5NM9g0lFWJc1aRqoR+pWxnmrEthngYTf fwk8lOa4JiwgvT2zKIn3X/8i4peEH+ll74fg38FnSbNd67IJKusm7Xi+fT8r87cmNW1fiQG2 SVufAQWbqz0lwcy2f8Lxb4bG+mRo64EtlOtCt/qMHt1i8b5QZ7dsvfPxH2sMNgcWfzd8qVtt evESRmCD1ycEvkvOl77DZypoEd+A5wwzZr8TDRRu838fYxAe+o0bJW1sj6W3YQGx0qMmoRBx na3iw/nDmVG3KwcIzi7mULKn+gpFL6Lw8jGCAf8wggH7AgEBMHkwZTELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIG A1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAOUlMjDnDIPB4oZ7y9klgpMAkG BSsOAwIaBQCgXTAjBgkqhkiG9w0BCQQxFgQUCo+8OFucdyX8PEzKga3ZoVAaPigwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTUwNjA0MjAwNTM4WjANBgkq hkiG9w0BAQEFAASCAQAL1SoOcPgaNz10ZqqQh2wj+M2Cophx+VTUy7ND5sT2vsDZgFzessES VXLcjjrCiwQtdDr/8WsqcQLxAfWObLX2ifr182dack4g6s1F51m2qBZxdsx5wKYZvmtnE46h JoGfHJDRd1yvFgr3te638bGXXwiYleGAXDxFLd/fDIwK+JTUoDVdbYUZMCQ8YGp3YpjId8Q6 hJpiWZDb8M5+H43HxgaGAa7MF32dlHavtUkrAyIEjIDXndZi1dI1M7UGXmusw0L2ufr0xymK sCTqhFz1l9M1w5B6EbtLV/mkTuH6ONnP0Qa+8Oqt/lv7uitAfvyog9RwV5hRFez56hssiuyG --B_3516278738_15486860-- From nobody Thu Jun 4 14:06: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 C208B1AC3C1 for ; Thu, 4 Jun 2015 14:06:44 -0700 (PDT) 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 s_QJeDlRJydz for ; Thu, 4 Jun 2015 14:06:43 -0700 (PDT) Received: from mx2.yitter.info (mx2.yitter.info [IPv6:2600:3c03::f03c:91ff:fedf:cfab]) by ietfa.amsl.com (Postfix) with ESMTP id 20AAB1A92F3 for ; Thu, 4 Jun 2015 14:06:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx2.yitter.info (Postfix) with ESMTP id 9831E106F8 for ; Thu, 4 Jun 2015 21:06:42 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx2.yitter.info ([127.0.0.1]) by localhost (mx2.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4HBzc17sbO8Y for ; Thu, 4 Jun 2015 21:06:41 +0000 (UTC) Received: from mx2.yitter.info (c-50-169-68-91.hsd1.nh.comcast.net [50.169.68.91]) by mx2.yitter.info (Postfix) with ESMTPSA id 9024110636 for ; Thu, 4 Jun 2015 21:06:41 +0000 (UTC) Date: Thu, 4 Jun 2015 17:06:39 -0400 From: Andrew Sullivan To: dbound@ietf.org Message-ID: <20150604210639.GU94969@mx2.yitter.info> References: <20150604163311.GN94969@mx2.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: Subject: Re: [dbound] Some work that will probably hit dbound sooner rather than later 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, 04 Jun 2015 21:06:44 -0000 On Thu, Jun 04, 2015 at 06:39:25PM +0000, Warren Kumari wrote: > On Thu, Jun 4, 2015 at 12:34 PM Andrew Sullivan > wrote: > > > problem we have to solve: DNS names do not carry semantics. > > > > True -- but people are going to /continue/ to assume that they do, and we > are going to have to keep reminding them, and ourselves, that they do not. That will be a waste of time. Remind people their beliefs are false all you like. They will believe them even harder. Instead, what we need is a mechanism by which such semantic intentions can be captured in a way that they can be communicated reliably. If we don't achieve that, then we won't have addressed the problem this WG is supposed to solve. (Which of course raises the fact that I haven't given the problem statement a good read. Sorry, I've been submerged, but I hope to get to it this week.) A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Thu Jun 4 15:12:58 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 BC31F1A039C for ; Thu, 4 Jun 2015 15:12:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, 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 BuGVjRcfNQjN for ; Thu, 4 Jun 2015 15:12:56 -0700 (PDT) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) (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 1A9911A0378 for ; Thu, 4 Jun 2015 15:12:56 -0700 (PDT) Received: by wgme6 with SMTP id e6so43782680wgm.2 for ; Thu, 04 Jun 2015 15:12:54 -0700 (PDT) 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=tUISoJpuSKTj48XQrWYEm/lfLmOkxqLSaHiThbEOQ5s=; b=c5+5VwrHUFAHCAO6e98MG6towwNAq4TR3e63y3Z/cwwswDweBZae2NMigflr7RxsII W1fTjXGYk3XnhzQJ5cJjf5rJndJR5+kxVX1bqQNbbP0a5G/IlTco6ELxJ5EA64tcFp7x DiltLWpeLvYfrWWpUhSHA9bGWiP4dq9kKpFcOIIqr/zBXxFvimzZwWiW1CJCpLpOaLhX N/paIXthpZ9y3uCNrOi1V5iDlANFpF7QdEtOgtygPMx15QAUXc00XdDg9QxeQl1JHBEg /NWaC/9x9cZSP+Vz2y1GTejv9188MjfcrapkCsWUgJmw80Jb6+bk7UxxUoAkPawds0Yx OKig== MIME-Version: 1.0 X-Received: by 10.180.206.45 with SMTP id ll13mr55721624wic.94.1433455974878; Thu, 04 Jun 2015 15:12:54 -0700 (PDT) Received: by 10.27.6.207 with HTTP; Thu, 4 Jun 2015 15:12:54 -0700 (PDT) In-Reply-To: References: <55300ADD.4080001@qti.qualcomm.com> Date: Thu, 4 Jun 2015 15:12:54 -0700 Message-ID: From: "Murray S. Kucherawy" To: Pete Resnick , "Murray S. Kucherawy" Content-Type: multipart/alternative; boundary=001a11c2382c2f12ff0517b87a35 Archived-At: Cc: "dbound@ietf.org" Subject: Re: [dbound] Schedule and milestones 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, 04 Jun 2015 22:12:57 -0000 --001a11c2382c2f12ff0517b87a35 Content-Type: text/plain; charset=UTF-8 So: On Thu, May 14, 2015 at 1:54 PM, Murray S. Kucherawy wrote: > On Thu, Apr 16, 2015 at 12:17 PM, Pete Resnick > wrote: > >> We're still plowing through the mailing list to come up with an issues >> list from previous discussions, but wanted to get a "plan" on the table. >> Here's what we've come up with, including due dates for each of the initial >> milestones: >> >> * Stabilization of the problem statement (May 15, 2015) >> * no intent to publish >> * could move it to the Wiki >> > With no response to this, and more importantly... > * Proposals for solutions (June 2, 2015) >> * on-list discussion of drafts >> * expect them to be Standards Track or Experimental; these are protocols >> > ...zero discussion here so far, and as a result... > * Drafts for discussion at IETF 93 (July 6, 2015) >> > ...none of these having appeared... * Calls for Adoption of some documents at IETF 93 (July 24, 2015) >> > ...making this unlikely, I'm inclined not to ask for a meeting in Prague. Is anyone planning a flurry of activity that would justify requesting a working group meeting (the deadline is tomorrow), or shall we regroup later when momentum has returned? If "yes", what length of a meeting would be needed? -MSK, DBOUND co-chair --001a11c2382c2f12ff0517b87a35 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
So:

On Thu, May 14, 2015 at 1:54 PM, Murray S. Kuch= erawy <superuser@gmail.com> wrote:
On Thu, Apr 16, 2015 at 12:17 = PM, Pete Resnick <presnick@qti.qualcomm.com> wrote:<= br>
We're still plo= wing through the mailing list to come up with an issues list from previous = discussions, but wanted to get a "plan" on the table. Here's = what we've come up with, including due dates for each of the initial mi= lestones:

* Stabilization of the problem statement (May 15, 2015)
=C2=A0 * no intent to publish
=C2=A0 * could move it to the Wiki

With no response to this, and more import= antly...
=C2=A0
* Proposals for solutions (June 2, 2015)
=C2=A0 * on-list discussion of drafts
=C2=A0 * expect them to be Standards Track or Experimental; these are proto= cols

<= div>...zero discussion here so far, and as a result...
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
* Drafts for discussion at IETF 93 (July 6, 2015)

...none of these having ap= peared...

* Calls for Adoption of some documents at IETF 93 (July 24, 2015)

...making = this unlikely, I'm inclined not to ask for a meeting in Prague.

Is anyone planning a flurry of activity that would=20 justify requesting a working group meeting (the deadline is tomorrow),=20 or shall we regroup later when momentum has returned?=C2=A0 If "yes&qu= ot;, what length of a meeting would be needed?

-MSK, DBOUND co= -chair
--001a11c2382c2f12ff0517b87a35-- From nobody Thu Jun 4 15:21:40 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 6D5881A88EF for ; Thu, 4 Jun 2015 15:21:38 -0700 (PDT) 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 a5AELU57gogf for ; Thu, 4 Jun 2015 15:21:37 -0700 (PDT) Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::22e]) (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 23A2D1A88EB for ; Thu, 4 Jun 2015 15:21:37 -0700 (PDT) Received: by igbpi8 with SMTP id pi8so2614285igb.0 for ; Thu, 04 Jun 2015 15:21:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=vHEY8t3dZvzlx9QSgVTwAqovon8SMC8+atrd074GZ/I=; b=mGoWHiXyyLtAECO5C7dknMdX8KI7BxKd6d0RaAj0VUouYkrBv98QTj5LzHMRsTSNQL l8891U/hnKWIiJtPB2LFVGFfzsMLwwj9goXxcsq6BlotBW6nh+UC1obRiXpYoFYzDcke 0XhCo4HFITbil9sZXbPTwplT/6fialb0QWp3fxsOkYuoUqD3DI+PnOSdEznH/+dLD3jp qobWMMllL4rUyD6fF7d4aPV4n16x+a0k3iNLELoP7mBPnmyhO7jcQXsEUuyr8fyxxjOU g6ZACsnecJKK6zZQCYPXV6oux2wDpkpTgC9X+rWb+SfDiey54G57Y+rzOvj+3c4ZtgVK L3EA== MIME-Version: 1.0 X-Received: by 10.50.30.197 with SMTP id u5mr37634052igh.9.1433456496647; Thu, 04 Jun 2015 15:21:36 -0700 (PDT) Received: by 10.36.77.15 with HTTP; Thu, 4 Jun 2015 15:21:36 -0700 (PDT) In-Reply-To: <20150604163311.GN94969@mx2.yitter.info> References: <20150604163311.GN94969@mx2.yitter.info> Date: Thu, 4 Jun 2015 18:21:36 -0400 Message-ID: From: Jeffrey Walton To: Andrew Sullivan Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "dbound@ietf.org" Subject: Re: [dbound] Some work that will probably hit dbound sooner rather than later X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: noloader@gmail.com List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2015 22:21:38 -0000 On Thu, Jun 4, 2015 at 12:33 PM, Andrew Sullivan wrote: > On Fri, May 29, 2015 at 05:08:24PM -0400, Jeffrey Walton wrote: >> >> By the way, the IETF appears to claim *.COM, *.NET etc is valid. > > They're perfectly legitimate wildcard names. That's at bottom the > problem we have to solve: DNS names do not carry semantics. > Maybe I'm missing the point... About all I would claim is they are well formed regular expressions, so they should not crash the program using them. Within context, there's nothing valid about them for use in PKIX because no entity or organization controls the gTLDs in question*. Here, the relevant gTLDs are *.COM, *.NET, *.ORG, etc. Its the e-equivalent of swamp land in Florida. The troubling part (I find) is folks are accepting them and citing the IETF. I can't make a counter argument citing the IETF it because its true. About the only thing I can do is cite the CA/B Forums Baseline Document and plead to common sense. You can imagine how well the plea to common sense goes over at times.... The CA/B Forums codified their exclusion in the Baseline Requirements. See section 3.2.2. Jeff * Related, ICANN calls the vanity TLDs gTLDs, too. So I'm not sure how to refer to them unambiguously here. Maybe gTLD (*.COM, *.NET), ccTLD (*.UK, *.CN), and vTLD (*.GOOGLE and friends). From nobody Thu Jun 4 21:20:55 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 A3D4C1B2AFC for ; Thu, 4 Jun 2015 21:20:54 -0700 (PDT) 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 tD27Y0CiZi_O for ; Thu, 4 Jun 2015 21:20:53 -0700 (PDT) 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 54AB51A88A1 for ; Thu, 4 Jun 2015 21:20:52 -0700 (PDT) Received: (qmail 84402 invoked from network); 5 Jun 2015 04:21:00 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 5 Jun 2015 04:21:00 -0000 Date: 5 Jun 2015 04:20:29 -0000 Message-ID: <20150605042029.1475.qmail@ary.lan> From: "John Levine" To: dbound@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: noloader@gmail.com Subject: Re: [dbound] Some work that will probably hit dbound sooner rather than later 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: Fri, 05 Jun 2015 04:20:55 -0000 >The troubling part (I find) is folks are accepting them and citing the >IETF. I can't make a counter argument citing the IETF it because its >true. If they're citing the IETF, they are badly misrepresenting what the IETF does and says. Our standards say a lot about mechanism, and generally nothing about policy. So if someone were to publish a *.COM record in the DNS (which happened a while ago), IETF standards say what queries it matches, what the formats of the DNS packets are, and so forth. Similarly if an https server were to present a certificate with a name of *.COM, IETF standards say what a browser would do with that certificate. None of that means that any of us think it would be a good idea to publish either of those. If you were to compose a death threat and e-mail it to president@whitehouse.gov, IETF standards also say how that message would be routed to its recipient, but that doesn't mean we think that would be a good idea, either. If DBOUND is moderately successful, we may well come up with a way for someone to publish boundary advice that could say that there's a boundary above COM. so a *.COM certificate would be a bad idea, but there's no boundary above BARCLAYCARD. so a *.BARCLAYCARD certificate would be OK. But it still won't be the IETF publishing that advice. It'll be someone else, using our standard for the format of the advice. R's, John PS: Yes, that's a real TLD. From nobody Thu Jun 4 22:12:14 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 6A4311B2BA5 for ; Thu, 4 Jun 2015 22:12:12 -0700 (PDT) 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 vASx-GA6cCpn for ; Thu, 4 Jun 2015 22:12:11 -0700 (PDT) Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001:c05::22a]) (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 135A41B2B8F for ; Thu, 4 Jun 2015 22:12:11 -0700 (PDT) Received: by igbzc4 with SMTP id zc4so7598207igb.0 for ; Thu, 04 Jun 2015 22:12:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=KsiggB2FxUANxg6k/qhjqHNwLlYZbWJkfP2syihwWXo=; b=TAWLbnSmWZGZ3PR0UXKdHPp9NZPXHER3JxuaYLcVW6fjE0GBiJph6yxxvZYNlb22XT T0MTcFkvIc/HOvZMRja1thrub+azgc8wMtum2SIMNkB0yNOO9xKyMZ2Qot+WC2Xsj4hz lmm5BKZIFysQVVi4Llxy15cigEeYVNOyEBOWroqRp0CscubjllsDXhNnunIWHlpnwZGW fru23iUxY6yTBYN/y/ITnYoccyXL+6VvK8Ixf8grUJOXyh9SzM3Lg6aJ8TsVsrrKyoEZ JyO6S5VCkF445totER/pKF2u08on+KlOLyQ6U0QJfiFADPytjGwZsiaBcz+y86DRJlV9 qBTg== MIME-Version: 1.0 X-Received: by 10.107.159.77 with SMTP id i74mr2012714ioe.9.1433481130621; Thu, 04 Jun 2015 22:12:10 -0700 (PDT) Received: by 10.36.77.15 with HTTP; Thu, 4 Jun 2015 22:12:10 -0700 (PDT) In-Reply-To: <20150605042029.1475.qmail@ary.lan> References: <20150605042029.1475.qmail@ary.lan> Date: Fri, 5 Jun 2015 01:12:10 -0400 Message-ID: From: Jeffrey Walton To: John Levine Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "dbound@ietf.org" Subject: Re: [dbound] Some work that will probably hit dbound sooner rather than later X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: noloader@gmail.com List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2015 05:12:12 -0000 On Fri, Jun 5, 2015 at 12:20 AM, John Levine wrote: >>The troubling part (I find) is folks are accepting them and citing the >>IETF. I can't make a counter argument citing the IETF it because its >>true. > > If they're citing the IETF, they are badly misrepresenting what the > IETF does and says. Our standards say a lot about mechanism, and > generally nothing about policy. So if someone were to publish a *.COM > record in the DNS (which happened a while ago), IETF standards say > what queries it matches, what the formats of the DNS packets are, and > so forth. Similarly if an https server were to present a certificate > with a name of *.COM, IETF standards say what a browser would do with > that certificate. > Thanks John. So we are clear... The actual argument is "The RFCs don't prohibit them." RFCs like 5280 and 6125 prohibit other things, but not wildcards on gTLDs like *.COM and *.NET. Folks are taking that to be an implicit approval. And its not just one set of folks. Its at least three or four different, disjoint projects. They all came back with the same argument when I filed the bug reports. I understand the IETF does not approve or condone it. I can even cite this thread now. Maybe it would be a good idea to codify it somewhere so that its relevant to or within reach of PKIX. Jeff From nobody Thu Jun 4 22:19: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 AE0191B2BAA for ; Thu, 4 Jun 2015 22:19:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.862 X-Spam-Level: X-Spam-Status: No, score=0.862 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 MsWl2gRSWnqy for ; Thu, 4 Jun 2015 22:19:34 -0700 (PDT) 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 C51E81B2BA9 for ; Thu, 4 Jun 2015 22:19:33 -0700 (PDT) Received: (qmail 90000 invoked from network); 5 Jun 2015 05:19:41 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 5 Jun 2015 05:19:41 -0000 Date: 5 Jun 2015 05:19:10 -0000 Message-ID: <20150605051910.1636.qmail@ary.lan> From: "John Levine" To: dbound@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: noloader@gmail.com Subject: Re: [dbound] Some work that will probably hit dbound sooner rather than later 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: Fri, 05 Jun 2015 05:19:34 -0000 >So we are clear... The actual argument is "The RFCs don't prohibit them." This is a fundamentally silly argument. The RFCs don't prohibit sending death threats either. When an IETF document says MUST or MUST NOT, that means "you have to do this, or not do this, or you won't interoperate with other software", a purely technical meaning. There's no technical difference at the protocol level between *.COM and *.BARCLAYCARD -- it's a policy difference, and other people set policy. >Folks are taking that to be an implicit approval. And its not just one >set of folks. Its at least three or four different, disjoint projects. >They all came back with the same argument when I filed the bug >reports. Sounds like ICANN, if reality and a business plan collide, reality loses every time. R's, John From nobody Thu Jun 4 22:23:55 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 178061B2BB8 for ; Thu, 4 Jun 2015 22:23:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 sVoFQZvkIs8i for ; Thu, 4 Jun 2015 22:23:53 -0700 (PDT) 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 E6E7C1B2BB1 for ; Thu, 4 Jun 2015 22:23:52 -0700 (PDT) Received: (qmail 90327 invoked from network); 5 Jun 2015 05:24:00 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=160d5.55713270.k1506; bh=HHPfsH/yX32XxQDKbV1DrMw0sdn1NGQMYXDhcE97+gI=; b=UKM2Fv46//Lb9iHzP3XkNJImdpsRx94L0DXzwD9xgPAD0LGtmG/GQvwZjHy/iQ1f7CL0FR+BrY1CYAaJPx798uJul52hPCFFiQugUWZN3oVSj0LEfVv8zmBDOci5Gkq9STBlGGc12kloRhRH5kDve+aahfymeygXu3JEQepakTErDxSfnw9BNVX1BPRuUATHCNczAgw6MicjmmjEfpNAcPQtWgzvr+9ihGg9MrM0Xj9jQ7Rd2FUILKniF2oWZiCV DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=160d5.55713270.k1506; bh=HHPfsH/yX32XxQDKbV1DrMw0sdn1NGQMYXDhcE97+gI=; b=kwDEPEK7XFkc+Y9f+CxHFnvkF3t4anwXzCJn3V8fRuSbYmYVGfxwdrd9ePLbOelx5ocJ71zBgw7I+lATGyJd4Q+OdIn45D7pY4VDgGCO7WWn0jc4O/ibjhaX+XargUj6mebcyiCiKYUkkrD9bzxY2KPd1G5IY6FnmqRDjrcoqcSfpLcdWacYPwEW/wuhoiuLUXLuORP/aRRbVtuDS0z+78+HzuNaJiS8V8WeiGW55wrQ2VwISb2AD1VP1AyRY4ld Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 05 Jun 2015 05:24:00 -0000 Date: 5 Jun 2015 01:23:50 -0400 Message-ID: From: "John R Levine" To: "Jeffrey Walton" In-Reply-To: References: <20150605042029.1475.qmail@ary.lan> User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: "dbound@ietf.org" Subject: Re: [dbound] Some work that will probably hit dbound sooner rather than later 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: Fri, 05 Jun 2015 05:23:54 -0000 > RFCs like 5280 and 6125 prohibit other things, but not wildcards on > gTLDs like *.COM and *.NET. It also occurs to me that the authors of 6125 and several of the authors of 5280 are quite active IETF participants. I'm sure any of them would be happy to write a note saying we wrote the RFCs and that's not what they mean. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Thu Jun 4 22:25:03 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 4264F1B2BB9 for ; Thu, 4 Jun 2015 22:25:02 -0700 (PDT) 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 2Grcl0LSvLNA for ; Thu, 4 Jun 2015 22:25:01 -0700 (PDT) Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001:c05::236]) (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 18DC61B2BB1 for ; Thu, 4 Jun 2015 22:25:01 -0700 (PDT) Received: by igbhj9 with SMTP id hj9so7825293igb.1 for ; Thu, 04 Jun 2015 22:25:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=AdsZtTKCAdPpwXhsXMpg9C8K4Ys95jOmHX28hFeczu8=; b=Bmv9rDBA4e4dn6C6f89IwDQXJ8IrLc4ORWqtpOxF7/H0DxvD6QZ+5RrJzRJKTJ9QR8 8ohpcglc3nlPmmQMO+uE9e6+MEBQy8h4j9YacywZz9rH0B9hA+R4Nu/73y6/7NnhF78D JqGG+uFf0V10U9ihXMSiH1cWkXscfrAkG/vSTMseOdcHMUUdLIBhqHCx4cQPl5gU9+6v 5/aIezuSr9Kh/QXBv4FTNian93Clh0etqbMbYVBlXFAx5gUc1jlSVrclZVsQy/W840zV cAzL7GsUVNLC5VfXP8isQsr2gbrnc68OZYAQaYpEO3IbhGdLzDEZIwAq8R6zM/xua8g5 UR5A== MIME-Version: 1.0 X-Received: by 10.50.30.197 with SMTP id u5mr39338487igh.9.1433481900584; Thu, 04 Jun 2015 22:25:00 -0700 (PDT) Received: by 10.36.77.15 with HTTP; Thu, 4 Jun 2015 22:25:00 -0700 (PDT) In-Reply-To: <20150605051910.1636.qmail@ary.lan> References: <20150605051910.1636.qmail@ary.lan> Date: Fri, 5 Jun 2015 01:25:00 -0400 Message-ID: From: Jeffrey Walton To: John Levine Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "dbound@ietf.org" Subject: Re: [dbound] Some work that will probably hit dbound sooner rather than later X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: noloader@gmail.com List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2015 05:25:02 -0000 On Fri, Jun 5, 2015 at 1:19 AM, John Levine wrote: >>So we are clear... The actual argument is "The RFCs don't prohibit them." > > This is a fundamentally silly argument. The RFCs don't prohibit > sending death threats either. OK, agreed. Developers do unexpected things. Life is stranger than fiction at times. So what is the IETF going to do about it now that its aware of the behavior? Maybe its not a DBOUND problem. Maybe this particular problem is a PKIX problem. Jeff From nobody Thu Jun 4 23:06: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 D532E1B2C51 for ; Thu, 4 Jun 2015 23:06:03 -0700 (PDT) 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 WIOGIF7583wn for ; Thu, 4 Jun 2015 23:06:02 -0700 (PDT) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) (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 6EF381B2C4E for ; Thu, 4 Jun 2015 23:06:02 -0700 (PDT) Received: by igbhj9 with SMTP id hj9so8321007igb.1 for ; Thu, 04 Jun 2015 23:06:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=eym4XlmB4mgqfAiTO425CCRiZlnrzC68kIPuwa7e21o=; b=TkRsaHpfmOZhb8L/sOacSvItCpBjl5NjJfguH247WtXGqGyZ3MY3dTmwlijTWsrFQ8 UCh5YqIdAjE+eKEaXV6AkyM3MjScNXwjWhNGt2ZswnM9DngS0I0w5th1x7xAG/z8C/eR aM/CLkSMUpe0EHp4uNwMREKkdy7mynWf5m3IxIfuTwWA+tE7A57q2BoBhKSTsyXO4XOu O3nvZjD8zYc+lMxLNhDl/Y/2VTuJ4zasMCZjpn81Ihos0lxcK4omlWj/aPidLZLhp/KT kpLBGZkx3XT+o5Tf3SIjpHTghxqFPoL9kywDuB9rAeulSIAnG40SnQbPyF5EBQ6hjXQ7 fj9A== MIME-Version: 1.0 X-Received: by 10.42.176.8 with SMTP id bc8mr8467777icb.22.1433484361949; Thu, 04 Jun 2015 23:06:01 -0700 (PDT) Received: by 10.36.77.15 with HTTP; Thu, 4 Jun 2015 23:06:01 -0700 (PDT) In-Reply-To: <20150605051910.1636.qmail@ary.lan> References: <20150605051910.1636.qmail@ary.lan> Date: Fri, 5 Jun 2015 02:06:01 -0400 Message-ID: From: Jeffrey Walton To: John Levine Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "dbound@ietf.org" Subject: Re: [dbound] Some work that will probably hit dbound sooner rather than later X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: noloader@gmail.com List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2015 06:06:04 -0000 On Fri, Jun 5, 2015 at 1:19 AM, John Levine wrote: >>So we are clear... The actual argument is "The RFCs don't prohibit them." > > This is a fundamentally silly argument. The RFCs don't prohibit > sending death threats either. > My bad... It looks like the RFCs allow it. >From https://tools.ietf.org/html/rfc6125#section-6.4.3: A client employing this specification's rules MAY match the reference identifier against a presented identifier whose DNS domain name portion contains the wildcard character '*' as part or all of a label... >From RFC 1034, there's only one reserved label and that is the root. >From https://tools.ietf.org/html/rfc1034#section-3.1: One label is reserved, and that is the null (i.e., zero length) label used for the root. Jeff From nobody Fri Jun 5 00:50:56 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 20EF41B2D2A for ; Fri, 5 Jun 2015 00:50:54 -0700 (PDT) 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 LMVe88VPuxr1 for ; Fri, 5 Jun 2015 00:50:53 -0700 (PDT) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) (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 E5A121ACDDB for ; Fri, 5 Jun 2015 00:50:52 -0700 (PDT) Received: by ieclw1 with SMTP id lw1so52792034iec.3 for ; Fri, 05 Jun 2015 00:50:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; bh=39+0m+35/4nvpP3LQYaenQnXXPXl7oCna7YzvmTe0FY=; b=n4/b1fSoN7dQ/yiorgTJaTF4svese76O2qX0GId88E3qa7bW0AEB/bKvQwO+/DDRY2 QW7IttSNvGQBvuSkpi6rnQV1/7/H0v1omR3bIV1mPigBj4qKdo7A2/AQy2ouf9JxfCbQ V8y4kUoqJLWYs9zLVuxzLLDB6SHp1uJmsUrpc/v70PIZfXOJlEqDco13MaB4KxJiGcs0 2ksAliLYMs1xUWGJmLuYWkysQBfF+LG/KDeWofdq9en29cwGlGUd2JfAY61sOa4/jDC5 +4+pferHS0LFoHP45phZ4a9sz+vUQKZ+Sp+1a/+y3n7u+NJjQj8FdABTjrKOBAvXir2a vmqQ== MIME-Version: 1.0 X-Received: by 10.107.159.77 with SMTP id i74mr2744889ioe.9.1433490652426; Fri, 05 Jun 2015 00:50:52 -0700 (PDT) Received: by 10.36.77.15 with HTTP; Fri, 5 Jun 2015 00:50:52 -0700 (PDT) Date: Fri, 5 Jun 2015 03:50:52 -0400 Message-ID: From: Jeffrey Walton To: "dbound@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [dbound] Are there any restrictions on potential DBOUND solutions? X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: noloader@gmail.com List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2015 07:50:54 -0000 Please forgive my ignorance.... Are there any restrictions on potential DBOUND solutions? For example, should they/must they involve DNS? From nobody Fri Jun 5 04:45:26 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 73F391A00D8 for ; Fri, 5 Jun 2015 04:45:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 Gfd0SF1ZP9PC for ; Fri, 5 Jun 2015 04:45:23 -0700 (PDT) Received: from out.west.pexch112.icann.org (pfe112-ca-1.pexch112.icann.org [64.78.40.7]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2461E1A00D6 for ; Fri, 5 Jun 2015 04:45:23 -0700 (PDT) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Fri, 5 Jun 2015 04:45:21 -0700 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1044.021; Fri, 5 Jun 2015 04:45:21 -0700 From: Edward Lewis To: "dbound@ietf.org" Thread-Topic: [dbound] Some work that will probably hit dbound sooner rather than later Thread-Index: AQHQmlOqZZi5T3Jaz0i/hNY0pNEdcp2dCPyAgAAjRYCAACkigIAAsm+A Date: Fri, 5 Jun 2015 11:45:20 +0000 Message-ID: References: <20150604163311.GN94969@mx2.yitter.info> <20150604210639.GU94969@mx2.yitter.info> In-Reply-To: <20150604210639.GU94969@mx2.yitter.info> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.1.150515 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.47.234] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3516335117_2382799" MIME-Version: 1.0 Archived-At: Subject: Re: [dbound] Some work that will probably hit dbound sooner rather than later 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: Fri, 05 Jun 2015 11:45:24 -0000 --B_3516335117_2382799 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit On 6/4/15, 17:06, "Andrew Sullivan" wrote: >Instead, what we need is a mechanism by which such semantic intentions >can be captured in a way that they can be communicated reliably. If >we don't achieve that, then we won't have addressed the problem this >WG is supposed to solve. What I would have written if I read faster. The difference is that at the syntactic level (so to speak), *.com. is a validly formed domain name and conforms to the protocol definition. At the policy level (the how we use the DNS), this is not "permitted" because it causes (and it has been demonstrated to cause) operational havoc. Remember, there's a distinction to be made between a protocol's definition and the operational use of it. --B_3516335117_2382799 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIR+AYJKoZIhvcNAQcCoIIR6TCCEeUCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC D8EwggWwMIIEmKADAgECAhAOWKbdwJ1jDL89eBrwPJq7MA0GCSqGSIb3DQEBCwUAMGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTAeFw0xNDA1MjMw MDAwMDBaFw0xNzA1MjMxMjAwMDBaMIHPMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZv cm5pYTEUMBIGA1UEBxMLTG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEZMBcGA1UECxMQUmVnaXN0cnkg TGlhaXNvbjEVMBMGA1UEAxMMRWR3YXJkIExld2lzMSUwIwYJKoZIhvcNAQkBFhZlZHdhcmQu bGV3aXNAaWNhbm4ub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0JEom0oS 4pUrB2WBIm2wlbHpZHfieug7mzF6dSQ4ko95ZtjYdBoD9bPg5DGJqbbYJPXW5QjtONH87Tks HYfgBJFGLghTdJQ7S0gG2Ey9gmqf0xkLZGLS/h5+8UUyuKsF33TZboycSEMQjpS/9NiyeCP1 IG7QA69VL//WzCcsMXfcYrqQy1++YNbCLO//h1sdOVHX1RAS5PjpBzqJkMaz+zeHPMGbO6p3 kVU5ww+z5bXOxPV7mg2aEYBGReOLE9AEcxC7G4p2JbhOIuFDrqReXNfP96+2gSSiIblZ5rvC 4CvDQngJkl8QpCDgIWivPwPd+pV7lIECnElyx7hID0XtrwIDAQABo4IB7zCCAeswHwYDVR0j BBgwFoAU5wIjgABP2Ne8lAvZP3Q5STI8inkwHQYDVR0OBBYEFInPVvBX6bjyb+ptVCyB9MCo AjCLMAwGA1UdEwEB/wQCMAAwIQYDVR0RBBowGIEWZWR3YXJkLmxld2lzQGljYW5uLm9yZzAO BgNVHQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8 MDowOAYKYIZIAYb9bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5j b20vQ1BTMIGIBgNVHR8EgYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0Rp Z2lDZXJ0U0hBMkFzc3VyZWRJRENBLWcxLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNl cnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLWcxLmNybDB5BggrBgEFBQcBAQRtMGsw JAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0 cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDAN BgkqhkiG9w0BAQsFAAOCAQEAXSa/5kRotclqD20zg8Q4k1CbLJXVEADyKZToYa/hwdv30MPe f+ahkFnqqL2tWMbCYydAzAwkdQInmMTB1LfriPaOieJiSA3HmCukmTuf8sW8DvpruIG2jl70 ZXStMKICbkmdQhnArVYqezzBbwJTMVQlTmaMOaZ3fLqsi5XzyD3l5llvR4AIkKwhWZU68q4m 4kGXPBpiPWMwEHX2DEixM/h1rGl1RXmG+FqjEG5H3wrPim3hUXcNyostwiZyRUVIuRlLGzJh nlJhql0YfTNg1YkLlX/YxbFov1nzobR84U39QLaqxiZ5F96WwBZLxW4nDn7rTDGG0l3W09yy EoOSczCCBk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcNAQELBQAwZTEL MAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEzMTEw NTEyMDAwMFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lD ZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg U0hBMiBBc3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgR Iz9qte/AJ3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pj eFkeIiwr+Lp+yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdT QDK9T+ZQelAfJUXo8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdf auIagkEK3OnZ9ZEXjsYhrTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16 CzfgT8uCig1xGOSm4IksG/OyczzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYD VR0TAQH/BAgwBgEB/wIBADAOBgNVHQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsG AQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0 dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4 oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5j cmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMIIBswYDVR0gBIIBqjCCAaYwggGi BgpghkgBhv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29t L0NQUzCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQAaABp AHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMAIABh AGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQAIABD AFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIAdAB5 ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkAYQBi AGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIj gABP2Ne8lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJ KoZIhvcNAQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFR XJmOtfrgYhmZpgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+ W0L2zpFg4/mgVgxIEM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0 UIBOAtmwXZG0k4f5lpaBVUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCwe knjGVT1YEhEybr1DDE0023vGQtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+Di bsIwggO3MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAw MDAwMDBaFw0zMTExMTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2Vy dCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFz c3VyZWQgSUQgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7k Q4BcsYfzt2D5cRKlrtwmlIiq9M71IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrn eVNcMYQq9g+YMjZ2zN7dPKii72r7IfJSYd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9Sw OD7BG8OMM9nYLxj+KA+zp4PWw25EwGE1lhb+WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyCh z+VtCshJfDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh5vqk2dUXMXWuhX0irj8BRob2KHnIsdrk VxfEfhwOsLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Yd08CAwEAAaNjMGEwDgYDVR0PAQH/ BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXroq/0ksuCMS1Ri6enIZ3zbcgP MB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqGSIb3DQEBBQUAA4IBAQCi Drzf4u3w43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwSTFjk0z2DSUVYlzVp GqhH6lbGeasS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJs13rsgkq6ybt eL59PyvztyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLxvlBnt2y9 8/Efaww2BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76jRsl bWyPpbdhAbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMYIB/zCCAfsCAQEweTBl MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGln aWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBTSEEyIEFzc3VyZWQgSUQgQ0ECEA5Ypt3A nWMMvz14GvA8mrswCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBTcaQrim42bIQtBON5d pQxNIGhDFTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTA2 MDUxMTQ1MTdaMA0GCSqGSIb3DQEBAQUABIIBAEQwmuDuPD3GhyhSVQvJ5mk5G/hDxWgE2Fn8 fKzTB6Rphi5qk2paC4vmVFbkq0WDtedALYH5Be9OCLPP3moAkqYq5siverXNo3At48L8ob+6 /b0MoVBj84jNCLP/jRYy6aAPn6vrSDCb3tVZBE++wwYn5cmaBSZFE1AS85z7RI/K4pDR+JkA fMn5p/mOSc3FPj3UgtjvwhEomncWUrY5X/4FNjYE2Gi9zBUQBFBxsGyn+SaYX86uCF0XcB0i kKxiEGopIUKSF3PF+6kVOflPSlm8paUHUHaBv+pfLEQVw7R5GuY52Mh6OBdb3vGWsPTpnKTY XAFB3GCqycTNwotMCRA= --B_3516335117_2382799-- From nobody Fri Jun 5 09:53: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 821831A86FA for ; Fri, 5 Jun 2015 09:53:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.862 X-Spam-Level: X-Spam-Status: No, score=0.862 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 x6Y3SZGQlBZH for ; Fri, 5 Jun 2015 09:53:33 -0700 (PDT) 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 2285A1A8714 for ; Fri, 5 Jun 2015 09:53:33 -0700 (PDT) Received: (qmail 86608 invoked from network); 5 Jun 2015 16:53:40 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 5 Jun 2015 16:53:40 -0000 Date: 5 Jun 2015 16:53:09 -0000 Message-ID: <20150605165309.4506.qmail@ary.lan> From: "John Levine" To: dbound@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: noloader@gmail.com Subject: Re: [dbound] Are there any restrictions on potential DBOUND solutions? 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: Fri, 05 Jun 2015 16:53:34 -0000 In article you write: >Please forgive my ignorance.... > >Are there any restrictions on potential DBOUND solutions? > >For example, should they/must they involve DNS? See the charter, which you can find here: https://datatracker.ietf.org/wg/dbound/charter/ R's, John From nobody Fri Jun 5 09:57:15 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 001831A8F44 for ; Fri, 5 Jun 2015 09:57:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.862 X-Spam-Level: X-Spam-Status: No, score=0.862 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 VFydd26TW88e for ; Fri, 5 Jun 2015 09:57:13 -0700 (PDT) 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 7A2C11A872B for ; Fri, 5 Jun 2015 09:57:10 -0700 (PDT) Received: (qmail 86966 invoked from network); 5 Jun 2015 16:57:18 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 5 Jun 2015 16:57:18 -0000 Date: 5 Jun 2015 16:56:47 -0000 Message-ID: <20150605165647.4541.qmail@ary.lan> From: "John Levine" To: dbound@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: noloader@gmail.com Subject: Re: [dbound] Some work that will probably hit dbound sooner rather than later 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: Fri, 05 Jun 2015 16:57:14 -0000 >>From https://tools.ietf.org/html/rfc6125#section-6.4.3: > > A client employing this specification's rules MAY match the reference > identifier against a presented identifier whose DNS domain name > portion contains the wildcard character '*' as part or all of a label... Right. A cert for *.sales.bigcorp.com or *.smallcorp.com is fine. A cert for *.barclaycard is probably fine. A cert for *.com is not fine. But there is no technical difference among those, only a policy difference. We do technology, not policy. We're certainly not thrilled when people make bad policies, but it's not something we can prevent. R's, John From nobody Sun Jun 7 08:35:32 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 2D4871A912F for ; Sun, 7 Jun 2015 08:35:31 -0700 (PDT) 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 1IvYVcy-6BVV for ; Sun, 7 Jun 2015 08:35:25 -0700 (PDT) Received: from mail-pd0-x22f.google.com (mail-pd0-x22f.google.com [IPv6:2607:f8b0:400e:c02::22f]) (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 0CE811A9134 for ; Sun, 7 Jun 2015 08:35:24 -0700 (PDT) Received: by pdjm12 with SMTP id m12so84592663pdj.3 for ; Sun, 07 Jun 2015 08:35:23 -0700 (PDT) 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=GhIWRwCqzv1QHl7QBUVFXKnnjRnjgRXU3k3qqqdN/f0=; b=xCvnFSEx+MnZ91wwIt3q8m7p934AkgsPXH8ADbih0yczT71sOAR/2BnocENDZdwIVm txNYLQrjdnaPGkXrGXgt1tk2ZzXdOncoEULD/R9OPFyTnZJZK5KD7shYsICC9qAvPO3p qaVp2Jc3sZarfYuStoof52AD8cj3qCRSQshL6Xupsl61beXOp+Ah606zlvQbD5NUAA1O DTXxs7YTSmjeJzMFdsQlT9V/ruptWX5eW9GbsK5sariqX0O+1p8M+H3ocJ9oOhVlWr5n OUkkA56HykDQOaWE4ata8VtI7Z17UaupyJAkwTRzG+jeyPeN8mZ0HMOrmciy9507Nhkh lXpQ== MIME-Version: 1.0 X-Received: by 10.70.91.3 with SMTP id ca3mr22753022pdb.16.1433691323228; Sun, 07 Jun 2015 08:35:23 -0700 (PDT) Received: by 10.70.66.5 with HTTP; Sun, 7 Jun 2015 08:35:23 -0700 (PDT) In-Reply-To: <20150605165647.4541.qmail@ary.lan> References: <20150605165647.4541.qmail@ary.lan> Date: Sun, 7 Jun 2015 08:35:23 -0700 Message-ID: From: Peter Bowen To: John Levine Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: noloader@gmail.com, dbound@ietf.org Subject: Re: [dbound] Some work that will probably hit dbound sooner rather than later 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: Sun, 07 Jun 2015 15:35:31 -0000 On Fri, Jun 5, 2015 at 9:56 AM, John Levine wrote: >>>From https://tools.ietf.org/html/rfc6125#section-6.4.3: >> >> A client employing this specification's rules MAY match the reference >> identifier against a presented identifier whose DNS domain name >> portion contains the wildcard character '*' as part or all of a label... > > Right. A cert for *.sales.bigcorp.com or *.smallcorp.com is fine. A > cert for *.barclaycard is probably fine. A cert for *.com is not > fine. But there is no technical difference among those, only a policy > difference. We do technology, not policy. > > We're certainly not thrilled when people make bad policies, but it's > not something we can prevent. 6125 does leave open a number of wildcard options that could be closed down via technology. 6.4.3 (1) and (3) could move to MUST NOT, which would mean the only allowed wildcard name would be "*" as the first label followed by LDH labels. As section 7.2 calls out, there are numerous issues with ambiguity when using labels that mix a wildcard with other characters in a single label. It doesn't solve the original issue (is *. acceptable?) but would help reduce the probability of accidental misuse in other situations. Thanks, Peter From nobody Sun Jun 7 10:03: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 7A6D91A870B for ; Sun, 7 Jun 2015 10:02:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.563 X-Spam-Level: * X-Spam-Status: No, score=1.563 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 3-ppS-YV9KF6 for ; Sun, 7 Jun 2015 10:02:58 -0700 (PDT) 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 55F311A7032 for ; Sun, 7 Jun 2015 10:02:58 -0700 (PDT) Received: (qmail 70279 invoked from network); 7 Jun 2015 17:03:06 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=11286.5574794a.k1506; bh=qd1v5kiHjlinTebYekdQfj6G5vrusuR41NKgYhXbenI=; b=aFzzG0teQUAVRbL0QvkqpFCi3jM+ddRP/S9Tve1tJnSWK4WdRaAOfH6oGR+gZ5zLm81qaWoywzvglfoX2M3ccA7g8o57o91UstAanhJSMnaO9PEitBFIfOOuWMuhfjooaYLVADw1GibGc+ACkLqJOxGsi+DyEO5VcLGWYsLmz/W+uLUSvJFhrO++g4Jlz5ifjGjsbgq66B2DaBJH187lZ7urcLhjHtuR2FPNEsgdE6TAIDBSUIk1ov7CV4bBFmko DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=11286.5574794a.k1506; bh=qd1v5kiHjlinTebYekdQfj6G5vrusuR41NKgYhXbenI=; b=ecYUFKtyjfLMuKDAqlke63E3uoKRWIsdGvfDJpVuROcDRArMQ6T6zs0C8HEzF2Y+Yjb4Ci2JGC9E1pQPFtp+zYAsSICo8d9h9/Rpemrz2aPmewemwrREb5hjWzfcinHA3VfgEkSw+WHMqB0i3vWO/b4q/5FnSTgimGgW5gX/83JSxzqEuwd3zngNQWTULiMsartFSEDp8qW66f7BIqsT17DnPtWAO6SS0HblBCCGumTRNWh7+TmDJpogXdt9vjtd Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 07 Jun 2015 17:03:06 -0000 Date: 7 Jun 2015 18:02:55 +0100 Message-ID: From: "John R Levine" To: "Peter Bowen" In-Reply-To: References: <20150605165647.4541.qmail@ary.lan> User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: dbound@ietf.org Subject: Re: [dbound] Some work that will probably hit dbound sooner rather than later 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: Sun, 07 Jun 2015 17:02:59 -0000 > 6125 does leave open a number of wildcard options that could be closed > down via technology. 6.4.3 (1) and (3) could move to MUST NOT, which > would mean the only allowed wildcard name would be "*" as the first > label followed by LDH labels. As section 7.2 calls out, there are > numerous issues with ambiguity when using labels that mix a wildcard > with other characters in a single label. Thanks for bringing this up, since this will be a problem for DBOUND. For actual domain names, the rules are clear that the single character "*" as the leftmost component is a wildcard, a * anywhere else is just a character, e.g., the name a*.example.com only matches the name a*.example.com where that * is a literal character. See RFC 4592. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Tue Jun 9 09:09:33 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 1FFFB1A895C for ; Tue, 9 Jun 2015 09:09:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 7d9RpbOO2djf for ; Tue, 9 Jun 2015 09:09:30 -0700 (PDT) Received: from mx-out-1.zmailcloud.com (01.zmailcloud.com [192.198.85.104]) by ietfa.amsl.com (Postfix) with ESMTP id 5029F1A8AE3 for ; Tue, 9 Jun 2015 09:09:24 -0700 (PDT) Received: from smtp.01.com (smtp.01.com [10.10.0.43]) by mx-out-1.zmailcloud.com (Postfix) with ESMTP id D685856401B for ; Tue, 9 Jun 2015 11:09:23 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id D089AA03C2 for ; Tue, 9 Jun 2015 11:09:23 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EOI-SsLE3i9R for ; Tue, 9 Jun 2015 11:09:23 -0500 (CDT) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id C84D2A03B6 for ; Tue, 9 Jun 2015 11:09:22 -0500 (CDT) DKIM-Filter: OpenDKIM Filter v2.8.4 smtp-out-1.01.com C84D2A03B6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=peachymango.org; s=61F775A4-4A7F-11E4-A6BB-61E3068E35F6; t=1433866163; bh=w2/BF8+nDrF7/RV7Et8kbNbX9dPMbTjoRFJ8hobFD/w=; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type; b=rjeMHLD+zvoS16SAnVO8otzqqZ0bMOyzhOUvGHB8ZHJ6q3NH8lO79P3OPbh4I/tVc iO3Ufj59pvUJu6yzCg5OvAOupAdJ+mC+fIZZSTD4qXx6kd/TL0f3mSNGBT9Pq5vI+l VqxpWpABcIsGTbIMEApXCvEdhPInEdFvCs18Rhbs= Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id A6C30A03C0 for ; Tue, 9 Jun 2015 11:09:22 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id t_sY3_tjTeVX for ; Tue, 9 Jun 2015 11:09:22 -0500 (CDT) Received: from mail-2.01.com (mail.01.com [10.10.0.41]) by smtp-out-1.01.com (Postfix) with ESMTP id 87092A03B6 for ; Tue, 9 Jun 2015 11:09:22 -0500 (CDT) Date: Tue, 9 Jun 2015 11:09:22 -0500 (CDT) From: Franck Martin To: dbound@ietf.org Message-ID: <407125776.31381.1433866162294.JavaMail.zimbra@peachymango.org> In-Reply-To: <1118731486.31297.1433865987506.JavaMail.zimbra@peachymango.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_31380_1587478072.1433866162294" X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF38 (Mac)/8.0.5_GA_5839) Thread-Topic: SSAC Advisory on the Use of Static TLD / Suffix Lists Thread-Index: sb37nGG7/eR3muGhgl6fz5QR6fihiA== Archived-At: Subject: [dbound] SSAC Advisory on the Use of Static TLD / Suffix Lists 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, 09 Jun 2015 16:09:32 -0000 ------=_Part_31380_1587478072.1433866162294 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit https://www.icann.org/en/system/files/files/sac-070-en.pdf ------=_Part_31380_1587478072.1433866162294 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit ------=_Part_31380_1587478072.1433866162294-- From nobody Fri Jun 12 10:01:22 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 61B481ACD3B for ; Fri, 12 Jun 2015 10:01:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-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 MkfLbjS4xX8H for ; Fri, 12 Jun 2015 10:01:15 -0700 (PDT) Received: from mx2.yitter.info (mx2.yitter.info [IPv6:2600:3c03::f03c:91ff:fedf:cfab]) by ietfa.amsl.com (Postfix) with ESMTP id 30A681ACD38 for ; Fri, 12 Jun 2015 10:01:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx2.yitter.info (Postfix) with ESMTP id BD82D105DE for ; Fri, 12 Jun 2015 17:01:14 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx2.yitter.info ([127.0.0.1]) by localhost (mx2.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9C2iu87I0zQL for ; Fri, 12 Jun 2015 17:01:14 +0000 (UTC) Received: from mx2.yitter.info (unknown [IPv6:2601:18d:8600:22:cc13:b82b:be5a:82a4]) by mx2.yitter.info (Postfix) with ESMTPSA id 0F3DE1000E for ; Fri, 12 Jun 2015 17:01:14 +0000 (UTC) Date: Fri, 12 Jun 2015 13:01:12 -0400 From: Andrew Sullivan To: dbound@ietf.org Message-ID: <20150612170112.GD8681@mx2.yitter.info> References: <20150604163311.GN94969@mx2.yitter.info> <20150604210639.GU94969@mx2.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: Subject: Re: [dbound] Some work that will probably hit dbound sooner rather than later 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: Fri, 12 Jun 2015 17:01:19 -0000 On Fri, Jun 05, 2015 at 11:45:20AM +0000, Edward Lewis wrote: > Remember, there's a distinction to be made between a protocol's definition > and the operational use of it. Yes, and what I've been arguing now for several years is that the basic problem here is the lack of a mechanism by which the operational policies can be expressed. Instead, people try to read the policy off the point in the hierarchy, and the PSL is the workaround for "where in the hierarchy do you do that?". I think the WG should try to provide a way of doing this more reliably. A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Sun Jun 14 18: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 330891A8906 for ; Sun, 14 Jun 2015 18:37:06 -0700 (PDT) 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 XDUurO20tMYY for ; Sun, 14 Jun 2015 18:37:05 -0700 (PDT) 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 BE0A01A8904 for ; Sun, 14 Jun 2015 18:37:04 -0700 (PDT) Received: (qmail 44028 invoked from network); 15 Jun 2015 01:37:12 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 15 Jun 2015 01:37:12 -0000 Date: 15 Jun 2015 01:36:40 -0000 Message-ID: <20150615013640.26782.qmail@ary.lan> From: "John Levine" To: dbound@ietf.org Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: [dbound] Certificate wildcards vs. DNS wildcards 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, 15 Jun 2015 01:37:06 -0000 I was surprised to find that the rules for domain wildcards in SSL certificates is different from the rules in the DNS. In the DNS, the only wild card is *. as the terminal name, while in certs, it's more like shell wildcards, abc*.example.com matches what it looks like. I verified that this isn't a bug, in that the description of cert wildcards in RFC 6125 is deliberately different and matches what browsers do. If we use something like my DNS hack (look in the list archives) to publish PSL-ish information, this could in principle be a problem. But I wondered how many certs actually use wildcards other than a plain *. I used the University of Michigan's HTTPS Ecosystem data, available here: https://scans.io/study/umich-https (It's newer than the EFF's SSL Observatory and a lot easier to download.) It has about 147M certificates. I mechanically went through and extracted every certificate CN= that contained a * and deduped them, coming up with 852K, a very small fraction. I then went through and selected the CN= that didn't start with *.x where x was not a *, of which there were only 5182. I put those files at http://www.taugh.com/certs, in stars.txt and oddstars.txt. Of those 5182 that didn't start with *., over 4000 were some odd pseudo-hex stuff starting \x00 that looks to me either intended for a non-standard application, or maybe they're just broken. So of the 147M certificates, I see less than a thousand that have plausible non-DNS wildcards, and eyeballing them, the wildcard stuff is all to the left of an ordinary domain name. So even though the wildcard rules are different, in practice it doesn't matter. R's, John From nobody Sun Jun 14 19:04:54 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 310E01AD08F for ; Sun, 14 Jun 2015 19:04:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.3 X-Spam-Level: * X-Spam-Status: No, score=1.3 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, J_CHICKENPOX_64=0.6, 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 CR4IA5BBS6Ke for ; Sun, 14 Jun 2015 19:04:51 -0700 (PDT) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) (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 AA1811AD080 for ; Sun, 14 Jun 2015 19:04:51 -0700 (PDT) Received: by iesa3 with SMTP id a3so53656600ies.2 for ; Sun, 14 Jun 2015 19:04:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=gCO6bipH0P3NMx8fDGnCwGKan7YneO/wHvcKdeHgrSQ=; b=DOPRu0qMbrpxJc7Kr8lol0ikVnrZcFE9mqi66sxM+x6wFlmcyjtCoG1NmhUw6oopIl HlaEk9QuWSNcFX9d6leiTB8GIsHverxwAE4gswsE7M1SwaYpmyqeq93C6nyg2fMU8h/5 pCA/BslJtLd0QxayNN6GnA0b1KkNxm+zUezOWxDCpZc2bde8A8CrNeWQsHznKFDD9LS9 63Y1CFAZkd1Fxm84deLtt9mxDz8LtDJObCqQz8bO4NkTVFffnWI/xSWiidGnDCIS6jsO ZT9yWY7DvLiZlD9fwlSgor2+w30+t99gPAL9rCXOUPpImHT5TjigUYfuE/EhKtWky7J5 wubA== MIME-Version: 1.0 X-Received: by 10.42.176.8 with SMTP id bc8mr12062082icb.22.1434333891109; Sun, 14 Jun 2015 19:04:51 -0700 (PDT) Received: by 10.36.77.15 with HTTP; Sun, 14 Jun 2015 19:04:51 -0700 (PDT) In-Reply-To: <20150615013640.26782.qmail@ary.lan> References: <20150615013640.26782.qmail@ary.lan> Date: Sun, 14 Jun 2015 22:04:51 -0400 Message-ID: From: Jeffrey Walton To: John Levine Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "dbound@ietf.org" Subject: Re: [dbound] Certificate wildcards vs. DNS wildcards X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: noloader@gmail.com List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2015 02:04:53 -0000 > Of those 5182 that didn't start with *., over 4000 were some odd > pseudo-hex stuff starting \x00 that looks to me either intended for a > non-standard application, or maybe they're just broken. This looks like the start of Marlinspike's Null Prefix attack*. I would reject it as malformed since the ASN.1 payload length is not equal to strlen(cstr of ASN.1 string). That still leaves about 1000 certificates from the reduced data set. Jeff * https://www.blackhat.com/presentations/bh-usa-09/MARLINSPIKE/BHUSA09-Marlinspike-DefeatSSL-SLIDES.pdf On Sun, Jun 14, 2015 at 9:36 PM, John Levine wrote: > I was surprised to find that the rules for domain wildcards in SSL > certificates is different from the rules in the DNS. In the DNS, the > only wild card is *. as the terminal name, while in certs, it's more > like shell wildcards, abc*.example.com matches what it looks like. I > verified that this isn't a bug, in that the description of cert > wildcards in RFC 6125 is deliberately different and matches what > browsers do. > > If we use something like my DNS hack (look in the list archives) to > publish PSL-ish information, this could in principle be a problem. > But I wondered how many certs actually use wildcards other than a > plain *. > > I used the University of Michigan's HTTPS Ecosystem data, available > here: https://scans.io/study/umich-https > (It's newer than the EFF's SSL Observatory and a lot easier to > download.) > > It has about 147M certificates. I mechanically went through and > extracted every certificate CN= that contained a * and deduped them, > coming up with 852K, a very small fraction. I then went through > and selected the CN= that didn't start with *.x where x was not > a *, of which there were only 5182. I put those files at > http://www.taugh.com/certs, in stars.txt and oddstars.txt. > > Of those 5182 that didn't start with *., over 4000 were some odd > pseudo-hex stuff starting \x00 that looks to me either intended for a > non-standard application, or maybe they're just broken. So of the > 147M certificates, I see less than a thousand that have plausible > non-DNS wildcards, and eyeballing them, the wildcard stuff is all to > the left of an ordinary domain name. > > So even though the wildcard rules are different, in practice it > doesn't matter. > From nobody Mon Jun 15 00:53: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 D93591B2B1E for ; Mon, 15 Jun 2015 00:53:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 wgXxj5ZBQKny for ; Mon, 15 Jun 2015 00:53:06 -0700 (PDT) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) (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 C98761A9138 for ; Mon, 15 Jun 2015 00:53:05 -0700 (PDT) Received: by wigg3 with SMTP id g3so68228197wig.1 for ; Mon, 15 Jun 2015 00:53:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:openpgp:message-id :date:user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=B4bXGrUlADWcliWEiIjZY9nFZ7IUwVlay0qAhDfwgoc=; b=MQwYa+aN0XqVwHQKkOAeR4dMGcjEaI0/AeDlN57IFhVWnmL6FZLimwjLHJTodfQr6q 318Epqo6paEUYWTd9hLfQYN4FU5WLwOpJjgp/zg9EMd/Sq4415Fytdyw7vtYmsNfC0lO yay/f+2wNESapORPJz4f/U83A0L4L9jzKjAddQUM65piO8Cal7qhfG4w8XIwK5I3n+X8 irbLaLg/8i4Qz+SamXXiBr4J64feKL+61JEg7Eh9boY/jbCySgypAKXEIciMFTm1CeiY sO7akmgWWjc6dTb12JiW6Hv7oEidXQh+8aHcSApoOqW4JBUovJ3DEUD8u02uC+xY7UXB TPDg== X-Gm-Message-State: ALoCoQnGevS1TwluBfyP4hFzS9U2kBQ2RdFFhdF1WRspteDU8qao8DRDFMvAOwHz9MWho2R6z0c6 X-Received: by 10.180.231.40 with SMTP id td8mr29712515wic.9.1434354784409; Mon, 15 Jun 2015 00:53:04 -0700 (PDT) Received: from [192.168.0.103] (fpc2-shef11-2-0-cust7.17-1.static.cable.virginm.net. [94.173.170.136]) by mx.google.com with ESMTPSA id n3sm15155786wix.1.2015.06.15.00.53.02 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 15 Jun 2015 00:53:03 -0700 (PDT) To: John Levine , dbound@ietf.org References: <20150615013640.26782.qmail@ary.lan> From: Gervase Markham Openpgp: id=EEDEEFF962E97696DACBD2CCD9B347EA9DF43DBB X-Enigmail-Draft-Status: N1110 Message-ID: <557E845E.3070608@mozilla.org> Date: Mon, 15 Jun 2015 08:53:02 +0100 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.0 MIME-Version: 1.0 In-Reply-To: <20150615013640.26782.qmail@ary.lan> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dbound] Certificate wildcards vs. DNS wildcards 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, 15 Jun 2015 07:53:08 -0000 On 15/06/15 02:36, John Levine wrote: > I was surprised to find that the rules for domain wildcards in SSL > certificates is different from the rules in the DNS. In the DNS, the > only wild card is *. as the terminal name, while in certs, it's more > like shell wildcards, abc*.example.com matches what it looks like. I > verified that this isn't a bug, in that the description of cert > wildcards in RFC 6125 is deliberately different and matches what > browsers do. I'm surprised that you've verified that, in that my understanding is that no browser for many years has supported abc*.example.com (or, for that matter, foo.*.example.com). This is why you don't see them in the wild. Do you have evidence to the contrary? Gerv From nobody Mon Jun 15 01:15:37 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 BCCCB1B2B58 for ; Mon, 15 Jun 2015 01:15:36 -0700 (PDT) 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 q_esDZMOJUDW for ; Mon, 15 Jun 2015 01:15:34 -0700 (PDT) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) (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 7223C1B29BF for ; Mon, 15 Jun 2015 01:15:34 -0700 (PDT) Received: by igbiq7 with SMTP id iq7so12809500igb.1 for ; Mon, 15 Jun 2015 01:15:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=deFw6bfo50e9zvTy7yU+l7iD+b49qmpZDrMw792NIfw=; b=DS9+ZUam/rSuwhNft826SNg62aNcUlkoYBMYUOrCbmphHaUi3BYcCfzoP0kavGpY2F ZgCto6ng+AbaOfOUidoh88pT46yVr+9qq8IbVrtyrMYEsD45+SwUw7vacXKMCRvWNkYU XHLbec2rXiYogxx7QPyEm/xfUhr8f7N7TMPtVXpIk9kbGxrpJuxGjnAWruR0+CyJc+ct E0ZNcOeU2L6QtVL97vfgQYjRmu1B3uS/Y9up2V+ETaDIUZ77JixM3Y2pqdSwZJrhD8V3 8hoMYWQTfj/R5D7HpoAHnwRl8yOlvYR+B+TOpvd0Kb5LOSx2tAjpDJ8I2XfHzi17JFs3 Jjqg== MIME-Version: 1.0 X-Received: by 10.42.176.8 with SMTP id bc8mr13181198icb.22.1434356133932; Mon, 15 Jun 2015 01:15:33 -0700 (PDT) Received: by 10.36.77.15 with HTTP; Mon, 15 Jun 2015 01:15:33 -0700 (PDT) In-Reply-To: <557E845E.3070608@mozilla.org> References: <20150615013640.26782.qmail@ary.lan> <557E845E.3070608@mozilla.org> Date: Mon, 15 Jun 2015 04:15:33 -0400 Message-ID: From: Jeffrey Walton To: Gervase Markham Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "dbound@ietf.org" Subject: Re: [dbound] Certificate wildcards vs. DNS wildcards X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: noloader@gmail.com List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2015 08:15:36 -0000 On Mon, Jun 15, 2015 at 3:53 AM, Gervase Markham wrote: > On 15/06/15 02:36, John Levine wrote: >> I was surprised to find that the rules for domain wildcards in SSL >> certificates is different from the rules in the DNS. In the DNS, the >> only wild card is *. as the terminal name, while in certs, it's more >> like shell wildcards, abc*.example.com matches what it looks like. I >> verified that this isn't a bug, in that the description of cert >> wildcards in RFC 6125 is deliberately different and matches what >> browsers do. > > I'm surprised that you've verified that, in that my understanding is > that no browser for many years has supported abc*.example.com (or, for > that matter, foo.*.example.com). This is why you don't see them in the > wild. Do you have evidence to the contrary? > Browsers are only one type of user agent. Jeff From nobody Mon Jun 15 01:19: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 9402F1B3405 for ; Mon, 15 Jun 2015 01:19:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 YxbqpVoptKvr for ; Mon, 15 Jun 2015 01:19:22 -0700 (PDT) Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) (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 54F0C1B3403 for ; Mon, 15 Jun 2015 01:19:22 -0700 (PDT) Received: by wgzl5 with SMTP id l5so37380620wgz.3 for ; Mon, 15 Jun 2015 01:19:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:openpgp:message-id :date:user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=RHN2gqEbTHKeumheT7HTViqgK6/9vPyT/NQFGwXfJxg=; b=iuXplzXUE8RKSaY3a0kj64uOnfFQubP14KgZwOQc/k28iMiZSF6ISUeIZ92G/lsd/k YMW/uraFirnwyRVDZotiipsmhdO/yBpvuLIxwqthDH/9vNzCxlPchzt+pzfnUZkJuDq+ DLrKEcWAwu1MSM02/nXsyk+D6gnc0Y46HdoJfeipfDqZ+jjZ6+ki2DlkzEZabM6YGf3+ URPAvUWtSB4wr7qJFB6POVKPQcJOOGBR37wK9jVWIU0lcc8quRDOrDBv3R5KTsU/jkUK u6CVo6K0rCRC7ayT6datlwio6xu6h2yhMxm13FQ01I5DScPE3idMnWSj0xnLDcrWJu7p W1Aw== X-Gm-Message-State: ALoCoQldHMiORcvGojM7GQCXMjNNvvsmHsOMPzonwXPrc19pibyTfKCzrKB0qqhFgffT3Z6bW11i X-Received: by 10.180.82.100 with SMTP id h4mr29279715wiy.34.1434356361034; Mon, 15 Jun 2015 01:19:21 -0700 (PDT) Received: from [192.168.0.103] (fpc2-shef11-2-0-cust7.17-1.static.cable.virginm.net. [94.173.170.136]) by mx.google.com with ESMTPSA id lf4sm17752086wjb.42.2015.06.15.01.19.19 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 15 Jun 2015 01:19:20 -0700 (PDT) To: noloader@gmail.com References: <20150615013640.26782.qmail@ary.lan> <557E845E.3070608@mozilla.org> From: Gervase Markham Openpgp: id=EEDEEFF962E97696DACBD2CCD9B347EA9DF43DBB X-Enigmail-Draft-Status: N1110 Message-ID: <557E8A87.1020607@mozilla.org> Date: Mon, 15 Jun 2015 09:19:19 +0100 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "dbound@ietf.org" Subject: Re: [dbound] Certificate wildcards vs. DNS wildcards 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, 15 Jun 2015 08:19:24 -0000 On 15/06/15 09:15, Jeffrey Walton wrote: > On Mon, Jun 15, 2015 at 3:53 AM, Gervase Markham wrote: >> On 15/06/15 02:36, John Levine wrote: >>> I was surprised to find that the rules for domain wildcards in SSL >>> certificates is different from the rules in the DNS. In the DNS, the >>> only wild card is *. as the terminal name, while in certs, it's more >>> like shell wildcards, abc*.example.com matches what it looks like. I >>> verified that this isn't a bug, in that the description of cert >>> wildcards in RFC 6125 is deliberately different and matches what >>> browsers do. >> >> I'm surprised that you've verified that, in that my understanding is >> that no browser for many years has supported abc*.example.com (or, for >> that matter, foo.*.example.com). This is why you don't see them in the >> wild. Do you have evidence to the contrary? >> > Browsers are only one type of user agent. Indeed so. But you said "matches what browsers do", not "matches what user agents do". I admit I have much less insight into the behaviour of non-browser user agents. I would still be interested in the names of current bits of software which recognise "abc*.example.com" or similar. Gerv From nobody Mon Jun 15 01:19: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 BDD531B3415 for ; Mon, 15 Jun 2015 01:19:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 aoU6oyN85SHt for ; Mon, 15 Jun 2015 01:19:29 -0700 (PDT) Received: from mail-wg0-f45.google.com (mail-wg0-f45.google.com [74.125.82.45]) (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 82B731B3403 for ; Mon, 15 Jun 2015 01:19:29 -0700 (PDT) Received: by wgv5 with SMTP id 5so62265008wgv.1 for ; Mon, 15 Jun 2015 01:19:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:openpgp:message-id :date:user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=j4gSkZuA0POH78tCgeMbOtospX2BSeXlmkWAr60lmUI=; b=FYb7jbIUQzn22QzneNq8X9QrC5rXOehgniJl6SATWuOC/XWEvk3Mrjbg8dPkTTb8qw cyt2ik+tFjDdeFSTrKPSVE1bZAgk8MdNounw+bv/20iWYlgQY07sCeUb23DJDWDOZi5o bAGm04WKw25QeydGT3ckMu8riUdra2A7ipR0XHoXD3m/D6s2F3nqyuy6mHdt1DYF+3X/ YfTybvHWF4BAY0QRbrjK97emxrpoYSd5Y/4EmhkUnE9b5hGTjbReYCpTnRCLwLgdtNzA +ngYpuXSKbBPS34iGUmLdRNbXTEeG4dH9NUWBBmZVcMkIJK7IfgSU8JhjD55bkwP4+I2 fqPQ== X-Gm-Message-State: ALoCoQlYoKnf5mGtks8tpzjuVvi61AnlX3yk1nelHPn8WAD9e429y78bgsUH0lpKAr/eEf7DCfVT X-Received: by 10.180.231.40 with SMTP id td8mr29910264wic.9.1434356368229; Mon, 15 Jun 2015 01:19:28 -0700 (PDT) Received: from [192.168.0.103] (fpc2-shef11-2-0-cust7.17-1.static.cable.virginm.net. [94.173.170.136]) by mx.google.com with ESMTPSA id 12sm17724697wjw.17.2015.06.15.01.19.27 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 15 Jun 2015 01:19:27 -0700 (PDT) To: noloader@gmail.com References: <20150615013640.26782.qmail@ary.lan> <557E845E.3070608@mozilla.org> From: Gervase Markham Openpgp: id=EEDEEFF962E97696DACBD2CCD9B347EA9DF43DBB X-Enigmail-Draft-Status: N1110 Message-ID: <557E8A8E.8020102@mozilla.org> Date: Mon, 15 Jun 2015 09:19:26 +0100 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "dbound@ietf.org" Subject: Re: [dbound] Certificate wildcards vs. DNS wildcards 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, 15 Jun 2015 08:19:34 -0000 On 15/06/15 09:15, Jeffrey Walton wrote: > On Mon, Jun 15, 2015 at 3:53 AM, Gervase Markham wrote: >> On 15/06/15 02:36, John Levine wrote: >>> I was surprised to find that the rules for domain wildcards in SSL >>> certificates is different from the rules in the DNS. In the DNS, the >>> only wild card is *. as the terminal name, while in certs, it's more >>> like shell wildcards, abc*.example.com matches what it looks like. I >>> verified that this isn't a bug, in that the description of cert >>> wildcards in RFC 6125 is deliberately different and matches what >>> browsers do. >> >> I'm surprised that you've verified that, in that my understanding is >> that no browser for many years has supported abc*.example.com (or, for >> that matter, foo.*.example.com). This is why you don't see them in the >> wild. Do you have evidence to the contrary? >> > Browsers are only one type of user agent. Indeed so. But he said "matches what browsers do", not "matches what user agents do". I admit I have much less insight into the behaviour of non-browser user agents. I would still be interested in the names of current bits of software which recognise "abc*.example.com" or similar. Gerv From nobody Mon Jun 15 01:28:52 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 12B041B3421 for ; Mon, 15 Jun 2015 01:28:51 -0700 (PDT) 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 tl45SrAAyePb for ; Mon, 15 Jun 2015 01:28:49 -0700 (PDT) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) (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 691AD1B3420 for ; Mon, 15 Jun 2015 01:28:49 -0700 (PDT) Received: by igbsb11 with SMTP id sb11so45353460igb.0 for ; Mon, 15 Jun 2015 01:28:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=j1CVllQ4TIj02/zBFqnBiFqvvI+VyBCiJ9mi+d++6/w=; b=LW96qqIM+DBXIvVi2HxDN88qjWkVc26ASUCOVsNDX1SFKG/blXm4b14lOuXAhj6dO2 xVaMucp3R3F6v4UXof173nf1DxT7sWlCRwOdi9tQzuubT4sylLsueIz6TKOeehl/pQEB iA1q/KhntJ9uekW+IAMNIHwC0nMdxKM6SMS8PHrmTgu6IKDo+8x5Oxddygjls9xiui3t 2bdxfrT8k3B5rB1pR9nllKWATGHfoZDLcJqso2OepeIvryrQDwmyV2n6iHJAF0gT0u1J AJMvhns1OqHOTMKX4zoI/fSnI4/UCazy10qhDUNSaeOjDk1GMMP1+9waolWLuzmgN4FE wV9g== MIME-Version: 1.0 X-Received: by 10.107.25.199 with SMTP id 190mr15060869ioz.11.1434356928875; Mon, 15 Jun 2015 01:28:48 -0700 (PDT) Received: by 10.36.77.15 with HTTP; Mon, 15 Jun 2015 01:28:48 -0700 (PDT) In-Reply-To: <557E8A87.1020607@mozilla.org> References: <20150615013640.26782.qmail@ary.lan> <557E845E.3070608@mozilla.org> <557E8A87.1020607@mozilla.org> Date: Mon, 15 Jun 2015 04:28:48 -0400 Message-ID: From: Jeffrey Walton To: Gervase Markham Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "dbound@ietf.org" Subject: Re: [dbound] Certificate wildcards vs. DNS wildcards X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: noloader@gmail.com List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2015 08:28:51 -0000 >>> I'm surprised that you've verified that, in that my understanding is >>> that no browser for many years has supported abc*.example.com (or, for >>> that matter, foo.*.example.com). This is why you don't see them in the >>> wild. Do you have evidence to the contrary? >>> >> Browsers are only one type of user agent. > > Indeed so. But you said "matches what browsers do", not "matches what > user agents do". > > I admit I have much less insight into the behaviour of non-browser user > agents. I would still be interested in the names of current bits of > software which recognise "abc*.example.com" or similar. OpenSSL has an option to match multiple wildcards at any label, and not just the leftmost label. And by default, it matches partials. See X509_check_host (3) (https://www.openssl.org/docs/crypto/X509_check_host.html) man pages. (Sorry if the terseness made it sound argumentative. That was not the point). Jeff From nobody Mon Jun 15 01:51:41 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 005C91B343F for ; Mon, 15 Jun 2015 01:51:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.622 X-Spam-Level: X-Spam-Status: No, score=0.622 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, HTML_MESSAGE=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 7esv1lxbzRJu for ; Mon, 15 Jun 2015 01:51:38 -0700 (PDT) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) (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 6C9C31B343A for ; Mon, 15 Jun 2015 01:51:38 -0700 (PDT) Received: by lbbtu8 with SMTP id tu8so49089342lbb.2 for ; Mon, 15 Jun 2015 01:51:37 -0700 (PDT) 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=G3+tUekOyohBGjsNFsqCKGc9ZGSz+7oD7/oCCmDBSDM=; b=e668XlpOm5evS5E+TMgfZDk3YIa6iyTn+OJOwuxwCeUetJXIrgBNxxyokX2oFq86Tx ZZGhG8HfxcKBZYbKVjO75SplpEMNQQypIufbEVY4abD20whzuLSm6+fuj5VoipcT32LL deoo5SPBo6gPjLSQEb2sTyv1CIYD/ZkCdXqxqMT9udXvN2TVEGvUDIqK3mJLYnSjP3I6 pSj5Grp0dYLyJDy6Q1IgiM/LCw7g6hOub+aoH1gUIKMknZt9gjd8BBCc4YrcK+znnaO0 GE+a4evSZsZphw5NlDfrh0gQ+Apiz9PEbMCTTJJ/xMOzpu2SA92IHTD6Gz80lC66k53e 0k7w== MIME-Version: 1.0 X-Received: by 10.152.26.106 with SMTP id k10mr19290724lag.13.1434358296960; Mon, 15 Jun 2015 01:51:36 -0700 (PDT) Sender: tomosann@gmail.com Received: by 10.25.143.212 with HTTP; Mon, 15 Jun 2015 01:51:36 -0700 (PDT) In-Reply-To: <557E8A87.1020607@mozilla.org> References: <20150615013640.26782.qmail@ary.lan> <557E845E.3070608@mozilla.org> <557E8A87.1020607@mozilla.org> Date: Mon, 15 Jun 2015 17:51:36 +0900 X-Google-Sender-Auth: KWknk2cP52GMJTic5-ZnDjU3CNE Message-ID: From: Tomoyuki Sahara To: Gervase Markham Content-Type: multipart/alternative; boundary=089e0160b4fec5669705188a904b Archived-At: Cc: noloader@gmail.com, "dbound@ietf.org" Subject: Re: [dbound] Certificate wildcards vs. DNS wildcards 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, 15 Jun 2015 08:51:40 -0000 --089e0160b4fec5669705188a904b Content-Type: text/plain; charset=UTF-8 Hi, I admit I have much less insight into the behaviour of non-browser user > agents. I would still be interested in the names of current bits of > software which recognise "abc*.example.com" or similar. > Current versions of Python3, Ruby, and curl allow such wildcards and try partial matching. LibreSSL does not. https://hg.python.org/cpython/file/f4b4e23475d0/Lib/ssl.py#l194 https://github.com/ruby/ruby/blob/trunk/ext/openssl/lib/openssl/ssl.rb#L200 https://github.com/bagder/curl/blob/master/lib/hostcheck.c#L60 Thanks, Tomoyuki --089e0160b4fec5669705188a904b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I admit I have much less insight into the behaviour of non-browser user
agents. I would still be interested in the names of current bits of
software which recognise "abc*.example.com" or similar.

Current versions of Python3, Ruby, and curl allow s= uch wildcards
--089e0160b4fec5669705188a904b-- From nobody Mon Jun 15 05:49: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 742381B35BA for ; Mon, 15 Jun 2015 05:49:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 KrxCleifcbLM for ; Mon, 15 Jun 2015 05:49:55 -0700 (PDT) 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 48E141B35B6 for ; Mon, 15 Jun 2015 05:49:53 -0700 (PDT) Received: (qmail 83411 invoked from network); 15 Jun 2015 12:50:01 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=145d2.557ec9f9.k1506; bh=QPYXKk0DB/4JIscLOqFdHwwmrXn0fgz2fLbndH/rdoA=; b=KCRDkyvcH9uerckvRNBl8rpPfUqqgtpCUEFxAhNm4PfOP9/AiyqjZ6J0xizoAHFlhgL4qauMgB4wRk6GPumDc72X7d0X4lgvcW2HrGzftpplPanxO8v1f+M4VQdFRMZvJeKMzWkMPsZkrdDBpvU6rfoaEuAb8VpOx6rVl/iVYDgu1Uuu8/XgdAhuK5HchjpelBpILBUFtAelI/fw+RWIHzt2LV5GM4aTtNwvhuRfbeFxwyha39efFTbMz4B1oV/P DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=145d2.557ec9f9.k1506; bh=QPYXKk0DB/4JIscLOqFdHwwmrXn0fgz2fLbndH/rdoA=; b=FHCYlsQOZ7ZrGzgdKhxI3mxqf0KcFE5vViZ6oTs8IK/UVkO0UiWf+z6wfNMteLrAjqDpkC3nEfrzBzLsOX8DfuIGyLK1vlOmRQrA/tHIyle33fNlaKL/bbczmbtgbB46nwqT9cZNjikox2ubDstHQFT4P4HnTtfC3AhRgjZnfjKposZ7f5deNwdm2GRxU5lt5jy5mMtjS9AoJT0oMVmx8DwGZYammHIXeteSerJa2bqo0yPrcTUH+3k2kP99c+Jm Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 15 Jun 2015 12:50:01 -0000 Date: 15 Jun 2015 08:49:51 -0400 Message-ID: From: "John R Levine" To: "Gervase Markham" In-Reply-To: <557E845E.3070608@mozilla.org> References: <20150615013640.26782.qmail@ary.lan> <557E845E.3070608@mozilla.org> User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: dbound@ietf.org Subject: Re: [dbound] Certificate wildcards vs. DNS wildcards 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, 15 Jun 2015 12:49:56 -0000 > I'm surprised that you've verified that, in that my understanding is > that no browser for many years has supported abc*.example.com (or, for > that matter, foo.*.example.com). This is why you don't see them in the > wild. Do you have evidence to the contrary? No, but the spec says what it says. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Mon Jun 15 05:57:13 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 C51201B2D0E for ; Mon, 15 Jun 2015 05:57:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 EeD3JzrbZaW5 for ; Mon, 15 Jun 2015 05:57:10 -0700 (PDT) Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com [209.85.212.169]) (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 A858F1B2D0C for ; Mon, 15 Jun 2015 05:57:10 -0700 (PDT) Received: by wiga1 with SMTP id a1so76727408wig.0 for ; Mon, 15 Jun 2015 05:57:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:openpgp:message-id :date:user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=MWTVFE7hILIJeqvj9lLaeNVe3nd9XAJhTru55MaW8Rc=; b=ITzpxyqyewQH0VXKFGg15M382qw90HSlm7JRb39jQnGlLTxShioysZ3C1tz9EN1bAr quDKxLYRLu3Bw7ES+nmb1zyhVc4InNpO+cA8lQHdu1C+q/6KOxDNTZu6h7+PXBmsMDhT 1fZ4bHM0ARwiJCyq7uMSzsWkj7JiYLqhb+pMu8k0Xy9YSSEzTGX/m0h73nR349xfglXd GuxC1t945bnE7vLEn4GEWa+e4prL+PNyjCi0L8Dyt11oRsVQHKrWknEojwKlp2Vz9Hnl y9RGyVCGSVOCpC7Rxpax09y5ZahVRsDOJhYnYZNR6BMeVOjMsoGSvoI8q7GmTedqViJ0 inRA== X-Gm-Message-State: ALoCoQlAlFC1FTlUdDVJMQuNnArhc2uevZVGGnAZi8xCXV510teNQvRqdqT8/MdPhnYT6wxVNdsu X-Received: by 10.194.200.194 with SMTP id ju2mr50336435wjc.61.1434373029303; Mon, 15 Jun 2015 05:57:09 -0700 (PDT) Received: from [192.168.0.103] (fpc2-shef11-2-0-cust7.17-1.static.cable.virginm.net. [94.173.170.136]) by mx.google.com with ESMTPSA id df1sm15780808wib.12.2015.06.15.05.57.07 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 15 Jun 2015 05:57:08 -0700 (PDT) To: John R Levine References: <20150615013640.26782.qmail@ary.lan> <557E845E.3070608@mozilla.org> From: Gervase Markham Openpgp: id=EEDEEFF962E97696DACBD2CCD9B347EA9DF43DBB X-Enigmail-Draft-Status: N1110 Message-ID: <557ECBA3.5030803@mozilla.org> Date: Mon, 15 Jun 2015 13:57:07 +0100 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: dbound@ietf.org Subject: Re: [dbound] Certificate wildcards vs. DNS wildcards 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, 15 Jun 2015 12:57:12 -0000 On 15/06/15 13:49, John R Levine wrote: >> I'm surprised that you've verified that, in that my understanding is >> that no browser for many years has supported abc*.example.com (or, for >> that matter, foo.*.example.com). This is why you don't see them in the >> wild. Do you have evidence to the contrary? > > No, but the spec says what it says. Indeed it does; but you made claims both about the spec (which are right) and about browser behaviour (which are wrong). https://bugzilla.mozilla.org/show_bug.cgi?id=159483#c11 and many related bugs. Gerv From nobody Mon Jun 15 12:09:30 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 EB3831A8779 for ; Mon, 15 Jun 2015 12:09:29 -0700 (PDT) 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 c0b_jNW9hq13 for ; Mon, 15 Jun 2015 12:09:29 -0700 (PDT) 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 E707B1A8731 for ; Mon, 15 Jun 2015 12:09:28 -0700 (PDT) Received: (qmail 66386 invoked from network); 15 Jun 2015 19:09:37 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 15 Jun 2015 19:09:37 -0000 Date: 15 Jun 2015 19:09:05 -0000 Message-ID: <20150615190905.30742.qmail@ary.lan> From: "John Levine" To: dbound@ietf.org In-Reply-To: <557E8A87.1020607@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] Certificate wildcards vs. DNS wildcards 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, 15 Jun 2015 19:09:30 -0000 >Indeed so. But you said "matches what browsers do", not "matches what >user agents do". Indeed, you're right. As we say, so sue me. We appear to be in agreement with the conclusion that although non-DNS wildcards are allowed, they are very uncommon in practice. R's, John From nobody Mon Jun 15 16:40: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 49CFA1B30CE for ; Mon, 15 Jun 2015 16:40:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 7Z1RmfWNeBjh for ; Mon, 15 Jun 2015 16:39:58 -0700 (PDT) Received: from tus1smtoutpex02.symantec.com (tus1smtoutpex02.symantec.com [216.10.195.242]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE9761B30C7 for ; Mon, 15 Jun 2015 16:39:58 -0700 (PDT) X-AuditID: d80ac3f2-f79b26d00000724a-69-557f624d50a2 Received: from ecl1mtahubpin02.ges.symantec.com (ecl1mtahubpin02.ges.symantec.com [10.48.69.202]) by tus1smtoutpex02.symantec.com (Symantec Brightmail Gateway out) with SMTP id 40.D2.29258.D426F755; Tue, 16 Jun 2015 00:39:57 +0100 (BST) Received: from [155.64.220.138] (helo=TUS1XCHHUBPIN02.SYMC.SYMANTEC.COM) by ecl1mtahubpin02.ges.symantec.com with esmtp (Exim 4.76) (envelope-from ) id 1Z4dyt-00071k-TJ; Mon, 15 Jun 2015 19:39:55 -0400 Received: from TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM ([155.64.220.146]) by TUS1XCHHUBPIN02.SYMC.SYMANTEC.COM ([155.64.220.138]) with mapi; Mon, 15 Jun 2015 16:39:33 -0700 From: Rick Andrews To: Tomoyuki Sahara , Gervase Markham Date: Mon, 15 Jun 2015 16:39:48 -0700 Thread-Topic: [dbound] Certificate wildcards vs. DNS wildcards Thread-Index: AdCnnX4r4BKFHn8fQkuceMiG1IUvaQAJv9Dg Message-ID: <544B0DD62A64C1448B2DA253C011414615B193DD80@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> References: <20150615013640.26782.qmail@ary.lan> <557E845E.3070608@mozilla.org> <557E8A87.1020607@mozilla.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_01EF_01D0A789.E40C64C0" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphleLIzCtJLcpLzFFi42LhMnA9peubVB9q0HhL12LX5WvsFnt2XGOy 2PNoC4vFn6ntzA4sHjtn3WX3WLLkJ5PH6ktXWD0+z53HHMASxWWTkpqTWZZapG+XwJXx+dM7 1oJDRRUzpj9iamB8mN3FyMEhIWAiMee8ZxcjJ5ApJnHh3nq2LkYuDiGBd4wS/9ecYIFwXjFK 9L5ZCJVZxSix/NAMNpAWNgE9iS2Pr7CD2CICnhJd2xYygUxlFgiRePNTHSTMIqAqcXHZMmYQ W1jAVuLem31sEOV2Eh1floKViwgYScxcXwMS5hWIkni+Yz07xKoGJomvPf/AxnMKBEq0vdkJ 1ssIdOn3U2uYQGxmAXGJW0/mM0F8ICLx8OJpNghbVOLl43+sEPWiEnfa1zOCDGUW6GWUePJ5 FiPENkGJkzOfsExgFJuFZNYsZHWzkNRBFEVLLG1uZISwtSWe3nwKFZeX2P52DvMssP+1JBbP 8oQpWbbwNTOEbS0x49dBNghbUWJK90N2CNtU4vXRj4wLGLlXMcqUlBYbFueW5JeWFKRWGBjp FVfmJgJTQ7Jecn7uJkZgerjBdfjTDsaZex0PMQpwMCrx8MqF1IcKsSaWAVUeYlQBGvdow+oL jFIsefl5qUoivE4WQGnelMTKqtSi/Pii0pzU4kOM0hwsSuK8toZVoUIC6YklqdmpqQWpRTBZ Jg5OqQbGjqiu0/NT5k61Pab86HvI/TXBUwpO/Ks82dETK7DNWuWMWGrfwwS1vLBFKZf5nujm etiVzpv+Y2P1+r27tR1ttFXu7ZAy6VwjV+zFl1Gxam6z2p3suRqT1jw9crRpee6qxLTYeeo3 b1c63T9WlpJ3yoNvodj31I8FLJzWb5+ti/235l2EnNJ7JZbijERDLeai4kQAOhXslxcDAAA= Archived-At: Cc: "noloader@gmail.com" , "dbound@ietf.org" Subject: Re: [dbound] Certificate wildcards vs. DNS wildcards 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, 15 Jun 2015 23:40:00 -0000 ------=_NextPart_000_01EF_01D0A789.E40C64C0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_01F0_01D0A789.E40C64C0" ------=_NextPart_001_01F0_01D0A789.E40C64C0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Also Windows SChannel supports those wildcards: http://support.microsoft.com/kb/258858 -Rick From: Tomoyuki Sahara [mailto:sahara@surt.net] Sent: Monday, June 15, 2015 1:52 AM To: Gervase Markham Cc: noloader@gmail.com; dbound@ietf.org Subject: Re: [dbound] Certificate wildcards vs. DNS wildcards Hi, I admit I have much less insight into the behaviour of non-browser user agents. I would still be interested in the names of current bits of software which recognise "abc*.example.com" or similar. Current versions of Python3, Ruby, and curl allow such wildcards and try partial matching. LibreSSL does not. https://hg.python.org/cpython/file/f4b4e23475d0/Lib/ssl.py#l194 https://github.com/ruby/ruby/blob/trunk/ext/openssl/lib/openssl/ssl.rb#L200 https://github.com/bagder/curl/blob/master/lib/hostcheck.c#L60 Thanks, Tomoyuki ------=_NextPart_001_01F0_01D0A789.E40C64C0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Also Windows SChannel supports those wildcards: http://support.microsoft.= com/kb/258858

 

-Rick

 

From:= = Tomoyuki Sahara [mailto:sahara@surt.net]
Sent: Monday, June = 15, 2015 1:52 AM
To: Gervase Markham
Cc: = noloader@gmail.com; dbound@ietf.org
Subject: Re: [dbound] = Certificate wildcards vs. DNS wildcards

 

Hi,

 

I admit I have much less insight into the = behaviour of non-browser user
agents. I would still be interested in = the names of current bits of
software which recognise "abc*.example.com" or = similar.

 

Current versions of = Python3, Ruby, and curl allow such wildcards

and try partial = matching.  LibreSSL does not.

 

 

 

Thanks,

Tomoyuki

 

<= /div> ------=_NextPart_001_01F0_01D0A789.E40C64C0-- ------=_NextPart_000_01EF_01D0A789.E40C64C0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRhzCCBBkw ggMBAhBhcMtJjF+YRSnnsKbZUFt6MA0GCSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4 BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkx RTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHMzAeFw05OTEwMDEwMDAwMDBaFw0zNjA3MTYyMzU5NTlaMIHKMQswCQYDVQQG EwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQg dXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlm aWNhdGlvbiBBdXRob3JpdHkgLSBHMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK8K DcLVLNtnuS3llCfdpb7gsE2Ps2FWPNZ8w/TNPobLooji4dikacW14r/BpkdQXkY5i9WWurVvFL8Q zicTngVHmzF6E9gf2dMCN4utLEfwjoEGpw0wDOv3PA8gHdxyRu6lAshbw8lWaUzFGMGRewvVEwCb vO/DSD5GYCCFKtWQts2LoMwy3bf9QFWyUBxWrsyNd03HIE2nMXbvaJKKkB4IgVayrWmjUtDLHMQj PR+Z/kzoFmOOxgiO9jH20vrldt21HJKjSc3NAc1ozalpuqPrHQ2cpCCmwaDF0UZMF23SrGY/lozg hNQ2/yJZxfkRYKhfBH3yGvYlQmEPxEq4PokCAwEAATANBgkqhkiG9w0BAQUFAAOCAQEANCYVPMCN TUNJHb3pIZLXZpy33sW40ORdX3YiwCb5hDo6+Yy1++xg8ejOBLDI3acDjzDzmN+k5qQx39McC0bc ciA/ru4FPKQzPws5rHB4c0uZK98wwlSwqDtVof4WKM1CvXRugNsnRKfORF3UG5CYDR5ClLEALATQ dKMCBSJjY82DtfvBbWJraXX9XXBBufW/fN++wTJzIiGLWIF7FZF6uuNkSLB/+zYl2pXQ8SQUF90Y gGtGIzlU9Y5iCQQdlJCmm+Yl4kJFqriQrb4Ij6kLQhiUz3I54bFD4CjPt+dabBNrSbP/4xh8iYsz Xawz16f52jpVyVgQ+arvWrbPS0vfKjCCBkwwggU0oAMCAQICEBw3Lcu5cD5rtz7z+tELQgYwDQYJ KoZIhvcNAQELBQAwgcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24s IEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3Mg MiBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTE1MDEwNjAw MDAwMFoXDTI1MDEwNTIzNTk1OVowgbAxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBD b3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazE1MDMGA1UECxMsQ2xh c3MgMiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0ExKjAoBgNVBAMTIVN5bWFu dGVjIENsYXNzIDIgRW1wbG95ZWUgQ0EgLSBHMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALbX9Fd7nt9wUT7ISGRoQMGJbj8EkkrtHHQnINo4z1KTPLnRWscXLT5oTmFpC7JuaHn0AnYK +NJutht+e0vGtU/avfhJDgLP7K1qZ+vOBHm9hMzzmiME1s9CP0nOlifrJK5h2TS5Znq8g4kfGJTA asB5zmfjNVCJomx17jhf8fuZrvMXSBsWDxl6NGohZloUgxFAwrCe0NuDzt8E8jJCgw5lewsqjlll eBvJbCxOXhcuMvjK6/ilNC1WjkaIlTWXyaraGQAMPm2nsZED4+aBNRMX855Amtk5zAoKh1oeIiN7 2YaPVmiIIOeGKqY0B3RYTY7cmxgU4RA5xgKA3LeMIP0CAwEAAaOCAkQwggJAMBIGA1UdEwEB/wQI MAYBAf8CAQAwbAYDVR0gBGUwYzBhBgtghkgBhvhFAQcXAjBSMCYGCCsGAQUFBwIBFhpodHRwOi8v d3d3LnN5bWF1dGguY29tL2NwczAoBggrBgEFBQcCAjAcGhpodHRwOi8vd3d3LnN5bWF1dGguY29t L3JwYTAOBgNVHQ8BAf8EBAMCAQYwNwYIKwYBBQUHAQEEKzApMCcGCCsGAQUFBzABhhtodHRwOi8v cGtpLW9jc3Auc3ltYXV0aC5jb20wNwYDVR0fBDAwLjAsoCqgKIYmaHR0cDovL2NybC53cy5zeW1h bnRlYy5jb20vcGNhMi1nMy5jcmwwKAYDVR0RBCEwH6QdMBsxGTAXBgNVBAMTEFN5bWFudGVjUEtJ LTItMjMwHQYDVR0OBBYEFKQzr7DDRoer5XhJsrTiRp/qCfwVMIHwBgNVHSMEgegwgeWhgdCkgc0w gcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3Ig YXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMiBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczghBhcMtJjF+YRSnnsKbZUFt6MA0GCSqG SIb3DQEBCwUAA4IBAQChthp96rPOdkvEEfo4yk4Q8auHf5LqUJUlwDdoAvuCrYDLM9TMQzCwRWf7 IpiGPMAVnddFj2ohiX3bYd0tkaqyjfDJDtZQK9YgN5GD0RTO2gHS0PHOOyJBSDJ5G0um4NLofhkB h9RqEE3mBF68RGe4Te7Z5ST+pvgqGzC8v/2xDEZcClXhch8gNU7muFl18YdX9gWV54BcTj0lo9E9 9/2HVCPB5QAzFhHqgHjDnETpw5S3JlpKTEMXyqaWd/5+Vo+ID+jd51HS+BS1u2Dguv+FvgINTVrr IO1ymEh5L3XM4gQrCgD7yajPRf/BIjyF/xzL/ONUoxd8e1gR/E1N98oyMIIHFjCCBf6gAwIBAgIQ OVrt7EotOiYavftZTf7D7jANBgkqhkiG9w0BAQsFADCBsDELMAkGA1UEBhMCVVMxHTAbBgNVBAoT FFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMTUw MwYDVQQLEyxDbGFzcyAyIE1hbmFnZWQgUEtJIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTEqMCgG A1UEAxMhU3ltYW50ZWMgQ2xhc3MgMiBFbXBsb3llZSBDQSAtIEczMB4XDTE1MDYwNTAwMDAwMFoX DTE2MDYwNDIzNTk1OVowWDEdMBsGA1UECgwUU3ltYW50ZWMgQ29ycG9yYXRpb24xIDAeBgNVBAsM F1N5bWFudGVjIEVtcGxveWVlIEVtYWlsMRUwEwYDVQQDDAxSaWNrIEFuZHJld3MwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQDMkzz3/cxC5IPK1PgEVnb2v6HNo5VaRHC5nKGTtKfmdl58 yBdBK4SJwGSIHiQsIgItAQc4mmd7MUIQOxt5RN7dCFMDFzxbSF0nIl1GR52WzN8mgVE9+6oMxDKN 5LOckMEKNH13NF7Ebjz/p0v0JaRHEuzG4w12ah3B8GkBKJn0XDRJjZNq1R/fJJxklUWsQcimw7S5 bb9bGQwCipDGDn1WLaXP1UWDqyP/ja6OYyKY3QFlk1olDk5iZ5XipSiX57euk9FigV4Ddu6gsVaE hQR/mZNcNag1rH/RjcVoox7iTgvKxyBh3VVT2dEX4vebLdt2/rwIgz626XDSTeUmJQ+ZAgMBAAGj ggOBMIIDfTAMBgNVHRMBAf8EAjAAMA4GA1UdDwEB/wQEAwIFoDAWBgNVHSUBAf8EDDAKBggrBgEF BQcDBDAdBgNVHQ4EFgQUVoVKaC1xEPB9EWKq3dWrwskIufkwJAYDVR0RBB0wG4EZUmlja19BbmRy ZXdzQHN5bWFudGVjLmNvbTAfBgNVHSMEGDAWgBSkM6+ww0aHq+V4SbK04kaf6gn8FTCCAWQGCCsG AQUFBwEBBIIBVjCCAVIwJwYIKwYBBQUHMAGGG2h0dHA6Ly9wa2ktb2NzcC5zeW1hdXRoLmNvbTCC ASUGCCsGAQUFBzAChoIBF2xkYXA6Ly9kaXJlY3RvcnkudmVyaXNpZ24uY29tL0NOJTIwJTNEJTIw U3ltYW50ZWMlMjBDbGFzcyUyMDIlMjBFbXBsb3llZSUyMENBJTIwLSUyMEczJTJDJTIwT1UlMjAl M0QlMjBDbGFzcyUyMDIlMjBNYW5hZ2VkJTIwUEtJJTIwSW5kaXZpZHVhbCUyMFN1YnNjcmliZXIl MjBDQSUyQyUyME9VJTIwJTNEJTIwU3ltYW50ZWMlMjBUcnVzdCUyME5ldHdvcmslMkMlMjBPJTIw JTNEJTIwU3ltYW50ZWMlMjBDb3Jwb3JhdGlvbiUyQyUyMEMlMjAlM0QlMjBVUz9jQUNlcnRpZmlj YXRlO2JpbmFyeTBdBgNVHR8EVjBUMFKgUKBOhkxodHRwOi8vcGtpLWNybC5zeW1hdXRoLmNvbS9j YV8yYzc5ZDVmMGM0NTZlMGUzZTJmYjNlMjM2OTAzZGExNS9MYXRlc3RDUkwuY3JsMGwGA1UdIARl MGMwYQYLYIZIAYb4RQEHFwIwUjAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9j cHMwKAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9ycGEwQgYJKoZIhvcNAQkP BDUwMzAKBggqhkiG9w0DBzALBglghkgBZQMEAQIwCwYJYIZIAWUDBAEWMAsGCWCGSAFlAwQBKjAr BgpghkgBhvhFARADBB0wGwYSYIZIAYb4RQEQAQICAQGdpPp0FgUxNjc0ODA5BgpghkgBhvhFARAF BCswKQIBABYkYUhSMGNITTZMeTl3YTJrdGNtRXVjM2x0WVhWMGFDNWpiMjA9MA0GCSqGSIb3DQEB CwUAA4IBAQAXM1lZbwfKyY8FFxOxBuM1zaVaoRHcKD6EjwhcTlIeFQSGl/n24G+1xpy6NIe7Mwzp EAwVUwzb3wKFyKnDMdDvPIedes3QyC1yIjA3ZViOLNpIhWmalth1ohXYFGjjLx7eAq6GJ7oorcJH ZCWOMNr4Nm82UlZ4WoOw1W9mU2ll9R4rfDxsWOImko7O0E9fvozhf4B224DA6cin71gk5rFzzzKC Knjv2lUSpjNuOmlcY2LFOIKPyFzpGKRikO/LwfWVsefhppBSRGKaxfbKS9QP8ex1IcZgGbdCTBzW t9u/tgGv8+qMCn347fdIwO3qFAFgGfJULuFLOvdwqtkJZ8CxMYIEsDCCBKwCAQEwgcUwgbAxCzAJ BgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50 ZWMgVHJ1c3QgTmV0d29yazE1MDMGA1UECxMsQ2xhc3MgMiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0ExKjAoBgNVBAMTIVN5bWFudGVjIENsYXNzIDIgRW1wbG95ZWUgQ0EgLSBH MwIQOVrt7EotOiYavftZTf7D7jAJBgUrDgMCGgUAoIICvzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xNTA2MTUyMzM5NDdaMCMGCSqGSIb3DQEJBDEWBBRG+D4RIVPa X2WxETKvzVS0mLOuWDCBqwYJKoZIhvcNAQkPMYGdMIGaMAsGCWCGSAFlAwQBKjALBglghkgBZQME ARYwCgYIKoZIhvcNAwcwCwYJYIZIAWUDBAECMA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBggq hkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjALBglghkgBZQMEAgMwCwYJYIZIAWUD BAICMAsGCWCGSAFlAwQCATCB1gYJKwYBBAGCNxAEMYHIMIHFMIGwMQswCQYDVQQGEwJVUzEdMBsG A1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxNTAzBgNVBAsTLENsYXNzIDIgTWFuYWdlZCBQS0kgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENB MSowKAYDVQQDEyFTeW1hbnRlYyBDbGFzcyAyIEVtcGxveWVlIENBIC0gRzMCEDla7exKLTomGr37 WU3+w+4wgdgGCyqGSIb3DQEJEAILMYHIoIHFMIGwMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3lt YW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxNTAzBgNV BAsTLENsYXNzIDIgTWFuYWdlZCBQS0kgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBMSowKAYDVQQD EyFTeW1hbnRlYyBDbGFzcyAyIEVtcGxveWVlIENBIC0gRzMCEDla7exKLTomGr37WU3+w+4wDQYJ KoZIhvcNAQEBBQAEggEAZJt8tonkv01KZwS1/Pr7aGSX2JDReWhn5FRR9aOu3uABzVOLzLZh24gd Fyv2xhrKG6wo2eiitNQ1h2Ht5PjHrR6SBjWGxbiAzQNs3PLxRaaqb+NTwQvWBVL0FF7ITDcs1D+q d5zitG6YpVd/WnUmt+mjfQj4qMwoI2rbt1FB+Q8iITT76HFHuZbF0X3TPfqyrdV4wMjSUlyKiTZw IxB11l34rvWxX721gRnN5Yy/aAWdVcopE2SFhc9TT6p0xOPYLfI2U86IOuuWOQIsfh6GXCKx+lye v7I0GpTBCK7tQS6epD4IeBozDS9XskmGAYwNSidzqYalOEwhJyMvUUkTOQAAAAAAAA== ------=_NextPart_000_01EF_01D0A789.E40C64C0-- From nobody Wed Jun 17 08:31:13 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 463091AD0A4 for ; Wed, 17 Jun 2015 08:31:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] 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 pYwUu_xwRs85 for ; Wed, 17 Jun 2015 08:31:09 -0700 (PDT) Received: from mx2.yitter.info (mx2.yitter.info [IPv6:2600:3c03::f03c:91ff:fedf:cfab]) by ietfa.amsl.com (Postfix) with ESMTP id CBC0B1AD0A1 for ; Wed, 17 Jun 2015 08:31:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx2.yitter.info (Postfix) with ESMTP id 5AB51105DB for ; Wed, 17 Jun 2015 15:31:09 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx2.yitter.info ([127.0.0.1]) by localhost (mx2.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PqNYvivoov6j for ; Wed, 17 Jun 2015 15:31:08 +0000 (UTC) Received: from anvilwalrusden.com (94.197.121.176.threembb.co.uk [94.197.121.176]) by mx2.yitter.info (Postfix) with ESMTPSA id C74521000F for ; Wed, 17 Jun 2015 15:31:07 +0000 (UTC) Date: Wed, 17 Jun 2015 16:31:04 +0100 From: Andrew Sullivan To: dbound@ietf.org Message-ID: <20150617153104.GD16823@anvilwalrusden.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: [dbound] Suggestion for Prague: let's try to converge on problem(s) 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, 17 Jun 2015 15:31:11 -0000 Hi, I've been trying to put together detailed comments on draft-deccio-domain-name-relationships-00, and to propose some changes to draft-sullivan-dbound-problem-statement-00. But I'm failing to get satisfying comments together, so sending this more general remark now because I think we still have some sort of fundamental gap in our collective understanding of what we're trying to do. I'd like to suggest we use some time in Prague to try to get this sorted out. In my reading, draft-deccio-domain-name-relationships-00 starts with a deep, fundamental division between "public" and (for want of a better term) "private" domain names. I think it starts there because the authors genuinely believe that the distinction is a fundamental one. In my opinion, that stance reifies a distinction that is implicit to the way the PSL has always worked into a distinction that is part of the world. For instance, to me it is extremely artifitcial to claim that the root zone and (say) the com zone are both "public" zones. The rules by which one gets an entry in the root zone are way more convoluted than the rules by which one gets an entry in the com zone. By the same token, the important relationship between (for example) co.uk and uk is not that they're both public, but the way the policy relationship between those domains works (and how it might evolve over time). My view is that this means we need a way to express these kinds of relationships, but that one thing we _must_ be able to capture (or perhaps emulate) the public/private distinction that is implicit in the PSL now. Part of the reason I keep harping on this is because, if we're merely going to produce a new way to express the same public/private distinction we have now, there will be poor incentives to use or deploy the new protocol. It imposes some costs, and if you don't get anything better than the mechanism you already have then the additional work will never be worth it. But the problem is, I think, that our use cases suggest that PSL has been embraced because it's the closest available, rather than being close enough. I'd like to spend the time we have in Prague really hashing the rest of the details of what problems we're really trying to work on, what ones are must-haves vs. nice to haves, and to prioritize the nice to have cases in order to understand how we can make trade-offs. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Wed Jun 17 10:38:19 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 33A371B2BE0 for ; Wed, 17 Jun 2015 10:38:13 -0700 (PDT) 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 d5S2ZfcSTNrK for ; Wed, 17 Jun 2015 10:38:12 -0700 (PDT) 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 07B501B2BD6 for ; Wed, 17 Jun 2015 10:38:11 -0700 (PDT) Received: (qmail 82241 invoked from network); 17 Jun 2015 17:38:20 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 17 Jun 2015 17:38:20 -0000 Date: 17 Jun 2015 17:37:48 -0000 Message-ID: <20150617173748.74404.qmail@ary.lan> From: "John Levine" To: dbound@ietf.org In-Reply-To: <20150617153104.GD16823@anvilwalrusden.com> 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] Suggestion for Prague: let's try to converge on problem(s) 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, 17 Jun 2015 17:38:13 -0000 >In my reading, draft-deccio-domain-name-relationships-00 starts with a >deep, fundamental division between "public" and (for want of a better >term) "private" domain names. I think it starts there because the >authors genuinely believe that the distinction is a fundamental one. I share your concern and agree with the implication this jumps to places we don't necessarily want to be. It seems to me more useful to look at the questions are currently answering using the PSL, and the kinds of answers: * Should I accept a cookie at this name? (domain -> yes/no) * Should I sign an SSL cert at this name? (domain -> yes/no) * Should I sign a wildcard SSL cert under this name? (domain -> yes/no) * Where is the DMARC record for this name? (domain -> domain) * Are these two names under the same control? (domain x domain -> yes/no) The fact that the questions and answers aren't even all of the same type should offer a hint that the structure is more complicated. R's, John From nobody Wed Jun 17 11:20: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 259AD1B2CBC for ; Wed, 17 Jun 2015 11:20:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 RR04FOCfRbzJ for ; Wed, 17 Jun 2015 11:20:33 -0700 (PDT) Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) (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 550F31B2CB4 for ; Wed, 17 Jun 2015 11:20:33 -0700 (PDT) Received: by wicnd19 with SMTP id nd19so91533195wic.1 for ; Wed, 17 Jun 2015 11:20:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:openpgp:message-id :date:user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=ZMEfrcmTqDUjjfilYi/monuz4L1TfxNn1MXvlzyUPkQ=; b=QXwXVTpjmRqDbHOcIeoVtwrsIOZJBG7XFlYFOLval0vnguS88xakURJ1ScbGeD5+eo FkFRc3tu9z8sNSpAjZP7AfM0mkjoM2zGnpZhPYMrWOxOL/xTd5Ns3yEzAK+MmG2a4W/j +HDLFWALDrX6sum1wf4lbkudcNQPNP8T6DQpPJ3p+1wMBFsrpj6xTgfbc8klGiyWzXP9 oR5iIdG//PHFrghBW9ksSOV2bQuCnUkidVTouVdeMlmk/JYwlQItyyryKyjN27T+egtu 9111P7WLMzYy98Yy0JvNGzuZ4c1pcpDgmhzK15oX0GvQ3+ECm1vM4yJ9/nOQtxPD3iqG G2JQ== X-Gm-Message-State: ALoCoQmD9aHv4K12oEK7EPka2AzONB91mjO4rlyOrg12Mju7LvGyF6NP3qQaq3oStNwplBh/zZr2 X-Received: by 10.180.109.136 with SMTP id hs8mr19948115wib.73.1434565232019; Wed, 17 Jun 2015 11:20:32 -0700 (PDT) Received: from [192.168.1.119] (host86-158-54-213.range86-158.btcentralplus.com. [86.158.54.213]) by mx.google.com with ESMTPSA id jy6sm3234232wjc.4.2015.06.17.11.20.30 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 17 Jun 2015 11:20:31 -0700 (PDT) To: John Levine , dbound@ietf.org References: <20150617173748.74404.qmail@ary.lan> From: Gervase Markham Openpgp: id=EEDEEFF962E97696DACBD2CCD9B347EA9DF43DBB X-Enigmail-Draft-Status: N1110 Message-ID: <5581BA6D.3090009@mozilla.org> Date: Wed, 17 Jun 2015 19:20:29 +0100 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.0 MIME-Version: 1.0 In-Reply-To: <20150617173748.74404.qmail@ary.lan> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: ajs@anvilwalrusden.com Subject: Re: [dbound] Suggestion for Prague: let's try to converge on problem(s) 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, 17 Jun 2015 18:20:35 -0000 On 17/06/15 18:37, John Levine wrote: > * Should I accept a cookie at this name? (domain -> yes/no) > > * Should I sign an SSL cert at this name? (domain -> yes/no) Again, the PSL does not give a yes/no answer to this question. It gives a "yes if everything else checks out/probably not but check carefully" answer. The real answer depends on factors external to both the PSL and the DNS. Gerv From nobody Wed Jun 17 11:48:23 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 7A6E41A86F5 for ; Wed, 17 Jun 2015 11:48:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.521 X-Spam-Level: X-Spam-Status: No, score=0.521 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=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 u3vXxsq4dBAu for ; Wed, 17 Jun 2015 11:48:17 -0700 (PDT) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) (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 C3ED51A00CD for ; Wed, 17 Jun 2015 11:48:05 -0700 (PDT) Received: by iecrd14 with SMTP id rd14so40044371iec.3 for ; Wed, 17 Jun 2015 11:48:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=deccio.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mnW1GEg/3/yrOSFz4i9teqxvflCKMdiW/fbQwtweAGc=; b=iaq2U6jXF7ntPa/B6UO6reH1jlfusCtikg1yuNjLciTSUQhthhdPid9zkXcEs0SKsW if9Axu1BQf/yiEo3sB+9MgWbTuEEUFkgSpLDPVagbMS/XSqOY/KbbTG/fMWARRUSXz2G UaOuUwoVeE6v6qYC5iLY5xEe/daSDSREr1Vl4= 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:date :message-id:subject:from:to:cc:content-type; bh=mnW1GEg/3/yrOSFz4i9teqxvflCKMdiW/fbQwtweAGc=; b=G+GHVdxfai5XavKd7vdevGY4dhTuC8mddgJIQMtHx2fKO1h+Q2rZ69eEnC7HgPTs5b BXK6OAfzOXMokvgiZWKJh8TrG89ap2qWg5H7f+M+fvIejoSl0ruIIYnE3cUq+gFgrACZ tZOPDKca8cKgWwsJ8YQ53/6mdRFkW5kCk9C5rFy2Z7G+eVBVPWAfUYHTPVKbqyzA/6FI l9lhX0zdnpCDEfHMpbEMXpaBvtrDwhjhDKrIZUuzzs8uSbiLQl5Z0EbASA4l1TMJpNFL CSJqXyUaANLMVnYhWdBLMKuNl/LRsiXiNjPCIeGzVRxfcDv3btXmdZQty2gFGUCR8Hwj e/HQ== X-Gm-Message-State: ALoCoQlLRX1algwUAYGp8qrr+Dk/eHXNt59EQUE9tfBhpf+pIkqMIzxfqbSfrAshi6bhOTi3BykQ MIME-Version: 1.0 X-Received: by 10.50.78.170 with SMTP id c10mr13098366igx.0.1434566885275; Wed, 17 Jun 2015 11:48:05 -0700 (PDT) Received: by 10.50.178.162 with HTTP; Wed, 17 Jun 2015 11:48:05 -0700 (PDT) In-Reply-To: <20150617153104.GD16823@anvilwalrusden.com> References: <20150617153104.GD16823@anvilwalrusden.com> Date: Wed, 17 Jun 2015 14:48:05 -0400 Message-ID: From: Casey Deccio To: Andrew Sullivan Content-Type: multipart/alternative; boundary=089e0122e6889a95d60518bb2125 Archived-At: Cc: "dbound@ietf.org" Subject: Re: [dbound] Suggestion for Prague: let's try to converge on problem(s) 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, 17 Jun 2015 18:48:20 -0000 --089e0122e6889a95d60518bb2125 Content-Type: text/plain; charset=UTF-8 Hi Andrew, Well said and proposed. Some additional comments inline. On Wed, Jun 17, 2015 at 11:31 AM, Andrew Sullivan wrote: > In my reading, draft-deccio-domain-name-relationships-00 starts with a > deep, fundamental division between "public" and (for want of a better > term) "private" domain names. I think it starts there because the > authors genuinely believe that the distinction is a fundamental one. > In my opinion, that stance reifies a distinction that is implicit to > the way the PSL has always worked into a distinction that is part of > the world. > Part of my reasoning for writing this draft is that I believe that the fundamental division between (currently called) public and private names, brought to light by the PSL, is a great asset in solving this problem. Understanding that division--and properly defining it--can help with identifying solution(s). That is not to say that the PSL is 100% accurate in implementing this distinction, nor is the PSL sufficient for determining policies. I am well aware of that. However, I argue that a line can be drawn through the breadth of the DNS namespace tree, above which names are not to be associated with names below, as far as policy relationships are concerned--even if those names above and below the line are administered by the same entity. If such is not true, then the line needs to be moved up until it is. Solutions have been proposed to more generally associate names for policy. Something of that nature is probably necessary. However, the proposals I've read thus far come with considerable complexity and high risk of "getting it wrong". It's not to say that they wouldn't work, and perhaps they can be improved within the working group to lower that risk. But the point of the boundary I'm referring to (and implemented, to some extent, by the PSL) is to cover many (most?) cases by simply identifying this boundary where the names in question are in relation to that boundary. If something cannot be determined with this boundary, other, more specific mechanisms, can be used to supplement. If someone doesn't want to use this boundary at all, then they simply move the line up, effectively making it "opt-in/opt-out". In other words, while the PSL concept is incomplete, there is a lot of good in it, and the ideas can exist even alongside other DBOUND solutions, to provide "sufficient" means for domain name policy, where other complexity is neither additionally useful nor desired. > By the same token, the important relationship between (for example) > co.uk and uk is not that they're both public, but the way the policy > relationship between those domains works (and how it might evolve over > time). > This all depends on what you want to know about them. But I would argue that for many (most?) cases the fact that they're both public is "sufficient". > My view is that this means we need a way to express these kinds of > relationships, but that one thing we _must_ be able to capture (or > perhaps emulate) the public/private distinction that is implicit in > the PSL now. > > Part of the reason I keep harping on this is because, if we're merely > going to produce a new way to express the same public/private > distinction we have now, there will be poor incentives to use or > deploy the new protocol. It imposes some costs, and if you don't get > anything better than the mechanism you already have then the > additional work will never be worth it. > I'll reiterate here, that while draft-deccio-domain-name-relationships-00 discusses public/private boundaries, neither the draft nor I am encouraging a solution that merely produces a new way to express the same public/private distinction--only that the distinction can be used to lift the complexity burden of other, more heavy-handed solutions, so dismissing the current paradigm entirely in order to get it "right" with one silver bullet solution is probably not the right way to go. Cheers, Casey --089e0122e6889a95d60518bb2125 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Andrew,

Well said and proposed.<= br>
Some additional comments inline.

= On Wed, Jun 17, 2015 at 11:31 AM, Andrew Sullivan <ajs@anvilwalrusden= .com> wrote:
I= n my reading, draft-deccio-domain-name-relationships-00 starts with a
deep, fundamental division between "public" and (for want of a be= tter
term) "private" domain names.=C2=A0 I think it starts there becau= se the
authors genuinely believe that the distinction is a fundamental one.
In my opinion, that stance reifies a distinction that is implicit to
the way the PSL has always worked into a distinction that is part of
the world.

Part of my reasoning for wri= ting this draft is that I believe that the fundamental division between (cu= rrently called) public and private names, brought to light by the PSL, is a= great asset in solving this problem.=C2=A0 Understanding that division--an= d properly defining it--can help with identifying solution(s).=C2=A0 That i= s not to say that the PSL is 100% accurate in implementing this distinction= , nor is the PSL sufficient for determining policies.=C2=A0 I am well aware= of that.=C2=A0 However, I argue that a line can be drawn through the bread= th of the DNS namespace tree, above which names are not to be associated wi= th names below, as far as policy relationships are concerned--even if those= names above and below the line are administered by the same entity.=C2=A0 = If such is not true, then the line needs to be moved up until it is.
Solutions have been proposed to more generally associate names for policy.= =C2=A0 Something of that nature is probably necessary.=C2=A0 However, the p= roposals I've read thus far come with considerable complexity and high = risk of "getting it wrong".=C2=A0 It's not to say that they w= ouldn't work, and perhaps they can be improved within the working group= to lower that risk.=C2=A0 But the point of the boundary I'm referring = to (and implemented, to some extent, by the PSL) is to cover many (most?) c= ases by simply identifying this boundary where the names in question are in= relation to that boundary.=C2=A0 If something cannot be determined with th= is boundary, other, more specific mechanisms, can be used to supplement.=C2= =A0 If someone doesn't want to use this boundary at all, then they simp= ly move the line up, effectively making it "opt-in/opt-out".
<= br>
In other words, while the PSL concept is incomplete, there is= a lot of good in it, and the ideas can exist even alongside other DBOUND s= olutions, to provide "sufficient" means for domain name policy, w= here other complexity is neither additionally useful nor desired.
=
=C2=A0
By the same token, the important relationship between (for example)
co.uk and= uk is not that they're both public, but the way the policy
relationship between those domains works (and how it might evolve over
time).

This all depends on what you wan= t to know about them.=C2=A0 But I would argue that for many (most?) cases t= he fact that they're both public is "sufficient".
=C2=A0
My view is that this means we need a way to express these kinds of
relationships, but that one thing we _must_ be able to capture (or
perhaps emulate) the public/private distinction that is implicit in
the PSL now.

Part of the reason I keep harping on this is because, if we're merely going to produce a new way to express the same public/private
distinction we have now, there will be poor incentives to use or
deploy the new protocol.=C2=A0 It imposes some costs, and if you don't = get
anything better than the mechanism you already have then the
additional work will never be worth it.

I'll reiterate here, that while draft-deccio-domain-name-relationships= -00 discusses public/private boundaries, neither the draft nor I am encoura= ging a solution that merely produces a new way to express the same public/p= rivate distinction--only that the distinction can be used to lift the compl= exity burden of other, more heavy-handed solutions, so dismissing the curre= nt paradigm entirely in order to get it "right" with one silver b= ullet solution is probably not the right way to go.

Cheer= s,
Casey
--089e0122e6889a95d60518bb2125-- From nobody Fri Jun 19 02:19:53 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 451201A87C9 for ; Fri, 19 Jun 2015 02:19:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.769 X-Spam-Level: X-Spam-Status: No, score=0.769 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_SORBS_WEB=0.77] 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 2AvSnJOoIcwF for ; Fri, 19 Jun 2015 02:19:51 -0700 (PDT) Received: from mx2.yitter.info (mx2.yitter.info [IPv6:2600:3c03::f03c:91ff:fedf:cfab]) by ietfa.amsl.com (Postfix) with ESMTP id 3FDC71A87C3 for ; Fri, 19 Jun 2015 02:19:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx2.yitter.info (Postfix) with ESMTP id B7C96105DC for ; Fri, 19 Jun 2015 09:19:50 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx2.yitter.info ([127.0.0.1]) by localhost (mx2.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m5HERvnQ6vOA for ; Fri, 19 Jun 2015 09:19:50 +0000 (UTC) Received: from mx2.yitter.info (unknown [89.246.150.136]) by mx2.yitter.info (Postfix) with ESMTPSA id ABE511000E for ; Fri, 19 Jun 2015 09:19:49 +0000 (UTC) Date: Fri, 19 Jun 2015 11:19:47 +0200 From: Andrew Sullivan To: dbound@ietf.org Message-ID: <20150619091946.GD17513@mx2.yitter.info> References: <20150617153104.GD16823@anvilwalrusden.com> 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: Subject: Re: [dbound] Suggestion for Prague: let's try to converge on problem(s) 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: Fri, 19 Jun 2015 09:19:52 -0000 Hi, On Wed, Jun 17, 2015 at 02:48:05PM -0400, Casey Deccio wrote: > Part of my reasoning for writing this draft is that I believe that the > fundamental division between (currently called) public and private names, > brought to light by the PSL, is a great asset in solving this problem. Yes, I know, and that's exactly what we disagree about. I think that this simple division causes as much harm as benefit. > policies. I am well aware of that. However, I argue that a line can be > drawn through the breadth of the DNS namespace tree, above which names are > not to be associated with names below, as far as policy relationships are > concerned--even if those names above and below the line are administered by > the same entity. If such is not true, then the line needs to be moved up > until it is. And I am arguing that "a line" is a fundamental mistake. Moreover, in my view the idea that these are always or even primarily parent-child relationships is a serious error (but I recognise that that is a more controversial point of view). > they can be improved within the working group to lower that risk. But the > point of the boundary I'm referring to (and implemented, to some extent, by > the PSL) is to cover many (most?) cases by simply identifying this boundary > where the names in question are in relation to that boundary. I think we disagree about what the facts are here, because I don't think the evidence before us gives us a reason that this single boundary works today. I argue that this is not because the details in the PSL happen to be wrong (sometimes they are, but it's at least 80% good), but because the PSL or any other single-factor distinction is making a category mistake. I think that John's questions upthread are a much better foundation from which to proceed. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Fri Jun 19 06:55:24 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 EA5C21A0235 for ; Fri, 19 Jun 2015 06:55:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.723 X-Spam-Level: X-Spam-Status: No, score=0.723 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 ux9Y3MU87EWo for ; Fri, 19 Jun 2015 06:55:19 -0700 (PDT) Received: from mail-lb0-f178.google.com (mail-lb0-f178.google.com [209.85.217.178]) (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 D9ABB1A0210 for ; Fri, 19 Jun 2015 06:55:18 -0700 (PDT) Received: by lbbvz5 with SMTP id vz5so24573295lbb.0 for ; Fri, 19 Jun 2015 06:55:17 -0700 (PDT) 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:date :message-id:subject:from:to:cc:content-type; bh=yyu8RQ1NBGlObZ3U+8NO/8rtk7jezlE4EOsjSXqsoL0=; b=G6EhSmsVojSw1fzK5wsGnF0vw2PdzpLm0AheCKo6qIH6GHtyLcfpucOVLMkFBbsRU6 aEYWVoG6Gk0DbpAOSzJXA9wbF0Ao9GQ8q6lt5xlJ7qTnUQKVYTdVYxRuNXM77Nf6m2mI k8ZiZNhlObYSh4zhrY9QYvuqWd/aSrCR+uZxZ096aXFDU1OHBeue5Bhv+0TCuoEz1O1I zBcWXCiK7vIKJNqlFQbULhu3b/BINICs+wGJ606rQbStrh55zA9ElvTHXDnQiaXpYYRM Diu/vHIJi+JYQxWfAB4FknKmD7y1U2F3Phyz0yabyIQEGHS79+5wjwaPlNoD48qW+tjX +dpg== X-Gm-Message-State: ALoCoQkges7Uif2MDy5F4gQ7leRtxIHRw+vEuYxgbgsfE+t/mQsrqvwILH86WD+Ra++SYcxxfuHI MIME-Version: 1.0 X-Received: by 10.112.137.1 with SMTP id qe1mr17701939lbb.22.1434722116908; Fri, 19 Jun 2015 06:55:16 -0700 (PDT) Received: by 10.25.128.210 with HTTP; Fri, 19 Jun 2015 06:55:16 -0700 (PDT) In-Reply-To: <20150619091946.GD17513@mx2.yitter.info> References: <20150617153104.GD16823@anvilwalrusden.com> <20150619091946.GD17513@mx2.yitter.info> Date: Fri, 19 Jun 2015 06:55:16 -0700 Message-ID: From: Jothan Frakes To: Andrew Sullivan Content-Type: multipart/alternative; boundary=089e01182daa2152910518df4695 Archived-At: Cc: "dbound@ietf.org" Subject: Re: [dbound] Suggestion for Prague: let's try to converge on problem(s) 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: Fri, 19 Jun 2015 13:55:24 -0000 --089e01182daa2152910518df4695 Content-Type: text/plain; charset=UTF-8 I completely concur with John's more organic-friendly questions, and also agree that a simple line as a boundary is not the right approach. CONTEXT is absolutely important. If we iterated through John's cases, it clearly demonstrates how things can be different per namespace per context. Context of use case ABSOLUTELY matters and it changes where any theoretical boundary exists, and context might also alter where boundaries are defined within namespaces (or if they) should. I have tried to make a few captures of what we might benefit from including in thoughts and discussion around the problems to solve. I don't wish to prescribe any solution in doing so, it is just a brain dump mostly. As I re-read them, I notice that we might benefit from thinking about organizing them per context, vs per namespace, but again, I fear I may be being prescriptive. Parent/child It seems like parent-child relationship is important to "domain boundaries", but records reflecting these should come with associated context also documented, to define child(ren) suffixes Contexts There should also be flexibility to allow for multiple contexts and variance to where these boundaries are. Administrative errata Having a place to indicate some form of normalized information, such as Whois server address for domains in it Abuse poc Registry URL Registry policy URL Code points (If IDN) Etc. Apex It does seem important, in the context of apex of root authority, (and also registry) to demonstrate top down chains of parent-child relationships like might exist between "." and ".uk" or ".uk" and ".ac.uk", such that ".ac.uk" and be known to be part of an authoritative administrative chain, unbroken, within ".". I always seem to pick on Centralnic names, but this would be true of any subdomaining entity like Amazon AWS or Dyn, but having some way for .com.de or co.com to self-represent apex within their record somehow to establish that they are not within the top down apex from the root, but are expressing other contexts and records to indicate what is appropriate within these namespaces for cookie behavior, certificate issue, etc. In doing some form of element to show administrative apex, there needs to be care to do so in a manner that would not prejudice self-apex types that may not have a chain of authority from the parent (like Github, Dyn, Centralnic, Amazon. Etc) that are not administratively connected all the way up to the root delegation. A commentary about caution and why I am inclusive about representation for subdomain entities, is that I could see a registry potentially salivating over charging a registrant extra to obtain a special connection/license to subdomain. We should be careful about ensuring no disruption, financial, operational, or otherwise, to the operators of subdomain solutions, whatever we label them as. Equivalence if there were some way to add aliases for equivilence - such that PIR .ONG/.NGO or other similar situations where registry makes paired names available - that we could have some alias record that could reflect this, per context. -jothan On Friday, June 19, 2015, Andrew Sullivan wrote: > Hi, > > On Wed, Jun 17, 2015 at 02:48:05PM -0400, Casey Deccio wrote: > > > Part of my reasoning for writing this draft is that I believe that the > > fundamental division between (currently called) public and private names, > > brought to light by the PSL, is a great asset in solving this problem. > > Yes, I know, and that's exactly what we disagree about. I think that > this simple division causes as much harm as benefit. > > > policies. I am well aware of that. However, I argue that a line can be > > drawn through the breadth of the DNS namespace tree, above which names > are > > not to be associated with names below, as far as policy relationships are > > concerned--even if those names above and below the line are administered > by > > the same entity. If such is not true, then the line needs to be moved up > > until it is. > > And I am arguing that "a line" is a fundamental mistake. Moreover, in > my view the idea that these are always or even primarily parent-child > relationships is a serious error (but I recognise that that is a more > controversial point of view). > > > they can be improved within the working group to lower that risk. But > the > > point of the boundary I'm referring to (and implemented, to some extent, > by > > the PSL) is to cover many (most?) cases by simply identifying this > boundary > > where the names in question are in relation to that boundary. > > I think we disagree about what the facts are here, because I don't > think the evidence before us gives us a reason that this single > boundary works today. I argue that this is not because the details in > the PSL happen to be wrong (sometimes they are, but it's at least 80% > good), but because the PSL or any other single-factor distinction is > making a category mistake. I think that John's questions upthread are > a much better foundation from which to proceed. > > Best regards, > > A > > -- > Andrew Sullivan > ajs@anvilwalrusden.com > > _______________________________________________ > dbound mailing list > dbound@ietf.org > https://www.ietf.org/mailman/listinfo/dbound > -- Jothan Frakes Tel: +1.206-355-0230 --089e01182daa2152910518df4695 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I completely concur with John's more organic-friendly questions, and al= so agree that a simple line as a boundary is not the right approach. =C2=A0= CONTEXT is absolutely important.

If we iterated through= John's cases, it clearly demonstrates how things can be different per = namespace per context.

Context of use case ABSOLUT= ELY matters and it changes where any theoretical boundary exists, and conte= xt might also alter where boundaries are defined within namespaces (or if t= hey) should.

I have tried to make a few captures o= f what we might benefit from including in thoughts and discussion around th= e problems to solve. =C2=A0

I don't wish to pr= escribe any solution in doing so, it is just a brain dump mostly.=C2=A0 As = I re-read them, I notice that we might benefit from thinking about organizi= ng them=C2=A0per context, vs per namespace, but again, I fear I may be bein= g prescriptive.

Parent/child
It seems li= ke parent-child relationship is important to "domain boundaries",= =C2=A0but records reflecting these=C2=A0should come with associated context= also documented, to define child(ren) suffixes

Co= ntexts
There should also=C2=A0be flexibility to allow for multipl= e contexts and variance to where these boundaries are.

=
Administrative errata
Having a place to indicate some form o= f normalized information, such as
Whois server address for domain= s in it
Abuse poc
Registry URL
Registry polic= y URL
Code points (If IDN)
Etc.

Apex
It does seem important,=C2=A0in the context of apex of=C2=A0root authori= ty, (and also registry)=C2=A0to demonstrate top down chains of parent-child rel= ationships=C2=A0like might exist between "." and ".uk" or ".uk" and ".ac.uk<= /a>", such that ".ac.uk" and be= known to be part of an authoritative administrative chain, unbroken,=C2=A0= within ".".=C2=A0=C2=A0

I always seem to pick= on Centralnic names, but this would be true of any subdomaining=C2=A0entit= y like Amazon=C2=A0AWS or Dyn, but having some way for=C2=A0.com.de or co.com to=C2=A0self= -represent apex within their record somehow to establish that they are not = within the top down apex from the root, but are expressing other contexts a= nd records to indicate what is appropriate within these namespaces for cook= ie behavior, certificate issue, etc.

In doing s= ome form of element to show administrative apex,=C2=A0there needs to be car= e=C2=A0to do so in a manner that would not prejudice self-apex types that m= ay not have a chain of authority from the parent =C2=A0(like Github, Dyn, C= entralnic, Amazon. Etc) that are not administratively connected all the way= up to the root delegation.

A commentary about caution = and why I am inclusive about representation for subdomain entities, is that= I could see a registry potentially salivating over charging a registrant= =C2=A0extra to obtain a special connection/license to subdomain.

We should be careful about ensuring no disruption, financial, oper= ational, or otherwise, to the operators of subdomain solutions, whatever we= label them as.

Equivalence
if there wer= e some way to add aliases for equivilence - such that PIR .ONG/.NGO or othe= r similar situations where registry makes paired names available - that we = could have some alias record that could reflect this, per context.

-jothan

On Friday, June 19, 2015, Andrew Sul= livan <ajs@anvilwalrusden.com<= /a>> wrote:
Hi,

On Wed, Jun 17, 2015 at 02:48:05PM -0400, Casey Deccio wrote:

> Part of my reasoning for writing this draft is that I believe that the=
> fundamental division between (currently called) public and private nam= es,
> brought to light by the PSL, is a great asset in solving this problem.=

Yes, I know, and that's exactly what we disagree about.=C2=A0 I think t= hat
this simple division causes as much harm as benefit.

> policies.=C2=A0 I am well aware of that.=C2=A0 However, I argue that a= line can be
> drawn through the breadth of the DNS namespace tree, above which names= are
> not to be associated with names below, as far as policy relationships = are
> concerned--even if those names above and below the line are administer= ed by
> the same entity.=C2=A0 If such is not true, then the line needs to be = moved up
> until it is.

And I am arguing that "a line" is a fundamental mistake.=C2=A0 Mo= reover, in
my view the idea that these are always or even primarily parent-child
relationships is a serious error (but I recognise that that is a more
controversial point of view).

> they can be improved within the working group to lower that risk.=C2= =A0 But the
> point of the boundary I'm referring to (and implemented, to some e= xtent, by
> the PSL) is to cover many (most?) cases by simply identifying this bou= ndary
> where the names in question are in relation to that boundary.

I think we disagree about what the facts are here, because I don't
think the evidence before us gives us a reason that this single
boundary works today.=C2=A0 I argue that this is not because the details in=
the PSL happen to be wrong (sometimes they are, but it's at least 80% good), but because the PSL or any other single-factor distinction is
making a category mistake.=C2=A0 I think that John's questions upthread= are
a much better foundation from which to proceed.

Best regards,

A

--
Andrew Sullivan
ajs@anvilwalrusden.com

_______________________________________________
dbound mailing list
dbound@ietf.org
= https://www.ietf.org/mailman/listinfo/dbound


--

Jothan Frakes<= br>Tel: +1.206-355-0230


--089e01182daa2152910518df4695-- From nobody Fri Jun 19 08:40: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 55AD51A90A6 for ; Fri, 19 Jun 2015 08:40:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.521 X-Spam-Level: X-Spam-Status: No, score=0.521 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=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 qahPYcZTwCLU for ; Fri, 19 Jun 2015 08:40:41 -0700 (PDT) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) (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 90BF61A90AA for ; Fri, 19 Jun 2015 08:40:41 -0700 (PDT) Received: by iebgx4 with SMTP id gx4so77156130ieb.0 for ; Fri, 19 Jun 2015 08:40:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=deccio.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Vo91L71+9rIfmoYDc/8I8lMiM8FzgwOEttr8UyTG6NM=; b=aObl+Q1sXWt1l5eQTTWYpisRwvz0UYXdeTi7ZSv0RDZO6wahI98f3kjK5vIZv8NXeO HSKpPPSRQdU5uY/rPDV9gkp5HvDFoTzcaLCI3CTj/MmxK3t56awArc5Fi4yzrS3tZ48r Chlau55DXBRR8ri0fgEa6uJHxZdvTJ58gEPB0= 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:date :message-id:subject:from:to:cc:content-type; bh=Vo91L71+9rIfmoYDc/8I8lMiM8FzgwOEttr8UyTG6NM=; b=NqiUFWJGmJ0QOTpR7YjrATaFkHVOkoD3diwBmX6qUka12i4RZMxcV63T7enzYZEHV/ Jk6rjO1YD2uaw4y9fGfBl+1sZ40Ke+cAQYDnbKZi2q0tJ7xoSocCWMKTbC3YsQOr6Kz7 CaC5hAdcxi805qg2Khu5OP5dy91iyF2c3CQ8Pb7LjV1B9MAzafA0TkBXVrJQwjoGLqYO +ouicTfaCQDHAMgnu3pxP56k/8tvoJNla9h+m3UL0E7EB5ZUqjYXHdeEu5sRVN/lAp5O 1ZCRvBwvxCv0Zb4956JM0/Bry56TCLNmfHdaeKIi+05IJQigBveUb0qlfd2GvKkaleC6 B1Fg== X-Gm-Message-State: ALoCoQmRVHv0bRMfXIH6O151FKMKOVdbnAf3as+ikHsDxHXDeD0rlHcL2+BEJ1aAhT0VkBWS+Bdz MIME-Version: 1.0 X-Received: by 10.107.46.2 with SMTP id i2mr22856319ioo.18.1434728440947; Fri, 19 Jun 2015 08:40:40 -0700 (PDT) Received: by 10.50.178.162 with HTTP; Fri, 19 Jun 2015 08:40:40 -0700 (PDT) In-Reply-To: <20150619091946.GD17513@mx2.yitter.info> References: <20150617153104.GD16823@anvilwalrusden.com> <20150619091946.GD17513@mx2.yitter.info> Date: Fri, 19 Jun 2015 11:40:40 -0400 Message-ID: From: Casey Deccio To: Andrew Sullivan Content-Type: multipart/alternative; boundary=001a1144068412803c0518e0bfbb Archived-At: Cc: "dbound@ietf.org" Subject: Re: [dbound] Suggestion for Prague: let's try to converge on problem(s) 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: Fri, 19 Jun 2015 15:40:44 -0000 --001a1144068412803c0518e0bfbb Content-Type: text/plain; charset=UTF-8 Hi Andrew, On Fri, Jun 19, 2015 at 5:19 AM, Andrew Sullivan wrote: > > policies. I am well aware of that. However, I argue that a line can be > > drawn through the breadth of the DNS namespace tree, above which names > are > > not to be associated with names below, as far as policy relationships are > > concerned--even if those names above and below the line are administered > by > > the same entity. If such is not true, then the line needs to be moved up > > until it is. > > And I am arguing that "a line" is a fundamental mistake. I'm not sure why it is a mistake or why that mistake is fundamental. It all depends on how that line is to be used, which helps determine where the line is, correct? > Moreover, in > my view the idea that these are always or even primarily parent-child > relationships is a serious error (but I recognise that that is a more > controversial point of view). > I'm not sure that I've ever conveyed that idea. If I have, it was unintentional. The purpose of the current PSL or some future mechanism that operates on similar principles is not to identify relationships but to define a boundary across which they can be repudiated. In many use cases that is sufficient. Where it is not, other mechanisms can be used to identify them (i.e., other solutions within DBOUND). > > they can be improved within the working group to lower that risk. But > the > > point of the boundary I'm referring to (and implemented, to some extent, > by > > the PSL) is to cover many (most?) cases by simply identifying this > boundary > > where the names in question are in relation to that boundary. > > I think we disagree about what the facts are here, because I don't > think the evidence before us gives us a reason that this single > boundary works today. "Works" is unfortunately a very ambiguous term. Does it work to serve the primary purposes for which it was originally developed (e.g., HTTP cookie domain limits and (later) rudimentary identifying of "non-public" parts of names for display purposes in your browser's location bar)? Does it fulfill those primary purposes for one or both of the two "categories" of suffixes in the file? Does it work for other applications (e.g., DMARC) for which it wasn't originally designed? For each previous question, what is the proportion of cases for which it has been successful and when it hasn't? The answers to each of these questions will likely vary (probably with decreasing success rate in the order in which they were asked). Previously, and again here I reiterate the following: I do not believe the current PSL or some future PSL-like mechanism can solve *by itself* what DBOUND has proposed to solve. Period. What I have continually suggested is that part of identifying relationships is repudiating relationships. And if there's a simple way to do *first* this, how often will this check suffice? When it does suffice, none of the other, more complicated, mechanisms need to be utilized. But it doesn't suffice, then the client has other avenues. I argue that this is not because the details in > the PSL happen to be wrong (sometimes they are, but it's at least 80% > good), What do you mean by "at least 80% good"? Are you saying that up to 20% of the list is inaccurate? Or that up to 20% of the use cases of the list are inaccurate? Or are you talking about actual uses? Where did you get these numbers? but because the PSL or any other single-factor distinction is > making a category mistake. Yup. Again, I am not, nor have I, advocated a single-factor distinction. I do not believe the current PSL or some future PSL-like mechanism can solve *by itself* what DBOUND has proposed to solve. Period. > I think that John's questions upthread are > a much better foundation from which to proceed. > > John's questions are great. And to me they show how a hybrid mechanism can work. For demonstrative purposes only (purely examples): * Should I accept a cookie at this name? (domain -> yes/no) Flow: 1. is there a public boundary between name and domain? yes: goto 5; no: goto 2; 2. is there (using some other DBOUND solution) a policy governing the domain? yes: goto 3; no: goto 4; 3. does policy allow name to set cookie for domain? yes: goto 6; no: goto 5; 4. does RFC 6265 allow name to cookie for domain? yes: goto 5; no: goto 6; 5. "no" 6. "yes" * Should I sign an SSL cert at this name? (domain -> yes/no) Flow: 1. is name above a public boundary? yes: goto 4; no: goto 2; 2. is there (using some other DBOUND solution) an SSL cert policy governing the name? yes: goto 3; no: goto 5; 3. does policy allow the name to qualify for an SSL cert? yes: goto 5; no: goto 4; 4. "no" 5. "yes" * Should I sign a wildcard SSL cert under this name? (domain -> yes/no) 1. is name (minus wildcard) above a public boundary? yes: goto 4; no: goto 2; 2. is there (using some other DBOUND solution) an SSL cert policy governing the name? yes: goto 3; no: goto 5; 3. does policy allow the name to have a wildcard SSL cert? yes: goto 5; no: goto 4; 4. "no" 5. "yes" * Where is the DMARC record for this name? (domain -> domain) Do you mean what is the "organizational domain" for this domain (i.e., RFC 7489, section 6.1)? 1. is there (using some other DBOUND solution) a policy to identify the organizational domain of name? yes: goto 2; no: goto 3; 2. the organizational domain of name, as produced by the solution found in 1 (perhaps this would have an additional check to make sure it's not above a public boundary). 3. the name formed by identifying the lowest public boundary, plus one label (i.e., as in RFC 7489, section 6.1) * Are these two names under the same control? (domain x domain -> yes/no) Under the same *control* or the same *policy*? The process here would vary based on the answer and might not involve DBOUND at all. So you might still be asking: if the "other" (i.e., non-PSL-like) solution could essentially stand alone, why even include that solution? I can think of a number of reasons, one of which, I've already mentioned, is for the "default" case (i.e., where there is no explicit policy--either by choice or by disregard/ignorance). I've said that this "default" case could apply to the vast majority of names. I say this because if the name (or organizational domain) happens to coincide with the name directly below the public boundary, then in most cases, there's no more to be done! I suspect that this is a large number, but I don't have stats. And again, I'm not saying that there aren't cases where this doesn't work! This also provides inherent backwards compatibility. Additionally, if implemented in a fashion like the current PSL, much of this can simply be done offline. Finally (and in conjunction with the self-contained, offline capability) the client can determine with what granularity it wants to identify (or repudiate) an association. For example, think identifying organizational domains (for lack of a better word) for log messages. I can't imagine a system administrator wanting to perform online lookups to identify organizations for names associated with log messages. Cheers, Casey --001a1144068412803c0518e0bfbb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Andrew,

On Fri, Jun 19, 2015 at 5:19 AM, An= drew Sullivan <ajs@anvilwalrusden.com> wrote:
> policies.=C2=A0 I am well aware of that.= =C2=A0 However, I argue that a line can be
> drawn through the breadth of the DNS namespace tree, above which names= are
> not to be associated with names below, as far as policy relationships = are
> concerned--even if those names above and below the line are administer= ed by
> the same entity.=C2=A0 If such is not true, then the line needs to be = moved up
> until it is.

And I am arguing that "a line" is a fundamental mistake.

I'm not sure why it is a mistake or why = that mistake is fundamental.=C2=A0 It all depends on how that line is to be= used, which helps determine where the line is, correct?
=C2= =A0
Moreover, in
my view the idea that these are always or even primarily parent-child
relationships is a serious error (but I recognise that that is a more
controversial point of view).

I'm n= ot sure that I've ever conveyed that idea.=C2=A0 If I have, it was unin= tentional.=C2=A0 The purpose of the current PSL or some future mechanism th= at operates on similar principles is not to identify relationships but to d= efine a boundary across which they can be repudiated.=C2=A0 In many use cas= es that is sufficient.=C2=A0 Where it is not, other mechanisms can be used = to identify them (i.e., other solutions within DBOUND).
=C2= =A0
> they can be improved within the working group to lower that risk.=C2= =A0 But the
> point of the boundary I'm referring to (and implemented, to some e= xtent, by
> the PSL) is to cover many (most?) cases by simply identifying this bou= ndary
> where the names in question are in relation to that boundary.

I think we disagree about what the facts are here, because I don'= ;t
think the evidence before us gives us a reason that this single
boundary works today.

&quo= t;Works" is unfortunately a very ambiguous term.=C2=A0 Does it work to= serve the primary purposes for which it was originally developed (e.g., HT= TP cookie domain limits and (later) rudimentary identifying of "non-pu= blic" parts of names for display purposes in your browser's locati= on bar)?=C2=A0 Does it fulfill those primary purposes for one or both of th= e two "categories" of suffixes in the file?=C2=A0 Does it work fo= r other applications (e.g., DMARC) for which it wasn't originally desig= ned?=C2=A0 For each previous question, what is the proportion of cases for = which it has been successful and when it hasn't?=C2=A0 The answers to e= ach of these questions will likely vary (probably with decreasing success r= ate in the order in which they were asked).

Previously, a= nd again here I reiterate the following: I do not believe the current PSL o= r some future PSL-like mechanism can solve *by itself* what DBOUND has prop= osed to solve.=C2=A0 Period.

What I have continually suggested is th= at part of identifying relationships is repudiating relationships.=C2=A0 An= d if there's a simple way to do *first* this, how often will this check= suffice?=C2=A0 When it does suffice, none of the other, more complicated, = mechanisms need to be utilized.=C2=A0 But it doesn't suffice, then the = client has other avenues.

I argue that this is not because t= he details in
the PSL happen to be wrong (sometimes they are, but it's at least 80% good),

What do you mean by "at least 8= 0% good"?=C2=A0 Are you saying that up to 20% of the list is inaccurat= e?=C2=A0 Or that up to 20% of the use cases of the list are inaccurate?=C2= =A0 Or are you talking about actual uses?=C2=A0 Where did you get these num= bers?

but be= cause the PSL or any other single-factor distinction is
making a category mistake.

Yup.=C2=A0 Again, I a= m not, nor have I, advocated a single-factor distinction.

I do not b= elieve the current PSL or some future PSL-like mechanism can solve *by itse= lf* what DBOUND has proposed to solve.=C2=A0 Period.
=C2=A0
I thi= nk that John's questions upthread are
a much better foundation from which to proceed.


John's quest= ions are great.=C2=A0 And to me they show how a hybrid mechanism can work.= =C2=A0 For demonstrative purposes only (purely examples):

* Should I= accept a cookie at this name?=C2=A0 (domain -> yes/no)
Fl= ow:
1. is there a public boundary between name and domain? yes: goto 5; = no: goto 2;
2. is there (using some other DBOUND solution) a = policy governing the domain? yes: goto 3; no: goto 4;
3. does= policy allow name to set cookie for domain? yes: goto 6; no: goto 5;
4. does RFC 6265 allow name to cookie for domain? yes: goto 5; no:= goto 6;
5. "no"
6. "yes"
* Should I sign an SSL cert at this name? (domain -> yes/no)=
Flow:
1. is name above a public boundary? yes: goto 4; no: goto 2;<= br>
2. is there (using some other DBOUND solution) an SSL cert po= licy governing the name? yes: goto 3; no: goto 5;
3. does pol= icy allow the name to qualify for an SSL cert? yes: goto 5; no: goto 4;
=
4. "no"
5. "yes"

* Should I sign a wildcard SSL cert under this name? (domain -> yes/no)<= br>1. is name (minus wildcard) above a public boundary? yes: goto 4; no: go= to 2;
2. is there (using some other DBOUND solution) an SSL cert po= licy governing the name? yes: goto 3; no: goto 5;
3. does pol= icy allow the name to have a wildcard SSL cert? yes: goto 5; no: goto 4;
4. "no"
5. "yes"

* Where is the DMARC record for this name? (domain -> domain)
<= div>Do you mean what is the "organizational domain" for this doma= in (i.e., RFC 7489, section 6.1)?
1. is there (using some other D= BOUND solution) a policy to identify the organizational domain of name? yes= : goto 2; no: goto 3;
2. the organizational domain of name, as prod= uced by the solution found in 1 (perhaps this would have an additional chec= k to make sure it's not above a public boundary).
3. the = name formed by identifying the lowest public boundary, plus one label (i.e.= , as in RFC 7489, section 6.1)

* Are these two names under the same control? (domain x domain -> yes/no= )=C2=A0
Under the same *control* or the same *policy*?=C2=A0 The pro= cess here would vary based on the answer and might not involve DBOUND at al= l.

So you might still be asking: if the "other"= (i.e., non-PSL-like) solution could essentially stand alone, why even incl= ude that solution?=C2=A0 I can think of a number of reasons, one of which, = I've already mentioned, is for the "default" case (i.e., wher= e there is no explicit policy--either by choice or by disregard/ignorance).= =C2=A0 I've said that this "default" case could apply to the = vast majority of names.=C2=A0 I say this because if the name (or organizati= onal domain) happens to coincide with the name directly below the public bo= undary, then in most cases, there's no more to be done!=C2=A0 I suspect= that this is a large number, but I don't have stats.=C2=A0 And again, = I'm not saying that there aren't cases where this doesn't work!=

This also provides inherent backwards compatibility.=C2=A0 Additio= nally, if implemented in a fashion like the current PSL, much of this can s= imply be done offline.=C2=A0 Finally (and in conjunction with the self-cont= ained, offline capability) the client can determine with what granularity i= t wants to identify (or repudiate) an association.=C2=A0 For example, think= identifying organizational domains (for lack of a better word) for log mes= sages.=C2=A0 I can't imagine a system administrator wanting to perform = online lookups to identify organizations for names associated with log mess= ages.

Cheers,
Casey
--001a1144068412803c0518e0bfbb-- From nobody Fri Jun 19 12:08: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 6C3A41ACF08 for ; Fri, 19 Jun 2015 12:08:44 -0700 (PDT) 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 1tjV6sV4lSHn for ; Fri, 19 Jun 2015 12:08:43 -0700 (PDT) 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 57E3B1AD06C for ; Fri, 19 Jun 2015 12:08:42 -0700 (PDT) Received: (qmail 43352 invoked from network); 19 Jun 2015 19:08:51 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 19 Jun 2015 19:08:51 -0000 Date: 19 Jun 2015 19:08:19 -0000 Message-ID: <20150619190819.84933.qmail@ary.lan> From: "John Levine" To: dbound@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: casey@deccio.net Subject: Re: [dbound] Suggestion for Prague: let's try to converge on problem(s) 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: Fri, 19 Jun 2015 19:08:44 -0000 >> And I am arguing that "a line" is a fundamental mistake. > >I'm not sure why it is a mistake or why that mistake is fundamental. Because it's not necessarily a line. For DMARC, it would be really nice if we could say that the policy record for names at and below foomail.ca and foocourriel.fr and foopost.de and foomail.co.uk is at foomail.com. For cookies we'd like to say that google.com and 1e100.com are under the same control. In general, we want to say that .ong and .ngo are under the same control for any . Maybe those are too hard, but I don't want to rule them out until we understand what the real options are. R's, John From nobody Fri Jun 19 12:22:23 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 E2E811AD0B4 for ; Fri, 19 Jun 2015 12:22:21 -0700 (PDT) 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 kf37YjkrZ9gA for ; Fri, 19 Jun 2015 12:22:20 -0700 (PDT) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) (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 69CBA1A8A4F for ; Fri, 19 Jun 2015 12:22:20 -0700 (PDT) Received: by wguu7 with SMTP id u7so24874890wgu.3 for ; Fri, 19 Jun 2015 12:22:19 -0700 (PDT) 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=s5GpPZ0y/1IudtBym43kTxLnKXMzhnnZ/GoaGa8eyVk=; b=kqpXUc1xRv7SQ5pvTxt9IZK1FxIxYUaYz6YxD4f5LcsbiC7YgUlAZPnomNLs/kJ/S7 Boe3a8Dm86bHFTPSiP56XFWwJWPhdim+9Gp2n+wWj0uYB0dJw9PNjI2dyZ3DvasSQNk5 n2f0N/bWkTIyhces9WEegnh9Tybb8XC/CiJRi8HeF3Vri7YkEMOETvUC/WS9OODkdCb9 alGq+prOVjrGwTX5SVRH//euiyZBbEoWr8J+HsmKS78XxBmhkM+I2MCYWvWYnAnz+RpY dxrE9WfwZB4JnxUl7mXlLM9KJifRL9Lkm3vp25RiQtbOubaFDHR72YtYN5UVhzGOmNaY tvxw== MIME-Version: 1.0 X-Received: by 10.194.109.36 with SMTP id hp4mr27726636wjb.4.1434741739169; Fri, 19 Jun 2015 12:22:19 -0700 (PDT) Received: by 10.27.6.11 with HTTP; Fri, 19 Jun 2015 12:22:19 -0700 (PDT) Date: Fri, 19 Jun 2015 12:22:19 -0700 Message-ID: From: "Murray S. Kucherawy" To: "dbound@ietf.org" Content-Type: multipart/alternative; boundary=047d7bf10a74b52f210518e3d756 Archived-At: Subject: [dbound] Agenda for IETF 93? 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: Fri, 19 Jun 2015 19:22:22 -0000 --047d7bf10a74b52f210518e3d756 Content-Type: text/plain; charset=UTF-8 We've requested an hour for IETF 93. The week's agenda is under development now. We had originally requested 90 minutes but were asked to scale it back as much as possible because of huge demand this time. Does anyone have specific agenda items, or documents to discuss? I'm not sure how wise it would be to have administrivia at the end and the rest of the time be unstructured "AOB" discussion. -MSK, DBOUND co-chair --047d7bf10a74b52f210518e3d756 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
We've requested an hour for IETF 93.=C2=A0 T= he week's agenda is under development now.=C2=A0 We had originally requ= ested 90 minutes but were asked to scale it back as much as possible becaus= e of huge demand this time.

Does anyone have specific agenda i= tems, or documents to discuss?=C2=A0 I'm not sure how wise it would be = to have administrivia at the end and the rest of the time be unstructured &= quot;AOB" discussion.

-MSK, DBOUND co-chair
--047d7bf10a74b52f210518e3d756-- From nobody Fri Jun 19 12:45:24 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 983381AD371 for ; Fri, 19 Jun 2015 12:45:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=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 qjrlQ8elDy0w for ; Fri, 19 Jun 2015 12:45:22 -0700 (PDT) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) (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 252681AD36B for ; Fri, 19 Jun 2015 12:45:21 -0700 (PDT) Received: by igbzc4 with SMTP id zc4so21522355igb.0 for ; Fri, 19 Jun 2015 12:45:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=deccio.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=isIFH2Nst/KVw6BA54qH17hKpADwhuXgXD+Z15DQrY0=; b=L+TnY+K9AFFltfo6yKP7GKs1fDAKSxkB1hnB1yhW4JOm+L3k5EYLFk8rMQbMxBqC1K DtsIi9NyM6Epd5ykIXMZj+VCf4jsmq2ky3XhpAqWHCnFGYMJIeFYrl53QljEshS76k42 ZtStTN3YjxNWSD2sF3wP3V3ITNAr3nUmCMG6E= 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:date :message-id:subject:from:to:cc:content-type; bh=isIFH2Nst/KVw6BA54qH17hKpADwhuXgXD+Z15DQrY0=; b=f6ZstTfkH+7Sj+1+UPtuaXNizg8A/ZXOmwurY8Y+OrGuUA1UCTWiSFyB+NpJJTmLEJ qTW+QjgkaYrG7oxqWO+ue1HleT1roPCpTNq6jpeQYQzAseswUBFxI8o4bjR/kmhm0XKq nxYEAaotU4kgHRFuen2QfJbkutLmPT9a2xBxg5VPQRiZn8LgRPF5TiHnQfOOuxSP3lU5 84NGm+reDK5stSFBLRPNXgcmKM6ig37m4rDg9uaTy1+sbKfypsUeKSC6UXY1YlbJPOmL kzgKp8cfuGcZ8352xeGuA7lfFsqyUwcLIt7dxnSE7Xd2IMd3u+SWgWt4O+vHPZB2ZCHc 9uVQ== X-Gm-Message-State: ALoCoQnXtGrHvMAQYc34OCjBzWuCw3UBWsvvU9cX1XOOc3Pd/D3Rt6scUG6JENNAMnEOrunsj0RX MIME-Version: 1.0 X-Received: by 10.107.12.202 with SMTP id 71mr24674149iom.73.1434743120711; Fri, 19 Jun 2015 12:45:20 -0700 (PDT) Received: by 10.50.178.162 with HTTP; Fri, 19 Jun 2015 12:45:20 -0700 (PDT) In-Reply-To: <20150619190819.84933.qmail@ary.lan> References: <20150619190819.84933.qmail@ary.lan> Date: Fri, 19 Jun 2015 15:45:20 -0400 Message-ID: From: Casey Deccio To: John Levine Content-Type: multipart/alternative; boundary=001a113fc42c13420b0518e42ad2 Archived-At: Cc: "dbound@ietf.org" Subject: Re: [dbound] Suggestion for Prague: let's try to converge on problem(s) 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: Fri, 19 Jun 2015 19:45:23 -0000 --001a113fc42c13420b0518e42ad2 Content-Type: text/plain; charset=UTF-8 On Fri, Jun 19, 2015 at 3:08 PM, John Levine wrote: > >> And I am arguing that "a line" is a fundamental mistake. > > > >I'm not sure why it is a mistake or why that mistake is fundamental. > > Because it's not necessarily a line. For DMARC, it would be really > nice if we could say that the policy record for names at and below > foomail.ca and foocourriel.fr and foopost.de and foomail.co.uk is at > foomail.com. For cookies we'd like to say that google.com and > 1e100.com are under the same control. In general, we want to say that > .ong and .ngo are under the same control for any . > > Maybe those are too hard, but I don't want to rule them out until we > understand what the real options are. > For the case you've given, assume "the line" is above all the names. Can it tell you anything about their relationships? No - only that it cannot repudiate any relationships. This is why I've repeatedly said that identifying "the line" is not a stand-alone solution, and why more specific solutions must be adopted to meet the larger DBOUND question. That doesn't mean that "the line" cannot help simplify the description/configuration and be sufficient for the more common cases (and a sane default when no configuration is given) . Casey --001a113fc42c13420b0518e42ad2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Jun 19, 2015 at 3:08 PM, John Levine <johnl@taugh.c= om> wrote:
>> And I am arguing that = "a line" is a fundamental mistake.
>
>I'm not sure why it is a mistake or why that mistake is fundamental= .

Because it's not necessarily a line.=C2=A0 For DMARC, it would b= e really
nice if we could say that the policy record for names at and below
foomail.= ca and foocourriel.fr and foopost.de and foomail.co.uk is at
foomail= .com. For cookies we'd like to say that google.com and
1e100.com= are under the same control. In general, we want to say that
<x>.ong and <x>.ngo are under the same control for any <x>= ;.

Maybe those are too hard, but I don't want to rule them out until we understand what the real options are.

F= or the case you've given, assume "the line" is above all the = names.=C2=A0 Can it tell you anything about their relationships?=C2=A0 No -= only that it cannot repudiate any relationships.=C2=A0 This is why I'v= e repeatedly said that identifying "the line" is not a stand-alon= e solution, and why more specific solutions must be adopted to meet the lar= ger DBOUND question.=C2=A0 That doesn't mean that "the line" = cannot help simplify the description/configuration and be sufficient for th= e more common cases (and a sane default when no configuration is given) .

Casey
--001a113fc42c13420b0518e42ad2-- From nobody Fri Jun 19 13:26:20 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 3F9721B2A16 for ; Fri, 19 Jun 2015 13:26:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=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 soybo5tfXnD9 for ; Fri, 19 Jun 2015 13:26:17 -0700 (PDT) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (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 14C231A8A66 for ; Fri, 19 Jun 2015 13:26:17 -0700 (PDT) Received: by igbiq7 with SMTP id iq7so22213602igb.1 for ; Fri, 19 Jun 2015 13:26:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=deccio.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=EY4j0/NJCDek/8UMEQlEOsLx2n8G0XC5W0HSodDEMzg=; b=Xcebp9TjU2Prn+TAslvHhcOZm4bW/XayzZOQv769E7jzYj+JXTXjFvWTQV+1OclX6N Jy8qUdc1Aa9+Qz9Hu1ebLLn1ib4UnrWcLRE78+odfQeMR8W+KA87zo2ERi3A1g0kZ5BR 3ApHUDnYGJFnmsntN4WMq4Q2bOVPrvtaXl/2U= 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:date :message-id:subject:from:to:cc:content-type; bh=EY4j0/NJCDek/8UMEQlEOsLx2n8G0XC5W0HSodDEMzg=; b=Vm1FtslAzI+mD1wrdBsAXGenE1axFx/Xa07Tp5/A/GluQE93bsb1yJcOxtHC31Bcoz Fpz/LE1tCB18TQqMMZDBJnHraRAu7cy8r7HWX2jBM992SFUDRkcC3k6kTvx3cgZY96D/ 0mYBKttK5ZTWC9A5hb6Wmt330OnTzjSVnz0ICRquFDDPkyYgprlpg5s9jmvKlumRxbCE nh9zFTbY4se0kvVv9xWAOMpKU3tM/NIATHE2DzGpiIFHy65j8o+ZBoibWR24CxpTdn09 9sQTZSm5pg9ilSMYQ49lLBNEf3W7uLCCYbdpHP/yVqS1fFkmPVbLtj9aNif2zl6WW4c9 o0ug== X-Gm-Message-State: ALoCoQlwXTL1A0QW8uLgHY++/m3cuLBbcFnQb52QBzmBpqUBdMa+v1dOr9Pq7QJCd02zAMLivC/U MIME-Version: 1.0 X-Received: by 10.107.46.2 with SMTP id i2mr24475073ioo.18.1434745576509; Fri, 19 Jun 2015 13:26:16 -0700 (PDT) Received: by 10.50.178.162 with HTTP; Fri, 19 Jun 2015 13:26:16 -0700 (PDT) In-Reply-To: References: Date: Fri, 19 Jun 2015 16:26:16 -0400 Message-ID: From: Casey Deccio To: "Murray S. Kucherawy" Content-Type: multipart/alternative; boundary=001a114406846e6c340518e4bc47 Archived-At: Cc: "dbound@ietf.org" Subject: Re: [dbound] Agenda for IETF 93? 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: Fri, 19 Jun 2015 20:26:18 -0000 --001a114406846e6c340518e4bc47 Content-Type: text/plain; charset=UTF-8 Andrew mentioned "converging on the problem". Perhaps talking about the two problem statement drafts could help with that. I am willing to talk about my problem/solutions concepts draft. Casey On Fri, Jun 19, 2015 at 3:22 PM, Murray S. Kucherawy wrote: > We've requested an hour for IETF 93. The week's agenda is under > development now. We had originally requested 90 minutes but were asked to > scale it back as much as possible because of huge demand this time. > > Does anyone have specific agenda items, or documents to discuss? I'm not > sure how wise it would be to have administrivia at the end and the rest of > the time be unstructured "AOB" discussion. > > -MSK, DBOUND co-chair > > _______________________________________________ > dbound mailing list > dbound@ietf.org > https://www.ietf.org/mailman/listinfo/dbound > > --001a114406846e6c340518e4bc47 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Andrew mentioned "converging on the problem"= ;.=C2=A0 Perhaps talking about the two problem statement drafts could help = with that.=C2=A0 I am willing to talk about my problem/solutions concepts d= raft.

Casey

On Fri, Jun 19, 2015 at 3:22 PM, Murray S. Kucherawy <s= uperuser@gmail.com> wrote:
=
We've requested an hour for IETF 93.=C2=A0 T= he week's agenda is under development now.=C2=A0 We had originally requ= ested 90 minutes but were asked to scale it back as much as possible becaus= e of huge demand this time.

Does anyone have specific agenda i= tems, or documents to discuss?=C2=A0 I'm not sure how wise it would be = to have administrivia at the end and the rest of the time be unstructured &= quot;AOB" discussion.

-MSK, DBOUND co-chair

_______________________________________________
dbound mailing list
dbound@ietf.org
https://www.ietf.org/mailman/listinfo/dbound


--001a114406846e6c340518e4bc47-- From nobody Fri Jun 19 15:53:53 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 CEEC41A8792 for ; Fri, 19 Jun 2015 15:53:51 -0700 (PDT) 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 XyI3279-tbbU for ; Fri, 19 Jun 2015 15:53:50 -0700 (PDT) Received: from mx2.yitter.info (mx2.yitter.info [50.116.54.116]) by ietfa.amsl.com (Postfix) with ESMTP id 5398A1A8785 for ; Fri, 19 Jun 2015 15:53:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx2.yitter.info (Postfix) with ESMTP id 123F810684; Fri, 19 Jun 2015 22:53:50 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx2.yitter.info ([127.0.0.1]) by localhost (mx2.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OT0cO_sSP283; Fri, 19 Jun 2015 22:53:49 +0000 (UTC) Received: from [10.145.11.114] (unknown [46.189.28.234]) by mx2.yitter.info (Postfix) with ESMTPSA id 3A2AA1000E; Fri, 19 Jun 2015 22:53:49 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Andrew Sullivan X-Mailer: iPhone Mail (12F70) In-Reply-To: Date: Sat, 20 Jun 2015 00:53:47 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <17944BA4-A39E-4AC7-ADF2-F424F6DED024@anvilwalrusden.com> References: To: "Murray S. Kucherawy" Archived-At: Cc: "dbound@ietf.org" Subject: Re: [dbound] Agenda for IETF 93? 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: Fri, 19 Jun 2015 22:53:52 -0000 Sorry for the iPhoney top-post.=20 My view is that we need to come out of Prague with a clear understanding of w= here the hard questions among us stand. Are these disagreements over substa= nce, or just misunderstanding one another's terms? Bonus if we solve those i= ssues. But the thrashing out of understanding is ideal in-person stuff. =20 I feel very strongly that we should minimize draft-presentation time and max= imize issue-discussion time. I've raised what I think is a fundamental issu= e on the list. There may be others, like which possible use cases we want t= o prioritize, if any.=20 Movement on any of this would, I think, suggest a way forward. A --=20 Andrew Sullivan=20 Please excuse my clumbsy thums.=20 > On Jun 19, 2015, at 21:22, Murray S. Kucherawy wrote= : >=20 > We've requested an hour for IETF 93. The week's agenda is under developme= nt now. We had originally requested 90 minutes but were asked to scale it b= ack as much as possible because of huge demand this time. >=20 > Does anyone have specific agenda items, or documents to discuss? I'm not s= ure how wise it would be to have administrivia at the end and the rest of th= e time be unstructured "AOB" discussion. >=20 > -MSK, DBOUND co-chair > _______________________________________________ > dbound mailing list > dbound@ietf.org > https://www.ietf.org/mailman/listinfo/dbound