From ondrej.mikle@nic.cz Fri Jul 1 06:01:52 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 889B221F8717 for ; Fri, 1 Jul 2011 06:01:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rePrgbBq8yyB for ; Fri, 1 Jul 2011 06:01:51 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 5032D11E8134 for ; Fri, 1 Jul 2011 06:01:16 -0700 (PDT) Received: from [IPv6:2001:1488:ac14:1400:21a:4bff:fe5b:152f] (unknown [IPv6:2001:1488:ac14:1400:21a:4bff:fe5b:152f]) by mail.nic.cz (Postfix) with ESMTPSA id 012B82A2C4D; Fri, 1 Jul 2011 15:01:14 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1309525274; bh=xILFAbb3BTYt7W0LDa8SmQw8DuSApe6s7QEr292dqjg=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=n4lU6IIeDF7Coc7S5RB+yJf0kkn52JTLRzseYLY2vweu0BlHQmaRD8xApxkzrRZhR yIHCsO2Dua4dGV8Bmy7WTpJj/PvBgmiVUNIEIeLRyh/p4JuRGcdMCX54s+OCUdEzvr 4Qiyb4H10GVeCV4tCoSxvsNAe+ZWqiiMhoLb8yVw= Message-ID: <4E0DC518.8040507@nic.cz> Date: Fri, 01 Jul 2011 15:01:12 +0200 From: Ondrej Mikle User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110409 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: rbarnes@bbn.com References: <20110629175538.13928.91137.idtracker@ietfa.amsl.com> In-Reply-To: <20110629175538.13928.91137.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: dane@ietf.org Subject: Re: [dane] I-D Action: draft-ietf-dane-use-cases-04.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2011 13:17:39 -0000 On 06/29/11 19:55, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS-based Authentication of Named Entities Working Group of the IETF. [...] > http://www.ietf.org/internet-drafts/draft-ietf-dane-use-cases-04.txt 1) One suggestion for clarity: Page 6, paragraph 2 - rest of Section 3.1 reads: "In principle, DANE information expressing CA constraints can be presented with or without DNSSEC protection. Presenting DANE information without DNSSEC protection does not introduce any new vulnerabilities, but neither does it add much assurance. Deletion of records removes the protection provided by this constraint, but the client is still protected by CA practices (as now). Injected or modified false records are not useful unless the attacker can also obtain a certificate for the target domain. Thus, In the worst case, tampering with these constraints increases the risk of false authentication to the level that is now standard." Since the case of CA constraints without DNSSEC/IPSec was much discussed (e.g. https://www.ietf.org/mail-archive/web/dane/current/msg02682.html), this section might use explicit note mentioning the "downgrade to type 1 (EE cert) attack" is not possible in this scenario and is covered/implied by Section 3.3, where DNSSEC is required. 2) Minor fixes (typos, missing words - changes enclosed in asterisks): Section 3.1, paragraph 3: - missing verb "be": Alice may wish to provide similar information to an external CA operator Charlie. Prior to issuing a certificate for alice.example.com to someone claiming to *be* Alice, Charlie needs to - extend "RPs" to "relying parties" (the acronym appears only once): Alice could indicate her preferred CA using DANE to CAs as well as *to relying parties*. - Page 6, paragraph 2 - de-capitalize "In" in the last sentence Thus, *in* the worst case, tampering with these constraints increases the risk of false authentication to the level that is now standard. Regards, Ondrej Mikle From alangley@gmail.com Fri Jul 1 10:16:44 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E72D1F0C40 for ; Fri, 1 Jul 2011 10:16:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2J3h0mH6WpYp for ; Fri, 1 Jul 2011 10:16:42 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 494B51F0C5A for ; Fri, 1 Jul 2011 10:16:35 -0700 (PDT) Received: by iye7 with SMTP id 7so3734687iye.31 for ; Fri, 01 Jul 2011 10:16:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=pQ2oH/DGJXPI3BznLImtJnjXRZcjCUERnG9OMcvn4yI=; b=pIp30lrl/H/EsGUS5W9m62wVzJkOLraZ5OB67k3ETFJNWGbYjXdMXvMGRigJKbM/XX rGAbG1EgTRzuT/zd4W6lkvthQ7/6VWa7cyknSGQDMI70d/MifGr1Wxxn00nAtY3M7VWu PbU7w7yWPZrAq7bHvx9zx2wQfrWVMgescMHhU= MIME-Version: 1.0 Received: by 10.42.163.130 with SMTP id c2mr3439055icy.522.1309540594749; Fri, 01 Jul 2011 10:16:34 -0700 (PDT) Sender: alangley@gmail.com Received: by 10.42.213.9 with HTTP; Fri, 1 Jul 2011 10:16:34 -0700 (PDT) Date: Fri, 1 Jul 2011 13:16:34 -0400 X-Google-Sender-Auth: _VI0ylWraJGYHtEVqBI_6hMS4ZE Message-ID: From: Adam Langley To: dane@ietf.org Content-Type: text/plain; charset=UTF-8 Subject: [dane] Draft for serializing DNSSEC chains (01) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2011 17:16:44 -0000 Addressing comments: 1) The details of the format have been pulled out from the verification procedure and the similarities to the DNS wire format have been highlighted. 2) A high level procedure for constructing the chains has been added. http://tools.ietf.org/html/draft-agl-dane-serializechain-01 Cheers AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org From mrex@sap.com Fri Jul 1 15:12:12 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8384511E815E for ; Fri, 1 Jul 2011 15:12:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.159 X-Spam-Level: X-Spam-Status: No, score=-10.159 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mi1Q4dRGae-Y for ; Fri, 1 Jul 2011 15:12:12 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 8BF6611E809D for ; Fri, 1 Jul 2011 15:12:04 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p61MBtW2010272 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 2 Jul 2011 00:11:55 +0200 (MEST) From: Martin Rex Message-Id: <201107012211.p61MBsLp003139@fs4113.wdf.sap.corp> To: stephen.farrell@cs.tcd.ie (Stephen Farrell) Date: Sat, 2 Jul 2011 00:11:54 +0200 (MEST) In-Reply-To: <4E0CDD70.8070304@cs.tcd.ie> from "Stephen Farrell" at Jun 30, 11 09:32:48 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: agl@imperialviolet.org, dane@ietf.org Subject: Re: [dane] Draft for serializing DNSSEC chains X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2011 22:12:12 -0000 Stephen Farrell wrote: > > On 30/06/11 21:26, Martin Rex wrote: > > The purpose of the original validity in X.509 is twofold > > -- to maintain the commercial CA business model and invoicing > > for a subscription model (recurring fee or slightly reduced fee > > upfront for the entire period with no refund for unused time). > > -- to limit the growth of CRLs and to allow CAs to eventually > > dispose of their old keys and retire CRL publishing for a CA key. > > Not part of the argument on this, but I believe the above > is incorrect. Yes, I'm sorry. Admittedly, I was ranting completely free of historic facts here, describing how X.509 Validity is actively employed today and how it could be used in areas where PKI/X.509 is used on the internet today. It's been only a couple of years that I got more deeply involved with PKI(X), and I know you've been working in this area for very much longer than that. > > X.509 was originally the authentication framework > for X.500 intended to allow DUAs to authenticate to directories. > For that use-case, an expiry is quite appropriate. Of course > notAfter is a PITA in some other cases and has given rise to > some parts of a business model. But I don't believe that either > of the above reasons were the original intent at all. While it might be difficult to believe (due to my occasional temper), I do appreciate clarifications on historic evolution that caused technology to become what we've got today, especially from folks who do know more about those events than I do. -Martin From wouter@nlnetlabs.nl Mon Jul 4 01:12:38 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41AA621F861B for ; Mon, 4 Jul 2011 01:12: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=-2.599, J_CHICKENPOX_55=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hyS-psht5wSp for ; Mon, 4 Jul 2011 01:12:37 -0700 (PDT) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 617EF21F861A for ; Mon, 4 Jul 2011 01:12:36 -0700 (PDT) Received: from gary.nlnetlabs.nl (gary.nlnetlabs.nl [IPv6:2001:7b8:206:1:216:76ff:feb8:1853]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.4/8.14.4) with ESMTP id p648CXW1023226 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 4 Jul 2011 10:12:34 +0200 (CEST) (envelope-from wouter@nlnetlabs.nl) Message-ID: <4E1175F1.4080201@nlnetlabs.nl> Date: Mon, 04 Jul 2011 10:12:33 +0200 From: "W.C.A. Wijngaards" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc14 Lightning/1.0b3pre Thunderbird/3.1.10 MIME-Version: 1.0 To: dane@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]); Mon, 04 Jul 2011 10:12:34 +0200 (CEST) Subject: Re: [dane] Draft for serializing DNSSEC chains (01) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jul 2011 08:12:38 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Adam, On 07/01/2011 07:16 PM, Adam Langley wrote: > Addressing comments: > > 1) The details of the format have been pulled out from the > verification procedure and the similarities to the DNS wire format > have been highlighted. > 2) A high level procedure for constructing the chains has been added. > > http://tools.ietf.org/html/draft-agl-dane-serializechain-01 It says: Filter the possible entry keys to only include those that have the SEP bit set in the flags. But the RFCs say you MUST NOT distinguish based on the SEP bit. It is for human consumption (and perhaps signer automation). Skip this step and remove this line. Also at other points you check flags, again the SEP flag is not required. Only the ZSK flag, which allows a DNSKEY to sign zone data (required for both KSK and ZSK keys, confusingly), is something to check. In case of algorithm rollover by the zones, you need to pick up one key per algorithm to store. Because some machines may support only one algorithm. A DNAME can simply be treated like you treat the CNAME redirect, but you store the DNAME+RRSIG. (the synthesized CNAME can be omitted since you want to save bytes), then you synthesize the redirect with DNAME rules (replace suffix labels). Best regards, Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJOEXXxAAoJEJ9vHC1+BF+NDX0P/39SnNZGNpb3Aga+QnzBpdKY LFeJ9/3cLmjSbls8bazmEU9D37y6N7VcoAjQqjwk22WuzTb4Tedss6d/w5QKJclK 06WUTk05McEHSeQSn8ybY8yXDTQMdP0KruheAPFfDYmmESNaSxr4R4dSspg5WZ4F CqmXexFMuELx1kgooEmTndlhyKNd7gtpko6JKWmbA5pYII0wkmbRrN/MV+eqohDB uSMEOZqi5avT+tMUELZIM5OI7RRz7ULxIeIuKOeHRlonz3Q9m/TwMJvnx7bD83Hf R+zavhpLXGjPoUQyXGe9FvJP+EE4/ZiNGxJEHKpHiUPjyY/V9TEEdAr4yKehN5hF aLkQ6VRpq4Swv7ZREAGETO++DOfEnYkP2o0GQCq8NXQBkdZVJD2dIMNrory8WifQ IprebTpRucVIq6Iv2ckpyQIWSmsy+bX0ngTErvgf4UJM7cPYl0m65ODsxG7yOzWk RWRgrRepuVcUWm1YGIWU0uqG2cJpag6ZYtS4e0z4sX26598uO6FZafsrhdnkIdgp Li+FOs1JLonfZnZtDkOXebzVLnTjsIKQvzz8IKJvPKAiQWu+MiK1brJUloHRB3Wr N7bArSPbrVJ2tEmUaZBq+mu/Xi/sF5jS7d8NXbVkycYixMC48O/edlBVecA8fELD W0kY3VgW2eQnsRurOGQn =Jagm -----END PGP SIGNATURE----- From marc.lampo@eurid.eu Mon Jul 4 06:34:17 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AFFE21F85C7 for ; Mon, 4 Jul 2011 06:34:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.736 X-Spam-Level: X-Spam-Status: No, score=-6.736 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, MSGID_MULTIPLE_AT=1.449, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9T593IFA28lQ for ; Mon, 4 Jul 2011 06:34:16 -0700 (PDT) Received: from barra.eurid.eu (mx.eurid.eu [212.190.206.103]) by ietfa.amsl.com (Postfix) with ESMTP id B2AE821F85BF for ; Mon, 4 Jul 2011 06:34:15 -0700 (PDT) X-ASG-Debug-ID: 1309786453-0369494a3709cb0001-pGO8SV Received: from zimbra.eurid.eu (zcs-master.vt.eurid.eu [10.19.100.121]) by barra.eurid.eu with ESMTP id g267ZFeV6e4ivJhp; Mon, 04 Jul 2011 15:34:13 +0200 (CEST) X-Barracuda-Envelope-From: marc.lampo@eurid.eu X-ASG-Whitelist: Client Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.eurid.eu (Postfix) with ESMTP id DACC8E4052; Mon, 4 Jul 2011 15:23:36 +0200 (CEST) X-Virus-Scanned: amavisd-new at techmail.eurid.eu Received: from zimbra.eurid.eu ([127.0.0.1]) by localhost (zimbra.eurid.eu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CTY4pQ8e7S+9; Mon, 4 Jul 2011 15:23:36 +0200 (CEST) Received: from zimbra.eurid.eu (zimbra.eurid.eu [10.19.100.120]) by zimbra.eurid.eu (Postfix) with ESMTP id C917FE4050; Mon, 4 Jul 2011 15:23:36 +0200 (CEST) From: "Marc Lampo" To: "'Richard L. Barnes'" References: <2F57E71D-5F04-4094-8E37-F0D7C8E33111@bbn.com> In-Reply-To: <2F57E71D-5F04-4094-8E37-F0D7C8E33111@bbn.com> Date: Mon, 4 Jul 2011 15:23:36 +0200 (CEST) X-ASG-Orig-Subj: RE: [dane] Draft for serializing DNSSEC chains Message-ID: <015901cc3a4f$10399ba0$30acd2e0$@lampo@eurid.eu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraConnectorForOutlook/5.0.3064.18) Thread-Index: Acw3ZuetsDXAeSSgTTWppTkCZgdQagC534bA Content-Language: en-za X-Originating-IP: [172.20.1.96] X-Barracuda-Connect: zcs-master.vt.eurid.eu[10.19.100.121] X-Barracuda-Start-Time: 1309786453 X-Barracuda-URL: http://172.20.1.190:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at eurid.eu Cc: dane@ietf.org Subject: Re: [dane] Draft for serializing DNSSEC chains X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jul 2011 13:34:17 -0000 Hello, You show a simple and most probably very frequent case : Root --> tld --> customer.tld But suppose "customer.tld" == "attacker.tld", And "attacker.tld" can have a virtually unlimited number of delegated subdomains (a.b.c.d. . . .z.attacker.tld.) each with their own DS and DNSKEY information. Can this lead to the script trying to achieve something which is impossible ? (like : is there an upper limit in size of the result ?) Just to double check this security aspect ... Kind regards, Marc Lampo Security Officer EURid -----Original Message----- From: Richard L. Barnes [mailto:rbarnes@bbn.com] Sent: 30 June 2011 10:47 PM To: Osterweil, Eric Cc: Adam Langley; dane@ietf.org Subject: Re: [dane] Draft for serializing DNSSEC chains ... 1. . DNSKEY 2. . DNSKEY 3. org DS 4. org DNSKEY 5. org DNSKEY 6. isoc.org DS 7. isoc.org DNSKEY 8. isoc.org DNSKEY 9. isoc.org TLSA So my script polls for these records whenever the TTL expires, and issues a new cert whenever the chain changes. Seems like a pretty defined scope, and like I said before, a plausible solution. --Richard From stephen.farrell@cs.tcd.ie Mon Jul 4 10:54:13 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CA4821F871A for ; Mon, 4 Jul 2011 10:54:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.449 X-Spam-Level: X-Spam-Status: No, score=-104.449 tagged_above=-999 required=5 tests=[AWL=1.850, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DZw++vPnVevI for ; Mon, 4 Jul 2011 10:54:10 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfa.amsl.com (Postfix) with ESMTP id 7E8FB21F8719 for ; Mon, 4 Jul 2011 10:54:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 04C76171C03; Mon, 4 Jul 2011 18:54:06 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1309802045; bh=9mVIzPfP6gdYyT si6iToNde+GJGtcsVPOM0IwMESrNI=; b=ZVe9fSU6j2H1awiyVHY4QRqP1QvjcW L5ttMxwybeCXg1Humk73a1FdlzF2gi2jJ1EXR6CPRUW2ihDPcwSi40s6VKhUtdFk tKdSIz8mOGN2VBgW1BByF4lr3T7V5trpTZv+Y/SsBKjTOaRJTP4nug0zJLFhWo+5 K/gUUXAy+d+ZIL1B69UKH+Rc+5zSyL6SOl4GlK2FLIGBRu7wq0I7fH7PHlQ77J3Y FpM8y2CovyN4Vhd2huL/hn7RB2hOlK6HJRj8I0YDp6JEfj96VOOHbmW15Upmqv1x zrvjs/IX+jG07PR9VqkJYjMK+Dw1e3bAfE2dDUr/Ea3EI0S+zjT3YIUg== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id OuVAwMwW8HQd; Mon, 4 Jul 2011 18:54:05 +0100 (IST) Received: from [134.226.36.137] (stephen-samy.dsg.cs.tcd.ie [134.226.36.137]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 9A09E171BFE; Mon, 4 Jul 2011 18:54:02 +0100 (IST) Message-ID: <4E11FE3A.2000403@cs.tcd.ie> Date: Mon, 04 Jul 2011 18:54:02 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= References: <4E0D703A.3070009@nic.cz> In-Reply-To: <4E0D703A.3070009@nic.cz> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: dane@ietf.org Subject: Re: [dane] Publication request for draft-ietf-dane-use-cases X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jul 2011 17:54:13 -0000 Thanks Ondřej, Good job all. My AD review below. Pretty much nits that are ok to process along with any IETF LC comments you get. I'm also ok if you ignore these if they trip over some WG controversy that I've forgotten:-) I've kicked off the IETF LC process for this. It'll go on an IESG agenda soon after Quebec I expect. Cheers, S. (1) Abstract: "PKIX trust hierarchies" is a bit odd. PKIX does not force use of a hierarchy, but implementations have chosen to take that approach. I think s/trust hierarchies,// would be fine. I'd also s/Traditionally,/Typically,/ in that same sentence - its not tradition, its according to the TLS spec and how browsers have implemented that. (2) DANE is really only addressing TLS server auth, except for less common cases like xmpp server-to-server where both sides would have a DNS name and could publish DANE records. I think making this clear in the abstract would be good, and could be most easily done by adding a bit to the end, e.g. "...that support the TLS authentication process for TLS endpoints that have associated DNS names." or equivalent. (3) section 1, 2nd para - the term "source" domain may be confusing and I think you could just omit the word "source" and it'd be fine. (4) Same para, suggest s/to a trust anchor/to a local trust anchor/ (5) section 3, s/initial goal for DANE/initial goals for DANE/ ? (6) section 3, last para, s/can applied/can be applied/ but I wonder if "can" is right, so maybe s/can applied/may be applicable/ is better. (7) section 3.7, useful to expand EE on 1st use (8) section 3.7, s/constraints can be made/constraints can be expressed/ maybe. (9) section 4, "Combination" bullet - "must allow multiple" may lead to complexity - can you qualify or weaken that a bit to say that simplicity is still important? Maybe just say that the DANE mechanism MUST NOT be limited to a single statement per domain name and leave the level of complexity to be handled during the protocol work? (10) Why are there normative references? If there's a reason then I don't get why 2818 is informative - I think making them all informative would be fine. (Other IESG members may disagree later though, but moving them about is easy:-) From rbarnes@bbn.com Mon Jul 4 12:35:56 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0677411E80FD for ; Mon, 4 Jul 2011 12:35:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.582 X-Spam-Level: X-Spam-Status: No, score=-106.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WjcCafvTweBf for ; Mon, 4 Jul 2011 12:35:55 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 54D3011E80F9 for ; Mon, 4 Jul 2011 12:35:55 -0700 (PDT) Received: from [128.89.254.140] (port=53738 helo=[172.27.17.202]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Qdovt-0003MP-EC; Mon, 04 Jul 2011 15:35:49 -0400 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <015901cc3a4f$10399ba0$30acd2e0$@lampo@eurid.eu> Date: Mon, 4 Jul 2011 15:35:47 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2F57E71D-5F04-4094-8E37-F0D7C8E33111@bbn.com> <015901cc3a4f$10399ba0$30acd2e0$@lampo@eurid.eu> To: "Marc Lampo" X-Mailer: Apple Mail (2.1082) Cc: dane@ietf.org Subject: Re: [dane] Draft for serializing DNSSEC chains X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jul 2011 19:35:56 -0000 In principle, that's true. An attacker could also increase the size of = the extension by choosing extraordinarily large keys (e.g., 4096-bit RSA = keys). But attacks of this character are not really all that big a = concern, since the attacker is just DOSing himself. --Richard On Jul 4, 2011, at 9:23 AM, Marc Lampo wrote: > Hello, >=20 > You show a simple and most probably very frequent case : > Root --> tld --> customer.tld >=20 > But suppose "customer.tld" =3D=3D "attacker.tld", > And "attacker.tld" can have a virtually unlimited number of delegated > subdomains > (a.b.c.d. . . .z.attacker.tld.) each with their own DS and DNSKEY > information. >=20 > Can this lead to the script trying to achieve something which is > impossible ? > (like : is there an upper limit in size of the result ?) >=20 >=20 > Just to double check this security aspect ... >=20 > Kind regards, >=20 > Marc Lampo > Security Officer > EURid >=20 >=20 > -----Original Message----- > From: Richard L. Barnes [mailto:rbarnes@bbn.com]=20 > Sent: 30 June 2011 10:47 PM > To: Osterweil, Eric > Cc: Adam Langley; dane@ietf.org > Subject: Re: [dane] Draft for serializing DNSSEC chains >=20 > ... >=20 > 1. . DNSKEY > 2. . DNSKEY=20 > 3. org DS > 4. org DNSKEY > 5. org DNSKEY > 6. isoc.org DS > 7. isoc.org DNSKEY > 8. isoc.org DNSKEY > 9. isoc.org TLSA >=20 > So my script polls for these records whenever the TTL expires, and = issues > a new cert whenever the chain changes. Seems like a pretty defined = scope, > and like I said before, a plausible solution. >=20 > --Richard From rbarnes@bbn.com Mon Jul 4 13:17:30 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DD9121F8802 for ; Mon, 4 Jul 2011 13:17:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.584 X-Spam-Level: X-Spam-Status: No, score=-106.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g3LBNy4OJHtO for ; Mon, 4 Jul 2011 13:17:29 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id C99FC21F8732 for ; Mon, 4 Jul 2011 13:17:29 -0700 (PDT) Received: from [128.89.254.140] (port=54043 helo=[172.27.17.202]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QdpaA-0006x5-0y; Mon, 04 Jul 2011 16:17:26 -0400 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <4E11FE3A.2000403@cs.tcd.ie> Date: Mon, 4 Jul 2011 16:17:25 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <1B68B34F-721A-44B1-986B-68FD25F7F067@bbn.com> References: <4E0D703A.3070009@nic.cz> <4E11FE3A.2000403@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1082) Cc: dane@ietf.org Subject: Re: [dane] Publication request for draft-ietf-dane-use-cases X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jul 2011 20:17:30 -0000 Hey Stephen, Thanks for the comments. Couple of comments inline below. --Richard > (1) Abstract: "PKIX trust hierarchies" is a bit odd. PKIX does > not force use of a hierarchy, but implementations have chosen to > take that approach. I think s/trust hierarchies,// would be fine. > I'd also s/Traditionally,/Typically,/ in that same sentence - its > not tradition, its according to the TLS spec and how browsers > have implemented that. Done: s/trust hierarchies, rooted in/certificate chains rooted in/ s/Traditionally,/Typically,/ > (2) DANE is really only addressing TLS server auth, except for > less common cases like xmpp server-to-server where both sides > would have a DNS name and could publish DANE records. I think > making this clear in the abstract would be good, and could be > most easily done by adding a bit to the end, e.g. "...that > support the TLS authentication process for TLS endpoints that > have associated DNS names." or equivalent. I would propose that "support the TLS authentication process" covers = both server auth and client auth, especially given that we do = specifically mention clients Section 2 and Section 3. But if you feel = strongly that we need to call this out in the Abstract, I can come up = with some text. > (3) section 1, 2nd para - the term "source" domain may be > confusing and I think you could just omit the word "source" and > it'd be fine. The term "source domain" is defined in RFC 6125: " source domain: The fully qualified DNS domain name that a client expects an application service to present in the certificate (e.g., "www.example.com"), typically input by a human user ... " There's already a reference to RFC 6125 later in the paragraph, but we = can push it up if you feel that would be clearer. > (4) Same para, suggest s/to a trust anchor/to a local trust > anchor/ Done: s/to a trust anchor/to one of the client's trust anchors/ > (5) section 3, s/initial goal for DANE/initial goals for DANE/ ? Done. > (6) section 3, last para, s/can applied/can be applied/ but I > wonder if "can" is right, so maybe s/can applied/may be > applicable/ is better. Done: s/can applied to/are applicable to/ > (7) section 3.7, useful to expand EE on 1st use Done (in section 3.4) > (8) section 3.7, s/constraints can be made/constraints can be > expressed/ maybe. Done: s/constraints can be made/constraints can be expressed by which actors/ > (9) section 4, "Combination" bullet - "must allow multiple" may > lead to complexity - can you qualify or weaken that a bit to say > that simplicity is still important? Maybe just say that the DANE > mechanism MUST NOT be limited to a single statement per domain > name and leave the level of complexity to be handled during the > protocol work? Done; added: " The precise types of combination allowed will be defined by the DANE = protocol. " > (10) Why are there normative references? If there's a reason then > I don't get why 2818 is informative - I think making them all > informative would be fine. (Other IESG members may disagree later > though, but moving them about is easy:-) Good point. For now, I've reorganized to better align with the = definition in RFC 3967, that normative references are ones that "must be = read to fully understand or implement the subject matter in the new = RFC". In light of that: Normative: 4033, 5246, 5280, 6125 Informative: 2595, 2818, 3207, 3261, 6120 In particular, RFC 2818 is informative because it's a specific = application that uses TLS authentication (and thus possibly DANE). Glad = to reconfigure if other people feel differently= From stephen.farrell@cs.tcd.ie Mon Jul 4 15:14:32 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F3BE21F87E4 for ; Mon, 4 Jul 2011 15:14:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UFd1kDkfs2Iy for ; Mon, 4 Jul 2011 15:14:31 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfa.amsl.com (Postfix) with ESMTP id D16D721F87F2 for ; Mon, 4 Jul 2011 15:14:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id C2F45171C03; Mon, 4 Jul 2011 23:14:25 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1309817665; bh=eomqLTuD75bp8i XCJG8bQ3LBUazeBfSGGEosJoA3aVw=; b=KBNLRVchxYmgb0TmXvTc3OnyGxQVFx pTWmirGuFa/Vcx/l0G7scuzpDuOY7fhwK+h2DRpmEAlGMpzKfSg3t6ksFcKumCdR Kh4POw9i0SjBx+gP0uzor5CZkbfjy0aov00ddZyU26162VfeiBrcBGc5nuGA5lMi cDG1cir8mrRXRNIFyW9pkl+KelFgQa7PTrhyz4w5soZ0kYoqiJilrsJ2cYdFO8te d+jVX/5zs/Q1im0Y6u756DcyQg5rGkSONx2FXDNB2YZhYEkb9xO9VKRXEG9w3YJo sAmhT+s5GKUFnpvO2aqpGkTbOmBv29ecbEoD8URBu+76g8TZS/SYSdzQ== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id e-aomQJm7qX1; Mon, 4 Jul 2011 23:14:25 +0100 (IST) Received: from [10.87.48.9] (unknown [86.44.78.235]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id A552B171BFE; Mon, 4 Jul 2011 23:14:23 +0100 (IST) Message-ID: <4E123B3F.9020406@cs.tcd.ie> Date: Mon, 04 Jul 2011 23:14:23 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: "Richard L. Barnes" References: <4E0D703A.3070009@nic.cz> <4E11FE3A.2000403@cs.tcd.ie> <1B68B34F-721A-44B1-986B-68FD25F7F067@bbn.com> In-Reply-To: <1B68B34F-721A-44B1-986B-68FD25F7F067@bbn.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: dane@ietf.org Subject: Re: [dane] Publication request for draft-ietf-dane-use-cases X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jul 2011 22:14:32 -0000 Hi Richard, I deleted all the "ok" bits. On 04/07/11 21:17, Richard L. Barnes wrote: >> (2) DANE is really only addressing TLS server auth, except for >> less common cases like xmpp server-to-server where both sides >> would have a DNS name and could publish DANE records. I think >> making this clear in the abstract would be good, and could be >> most easily done by adding a bit to the end, e.g. "...that >> support the TLS authentication process for TLS endpoints that >> have associated DNS names." or equivalent. > > I would propose that "support the TLS authentication process" covers both server auth and client auth, especially given that we do specifically mention clients Section 2 and Section 3. But if you feel strongly that we need to call this out in the Abstract, I can come up with some text. I agree that you're correct. However, I'd like to head off the possibility that someone thinks that DANE is going to give every person a DNS naame and associated public key. (Or, worse, require them to have a DNS name and key.) I realise the WG don't need this clarification - it might however be useful for folks that aren't familiar with DANE. (Remember the abstract goes to the IETF announce list, which is a lot of non-DANE folks.) But I don't feel so strongly as to insist. >> (3) section 1, 2nd para - the term "source" domain may be >> confusing and I think you could just omit the word "source" and >> it'd be fine. > > The term "source domain" is defined in RFC 6125: Fair enough. Didn't spot that myself. Making it clearer might be no harm if you like. >> (9) section 4, "Combination" bullet - "must allow multiple" may >> lead to complexity - can you qualify or weaken that a bit to say >> that simplicity is still important? Maybe just say that the DANE >> mechanism MUST NOT be limited to a single statement per domain >> name and leave the level of complexity to be handled during the >> protocol work? > > Done; added: > " > The precise types of combination allowed will be defined by the DANE protocol. > " Ok, but if the WG come back with a protocol that includes a fully general language for expressing all possible policy constraints including the ability to say that a public key is only to be used on Irish national holidays, then I'll be thinking of sending that back. I don't expect that to happen, but the "must" (even if its not a "MUST") could be used to argue for more complexity in the protocol, which seems like a bad plan to me. Given we all get a shot at that debate later, I'm not going to insist now. >> (10) Why are there normative references? If there's a reason then >> I don't get why 2818 is informative - I think making them all >> informative would be fine. (Other IESG members may disagree later >> though, but moving them about is easy:-) > > Good point. For now, I've reorganized to better align with the definition in RFC 3967, that normative references are ones that "must be read to fully understand or implement the subject matter in the new RFC". In light of that: > Normative: 4033, 5246, 5280, 6125 > Informative: 2595, 2818, 3207, 3261, 6120 > In particular, RFC 2818 is informative because it's a specific application that uses TLS authentication (and thus possibly DANE). Glad to reconfigure if other people feel differently Just a nit. Ignore at will. Thanks, S. From rbarnes@bbn.com Mon Jul 4 15:29:10 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E5FB21F87AA for ; Mon, 4 Jul 2011 15:29:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.585 X-Spam-Level: X-Spam-Status: No, score=-106.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5x23R0vR7FXO for ; Mon, 4 Jul 2011 15:29:09 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 5D03B21F87A9 for ; Mon, 4 Jul 2011 15:29:09 -0700 (PDT) Received: from [128.89.254.140] (port=55877 helo=[172.27.17.202]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Qdrdb-000Hnf-Gq; Mon, 04 Jul 2011 18:29:07 -0400 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <4E123B3F.9020406@cs.tcd.ie> Date: Mon, 4 Jul 2011 18:29:06 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <353CD716-3DAE-41B4-8C54-1A653794DB48@bbn.com> References: <4E0D703A.3070009@nic.cz> <4E11FE3A.2000403@cs.tcd.ie> <1B68B34F-721A-44B1-986B-68FD25F7F067@bbn.com> <4E123B3F.9020406@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1082) Cc: dane@ietf.org Subject: Re: [dane] Publication request for draft-ietf-dane-use-cases X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jul 2011 22:29:10 -0000 Couple of resolutions below... >>> (2) DANE is really only addressing TLS server auth, except for >>> less common cases like xmpp server-to-server where both sides >>> would have a DNS name and could publish DANE records. I think >>> making this clear in the abstract would be good, and could be >>> most easily done by adding a bit to the end, e.g. "...that >>> support the TLS authentication process for TLS endpoints that >>> have associated DNS names." or equivalent. >>=20 >> I would propose that "support the TLS authentication process" covers = both server auth and client auth, especially given that we do = specifically mention clients Section 2 and Section 3. But if you feel = strongly that we need to call this out in the Abstract, I can come up = with some text. >=20 > I agree that you're correct. However, I'd like to head off > the possibility that someone thinks that DANE is going to > give every person a DNS naame and associated public key. (Or, > worse, require them to have a DNS name and key.) I realise > the WG don't need this clarification - it might however be > useful for folks that aren't familiar with DANE. (Remember > the abstract goes to the IETF announce list, which is a lot > of non-DANE folks.) But I don't feel so strongly as to insist. Added the following: " The main focus of this document is TLS server authentication, but it = also covers TLS client authentication for applications where TLS clients = are identified by domain names. " >>> (3) section 1, 2nd para - the term "source" domain may be >>> confusing and I think you could just omit the word "source" and >>> it'd be fine. >>=20 >> The term "source domain" is defined in RFC 6125: >=20 > Fair enough. Didn't spot that myself. Making it clearer > might be no harm if you like. Added reference to 6125. From paul@xelerance.com Mon Jul 4 15:59:36 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C58621F878B for ; Mon, 4 Jul 2011 15:59:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.274 X-Spam-Level: X-Spam-Status: No, score=-6.274 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fyYHKE3RnUZf for ; Mon, 4 Jul 2011 15:59:36 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by ietfa.amsl.com (Postfix) with ESMTP id D041F21F85BA for ; Mon, 4 Jul 2011 15:59:35 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 4A087BFE0; Mon, 4 Jul 2011 18:59:34 -0400 (EDT) Date: Mon, 4 Jul 2011 18:59:34 -0400 (EDT) From: Paul Wouters To: Stephen Farrell In-Reply-To: <4E123B3F.9020406@cs.tcd.ie> Message-ID: References: <4E0D703A.3070009@nic.cz> <4E11FE3A.2000403@cs.tcd.ie> <1B68B34F-721A-44B1-986B-68FD25F7F067@bbn.com> <4E123B3F.9020406@cs.tcd.ie> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dane@ietf.org Subject: Re: [dane] Publication request for draft-ietf-dane-use-cases X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jul 2011 22:59:36 -0000 On Mon, 4 Jul 2011, Stephen Farrell wrote: > On 04/07/11 21:17, Richard L. Barnes wrote: >>> (2) DANE is really only addressing TLS server auth, except for >>> less common cases like xmpp server-to-server where both sides >>> would have a DNS name and could publish DANE records. I think >>> making this clear in the abstract would be good, and could be >>> most easily done by adding a bit to the end, e.g. "...that >>> support the TLS authentication process for TLS endpoints that >>> have associated DNS names." or equivalent. >> >> I would propose that "support the TLS authentication process" covers both server auth and client auth, especially given that we do specifically mention clients Section 2 and Section 3. But if you feel strongly that we need to call this out in the Abstract, I can come up with some text. > > I agree that you're correct. However, I'd like to head off > the possibility that someone thinks that DANE is going to > give every person a DNS naame and associated public key. (Or, > worse, require them to have a DNS name and key.) But now you are doing the reverse, implying to those who see a bright future for dane possibilities that it may never be used to authenticate both client and server. If you look at the TLS extension draft we just submited, all you need to do client and server auth is to create a clientname extension equivalent to servername. Paul From paul@xelerance.com Mon Jul 4 16:00:18 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F27221F879F for ; Mon, 4 Jul 2011 16:00:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.339 X-Spam-Level: X-Spam-Status: No, score=-6.339 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hOlm2Zmd9r54 for ; Mon, 4 Jul 2011 16:00:18 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by ietfa.amsl.com (Postfix) with ESMTP id EB68A21F85BA for ; Mon, 4 Jul 2011 16:00:17 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 4E8B7BFEF for ; Mon, 4 Jul 2011 19:00:17 -0400 (EDT) Date: Mon, 4 Jul 2011 19:00:17 -0400 (EDT) From: Paul Wouters To: dane@ietf.org Message-ID: User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: [dane] FYI: [TLS] New Version Notification for draft-wouters-tls-oob-pubkey-00.txt (fwd) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jul 2011 23:00:18 -0000 I thought this draft might be of interest to people on the list here, Paul ---------- Forwarded message ---------- Date: Mon, 4 Jul 2011 17:43:48 -0400 (EDT) From: Paul Wouters To: tls@ietf.org Subject: [TLS] New Version Notification for draft-wouters-tls-oob-pubkey-00.txt (fwd) I just submitted draft-wouters-tls-oob-pubkey-00.txt which documents a TLS extension for use when a TLS client has obtained a server's public key (or keys) out-of-band. It allows the suppression of sending PKIX certificates This is useful for example when obtaining the TLS server public key using DANE. I'd like the WG to consider adopting it as a WG work item. Paul ---------- Forwarded message ---------- Date: Mon, 04 Jul 2011 14:33:54 -0700 From: internet-drafts@ietf.org Cc: weiler@tislabs.com, gnu@toad.com, paul@xelerance.com To: paul@xelerance.com Subject: New Version Notification for draft-wouters-tls-oob-pubkey-00.txt A new version of I-D, draft-wouters-tls-oob-pubkey-00.txt has been successfully submitted by Paul Wouters and posted to the IETF repository. Filename: draft-wouters-tls-oob-pubkey Revision: 00 Title: TLS Extension for out-of-band public key validation Creation date: 2011-07-04 WG ID: Individual Submission Number of pages: 8 Abstract: This document specifies a new TLS extension as well as modified TLS client and TLS server behaviour when public keys are authenticated out-of-band to the current TLS connection. It is a companion document for RFC 5246, "The Transport Layer Security (TLS) Protocol Version 1.2". The new extension specified is "oob_pubkey_list" which can be used when the TLS client is already in possession of a validated public key of the TLS server before it starts the TLS handshake. The IETF Secretariat _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From stephen.farrell@cs.tcd.ie Mon Jul 4 16:17:39 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CC2C1F0C7C for ; Mon, 4 Jul 2011 16:17:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kNYp9IfMgjfU for ; Mon, 4 Jul 2011 16:17:38 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfa.amsl.com (Postfix) with ESMTP id 629461F0C3D for ; Mon, 4 Jul 2011 16:17:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 653B6171C18; Tue, 5 Jul 2011 00:17:31 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1309821451; bh=0sU27OEdnM8jac mrqxRVfzf1HXhR4RopmXm/Zfclajg=; b=pHT7FTE/V9lSV3iF0aLpF/KdRTxMva HpF9t+LdyIBC23sJ/YkFiwkqxfdVJBh4f5vZnezzAQviOTueCFFPI0NOOn81R0hC 1DWs2DaPVGDgb54RbfZpuRB6log6wy4EgFd2BxjabKayJFc50JBVKQu9RJmE4jRK vecQAIW/PTRgi2L4dbIjn2nwCx5X2SKsZgbknxEUppVQHMIAsRzLJ+hCRQLd5Kbr q297ZkDYAobweMZrsL9DYAW00q4C9aLsb2G1U8++yVBJPHFVUfunXpZguQ8c7T1v 3eZnDGcbnp2yIAbsQC2VcqyaqEhau04YpUai0ClnJ1xZTvH16rKduoqQ== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id ktrVPSiLmjCQ; Tue, 5 Jul 2011 00:17:31 +0100 (IST) Received: from [10.87.48.9] (unknown [86.44.78.235]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 151CB171C03; Tue, 5 Jul 2011 00:17:26 +0100 (IST) Message-ID: <4E1249FA.2000302@cs.tcd.ie> Date: Tue, 05 Jul 2011 00:17:14 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: "Richard L. Barnes" References: <4E0D703A.3070009@nic.cz> <4E11FE3A.2000403@cs.tcd.ie> <1B68B34F-721A-44B1-986B-68FD25F7F067@bbn.com> <4E123B3F.9020406@cs.tcd.ie> <353CD716-3DAE-41B4-8C54-1A653794DB48@bbn.com> In-Reply-To: <353CD716-3DAE-41B4-8C54-1A653794DB48@bbn.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: dane@ietf.org Subject: Re: [dane] Publication request for draft-ietf-dane-use-cases X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jul 2011 23:17:39 -0000 Lovely jubbly. Thanks, S. On 04/07/11 23:29, Richard L. Barnes wrote: > Couple of resolutions below... > >>>> (2) DANE is really only addressing TLS server auth, except for >>>> less common cases like xmpp server-to-server where both sides >>>> would have a DNS name and could publish DANE records. I think >>>> making this clear in the abstract would be good, and could be >>>> most easily done by adding a bit to the end, e.g. "...that >>>> support the TLS authentication process for TLS endpoints that >>>> have associated DNS names." or equivalent. >>> >>> I would propose that "support the TLS authentication process" covers both server auth and client auth, especially given that we do specifically mention clients Section 2 and Section 3. But if you feel strongly that we need to call this out in the Abstract, I can come up with some text. >> >> I agree that you're correct. However, I'd like to head off >> the possibility that someone thinks that DANE is going to >> give every person a DNS naame and associated public key. (Or, >> worse, require them to have a DNS name and key.) I realise >> the WG don't need this clarification - it might however be >> useful for folks that aren't familiar with DANE. (Remember >> the abstract goes to the IETF announce list, which is a lot >> of non-DANE folks.) But I don't feel so strongly as to insist. > > Added the following: > " > The main focus of this document is TLS server authentication, but it also covers TLS client authentication for applications where TLS clients are identified by domain names. > " > > > > >>>> (3) section 1, 2nd para - the term "source" domain may be >>>> confusing and I think you could just omit the word "source" and >>>> it'd be fine. >>> >>> The term "source domain" is defined in RFC 6125: >> >> Fair enough. Didn't spot that myself. Making it clearer >> might be no harm if you like. > > Added reference to 6125. > > > From stephen.farrell@cs.tcd.ie Mon Jul 4 16:32:01 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC37F21F859A for ; Mon, 4 Jul 2011 16:32:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gqy7Prn-twbY for ; Mon, 4 Jul 2011 16:32:01 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfa.amsl.com (Postfix) with ESMTP id A6BD221F8597 for ; Mon, 4 Jul 2011 16:32:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id B695B171C18; Tue, 5 Jul 2011 00:31:53 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1309822313; bh=0r/AH4E3LBSN9H l8HXlXhe7DngIRI14ew07dAqM31UM=; b=4oSNQtikVXZadCc6LGgpXGBfLQMb9R QdctZmgRFZnB/C1EU7PnB/wqS9ERWZxZoY+WRZusKJ6HUHg8jCC+xPRDganIBD9X fOAgzjcWIiaiTN4rJA4j1OgzJhQO+CIGxhv3cXs7E6qHtW0ufzazlrcVgRvcFxgm sIf4ocH3pMQBlJDeC2Bm9P+k+091CiMMSr9DPAOuqctIIGPUM/z0O0hUypRF7X4R aw0R7TWwwFf+XqgoN5v3aZsYDTVwmgquvQSuE68S1aQgRfmDaUA2EZhQAmbBbxVq uoFjJGmfS2Rkxa1bCqCUvnwp/Vutq1xgPqSkNSd9Z18CN+6HM5yB+lPQ== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id nzh+JJJN3lAi; Tue, 5 Jul 2011 00:31:53 +0100 (IST) Received: from [10.87.48.9] (unknown [86.44.78.235]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 36A2B171C03; Tue, 5 Jul 2011 00:31:52 +0100 (IST) Message-ID: <4E124D67.2020309@cs.tcd.ie> Date: Tue, 05 Jul 2011 00:31:51 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Paul Wouters References: <4E0D703A.3070009@nic.cz> <4E11FE3A.2000403@cs.tcd.ie> <1B68B34F-721A-44B1-986B-68FD25F7F067@bbn.com> <4E123B3F.9020406@cs.tcd.ie> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dane@ietf.org Subject: Re: [dane] Publication request for draft-ietf-dane-use-cases X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jul 2011 23:32:01 -0000 On 04/07/11 23:59, Paul Wouters wrote: > On Mon, 4 Jul 2011, Stephen Farrell wrote: > >> On 04/07/11 21:17, Richard L. Barnes wrote: >>>> (2) DANE is really only addressing TLS server auth, except for >>>> less common cases like xmpp server-to-server where both sides >>>> would have a DNS name and could publish DANE records. I think >>>> making this clear in the abstract would be good, and could be >>>> most easily done by adding a bit to the end, e.g. "...that >>>> support the TLS authentication process for TLS endpoints that >>>> have associated DNS names." or equivalent. >>> >>> I would propose that "support the TLS authentication process" covers >>> both server auth and client auth, especially given that we do >>> specifically mention clients Section 2 and Section 3. But if you >>> feel strongly that we need to call this out in the Abstract, I can >>> come up with some text. >> >> I agree that you're correct. However, I'd like to head off >> the possibility that someone thinks that DANE is going to >> give every person a DNS naame and associated public key. (Or, >> worse, require them to have a DNS name and key.) > > But now you are doing the reverse, implying to those who see a bright > future for dane possibilities that it may never be used to authenticate > both client and server. Nope. > If you look at the TLS extension draft we just submited, all you need > to do client and server auth is to create a clientname extension equivalent > to servername. That may, or may not, be all that's needed. We don't need to figure that out today. My understanding is that the WG consensus is reflected by Richard's additional phrase, and all I asked for is that the abstract reflect that. I'm sure if Richard's suggestion (at my prompting) goes against the WG consensus a bunch of people will comment on that and it'll get fixed. If more stuff gets done later, that's fine if its useful etc. but I'm sure you're not suggesting your new I-D get reflected in the abstract of the use-cases document right now. S. > > Paul > From iesg-secretary@ietf.org Tue Jul 5 06:17:24 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E87021F8712; Tue, 5 Jul 2011 06:17:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.503 X-Spam-Level: X-Spam-Status: No, score=-102.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FEwuB0prkabv; Tue, 5 Jul 2011 06:17:24 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1016221F8689; Tue, 5 Jul 2011 06:17:24 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110705131724.32635.63698.idtracker@ietfa.amsl.com> Date: Tue, 05 Jul 2011 06:17:24 -0700 Cc: dane@ietf.org Subject: [dane] Last Call: (Use Cases and Requirements for DNS-based Authentication of Named Entities (DANE)) to Informational RFC X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2011 13:17:24 -0000 The IESG has received a request from the DNS-based Authentication of Named Entities WG (dane) to consider the following document: - 'Use Cases and Requirements for DNS-based Authentication of Named Entities (DANE)' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-07-19. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Many current applications use the certificate-based authentication features in TLS to allow clients to verify that a connected server properly represents a desired domain name. Traditionally, this authentication has been based on PKIX trust hierarchies, rooted in well-known CAs, but additional information can be provided via the DNS itself. This document describes a set of use cases in which the DNS and DNSSEC could be used to make assertions that support the TLS authentication process. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-dane-use-cases/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-dane-use-cases/ No IPR declarations have been submitted directly on this I-D. From eosterweil@verisign.com Wed Jul 6 07:44:27 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0705621F8739 for ; Wed, 6 Jul 2011 07:44:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.702 X-Spam-Level: X-Spam-Status: No, score=-5.702 tagged_above=-999 required=5 tests=[AWL=-0.499, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eH8hIZf8jWf6 for ; Wed, 6 Jul 2011 07:44:24 -0700 (PDT) Received: from exprod6og107.obsmtp.com (exprod6og107.obsmtp.com [64.18.1.208]) by ietfa.amsl.com (Postfix) with ESMTP id 1946221F85F6 for ; Wed, 6 Jul 2011 07:44:20 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob107.postini.com ([64.18.5.12]) with SMTP ID DSNKThR0w/Fs/7JyPI2WEUr3u7knOv5nYTAr@postini.com; Wed, 06 Jul 2011 07:44:23 PDT Received: from dul1wnexcn01.vcorp.ad.vrsn.com (dul1wnexcn01.vcorp.ad.vrsn.com [10.170.12.138]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id p66EiIvG032629; Wed, 6 Jul 2011 10:44:18 -0400 Received: from DUL1WNEXMB11.vcorp.ad.vrsn.com ([10.170.13.11]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 6 Jul 2011 10:44:18 -0400 Received: from 10.131.30.110 ([10.131.30.110]) by DUL1WNEXMB11.vcorp.ad.vrsn.com ([10.170.13.11]) with Microsoft Exchange Server HTTP-DAV ; Wed, 6 Jul 2011 14:43:46 +0000 User-Agent: Microsoft-Entourage/12.29.0.110113 Date: Wed, 06 Jul 2011 10:43:49 -0400 From: "Osterweil, Eric" To: Phillip Hallam-Baker , Mark Andrews Message-ID: Thread-Topic: [dane] Draft for serializing DNSSEC chains Thread-Index: Acw2wUwJrIbm3356RIKqWVcoBokHpQFKdHAd In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 06 Jul 2011 14:44:18.0132 (UTC) FILETIME=[2F26B140:01CC3BEB] Cc: Adam Langley , dane@ietf.org Subject: Re: [dane] Draft for serializing DNSSEC chains X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 14:44:27 -0000 Have you guys looked at libvdns (specifically the dns_srv.h file)? http://vantage-points.org/libvdns.html Eric On 6/29/11 9:01 PM, "Phillip Hallam-Baker" wrote: > Yes, but you try calling them from managed code and the results are going= to > be less than pretty. >=20 > All I am saying is that there is probably a reason that very few applicat= ions > seem to be making use of features like SRV and I don't think it is a prob= lem > with the ideas, its in the deployment. >=20 >=20 >=20 >=20 > On Wed, Jun 29, 2011 at 7:54 PM, Mark Andrews wrote: >>=20 >> In message , Phillip >> Hallam- >> Baker writes: >>>>=20 >>>> The concepts are independent, the code most certainly is not. >>>>=20 >>>> This is why I have spent the past few weeks writing a DNS resolver in = C# to >>>> hopefully render the issue moot. >>>>=20 >>>>=20 >>>> While you can call unmanaged code from a managed environment like C#, = the >>>> means of doing so is not at all pretty. And making the result threadsa= fe is >>>> a nightmare. It is in fact much easier to recode from scratch than to = use >>>> the existing stuff. >>=20 >> There are already plenty of thread safe resolver libraries. =A0Which >> can perform queries in parallel. =A0They can even be talking to >> different sets of recursive servers if you want. =A0libresolv was >> made thread safe in 1900's and no it was not a giant lock. >>=20 >>>> Calling a math function or a crypto algorithm is one thing, but a DNS >>>> library is by its very nature asynchronous and it is possible to have >>>> multiple queries in flight at the same time. I suspect that a lot of t= he >>>> objections to using DNS for more sophisticated discovery come from the= lack >>>> of decent DNS library support in modern programming languages. >>>>=20 >>>> It is easy enough to support an API like this with blocking code: >>>>=20 >>>> =A0 =A0 EDNS.Client resolver =3D new EDNS.Client (); >>>>=20 >>>> =A0 =A0 EDNS.DNSMessage Response; >>>> =A0 =A0 int result =3D resolver.Resolve (Domain, EDNS.DNSType.CAA, out Respo= nse); >>>>=20 >>>>=20 >>>> But most of us would like to have multiple queries in parallel: >>>>=20 >>>> =A0 =A0 =A0 =A0 =A0 =A0 DNSClient Client =3D new DNSClient (); >>>>=20 >>>> =A0 =A0 =A0 =A0 =A0 =A0 // Non blocking request >>>> =A0 =A0 =A0 =A0 =A0 =A0 DNSMessage Request =3D new DNSQueryMessage (Domain, >>> EDNS.DNSType.A >>>> ); >>>> =A0 =A0 =A0 =A0 =A0 =A0 DNSTransaction Transaction1 =3D Client.Send (Request); >>>>=20 >>>> =A0 =A0 =A0 =A0 =A0 =A0 DNSMessage Request =3D new DNSQueryMessage >>>> (Domain, EDNS.DNSType.CAA); >>>> =A0 =A0 =A0 =A0 =A0 =A0 DNSTransaction Transaction2 =3D Client.Send (Request); >>>>=20 >>>> =A0 =A0 =A0 =A0 =A0 =A0 // Does other useful stuff like create the message headers >>>> =A0 =A0 =A0 =A0 =A0 =A0 // Can poll status of transactions using >>> DNSTransaction.Complete >>>> () >>>>=20 >>>> =A0 =A0 =A0 =A0 =A0 =A0 Response =3D Client.Receive (Transaction1); >>>> =A0 =A0 =A0 =A0 =A0 =A0 Response =3D Client.Receive (Transaction2); >>>>=20 >>>>=20 >>>> And that is still much less than you would want a .NET library to prov= ide. >>>> A >>>> proper .NET library should let the caller loop things into the asynchr= onous >>>> caller. >>>>=20 >>>> Ultimately, the goal is to produce a subclass of the TcpClient class s= uch >>>> that the only difference that the programmer needs to consider is to >>> replace >>>> the creation method: >>>>=20 >>>> public TcpClient(string hostname, int port) >>>>=20 >>>>=20 >>>> with the creation method: >>>>=20 >>>> public InternetClient(string hostname, string service, int port) >>>>=20 >>>>=20 >>>>=20 >>>> The difference here is the level of abstraction. TcpClient connects vi= a >>>> hostname and port and always returns a raw bytestream. InternetClient = uses >>>> the DNS to determine what the best connection that is available for a >>>> service. If the best connection is raw TCP it will return that, if it = can >>>> form an SSL socket, it will return that. >>>>=20 >>>> [Yes, I know that there is also the question of how to specify 'best',= but >>>> that is something that is more usually something you want to specify a= t the >>>> host level or higher and want to avoid embedding in actual application= s] >>>>=20 >>>> This actually has a major performance advantage in the right hands bec= ause >>>> the implementation can also be asynchronous. So in the typical calling >>>> sequence we would have: >>>>=20 >>>> // Create the socket >>>> // Generate the message headers >>>> // Check the socket is OK >>>> // Send the first byte >>>>=20 >>>> In terms of timing what would be going on is: >>>>=20 >>>> // Create the socket >>>> =A0 [Async socket establishment starts] >>>> // Generate the message headers >>>> =A0 [Wait for the socket to be completed] >>>> // Check the socket is OK >>>> // Send the first byte >>>>=20 >>>>=20 >>>> Now in my preferred programming language, you could just throw up a PA= R >>>> statement and it would work anyway, but very few programmers grok that= sort >>>> of stuff. >>=20 >> And this has gone very far from the original issue of handling unknown t= ypes. >>=20 >>>> On Wed, Jun 29, 2011 at 2:21 AM, Mark Andrews wrote: >>>>=20 >>>>>>=20 >>>>>> In message >>> >, Phill= ip >>>>>> Hallam- >>>>>> Baker writes: >>>>>>>> I guess that would work for the application programmers who still = >>>> >>>>>>>> code in >>>>>> C >>>>>>>> or C++. That is not where the industry has been for a decade now. >>>>>>=20 >>>>>> The concepts are language independent. >>>>>>=20 >>>>>> -- >>>>>> Mark Andrews, ISC >>>>>> 1 Seymour St., Dundas Valley, NSW 2117, Australia >>>>>> PHONE: +61 2 9871 4742 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 >>>> INTERNET: marka@isc.org >>>>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> -- >>>> Website: http://hallambaker.com/ >>>>=20 >>>> --0016e68debd4b5f20c04a6db8b0b >>>> Content-Type: text/html; charset=3DISO-8859-1 >>>> Content-Transfer-Encoding: quoted-printable >>>>=20 >>>> The concepts are independent, the code most certainly is >>> not.

>>>>>
This is why I have spent the past few weeks writing a DNS resol= ver >>>>>> >>> in=3D >>>> =A0C# to hopefully render the issue moot.


<= /div> >>>>
While you can call unmanaged code from a managed environment like= C#, >>>> =3D >>>> the means of doing so is not at all pretty. And making the result >>> threadsaf=3D >>>> e is a nightmare. It is in fact much easier to recode from scratch tha= n to >>>> =3D >>>> use the existing stuff.
>>>>

Calling a math function or a crypto algorithm is o= ne >> >>>> th=3D >>>> ing, but a DNS library is by its very nature asynchronous and it is >>> possibl=3D >>>> e to have multiple queries in flight at the same time. I suspect that = a >>> lot=3D >>>> =A0of the objections to using DNS for more sophisticated discovery come = from >>>> =3D >>>> the lack of decent DNS library support in modern programming >>> languages.>>> v> >>>>


It is easy enough to support an API >>> like=3D >>>> =A0this with blocking code:

=3DA0 =3DA0 >>> EDNS.Client=3D >>>> =A0resolver =3D3D new EDNS.Client ();

=3DA0 =3DA0 >>> EDNS.DNS=3D >>>> Message Response;
>>>>
=3DA0 =3DA0 int result =3D3D resolver.Resolve (Domain, EDNS.DNSType.CAA= , >>> out=3D >>>> =A0Response);


But most of = us >> >>>> wo=3D >>>> uld like to have multiple queries in >>> parallel:

>>> v> >>>> =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 DNSClient Client =3D3D new DNSClient >>> ();
<=3D >>>> div>
=3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 // Non blocking >>> request
>>> v>
=3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 DNSMes= sage >>>> =3D >>>> Request =3D3D new DNSQueryMessage (Domain,=3DA0EDNS.DNSType.A>> class=3D >>>> =3D3D"Apple-style-span">);
>>>>
=3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 DNSTransaction Transaction1 =3D3D >>> Client.S=3D >>>> end (Request);

=3DA0 =3DA0 =3DA0 =3DA0 =3DA0 = =3DA0 >>>> >> D=3D >>>> NSMessage Request =3D3D new DNSQueryMessage >>> (Domain,=3DA0EDNS.DNSType.CAA);>>> v>
=3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 DNSTransaction Transaction2 =3D3D >>> Client=3D >>>> .Send (Request);
>>>>

=3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 // Does other useful >>> stuf=3D >>>> f like create the message headers
=3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 //= Can >>>> =3D >>>> poll status of transactions using=3DA0DNSTransaction.Complete >>> ()
>>> r>
=3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 Response =3D3D Client.Receive >>> (Tran=3D >>>> saction1);
>>>>
=3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 Response =3D3D Client.Receive >>> (Transa=3D >>>> ction2);


And that is sti= ll >> >>>> mu=3D >>>> ch less than you would want a .NET library to provide. A proper .NET >>> librar=3D >>>> y should let the caller loop things into the asynchronous caller. >>>>

Ultimately, the goal is to produce a subclass of t= he >> >>>> Tc=3D >>>> pClient class such that the only difference that the programmer needs = to >> >>>> co=3D >>>> nsider is to replace the creation method:

> >>>> cl=3D >>>> ass=3D3D"Apple-style-span" style=3D3D"font-family: 'Segoe UI', >>> Verdana,=3D >>>> =A0Arial; font-size: 17px; ">
>>> >> 5=3D
>>>> px; padding-bottom: 5px; padding-left: 5px; margin-top: 0px; margin-ri=
ght:
>>>> =3D
>>>> 0px; margin-bottom: 0px; margin-left: 0px; font-family: Consolas, Cour=
ier,
>>>> =3D
>>>> monospace; word-break: break-all; word-wrap: break-word; font-style:
>>> normal=3D
>>>> ; font-weight: normal; overflow-x: auto; overflow-y: auto; ">
>>>> public TcpClient(>> style=3D3D"color:=3D
>>>> =A0blue; ">string hostname, int
>>>> >> p=3D
>>>> ort)

with the creation >>> method:
<=3D >>>> div> >>>>
>> '=3D >>>> Segoe UI', Verdana, Arial; font-size: 17px; ">
>> style=3D3D"padding-top=3D
>>>> : 5px; padding-right: 5px; padding-bottom: 5px; padding-left: 5px;
>>> margin-t=3D
>>>> op: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;
>>> font-fami=3D
>>>> ly: Consolas, Courier, monospace; word-break: break-all; word-wrap:
>>> break-w=3D
>>>> ord; font-style: normal; font-weight: normal; overflow-x: auto;
>>> overflow-y:=3D
>>>> =A0auto; ">
>>>> public InternetClient(>> style=3D3D"c=3D
>>>> olor: blue; ">string hostname, >> ">string<=3D
>>>> /span> service, int
>>> port)


<=3D >>>> div> >>>> The difference here is the level of abstraction. TcpClient connects vi= a >>> hos=3D >>>> tname and port and always returns a raw bytestream. InternetClient use= s >>> the=3D >>>> =A0DNS to determine what the best connection that is available for a >>> service.=3D >>>> =A0If the best connection is raw TCP it will return that, if it can form= an >>>> >> S=3D >>>> SL socket, it will return that.
>>>>

[Yes, I know that there is also the question of ho= w to >>>> =3D >>>> specify 'best', but that is something that is more usually >>> somethin=3D >>>> g you want to specify at the host level or higher and want to avoid >>> embeddi=3D >>>> ng in actual applications]
>>>>

This actually has a major performance advantage in= the >>>> =3D >>>> right hands because the implementation can also be asynchronous. So in= the >>>> =3D >>>> typical calling sequence we would have:

// Cr= eate >>>> =3D >>>> the socket
>>>>
// Generate the message headers
// Check the socket is >>> OK>>> iv>
// Send the first byte

In terms of ti= ming >>>> =3D >>>> what would be going on is:

// Create the >>> sock=3D >>>> et
>>>>
=3DA0 [Async socket establishment starts]
// Generate the >>> mess=3D >>>> age headers
=3DA0 [Wait for the socket to be >>> completed]
/=3D >>>> / Check the socket is OK
// Send the first >>> byte
<=3D >>>> br> >>>>

Now in my preferred programming language, yo= u >>> cou=3D >>>> ld just throw up a PAR statement and it would work anyway, but very fe= w >>> pro=3D >>>> grammers grok that sort of stuff.


>>> =3D3D"gmail_quote"> >>>> On Wed, Jun 29, 2011 at 2:21 AM, Mark Andrews <>> href=3D >>>> =3D3D"mailto:marka@isc.org">marka@isc.org> >>> wrote:
>>> e class=3D3D"gmail_quote" style=3D3D"margin:0 0 0 .8ex;border-left:1px #cc= c >>> sol=3D >>>> id;padding-left:1ex;"> >>>>
>>>> In message <>> =3D >>>> .gmail.com >>> ">BANLkTimX2XRgJHSkUq-GAAMDs+Mb6V2VYw@mail.gmail.com >>> >,= Phi=3D >>>> llip Hallam-
>>>>
Baker writes:
>>>> > I guess that would work for the application programmers who still >>> code=3D >>>> =A0in C
>>>> > or C++. That is not where the industry has been for a decade now.=
>>>>
>>>>
The concepts are language independent.
>>>>
>>>> --
>>>>
Mark Andrews, ISC
>>>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
>>>> PHONE: >> ">+61 2=3D >>>> =A09871 4742 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 INTERNET: >> href=3D3D"mailto:=3D >>>> marka@isc.org">marka@isc.org
>>>>



--
Websit= e: >> >>>> >>> =A0href=3D3D"http://hallambaker.com/">http://hallambaker.com/

>>>>
>>>>=20 >>>> --0016e68debd4b5f20c04a6db8b0b-- >> -- >> Mark Andrews, ISC >> 1 Seymour St., Dundas Valley, NSW 2117, Australia >> PHONE: +61 2 9871 4742 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >> INTERNET: marka@isc.org >=20 >=20 From alangley@gmail.com Wed Jul 6 07:53:44 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D51B721F85E1 for ; Wed, 6 Jul 2011 07:53:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9iC2-jt6NVl7 for ; Wed, 6 Jul 2011 07:53:43 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7F20321F85D2 for ; Wed, 6 Jul 2011 07:53:43 -0700 (PDT) Received: by iye7 with SMTP id 7so7582918iye.31 for ; Wed, 06 Jul 2011 07:53:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=VZM93NIutfL6n72iiiAA24vUn7zjF3JBeh0AYryzGDU=; b=cAnmk9E+WgwQIkf/zRDooodCCkgqeEUGo+ksbyrxYctIdbGi6Q1jQWB5YEl0g8+Ijz iBTDTAjYoAtNx+6JsFc1HkxYZ6x93qAtW5gfyM5PmA2KubiEE8WBODrlZk4F4Zc7ibwB ZPyFq92K59FaMWZUppcrgSwcfq/9yc61QiqPs= MIME-Version: 1.0 Received: by 10.42.144.194 with SMTP id c2mr9432607icv.120.1309964022934; Wed, 06 Jul 2011 07:53:42 -0700 (PDT) Sender: alangley@gmail.com Received: by 10.42.213.9 with HTTP; Wed, 6 Jul 2011 07:53:42 -0700 (PDT) In-Reply-To: <4E1175F1.4080201@nlnetlabs.nl> References: <4E1175F1.4080201@nlnetlabs.nl> Date: Wed, 6 Jul 2011 10:53:42 -0400 X-Google-Sender-Auth: Dkbao3gjfgsEbZsn1e2SL0OnPfk Message-ID: From: Adam Langley To: "W.C.A. Wijngaards" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: dane@ietf.org Subject: Re: [dane] Draft for serializing DNSSEC chains (01) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 14:53:44 -0000 On Mon, Jul 4, 2011 at 4:12 AM, W.C.A. Wijngaards wro= te: > But the RFCs say you MUST NOT distinguish based on the SEP bit. It is > for human consumption (and perhaps signer automation). Thank you for the review. You're correct and I'll remove the SEP parts in the next draft and probably replace them with wording about the ZSK flag. > In case of algorithm rollover by the zones, you need to pick up one key > per algorithm to store. =C2=A0Because some machines may support only one > algorithm. The idea that a single trust path is predetermined is important for simplicity, which I greatly value. In order to keep the simplicity I'm giving the algorithm rollover problem to another layer. Unlike serving DNSSEC data using the DNS protocol, there's the possibility of choosing a different serialization for different clients. Negotiation of acceptable algorithms can thus be done by the higher layers. > A DNAME can simply be treated like you treat the CNAME redirect, but you > store the DNAME+RRSIG. =C2=A0(the synthesized CNAME can be omitted since = you > want to save bytes), then you synthesize the redirect with DNAME rules > (replace suffix labels). Yes, I believe that DNAMEs would be simple to add but I've hesitated so far because I've never seen a DNAME used in practice so have no reality on which to write test code. Cheers AGL --=20 Adam Langley agl@imperialviolet.org http://www.imperialviolet.org From fanf2@hermes.cam.ac.uk Wed Jul 6 08:10:59 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9AB421F871A for ; Wed, 6 Jul 2011 08:10:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dbCtuJMOcOLB for ; Wed, 6 Jul 2011 08:10:52 -0700 (PDT) Received: from ppsw-50.csi.cam.ac.uk (ppsw-50.csi.cam.ac.uk [131.111.8.150]) by ietfa.amsl.com (Postfix) with ESMTP id 8B42621F8766 for ; Wed, 6 Jul 2011 08:10:50 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:46068) by ppsw-50.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1QeTkV-0003Sf-sU (Exim 4.72) (return-path ); Wed, 06 Jul 2011 16:10:47 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1QeTkV-00053t-SF (Exim 4.67) (return-path ); Wed, 06 Jul 2011 16:10:47 +0100 Date: Wed, 6 Jul 2011 16:10:47 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Adam Langley In-Reply-To: Message-ID: References: <4E1175F1.4080201@nlnetlabs.nl> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: dane@ietf.org Subject: Re: [dane] Draft for serializing DNSSEC chains (01) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 15:10:59 -0000 Adam Langley wrote: > > Yes, I believe that DNAMEs would be simple to add but I've hesitated > so far because I've never seen a DNAME used in practice so have no > reality on which to write test code. Have a look at the top half of the 232.128.in-addr.arpa zone. Sadly my colleagues haven't rolled out DNSSEC to that zone or to the target of the DNAMEs yet. Tony. -- f.anthony.n.finch http://dotat.at/ Shannon: Cyclonic mainly west or northwest 6 to gale 8, decreasing 5 at times. Rough or very rough, occasionally high at first in south. Rain or squally showers. Good, occasionally poor. From hallam@gmail.com Wed Jul 6 08:55:41 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0674F21F8876 for ; Wed, 6 Jul 2011 08:55:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.565 X-Spam-Level: X-Spam-Status: No, score=-3.565 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8UbT2b1ODrW4 for ; Wed, 6 Jul 2011 08:55:36 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 373B621F8863 for ; Wed, 6 Jul 2011 08:55:36 -0700 (PDT) Received: by gyd5 with SMTP id 5so35171gyd.31 for ; Wed, 06 Jul 2011 08:55:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JhYhXOYU13lwv3LLfJeJgOOan8k/1fDY9iyglECETNE=; b=GjmyxnqBcfuRJqgtyVTuvwMA4POIRIcW/B9pdzJ4GRjcCTrsa57qQybEhxFyCVZcWC OxL2oSQjXdak1+3QS3tePkpSYg+qPUMuyv3hmvgYV1EjWN0tNjVKOPcnUAADX2OLSK5W +f7va+XRZzPycR8jY2e7KV0E3pfGBEKa2+gNA= MIME-Version: 1.0 Received: by 10.101.152.34 with SMTP id e34mr1892322ano.124.1309967735547; Wed, 06 Jul 2011 08:55:35 -0700 (PDT) Received: by 10.100.93.12 with HTTP; Wed, 6 Jul 2011 08:55:35 -0700 (PDT) In-Reply-To: References: Date: Wed, 6 Jul 2011 11:55:35 -0400 Message-ID: From: Phillip Hallam-Baker To: "Osterweil, Eric" Content-Type: multipart/alternative; boundary=001636c5bd698b673304a768a109 Cc: Adam Langley , dane@ietf.org Subject: Re: [dane] Draft for serializing DNSSEC chains X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 15:55:41 -0000 --001636c5bd698b673304a768a109 Content-Type: text/plain; charset=ISO-8859-1 It is still a bolt on, not part of the default installation. If the world was using DNS the way people in the DNS world think they should, these packages would be part of the Web Services platforms. The fact that they are not suggests a disconnect. The developer world lives in a world of C#, Java, Ruby and Python. C++ might as well be Cobol as far as they are concerned. On Wed, Jul 6, 2011 at 10:43 AM, Osterweil, Eric wrote: > > > Have you guys looked at libvdns (specifically the dns_srv.h file)? > > http://vantage-points.org/libvdns.html > > Eric > > > On 6/29/11 9:01 PM, "Phillip Hallam-Baker" wrote: > > > Yes, but you try calling them from managed code and the results are going > to > > be less than pretty. > > > > All I am saying is that there is probably a reason that very few > applications > > seem to be making use of features like SRV and I don't think it is a > problem > > with the ideas, its in the deployment. > > > > > > > > > > On Wed, Jun 29, 2011 at 7:54 PM, Mark Andrews wrote: > >> > >> In message , > Phillip > >> Hallam- > >> Baker writes: > >>>> > >>>> The concepts are independent, the code most certainly is not. > >>>> > >>>> This is why I have spent the past few weeks writing a DNS resolver in > C# to > >>>> hopefully render the issue moot. > >>>> > >>>> > >>>> While you can call unmanaged code from a managed environment like C#, > the > >>>> means of doing so is not at all pretty. And making the result > threadsafe is > >>>> a nightmare. It is in fact much easier to recode from scratch than to > use > >>>> the existing stuff. > >> > >> There are already plenty of thread safe resolver libraries. Which > >> can perform queries in parallel. They can even be talking to > >> different sets of recursive servers if you want. libresolv was > >> made thread safe in 1900's and no it was not a giant lock. > >> > >>>> Calling a math function or a crypto algorithm is one thing, but a DNS > >>>> library is by its very nature asynchronous and it is possible to have > >>>> multiple queries in flight at the same time. I suspect that a lot of > the > >>>> objections to using DNS for more sophisticated discovery come from the > lack > >>>> of decent DNS library support in modern programming languages. > >>>> > >>>> It is easy enough to support an API like this with blocking code: > >>>> > >>>> EDNS.Client resolver = new EDNS.Client (); > >>>> > >>>> EDNS.DNSMessage Response; > >>>> int result = resolver.Resolve (Domain, EDNS.DNSType.CAA, out > Response); > >>>> > >>>> > >>>> But most of us would like to have multiple queries in parallel: > >>>> > >>>> DNSClient Client = new DNSClient (); > >>>> > >>>> // Non blocking request > >>>> DNSMessage Request = new DNSQueryMessage (Domain, > >>> EDNS.DNSType.A > >>>> ); > >>>> DNSTransaction Transaction1 = Client.Send (Request); > >>>> > >>>> DNSMessage Request = new DNSQueryMessage > >>>> (Domain, EDNS.DNSType.CAA); > >>>> DNSTransaction Transaction2 = Client.Send (Request); > >>>> > >>>> // Does other useful stuff like create the message headers > >>>> // Can poll status of transactions using > >>> DNSTransaction.Complete > >>>> () > >>>> > >>>> Response = Client.Receive (Transaction1); > >>>> Response = Client.Receive (Transaction2); > >>>> > >>>> > >>>> And that is still much less than you would want a .NET library to > provide. > >>>> A > >>>> proper .NET library should let the caller loop things into the > asynchronous > >>>> caller. > >>>> > >>>> Ultimately, the goal is to produce a subclass of the TcpClient class > such > >>>> that the only difference that the programmer needs to consider is to > >>> replace > >>>> the creation method: > >>>> > >>>> public TcpClient(string hostname, int port) > >>>> > >>>> > >>>> with the creation method: > >>>> > >>>> public InternetClient(string hostname, string service, int port) > >>>> > >>>> > >>>> > >>>> The difference here is the level of abstraction. TcpClient connects > via > >>>> hostname and port and always returns a raw bytestream. InternetClient > uses > >>>> the DNS to determine what the best connection that is available for a > >>>> service. If the best connection is raw TCP it will return that, if it > can > >>>> form an SSL socket, it will return that. > >>>> > >>>> [Yes, I know that there is also the question of how to specify 'best', > but > >>>> that is something that is more usually something you want to specify > at the > >>>> host level or higher and want to avoid embedding in actual > applications] > >>>> > >>>> This actually has a major performance advantage in the right hands > because > >>>> the implementation can also be asynchronous. So in the typical calling > >>>> sequence we would have: > >>>> > >>>> // Create the socket > >>>> // Generate the message headers > >>>> // Check the socket is OK > >>>> // Send the first byte > >>>> > >>>> In terms of timing what would be going on is: > >>>> > >>>> // Create the socket > >>>> [Async socket establishment starts] > >>>> // Generate the message headers > >>>> [Wait for the socket to be completed] > >>>> // Check the socket is OK > >>>> // Send the first byte > >>>> > >>>> > >>>> Now in my preferred programming language, you could just throw up a > PAR > >>>> statement and it would work anyway, but very few programmers grok that > sort > >>>> of stuff. > >> > >> And this has gone very far from the original issue of handling unknown > types. > >> > >>>> On Wed, Jun 29, 2011 at 2:21 AM, Mark Andrews wrote: > >>>> > >>>>>> > >>>>>> In message >>>> >, > Phillip > >>>>>> Hallam- > >>>>>> Baker writes: > >>>>>>>> I guess that would work for the application programmers who still > >>>> > >>>>>>>> code in > >>>>>> C > >>>>>>>> or C++. That is not where the industry has been for a decade now. > >>>>>> > >>>>>> The concepts are language independent. > >>>>>> > >>>>>> -- > >>>>>> Mark Andrews, ISC > >>>>>> 1 Seymour St., Dundas Valley, NSW 2117, Australia > >>>>>> PHONE: +61 2 9871 4742 > > >>>> INTERNET: marka@isc.org > >>>>>> > >>>> > >>>> > >>>> > >>>> -- > >>>> Website: http://hallambaker.com/ > >>>> > >>>> --0016e68debd4b5f20c04a6db8b0b > >>>> Content-Type: text/html; charset=ISO-8859-1 > >>>> Content-Transfer-Encoding: quoted-printable > >>>> > >>>> The concepts are independent, the code most certainly is > >>> not.

>>>>>>
This is why I have spent the past few weeks writing a DNS > resolver > >>>>>> >>> in= > >>>> C# to hopefully render the issue > moot.


> >>>>
While you can call unmanaged code from a managed environment like > C#, > >>>> = > >>>> the means of doing so is not at all pretty. And making the result > >>> threadsaf= > >>>> e is a nightmare. It is in fact much easier to recode from scratch > than to > >>>> = > >>>> use the existing stuff.
> >>>>

Calling a math function or a crypto algorithm is > one >> > >>>> th= > >>>> ing, but a DNS library is by its very nature asynchronous and it is > >>> possibl= > >>>> e to have multiple queries in flight at the same time. I suspect that > a > >>> lot= > >>>> of the objections to using DNS for more sophisticated discovery come > from > >>>> = > >>>> the lack of decent DNS library support in modern programming > >>> languages. >>>> v> > >>>>


It is easy enough to support an API > >>> like= > >>>> this with blocking code:

=A0 =A0 > >>> EDNS.Client= > >>>> resolver =3D new EDNS.Client ();

=A0 =A0 > >>> EDNS.DNS= > >>>> Message Response;
> >>>>
=A0 =A0 int result =3D resolver.Resolve (Domain, > EDNS.DNSType.CAA, > >>> out= > >>>> Response);


But most of > us >> > >>>> wo= > >>>> uld like to have multiple queries in > >>> parallel:

>>>> v> > >>>> =A0 =A0 =A0 =A0 =A0 =A0 DNSClient Client =3D new DNSClient > >>> ();
<= > >>>> div>
=A0 =A0 =A0 =A0 =A0 =A0 // Non blocking > >>> request
>>>> v>
=A0 =A0 =A0 =A0 =A0 =A0 > DNSMessage > >>>> = > >>>> Request =3D new DNSQueryMessage (Domain,=A0EDNS.DNSType.A >>> class= > >>>> =3D"Apple-style-span">);
> >>>>
=A0 =A0 =A0 =A0 =A0 =A0 DNSTransaction Transaction1 =3D > >>> Client.S= > >>>> end (Request);

=A0 =A0 =A0 =A0 =A0 > =A0 > >>>> >> D= > >>>> NSMessage Request =3D new DNSQueryMessage > >>> (Domain,=A0EDNS.DNSType.CAA); >>>> v>
=A0 =A0 =A0 =A0 =A0 =A0 DNSTransaction Transaction2 =3D > >>> Client= > >>>> .Send (Request);
> >>>>

=A0 =A0 =A0 =A0 =A0 =A0 // Does other useful > >>> stuf= > >>>> f like create the message headers
=A0 =A0 =A0 =A0 =A0 =A0 // > Can > >>>> = > >>>> poll status of transactions using=A0DNSTransaction.Complete > >>> ()
>>>> r>
=A0 =A0 =A0 =A0 =A0 =A0 Response =3D Client.Receive > >>> (Tran= > >>>> saction1);
> >>>>
=A0 =A0 =A0 =A0 =A0 =A0 Response =3D Client.Receive > >>> (Transa= > >>>> ction2);


And that is > still >> > >>>> mu= > >>>> ch less than you would want a .NET library to provide. A proper .NET > >>> librar= > >>>> y should let the caller loop things into the asynchronous > caller.
> >>>>

Ultimately, the goal is to produce a subclass of > the >> > >>>> Tc= > >>>> pClient class such that the only difference that the programmer needs > to >> > >>>> co= > >>>> nsider is to replace the creation > method:

> > >>>> cl= > >>>> ass=3D"Apple-style-span" style=3D"font-family: 'Segoe UI', > >>> Verdana,= > >>>> Arial; font-size: 17px; ">
 padding-right:
> >>>> >> 5=
> >>>> px; padding-bottom: 5px; padding-left: 5px; margin-top: 0px;
> margin-right:
> >>>> =
> >>>> 0px; margin-bottom: 0px; margin-left: 0px; font-family: Consolas,
> Courier,
> >>>> =
> >>>> monospace; word-break: break-all; word-wrap: break-word; font-style:
> >>> normal=
> >>>> ; font-weight: normal; overflow-x: auto; overflow-y: auto; ">
> >>>> public TcpClient( >>> style=3D"color:=
> >>>>  blue; ">string hostname,  ">int
> >>>> >> p=
> >>>> ort)

with the creation > >>> method:
<= > >>>> div> > >>>>
>>> '= > >>>> Segoe UI', Verdana, Arial; font-size: 17px; ">
 >>> style=3D"padding-top=
> >>>> : 5px; padding-right: 5px; padding-bottom: 5px; padding-left: 5px;
> >>> margin-t=
> >>>> op: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;
> >>> font-fami=
> >>>> ly: Consolas, Courier, monospace; word-break: break-all; word-wrap:
> >>> break-w=
> >>>> ord; font-style: normal; font-weight: normal; overflow-x: auto;
> >>> overflow-y:=
> >>>>  auto; ">
> >>>> public InternetClient( >>> style=3D"c=
> >>>> olor: blue; ">string hostname,  >>> ">string<=
> >>>> /span> service, int
> >>> port)


<= > >>>> div> > >>>> The difference here is the level of abstraction. TcpClient connects > via > >>> hos= > >>>> tname and port and always returns a raw bytestream. InternetClient > uses > >>> the= > >>>> DNS to determine what the best connection that is available for a > >>> service.= > >>>> If the best connection is raw TCP it will return that, if it can form > an > >>>> >> S= > >>>> SL socket, it will return that. > >>>>

[Yes, I know that there is also the question of > how to > >>>> = > >>>> specify 'best', but that is something that is more usually > >>> somethin= > >>>> g you want to specify at the host level or higher and want to avoid > >>> embeddi= > >>>> ng in actual applications]
> >>>>

This actually has a major performance advantage in > the > >>>> = > >>>> right hands because the implementation can also be asynchronous. So in > the > >>>> = > >>>> typical calling sequence we would have:

// > Create > >>>> = > >>>> the socket
> >>>>
// Generate the message headers
// Check the socket is > >>> OK >>>> iv>
// Send the first byte

In terms of > timing > >>>> = > >>>> what would be going on is:

// Create the > >>> sock= > >>>> et
> >>>>
=A0 [Async socket establishment starts]
// Generate the > >>> mess= > >>>> age headers
=A0 [Wait for the socket to be > >>> completed]
/= > >>>> / Check the socket is OK
// Send the first > >>> byte
<= > >>>> br> > >>>>

Now in my preferred programming language, > you > >>> cou= > >>>> ld just throw up a PAR statement and it would work anyway, but very > few > >>> pro= > >>>> grammers grok that sort of stuff.


class= > >>>> =3D"gmail_quote"> > >>>> On Wed, Jun 29, 2011 at 2:21 AM, Mark Andrews < >>> href= > >>>> =3D"mailto:marka@isc.org">marka@isc.org> > >>> wrote:
>>>> e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px > #ccc > >>> sol= > >>>> id;padding-left:1ex;"> > >>>>
> >>>> In message < BANLkTimX2XRgJHSkUq-GAAMDs%2BMb6V2VYw@mail > >>> = > >>>> .gmail.com > >>> ">BANLkTimX2XRgJHSkUq-GAAMDs+Mb6V2VYw@mail.gmail.com > >>> > >, Phi= > >>>> llip Hallam-
> >>>>
Baker writes:
> >>>> > I guess that would work for the application programmers who still > >>> code= > >>>> in C
> >>>> > or C++. That is not where the industry has been for a decade > now.
> >>>>
> >>>>
The concepts are language independent.
> >>>>
> >>>> --
> >>>>
Mark Andrews, ISC
> >>>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> >>>> PHONE: >>> ">+61 2= > >>>> 9871 4742 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 INTERNET: >>> href=3D"mailto:= > >>>> marka@isc.org">marka@isc.org
> >>>>



-- >
Website: >> > >>>> >>>> href=3D"http://hallambaker.com/">http://hallambaker.com/

> >>>>
> >>>> > >>>> --0016e68debd4b5f20c04a6db8b0b-- > >> -- > >> Mark Andrews, ISC > >> 1 Seymour St., Dundas Valley, NSW 2117, Australia > >> PHONE: +61 2 9871 4742 > >> INTERNET: marka@isc.org > > > > > > -- Website: http://hallambaker.com/ --001636c5bd698b673304a768a109 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable It is still a bolt on, not part of the default installation.

=
If the world was using DNS the way people in the DNS world think they = should, these packages would be part of the Web Services platforms. The fac= t that they are not suggests a disconnect.

The developer world lives in a world of C#, Java, Ruby = and Python. C++ might as well be Cobol as far as they are concerned.
On Wed, Jul 6, 2011 at 10:43 AM, Osterweil, Eri= c <eosterwe= il@verisign.com> wrote:


Have you guys looked at libvdns (specifically the dns_srv.h file)?

=A0 =A0http://vantage-points.org/libvdns.html

Eric


On 6/29/11 9:01 PM, "Phillip Hallam-Baker" <hallam@gmail.com> wrote:

> Yes, but you try calling them from managed code and the results are go= ing to
> be less than pretty.
>
> All I am saying is that there is probably a reason that very few appli= cations
> seem to be making use of features like SRV and I don't think it is= a problem
> with the ideas, its in the deployment.
>
>
>
>
> On Wed, Jun 29, 2011 at 7:54 PM, Mark Andrews <marka@isc.org> wrote:
>>
>> In message <BANLkTikgeZbV28mj8nPSicDmQoqz0f9M4A@mail.gmail.com&g= t;, Phillip
>> Hallam-
>> Baker writes:
>>>>
>>>> The concepts are independent, the code most certainly is n= ot.
>>>>
>>>> This is why I have spent the past few weeks writing a DNS = resolver in C# to
>>>> hopefully render the issue moot.
>>>>
>>>>
>>>> While you can call unmanaged code from a managed environme= nt like C#, the
>>>> means of doing so is not at all pretty. And making the res= ult threadsafe is
>>>> a nightmare. It is in fact much easier to recode from scra= tch than to use
>>>> the existing stuff.
>>
>> There are already plenty of thread safe resolver libraries. =A0Whi= ch
>> can perform queries in parallel. =A0They can even be talking to >> different sets of recursive servers if you want. =A0libresolv was<= br> >> made thread safe in 1900's and no it was not a giant lock.
>>
>>>> Calling a math function or a crypto algorithm is one thing= , but a DNS
>>>> library is by its very nature asynchronous and it is possi= ble to have
>>>> multiple queries in flight at the same time. I suspect tha= t a lot of the
>>>> objections to using DNS for more sophisticated discovery c= ome from the lack
>>>> of decent DNS library support in modern programming langua= ges.
>>>>
>>>> It is easy enough to support an API like this with blockin= g code:
>>>>
>>>> =A0 =A0 EDNS.Client resolver =3D new EDNS.Client ();
>>>>
>>>> =A0 =A0 EDNS.DNSMessage Response;
>>>> =A0 =A0 int result =3D resolver.Resolve (Domain, EDNS.DNST= ype.CAA, out Response);
>>>>
>>>>
>>>> But most of us would like to have multiple queries in para= llel:
>>>>
>>>> =A0 =A0 =A0 =A0 =A0 =A0 DNSClient Client =3D new DNSClient= ();
>>>>
>>>> =A0 =A0 =A0 =A0 =A0 =A0 // Non blocking request
>>>> =A0 =A0 =A0 =A0 =A0 =A0 DNSMessage Request =3D new DNSQuer= yMessage (Domain,
>>> EDNS.DNSType.A
>>>> );
>>>> =A0 =A0 =A0 =A0 =A0 =A0 DNSTransaction Transaction1 =3D Cl= ient.Send (Request);
>>>>
>>>> =A0 =A0 =A0 =A0 =A0 =A0 DNSMessage Request =3D new DNSQuer= yMessage
>>>> (Domain, EDNS.DNSType.CAA);
>>>> =A0 =A0 =A0 =A0 =A0 =A0 DNSTransaction Transaction2 =3D Cl= ient.Send (Request);
>>>>
>>>> =A0 =A0 =A0 =A0 =A0 =A0 // Does other useful stuff like cr= eate the message headers
>>>> =A0 =A0 =A0 =A0 =A0 =A0 // Can poll status of transactions= using
>>> DNSTransaction.Complete
>>>> ()
>>>>
>>>> =A0 =A0 =A0 =A0 =A0 =A0 Response =3D Client.Receive (Trans= action1);
>>>> =A0 =A0 =A0 =A0 =A0 =A0 Response =3D Client.Receive (Trans= action2);
>>>>
>>>>
>>>> And that is still much less than you would want a .NET lib= rary to provide.
>>>> A
>>>> proper .NET library should let the caller loop things into= the asynchronous
>>>> caller.
>>>>
>>>> Ultimately, the goal is to produce a subclass of the TcpCl= ient class such
>>>> that the only difference that the programmer needs to cons= ider is to
>>> replace
>>>> the creation method:
>>>>
>>>> public TcpClient(string hostname, int port)
>>>>
>>>>
>>>> with the creation method:
>>>>
>>>> public InternetClient(string hostname, string service, int= port)
>>>>
>>>>
>>>>
>>>> The difference here is the level of abstraction. TcpClient= connects via
>>>> hostname and port and always returns a raw bytestream. Int= ernetClient uses
>>>> the DNS to determine what the best connection that is avai= lable for a
>>>> service. If the best connection is raw TCP it will return = that, if it can
>>>> form an SSL socket, it will return that.
>>>>
>>>> [Yes, I know that there is also the question of how to spe= cify 'best', but
>>>> that is something that is more usually something you want = to specify at the
>>>> host level or higher and want to avoid embedding in actual= applications]
>>>>
>>>> This actually has a major performance advantage in the rig= ht hands because
>>>> the implementation can also be asynchronous. So in the typ= ical calling
>>>> sequence we would have:
>>>>
>>>> // Create the socket
>>>> // Generate the message headers
>>>> // Check the socket is OK
>>>> // Send the first byte
>>>>
>>>> In terms of timing what would be going on is:
>>>>
>>>> // Create the socket
>>>> =A0 [Async socket establishment starts]
>>>> // Generate the message headers
>>>> =A0 [Wait for the socket to be completed]
>>>> // Check the socket is OK
>>>> // Send the first byte
>>>>
>>>>
>>>> Now in my preferred programming language, you could just t= hrow up a PAR
>>>> statement and it would work anyway, but very few programme= rs grok that sort
>>>> of stuff.
>>
>> And this has gone very far from the original issue of handling unk= nown types.
>>
>>>> On Wed, Jun 29, 2011 at 2:21 AM, Mark Andrews <marka@isc.org> wrote:
>>>>
>>>>>>
>>>>>> In message <BANLkTimX2XRgJHSkUq-GAAMDs+Mb6V2VYw@ma= il.gmail.com
>>>> <mailto:BANLkTimX2XRgJHSkUq-GAAMDs%2BMb6V2VY= w@mail.gmail.com> >, Phillip
>>>>>> Hallam-
>>>>>> Baker writes:
>>>>>>>> I guess that would work for the applicatio= n programmers who still >>>>
>>>>>>>> code in
>>>>>> C
>>>>>>>> or C++. That is not where the industry has= been for a decade now.
>>>>>>
>>>>>> The concepts are language independent.
>>>>>>
>>>>>> --
>>>>>> Mark Andrews, ISC
>>>>>> 1 Seymour St., Dundas Valley, NSW 2117, Australia<= br>
>>>>>> PHONE: +61 2 9871 4742 <tel:%2B61%202%209871%2047= 42> =A0=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0
>>>> INTERNET: marka@isc.org
>>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Website: http://hallambaker.com/
>>>>
>>>> --0016e68debd4b5f20c04a6db8b0b
>>>> Content-Type: text/html; charset=3DISO-8859-1
>>>> Content-Transfer-Encoding: quoted-printable
>>>>
>>>> The concepts are independent, the code most certainly is >>> not.<div><br></div=3D
>>>>>> <div>This is why I have spent the past few w= eeks writing a DNS resolver
>>>>>> >>> in=3D
>>>> =A0C# to hopefully render the issue moot.</div><d= iv><br></div><div><br></div>
>>>> <div>While you can call unmanaged code from a manage= d environment like C#,
>>>> =3D
>>>> the means of doing so is not at all pretty. And making the= result
>>> threadsaf=3D
>>>> e is a nightmare. It is in fact much easier to recode from= scratch than to
>>>> =3D
>>>> use the existing stuff.</div>
>>>> <div><br></div><div>Calling a math= function or a crypto algorithm is one >>
>>>> th=3D
>>>> ing, but a DNS library is by its very nature asynchronous = and it is
>>> possibl=3D
>>>> e to have multiple queries in flight at the same time. I s= uspect that a
>>> lot=3D
>>>> =A0of the objections to using DNS for more sophisticated d= iscovery come from
>>>> =3D
>>>> the lack of decent DNS library support in modern programmi= ng
>>> languages.</di=3D
>>>> v>
>>>> <div><br></div><div><br><= /div><div>It is easy enough to support an API
>>> like=3D
>>>> =A0this with blocking code:</div><div><br&g= t;</div><div><div>=3DA0 =3DA0
>>> EDNS.Client=3D
>>>> =A0resolver =3D3D new EDNS.Client ();</div><div&g= t;<br></div><div>=3DA0 =3DA0
>>> EDNS.DNS=3D
>>>> Message Response;</div>
>>>> <div>=3DA0 =3DA0 int result =3D3D resolver.Resolve (= Domain, EDNS.DNSType.CAA,
>>> out=3D
>>>> =A0Response);</div><div><br></div>= </div><div><br></div><div>But most of us >= >
>>>> wo=3D
>>>> uld like to have multiple queries in
>>> parallel:</div><div><br></div><div&= gt;<di=3D
>>>> v>
>>>> =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 DNSClient Client =3D3D= new DNSClient
>>> ();</div></div><=3D
>>>> div><br></div><div>=3DA0 =3DA0 =3DA0 = =3DA0 =3DA0 =3DA0 // Non blocking
>>> request</div><di=3D
>>>> v><div><span class=3D3D"Apple-style-span&= quot;>=3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 DNSMessage
>>>> =3D
>>>> Request =3D3D new DNSQueryMessage (Domain,=3DA0</span&g= t;EDNS.DNSType.A<span
>>> class=3D
>>>> =3D3D"Apple-style-span">);</span></d= iv>
>>>> </div><div>=3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0= DNSTransaction Transaction1 =3D3D
>>> Client.S=3D
>>>> end (Request);</div><div><br></div>= ;<div><div><div>=3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0
>>>> >> D=3D
>>>> NSMessage Request =3D3D new DNSQueryMessage
>>> (Domain,=3DA0EDNS.DNSType.CAA);</di=3D
>>>> v></div><div>=3DA0 =3DA0 =3DA0 =3DA0 =3DA0 = =3DA0 DNSTransaction Transaction2 =3D3D
>>> Client=3D
>>>> .Send (Request);</div>
>>>> </div><div><br></div><div>= =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 // Does other useful
>>> stuf=3D
>>>> f like create the message headers</div><div>= =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 // Can
>>>> =3D
>>>> poll status of transactions using=3DA0DNSTransaction.Compl= ete
>>> ()</div><div><b=3D
>>>> r></div><div><div>=3DA0 =3DA0 =3DA0 = =3DA0 =3DA0 =3DA0 Response =3D3D Client.Receive
>>> (Tran=3D
>>>> saction1);</div>
>>>> </div><div><div>=3DA0 =3DA0 =3DA0 =3DA0 = =3DA0 =3DA0 Response =3D3D Client.Receive
>>> (Transa=3D
>>>> ction2);</div></div><div><br></= div><div><br></div><div>And that is still >&g= t;
>>>> mu=3D
>>>> ch less than you would want a .NET library to provide. A p= roper .NET
>>> librar=3D
>>>> y should let the caller loop things into the asynchronous = caller.</div>
>>>> <div><br></div><div>Ultimately, th= e goal is to produce a subclass of the >>
>>>> Tc=3D
>>>> pClient class such that the only difference that the progr= ammer needs to >>
>>>> co=3D
>>>> nsider is to replace the creation method:</div><d= iv><br></div><div><span >>
>>>> cl=3D
>>>> ass=3D3D"Apple-style-span" style=3D3D"font-= family: &#39;Segoe UI&#39;,
>>> Verdana,=3D
>>>> =A0Arial; font-size: 17px; "><pre style=3D3D&qu= ot;padding-top: 5px; padding-right:
>>>> >> 5=3D
>>>> px; padding-bottom: 5px; padding-left: 5px; margin-top: 0p= x; margin-right:
>>>> =3D
>>>> 0px; margin-bottom: 0px; margin-left: 0px; font-family: Co= nsolas, Courier,
>>>> =3D
>>>> monospace; word-break: break-all; word-wrap: break-word; f= ont-style:
>>> normal=3D
>>>> ; font-weight: normal; overflow-x: auto; overflow-y: auto;= ">
>>>> <span style=3D3D"color: blue; ">public<= /span> TcpClient(<span
>>> style=3D3D"color:=3D
>>>> =A0blue; ">string</span> hostname, <span = style=3D3D"color: blue; ">int</span>
>>>> >> p=3D
>>>> ort)</pre></span></div><div><br= ></div><div>with the creation
>>> method:</div><=3D
>>>> div>
>>>> <br></div><div><span class=3D3D"= Apple-style-span" style=3D3D"font-family:
>>> &#39;=3D
>>>> Segoe UI&#39;, Verdana, Arial; font-size: 17px; "= ><pre
>>> style=3D3D"padding-top=3D
>>>> : 5px; padding-right: 5px; padding-bottom: 5px; padding-le= ft: 5px;
>>> margin-t=3D
>>>> op: 0px; margin-right: 0px; margin-bottom: 0px; margin-lef= t: 0px;
>>> font-fami=3D
>>>> ly: Consolas, Courier, monospace; word-break: break-all; w= ord-wrap:
>>> break-w=3D
>>>> ord; font-style: normal; font-weight: normal; overflow-x: = auto;
>>> overflow-y:=3D
>>>> =A0auto; ">
>>>> <span style=3D3D"color: blue; ">public<= /span> InternetClient(<span
>>> style=3D3D"c=3D
>>>> olor: blue; ">string</span> hostname, <sp= an style=3D3D"color: blue;
>>> ">string<=3D
>>>> /span> service, int
>>> port)</pre></span></div><div><br>= ;</div><div><br></div><=3D
>>>> div>
>>>> The difference here is the level of abstraction. TcpClient= connects via
>>> hos=3D
>>>> tname and port and always returns a raw bytestream. Intern= etClient uses
>>> the=3D
>>>> =A0DNS to determine what the best connection that is avail= able for a
>>> service.=3D
>>>> =A0If the best connection is raw TCP it will return that, = if it can form an
>>>> >> S=3D
>>>> SL socket, it will return that.</div>
>>>> <div><br></div><div>[Yes, I know t= hat there is also the question of how to
>>>> =3D
>>>> specify &#39;best&#39;, but that is something that= is more usually
>>> somethin=3D
>>>> g you want to specify at the host level or higher and want= to avoid
>>> embeddi=3D
>>>> ng in actual applications]</div>
>>>> <div><br></div><div>This actually = has a major performance advantage in the
>>>> =3D
>>>> right hands because the implementation can also be asynchr= onous. So in the
>>>> =3D
>>>> typical calling sequence we would have:</div><div= ><br></div><div>// Create
>>>> =3D
>>>> the socket</div>
>>>> <div>// Generate the message headers</div><= div>// Check the socket is
>>> OK</d=3D
>>>> iv><div>// Send the first byte</div><div= ><br></div><div>In terms of timing
>>>> =3D
>>>> what would be going on is:</div><div><br>= ;</div><div><div>// Create the
>>> sock=3D
>>>> et</div>
>>>> <div>=3DA0 [Async socket establishment starts]</d= iv><div>// Generate the
>>> mess=3D
>>>> age headers</div><div>=3DA0 [Wait for the sock= et to be
>>> completed]</div><div>/=3D
>>>> / Check the socket is OK</div><div>// Send the= first
>>> byte</div></div><div><=3D
>>>> br>
>>>> </div><div><br></div><div>No= w in my preferred programming language, you
>>> cou=3D
>>>> ld just throw up a PAR statement and it would work anyway,= but very few
>>> pro=3D
>>>> grammers grok that sort of stuff.</div><div>&l= t;br></div><div><br><div class=3D
>>>> =3D3D"gmail_quote">
>>>> On Wed, Jun 29, 2011 at 2:21 AM, Mark Andrews <span dir= =3D3D"ltr">&lt;<a
>>> href=3D
>>>> =3D3D"mailto:marka@i= sc.org">marka@isc.org</= a>&gt;</span>
>>> wrote:<br><blockquot=3D
>>>> e class=3D3D"gmail_quote" style=3D3D"margin= :0 0 0 .8ex;border-left:1px #ccc
>>> sol=3D
>>>> id;padding-left:1ex;">
>>>> <br>
>>>> In message &lt;<a href=3D3D"mailto:BANLkTimX2XRgJHSkUq-GA= AMDs%2BMb6V2VYw@mail
>>> <mailto:BANLkTimX2XRgJHSkUq-GAAMDs%252BMb6V2VYw@mail= > =3D
>>>> .gmail.com<= /a> <http://gmail.com= >
>>> ">BANLkTimX2XRgJHSkUq-GAAMDs+Mb6V2VYw@m= ail.gmail.com
>>> <mailto:BANLkTimX2XRgJHSkUq-GAAMDs%2BMb6V2VYw@mail.gma= il.com> </a>&gt;, Phi=3D
>>>> llip Hallam-<br>
>>>> <div class=3D3D"im">Baker writes:<br>= ;
>>>> &gt; I guess that would work for the application progr= ammers who still
>>> code=3D
>>>> =A0in C<br>
>>>> &gt; or C++. That is not where the industry has been f= or a decade now.<br>
>>>> <br>
>>>> </div>The concepts are language independent.<br&g= t;
>>>> <font color=3D3D"#888888"><br>
>>>> --<br>
>>>> </font><div><div></div><div cla= ss=3D3D"h5">Mark Andrews, ISC<br>
>>>> 1 Seymour St., Dundas Valley, NSW 2117, Australia<br>= ;
>>>> PHONE: <a href=3D3D"tel:%2B61%202%209871%204742&qu= ot; value=3D3D"+= 61298714742
>>> <tel:%2B61298714742> ">+61 2=3D
>>>> =A09871 4742</a> =3DA0 =3DA0 =3DA0= =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 INTERNET: <a
>>> href=3D3D"mailto:=3D
>>>> marka@isc.org"&g= t;marka@isc.org</a><br> >>>> </div></div></blockquote></div><= ;br><br clear=3D3D"all"><br>-- <br>Website: = >>
>>>> <a=3D
>>>> =A0href=3D3D"http://hallambaker.com/">http://hallambaker.com/</a><br&g= t;<br>
>>>> </div>
>>>>
>>>> --0016e68debd4b5f20c04a6db8b0b--
>> --
>> Mark Andrews, ISC
>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
>> PHONE: +61 2 9871 4742 <tel:%2B61%202%209871%204742> =A0=A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0
>> INTERNET: marka@isc.org
>
>




--
Website: http://hallambaker.com/

--001636c5bd698b673304a768a109-- From eosterweil@verisign.com Wed Jul 6 10:34:57 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B817121F891F for ; Wed, 6 Jul 2011 10:34:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.639 X-Spam-Level: X-Spam-Status: No, score=-5.639 tagged_above=-999 required=5 tests=[AWL=-0.436, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7QJtU3wJShX6 for ; Wed, 6 Jul 2011 10:34:56 -0700 (PDT) Received: from exprod6og110.obsmtp.com (exprod6og110.obsmtp.com [64.18.1.25]) by ietfa.amsl.com (Postfix) with ESMTP id 8ECBE21F891A for ; Wed, 6 Jul 2011 10:34:52 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob110.postini.com ([64.18.5.12]) with SMTP ID DSNKThScu2nQDqXlcOIeBNqlvixmEPTbid3u@postini.com; Wed, 06 Jul 2011 10:34:55 PDT Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id p66HYo8r009678; Wed, 6 Jul 2011 13:34:50 -0400 Received: from DUL1WNEXMB11.vcorp.ad.vrsn.com ([10.170.13.11]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 6 Jul 2011 13:34:50 -0400 Received: from 10.131.30.110 ([10.131.30.110]) by DUL1WNEXMB11.vcorp.ad.vrsn.com ([10.170.13.11]) with Microsoft Exchange Server HTTP-DAV ; Wed, 6 Jul 2011 17:34:38 +0000 User-Agent: Microsoft-Entourage/12.29.0.110113 Date: Wed, 06 Jul 2011 13:34:36 -0400 From: "Osterweil, Eric" To: Phillip Hallam-Baker Message-ID: Thread-Topic: [dane] Draft for serializing DNSSEC chains Thread-Index: Acw79TiDe2YyP39XSDC5iUCAswVhigADcD0h In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 06 Jul 2011 17:34:50.0363 (UTC) FILETIME=[02093CB0:01CC3C03] Cc: Adam Langley , dane@ietf.org Subject: Re: [dane] Draft for serializing DNSSEC chains X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 17:34:57 -0000 On 7/6/11 11:55 AM, "Phillip Hallam-Baker" wrote: > It is still a bolt on, not part of the default installation. A dependency? Sure. ;) Eric =20 > If the world was using DNS the way people in the DNS world think they sho= uld, > these packages would be part of the Web Services platforms. The fact that= they > are not suggests a disconnect. >=20 > The developer world lives in a world of C#, Java, Ruby and Python. C++ mi= ght > as well be Cobol as far as they are concerned. >=20 > On Wed, Jul 6, 2011 at 10:43 AM, Osterweil, Eric > wrote: >>=20 >>=20 >> Have you guys looked at libvdns (specifically the dns_srv.h file)? >>=20 >> =A0 =A0http://vantage-points.org/libvdns.html >>=20 >> Eric >>=20 >>=20 >> On 6/29/11 9:01 PM, "Phillip Hallam-Baker" wrote: >>=20 >>>> Yes, but you try calling them from managed code and the results are go= ing >>>> >> to >>>> be less than pretty. >>>>=20 >>>> All I am saying is that there is probably a reason that very few >>> applications >>>> seem to be making use of features like SRV and I don't think it is a >>> problem >>>> with the ideas, its in the deployment. >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> On Wed, Jun 29, 2011 at 7:54 PM, Mark Andrews wrote: >>>>>>=20 >>>>>> In message , Phi= llip >>>>>> Hallam- >>>>>> Baker writes: >>>>>>>>>>=20 >>>>>>>>>> The concepts are independent, the code most certainly is not. >>>>>>>>>>=20 >>>>>>>>>> This is why I have spent the past few weeks writing a DNS resolv= er in >>>>>>>>>> >>>>> C# to >>>>>>>>>> hopefully render the issue moot. >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> While you can call unmanaged code from a managed environment lik= e C#, >>>>>>>>>> the >>>>>>>>>> means of doing so is not at all pretty. And making the result >>>>>> threadsafe is >>>>>>>>>> a nightmare. It is in fact much easier to recode from scratch th= an to >>>>>>>>>> use >>>>>>>>>> the existing stuff. >>>>>>=20 >>>>>> There are already plenty of thread safe resolver libraries. =A0Which >>>>>> can perform queries in parallel. =A0They can even be talking to >>>>>> different sets of recursive servers if you want. =A0libresolv was >>>>>> made thread safe in 1900's and no it was not a giant lock. >>>>>>=20 >>>>>>>>>> Calling a math function or a crypto algorithm is one thing, but = a DNS >>>>>>>>>> library is by its very nature asynchronous and it is possible to= have >>>>>>>>>> multiple queries in flight at the same time. I suspect that a lo= t of >>>>>>>>>> the >>>>>>>>>> objections to using DNS for more sophisticated discovery come fr= om >>>>>> the lack >>>>>>>>>> of decent DNS library support in modern programming languages. >>>>>>>>>>=20 >>>>>>>>>> It is easy enough to support an API like this with blocking code= : >>>>>>>>>>=20 >>>>>>>>>> =A0 =A0 EDNS.Client resolver =3D new EDNS.Client (); >>>>>>>>>>=20 >>>>>>>>>> =A0 =A0 EDNS.DNSMessage Response; >>>>>>>>>> =A0 =A0 int result =3D resolver.Resolve (Domain, EDNS.DNSType.CAA, out >>>>>> Response); >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> But most of us would like to have multiple queries in parallel: >>>>>>>>>>=20 >>>>>>>>>> =A0 =A0 =A0 =A0 =A0 =A0 DNSClient Client =3D new DNSClient (); >>>>>>>>>>=20 >>>>>>>>>> =A0 =A0 =A0 =A0 =A0 =A0 // Non blocking request >>>>>>>>>> =A0 =A0 =A0 =A0 =A0 =A0 DNSMessage Request =3D new DNSQueryMessage (Domain, >>>>>>>> EDNS.DNSType.A >>>>>>>>>> ); >>>>>>>>>> =A0 =A0 =A0 =A0 =A0 =A0 DNSTransaction Transaction1 =3D Client.Send (Request); >>>>>>>>>>=20 >>>>>>>>>> =A0 =A0 =A0 =A0 =A0 =A0 DNSMessage Request =3D new DNSQueryMessage >>>>>>>>>> (Domain, EDNS.DNSType.CAA); >>>>>>>>>> =A0 =A0 =A0 =A0 =A0 =A0 DNSTransaction Transaction2 =3D Client.Send (Request); >>>>>>>>>>=20 >>>>>>>>>> =A0 =A0 =A0 =A0 =A0 =A0 // Does other useful stuff like create the message >>>>>> headers >>>>>>>>>> =A0 =A0 =A0 =A0 =A0 =A0 // Can poll status of transactions using >>>>>>>> DNSTransaction.Complete >>>>>>>>>> () >>>>>>>>>>=20 >>>>>>>>>> =A0 =A0 =A0 =A0 =A0 =A0 Response =3D Client.Receive (Transaction1); >>>>>>>>>> =A0 =A0 =A0 =A0 =A0 =A0 Response =3D Client.Receive (Transaction2); >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> And that is still much less than you would want a .NET library t= o >>>>>> provide. >>>>>>>>>> A >>>>>>>>>> proper .NET library should let the caller loop things into the >>>>>> asynchronous >>>>>>>>>> caller. >>>>>>>>>>=20 >>>>>>>>>> Ultimately, the goal is to produce a subclass of the TcpClient c= lass >>>>>>>>>> such >>>>>>>>>> that the only difference that the programmer needs to consider i= s to >>>>>>>> replace >>>>>>>>>> the creation method: >>>>>>>>>>=20 >>>>>>>>>> public TcpClient(string hostname, int port) >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> with the creation method: >>>>>>>>>>=20 >>>>>>>>>> public InternetClient(string hostname, string service, int port) >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> The difference here is the level of abstraction. TcpClient conne= cts >>>>>>>>>> via >>>>>>>>>> hostname and port and always returns a raw bytestream. InternetC= lient >>>>>>>>>> uses >>>>>>>>>> the DNS to determine what the best connection that is available = for a >>>>>>>>>> service. If the best connection is raw TCP it will return that, = if it >>>>>>>>>> can >>>>>>>>>> form an SSL socket, it will return that. >>>>>>>>>>=20 >>>>>>>>>> [Yes, I know that there is also the question of how to specify >>>>>> 'best', but >>>>>>>>>> that is something that is more usually something you want to spe= cify >>>>>>>>>> >>>>> at the >>>>>>>>>> host level or higher and want to avoid embedding in actual >>>>>> applications] >>>>>>>>>>=20 >>>>>>>>>> This actually has a major performance advantage in the right han= ds >>>>>> because >>>>>>>>>> the implementation can also be asynchronous. So in the typical >>>>>> calling >>>>>>>>>> sequence we would have: >>>>>>>>>>=20 >>>>>>>>>> // Create the socket >>>>>>>>>> // Generate the message headers >>>>>>>>>> // Check the socket is OK >>>>>>>>>> // Send the first byte >>>>>>>>>>=20 >>>>>>>>>> In terms of timing what would be going on is: >>>>>>>>>>=20 >>>>>>>>>> // Create the socket >>>>>>>>>> =A0 [Async socket establishment starts] >>>>>>>>>> // Generate the message headers >>>>>>>>>> =A0 [Wait for the socket to be completed] >>>>>>>>>> // Check the socket is OK >>>>>>>>>> // Send the first byte >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> Now in my preferred programming language, you could just throw u= p a >>>>>>>>>> PAR >>>>>>>>>> statement and it would work anyway, but very few programmers gro= k >>>>>> that sort >>>>>>>>>> of stuff. >>>>>>=20 >>>>>> And this has gone very far from the original issue of handling unkno= wn >>>> types. >>>>>>=20 >>>>>>>>>> On Wed, Jun 29, 2011 at 2:21 AM, Mark Andrews wr= ote: >>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> In message >>>>>>> >>>>>>>>>> >>>>> > >, >>>>>> Phillip >>>>>>>>>>>> Hallam- >>>>>>>>>>>> Baker writes: >>>>>>>>>>>> I guess that would work for the application programmers who >>>>>>>>>>>> >>>>>>>>> still >>>> >>>>>>>>>>>> code in >>>>>>>>>>>> C >>>>>>>>>>>> or C++. That is not where the industry has been for a decade n= ow. >>>>>>>>>>>>=20 >>>>>>>>>>>> The concepts are language independent. >>>>>>>>>>>>=20 >>>>>>>>>>>> -- >>>>>>>>>>>> Mark Andrews, ISC >>>>>>>>>>>> 1 Seymour St., Dundas Valley, NSW 2117, Australia >>>>>>>>>>>> PHONE: +61 2 9871 4742 >>>>>>>> =A0=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >>>>>>>>>> INTERNET: marka@isc.org >>>>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> -- >>>>>>>>>> Website: http://hallambaker.com/ >>>>>>>>>>=20 >>>>>>>>>> --0016e68debd4b5f20c04a6db8b0b >>>>>>>>>> Content-Type: text/html; charset=3DISO-8859-1 >>>>>>>>>> Content-Transfer-Encoding: quoted-printable >>>>>>>>>>=20 >>>>>>>>>> The concepts are independent, the code most certainly is >>>>>>>> not.

>>>>>>>>>>>
This is why I have spent the past few weeks writing a DNS >>>>>>>>>>>> >>>>>>> resolver >>>>>>>>>>>> in=3D >>>>>>>>>> =A0C# to hopefully render the issue >>>>>> moot.


>>>>>>>>>>
While you can call unmanaged code from a managed environmen= t >>>>>> like C#, >>>>>>>>>> =3D >>>>>>>>>> the means of doing so is not at all pretty. And making the resul= t >>>>>>>> threadsaf=3D >>>>>>>>>> e is a nightmare. It is in fact much easier to recode from scrat= ch >>>>>> than to >>>>>>>>>> =3D >>>>>>>>>> use the existing stuff.
>>>>>>>>>>

Calling a math function or a crypto algorith= m is >>>>>>>>>> >>>>> one >> >>>>>>>>>> th=3D >>>>>>>>>> ing, but a DNS library is by its very nature asynchronous and it= is >>>>>>>> possibl=3D >>>>>>>>>> e to have multiple queries in flight at the same time. I suspect= that >>>>>>>>>> a >>>>>>>> lot=3D >>>>>>>>>> =A0of the objections to using DNS for more sophisticated discovery= come >>>>>>>>>> from >>>>>>>>>> =3D >>>>>>>>>> the lack of decent DNS library support in modern programming >>>>>>>> languages.>>>>>>>>> v> >>>>>>>>>>


It is easy enough to support = an >>>>>>>>>> API >>>>>>>> like=3D >>>>>>>>>> =A0this with blocking code:

=3DA0 =3DA0 >>>>>>>> EDNS.Client=3D >>>>>>>>>> =A0resolver =3D3D new EDNS.Client ();

=3DA0 =3D= A0 >>>>>>>> EDNS.DNS=3D >>>>>>>>>> Message Response;
>>>>>>>>>>
=3DA0 =3DA0 int result =3D3D resolver.Resolve (Domain, >>>>>> EDNS.DNSType.CAA, >>>>>>>> out=3D >>>>>>>>>> =A0Response);


But mo= st of >>>>>>>>>> >>>>> us >> >>>>>>>>>> wo=3D >>>>>>>>>> uld like to have multiple queries in >>>>>>>> parallel:

>>>>>>>>> v> >>>>>>>>>> =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 DNSClient Client =3D3D new DNSClient >>>>>>>> ();
<=3D >>>>>>>>>> div>
=3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 // Non blocking >>>>>>>> request
>>>>>>>>> v>
=3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 >>>>>> DNSMessage >>>>>>>>>> =3D >>>>>>>>>> Request =3D3D new DNSQueryMessage (Domain,=3DA0EDNS.DNSType.A= >>>>>>> class=3D >>>>>>>>>> =3D3D"Apple-style-span">);
>>>>>>>>>>
=3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 DNSTransaction Transaction1 =3D= 3D >>>>>>>> Client.S=3D >>>>>>>>>> end (Request);

=3DA0 =3DA0 =3DA0 =3DA= 0 =3DA0 >>>>>>>>>> =3DA0 >>>>>>>>>>>> D=3D >>>>>>>>>> NSMessage Request =3D3D new DNSQueryMessage >>>>>>>> (Domain,=3DA0EDNS.DNSType.CAA);>>>>>>>>> v>
=3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 DNSTransaction Transaction2= =3D3D >>>>>>>> Client=3D >>>>>>>>>> .Send (Request);
>>>>>>>>>>

=3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 // Does other = >>>>> >>>>>>>>>> useful >>>>>>>> stuf=3D >>>>>>>>>> f like create the message headers
=3DA0 =3DA0 =3DA0 =3DA0 =3DA0 = =3DA0 >>>>>>>>>> >>>>> // Can >>>>>>>>>> =3D >>>>>>>>>> poll status of transactions using=3DA0DNSTransaction.Complete >>>>>>>> ()
>>>>>>>>> r>
=3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 Response =3D3D Client.Re= ceive >>>>>>>> (Tran=3D >>>>>>>>>> saction1);
>>>>>>>>>>
=3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 Response =3D3D Client.Rece= ive >>>>>>>> (Transa=3D >>>>>>>>>> ction2);


And that = is >>>>>> still >> >>>>>>>>>> mu=3D >>>>>>>>>> ch less than you would want a .NET library to provide. A proper = .NET >>>>>>>> librar=3D >>>>>>>>>> y should let the caller loop things into the asynchronous >>>>>> caller.
>>>>>>>>>>

Ultimately, the goal is to produce a subclas= s of >>>>>>>>>> >>>>> the >> >>>>>>>>>> Tc=3D >>>>>>>>>> pClient class such that the only difference that the programmer = needs >>>>>>>>>> >>>>> to >> >>>>>>>>>> co=3D >>>>>>>>>> nsider is to replace the creation >>>>>> method:

> >>>>>>>>>> cl=3D >>>>>>>>>> ass=3D3D"Apple-style-span" style=3D3D"font-family: 'Segoe UI'= ;, >>>>>>>> Verdana,=3D >>>>>>>>>> =A0Arial; font-size: 17px; ">
>>>>> padding-right:
>>>>>>>>>>>> 5=3D
>>>>>>>>>> px; padding-bottom: 5px; padding-left: 5px; margin-top: 0px;
>>>>>> margin-right:
>>>>>>>>>> =3D
>>>>>>>>>> 0px; margin-bottom: 0px; margin-left: 0px; font-family: Consolas=
,
>>>>>> Courier,
>>>>>>>>>> =3D
>>>>>>>>>> monospace; word-break: break-all; word-wrap: break-word; font-st=
yle:
>>>>>>>> normal=3D
>>>>>>>>>> ; font-weight: normal; overflow-x: auto; overflow-y: auto; ">
>>>>>>>>>> public TcpClient(>>>>>>> style=3D3D"color:=3D
>>>>>>>>>> =A0blue; ">string hostname, >>>>> ">int
>>>>>>>>>>>> p=3D
>>>>>>>>>> ort)

with the creation >>>>>>>> method:
<=3D >>>>>>>>>> div> >>>>>>>>>>
>>>>>>> '=3D >>>>>>>>>> Segoe UI', Verdana, Arial; font-size: 17px; ">
>>>>>>> style=3D3D"padding-top=3D
>>>>>>>>>> : 5px; padding-right: 5px; padding-bottom: 5px; padding-left: 5p=
x;
>>>>>>>> margin-t=3D
>>>>>>>>>> op: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px=
;
>>>>>>>> font-fami=3D
>>>>>>>>>> ly: Consolas, Courier, monospace; word-break: break-all; word-wr=
ap:
>>>>>>>> break-w=3D
>>>>>>>>>> ord; font-style: normal; font-weight: normal; overflow-x: auto;
>>>>>>>> overflow-y:=3D
>>>>>>>>>> =A0auto; ">
>>>>>>>>>> public InternetClient(>>>>>>> style=3D3D"c=3D
>>>>>>>>>> olor: blue; ">string hostname, >>>>>>> ">string<=3D
>>>>>>>>>> /span> service, int
>>>>>>>> port)


<=3D >>>>>>>>>> div> >>>>>>>>>> The difference here is the level of abstraction. TcpClient conne= cts >>>>>>>>>> via >>>>>>>> hos=3D >>>>>>>>>> tname and port and always returns a raw bytestream. InternetClie= nt >>>>>>>>>> uses >>>>>>>> the=3D >>>>>>>>>> =A0DNS to determine what the best connection that is available for= a >>>>>>>> service.=3D >>>>>>>>>> =A0If the best connection is raw TCP it will return that, if it ca= n >>>>>> form an >>>>>>>>>>>> S=3D >>>>>>>>>> SL socket, it will return that. >>>>>>>>>>

[Yes, I know that there is also the question= of >>>>>>>>>> >>>>> how to >>>>>>>>>> =3D >>>>>>>>>> specify 'best', but that is something that is more usual= ly >>>>>>>> somethin=3D >>>>>>>>>> g you want to specify at the host level or higher and want to av= oid >>>>>>>> embeddi=3D >>>>>>>>>> ng in actual applications]
>>>>>>>>>>

This actually has a major performance advant= age >>>>>>>>>> >>>>> in the >>>>>>>>>> =3D >>>>>>>>>> right hands because the implementation can also be asynchronous.= So >>>>>>>>>> >>>>> in the >>>>>>>>>> =3D >>>>>>>>>> typical calling sequence we would have:

// >>>>>>>>>> >>>>> Create >>>>>>>>>> =3D >>>>>>>>>> the socket >>>>>>>>>>
// Generate the message headers
// Check the sock= et is >>>>>>>> OK>>>>>>>>> iv>
// Send the first byte

In terms= of >>>>>>>>>> >>>>> timing >>>>>>>>>> =3D >>>>>>>>>> what would be going on is:

// Crea= te >>>>>>>>>> the >>>>>>>> sock=3D >>>>>>>>>> et
>>>>>>>>>>
=3DA0 [Async socket establishment starts]
// Genera= te >>>>>>>>>> the >>>>>>>> mess=3D >>>>>>>>>> age headers
=3DA0 [Wait for the socket to be >>>>>>>> completed]
/=3D >>>>>>>>>> / Check the socket is OK
// Send the first >>>>>>>> byte
<=3D >>>>>>>>>> br> >>>>>>>>>>

Now in my preferred programming langua= ge, >>>>>>>>>> you >>>>>>>> cou=3D >>>>>>>>>> ld just throw up a PAR statement and it would work anyway, but v= ery >>>>>>>>>> few >>>>>>>> pro=3D >>>>>>>>>> grammers grok that sort of stuff.


<= div >>>>>>>>>> >>>>> class=3D >>>>>>>>>> =3D3D"gmail_quote"> >>>>>>>>>> On Wed, Jun 29, 2011 at 2:21 AM, Mark Andrews >>>>> dir=3D3D"ltr"><>>>>>>> href=3D >>>>>>>>>> =3D3D"mailto:marka@isc.org">marka@isc.org> >>>>>>>> wrote:
>>>>>>>>> e class=3D3D"gmail_quote" style=3D3D"margin:0 0 0 .8ex;border-left:1= px >>>>>>>>>> #ccc >>>>>>>> sol=3D >>>>>>>>>> id;padding-left:1ex;"> >>>>>>>>>>
>>>>>>>>>> In message <>>>>> href=3D3D"mailto:BANLkTimX2XRgJHSkUq-GAAMDs%2BMb6V2VYw@mail >>>>>> >>>>>>>> >>>> > =3D >>>>>>>>>> .gmail.com >>>>>>>> ">BANLkTimX2XRgJHSkUq-GAAMDs+Mb6V2VYw@mail.gmail.com >>>>> >>>>>>>> >>>> > >>>>> >, >>>> Phi=3D >>>>>>>>>> llip Hallam-
>>>>>>>>>>
Baker writes:
>>>>>>>>>> > I guess that would work for the application programmers who >>>>>>>>>> >>>>> still >>>>>>>> code=3D >>>>>>>>>> =A0in C
>>>>>>>>>> > or C++. That is not where the industry has been for a decad= e >>>>>> now.
>>>>>>>>>>
>>>>>>>>>>
The concepts are language independent.
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>>
Mark Andrews, ISC
>>>>>>>>>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
>>>>>>>>>> PHONE: >>>>> >>>>>>>> ">+61 2=3D >>>>>>>>>> =A09871 4742 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 INTERNET: >>>>>>> href=3D3D"mailto:=3D >>>>>>>>>> marka@isc.org">marka@isc.org
>>>>>>>>>>



-- >>>>>>
Website: >> >>>>>>>>>> >>>>>>>>> =A0href=3D3D"http://hallambaker.com/">http://hallambaker.com/
>>>>>>>>>>
>>>>>>>>>>=20 >>>>>>>>>> --0016e68debd4b5f20c04a6db8b0b-- >>>>>> -- >>>>>> Mark Andrews, ISC >>>>>> 1 Seymour St., Dundas Valley, NSW 2117, Australia >>>>>> PHONE: +61 2 9871 4742 >>>> =A0=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >>>>>> INTERNET: marka@isc.org >>>>=20 >>>>=20 >>=20 >=20 >=20 From eosterweil@verisign.com Wed Jul 6 10:34:57 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5DF321F8922 for ; Wed, 6 Jul 2011 10:34:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.345 X-Spam-Level: X-Spam-Status: No, score=-6.345 tagged_above=-999 required=5 tests=[AWL=0.254, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BEtD8kpH99ek for ; Wed, 6 Jul 2011 10:34:57 -0700 (PDT) Received: from exprod6og104.obsmtp.com (exprod6og104.obsmtp.com [64.18.1.187]) by ietfa.amsl.com (Postfix) with ESMTP id BE30C21F891C for ; Wed, 6 Jul 2011 10:34:53 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob104.postini.com ([64.18.5.12]) with SMTP ID DSNKThScu2nQDqXlcOIeBNqlvixmEPTbid3u@postini.com; Wed, 06 Jul 2011 10:34:56 PDT Received: from dul1wnexcn01.vcorp.ad.vrsn.com (dul1wnexcn01.vcorp.ad.vrsn.com [10.170.12.138]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id p66HYof6009677; Wed, 6 Jul 2011 13:34:50 -0400 Received: from DUL1WNEXMB11.vcorp.ad.vrsn.com ([10.170.13.11]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 6 Jul 2011 13:34:49 -0400 Received: from 10.131.30.110 ([10.131.30.110]) by DUL1WNEXMB11.vcorp.ad.vrsn.com ([10.170.13.11]) with Microsoft Exchange Server HTTP-DAV ; Wed, 6 Jul 2011 17:34:35 +0000 User-Agent: Microsoft-Entourage/12.29.0.110113 Date: Wed, 06 Jul 2011 13:34:33 -0400 From: "Osterweil, Eric" To: "Richard L. Barnes" Message-ID: Thread-Topic: [dane] Draft for serializing DNSSEC chains Thread-Index: Acw3ZvcvVK4189dFSNyv7Zylz4XAJQEnACBk In-Reply-To: <2F57E71D-5F04-4094-8E37-F0D7C8E33111@bbn.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 06 Jul 2011 17:34:49.0950 (UTC) FILETIME=[01CA37E0:01CC3C03] Cc: Adam Langley , dane@ietf.org Subject: Re: [dane] Draft for serializing DNSSEC chains X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 17:34:58 -0000 On 6/30/11 4:47 PM, "Richard L. Barnes" wrote: >>>> Managing the crypto in just >>>> one system is hard enough, this seems to inheret baggage from two >>>> crypto-enhanced systems... :-/ >>> >>> I don't think it's quite that bad. There's not really any PKIX baggage, >>> since >>> the all of the crypto validation comes from the DNSSEC extension. >>> >>> The risk of falling out of sync may just be part of the trade-off for speed. >>> It seems like there's a plausible solution (mod_dnssec_staple), so it >>> doesn't >>> seem like it necessarily has to be a blocking issue. >> >> Again, I think the operational complexities are being vastly underestimated. >> The certs have to be regenerated by authorities for websites based on >> changes in DNS zones that exist anywhere along the validation chain. In >> particular, how many web server admins keep track of when the root changes >> its ZSKs? I know of the top of my head, but I still would find it a pain if >> I had to go regen certs because someone popped a key somewhere... I still >> don't even know how I would find that out? > > It's not really so mysterious, it's just the chain from the name in the cert > to the root. If I'm trying to maintain a cert for isoc.org, I have to monitor > 9 records (+RRSIGs) > > 1. . DNSKEY > 2. . DNSKEY > 3. org DS > 4. org DNSKEY > 5. org DNSKEY > 6. isoc.org DS > 7. isoc.org DNSKEY > 8. isoc.org DNSKEY > 9. isoc.org TLSA How much DNS monitoring is built into operational practices of cert users now? I know you COULD do the above. I even have a pretty solid background in doing it myself. However, if a web server admin now needs to know to do do this, know how to do this, and always actually do it, the process has gone from automatic to quite complex, overnight. Perl doesn't just happen by itself. ;) > > So my script polls for these records whenever the TTL expires, and issues a > new cert whenever the chain changes. Seems like a pretty defined scope, and > like I said before, a plausible solution. So you're not issuing certs and inserting them into your zone and re-signing all from cron? Is that what you think everyone should do? I'm not saying this could never work, but don't you see how much operational complexity (not to mention un-developed tools) you just implicitly required? This is a straightforward design with very complicated operational implications. Eric From eosterweil@verisign.com Wed Jul 6 10:34:57 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D572A21F8920 for ; Wed, 6 Jul 2011 10:34:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.32 X-Spam-Level: X-Spam-Status: No, score=-6.32 tagged_above=-999 required=5 tests=[AWL=0.279, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BWuKUuXcTA2c for ; Wed, 6 Jul 2011 10:34:57 -0700 (PDT) Received: from exprod6og105.obsmtp.com (exprod6og105.obsmtp.com [64.18.1.189]) by ietfa.amsl.com (Postfix) with ESMTP id C633621F891D for ; Wed, 6 Jul 2011 10:34:53 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob105.postini.com ([64.18.5.12]) with SMTP ID DSNKThScu2nQDqXlcOIeBNqlvixmEPTbid3u@postini.com; Wed, 06 Jul 2011 10:34:56 PDT Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id p66HYo8p009678; Wed, 6 Jul 2011 13:34:50 -0400 Received: from DUL1WNEXMB11.vcorp.ad.vrsn.com ([10.170.13.11]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 6 Jul 2011 13:34:50 -0400 Received: from 10.131.30.110 ([10.131.30.110]) by DUL1WNEXMB11.vcorp.ad.vrsn.com ([10.170.13.11]) with Microsoft Exchange Server HTTP-DAV ; Wed, 6 Jul 2011 17:34:35 +0000 User-Agent: Microsoft-Entourage/12.29.0.110113 Date: Wed, 06 Jul 2011 13:34:34 -0400 From: "Osterweil, Eric" To: Mark Andrews , "Richard L. Barnes" Message-ID: Thread-Topic: [dane] Draft for serializing DNSSEC chains Thread-Index: Acw3gZrtnlPLCaEhTrKQoHcNvskNOwEgV1ad In-Reply-To: <20110630235734.8A6FC115363A@drugs.dv.isc.org> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 06 Jul 2011 17:34:50.0144 (UTC) FILETIME=[01E7D200:01CC3C03] Cc: Adam Langley , dane@ietf.org Subject: Re: [dane] Draft for serializing DNSSEC chains X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 17:34:58 -0000 On 6/30/11 7:57 PM, "Mark Andrews" wrote: > > > In message <2F57E71D-5F04-4094-8E37-F0D7C8E33111@bbn.com>, "Richard L. Barnes" > writes: >>>>> Managing the crypto in just >>>>> one system is hard enough, this seems to inheret baggage from two >>>>> crypto-enhanced systems... :-/ >>>> >>>> I don't think it's quite that bad. There's not really any PKIX baggage, s >> ince >>>> the all of the crypto validation comes from the DNSSEC extension. >>>> >>>> The risk of falling out of sync may just be part of the trade-off for spee >> d. >>>> It seems like there's a plausible solution (mod_dnssec_staple), so it does >> n't >>>> seem like it necessarily has to be a blocking issue. >>> >>> Again, I think the operational complexities are being vastly underestimated >> . >>> The certs have to be regenerated by authorities for websites based on >>> changes in DNS zones that exist anywhere along the validation chain. In >>> particular, how many web server admins keep track of when the root changes >>> its ZSKs? I know of the top of my head, but I still would find it a pain i >> f >>> I had to go regen certs because someone popped a key somewhere... I still >>> don't even know how I would find that out? >> >> It's not really so mysterious, it's just the chain from the name in the cert >> to the root. If I'm trying to maintain a cert for isoc.org, I have to monito >> r 9 records (+RRSIGs) > > 6 RRsets + RRSIGs > >> 1. . DNSKEY >> 2. . DNSKEY RRSIG (15 days validity) >> 3. org DS >> 3. org DS RRSIG (5 days validity) >> 4. org DNSKEY >> 5. org DNSKEY RRSIG (20 days validity) >> 6. isoc.org DS >> 6. isoc.org DS RRSIG (20 days validity) >> 7. isoc.org DNSKEY >> 8. isoc.org DNSKEY RRSIG (14 days validity) >> 9. isoc.org TLSA >> 9. isoc.org TLSA (30 days validity) >> >> So my script polls for these records whenever the TTL expires, and issues a n >> ew cert whenever the chain changes. Seems like a pretty defined scope, and l >> ike I said before, a plausible solution. > > Now having the server maintain a DNS TTL controlled cache of the > records required to validate the TLSA and returning those wouldn't > break anything the DNS zone operators are depending apon. This > doesn't have to be in the CERT. You can tentitively trust the CERT, > then request the DNS validation chain, then decide whether you full > trust the CERT. The only thing the CERT needs is a indication that > the server supports requesting the DNS validation chain. Even if > the returned validation chain is incomplete the client can request > the missing bits. Something like this (where a cert says, "use DNS") makes a lot more sense. It's when the cert takes a snapshot of the DNS and says, "trust what I saw back when this was valid" that worries me. The attack is that an adversary who compromises a key can re-use that key as long as a browser doesn't look into DNS an just trusts the cert. Eric From eosterweil@verisign.com Wed Jul 6 10:34:57 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6F5621F891A for ; Wed, 6 Jul 2011 10:34:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.289 X-Spam-Level: X-Spam-Status: No, score=-6.289 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lkPOpJnFR4J6 for ; Wed, 6 Jul 2011 10:34:57 -0700 (PDT) Received: from exprod6og102.obsmtp.com (exprod6og102.obsmtp.com [64.18.1.183]) by ietfa.amsl.com (Postfix) with ESMTP id CCDE421F891E for ; Wed, 6 Jul 2011 10:34:53 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob102.postini.com ([64.18.5.12]) with SMTP ID DSNKThScu2nQDqXlcOIeBNqlvixmEPTbid3u@postini.com; Wed, 06 Jul 2011 10:34:56 PDT Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id p66HYo9u009689; Wed, 6 Jul 2011 13:34:50 -0400 Received: from DUL1WNEXMB11.vcorp.ad.vrsn.com ([10.170.13.11]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 6 Jul 2011 13:34:50 -0400 Received: from 10.131.30.110 ([10.131.30.110]) by DUL1WNEXMB11.vcorp.ad.vrsn.com ([10.170.13.11]) with Microsoft Exchange Server HTTP-DAV ; Wed, 6 Jul 2011 17:34:36 +0000 User-Agent: Microsoft-Entourage/12.29.0.110113 Date: Wed, 06 Jul 2011 13:34:35 -0400 From: "Osterweil, Eric" To: Tony Finch Message-ID: Thread-Topic: [dane] Draft for serializing DNSSEC chains Thread-Index: Acw3jEQ5bw/voir+T1G4b6k0hceb+wEdrSrZ In-Reply-To: <0278EF9B-E52F-4D76-94AB-0B382AE51441@dotat.at> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 06 Jul 2011 17:34:50.0582 (UTC) FILETIME=[022AA760:01CC3C03] Cc: Adam Langley , dane@ietf.org Subject: Re: [dane] Draft for serializing DNSSEC chains X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 17:34:58 -0000 On 6/30/11 9:14 PM, "Tony Finch" wrote: > On 30 Jun 2011, at 20:57, "Osterweil, Eric" wrote: >> In particular, how many web server admins keep track of when the root changes >> its ZSKs? I know of the top of my head, but I still would find it a pain if >> I had to go regen certs because someone popped a key somewhere... > > No no no. Key lifetimes are not a problem. They are measured in years. Where do you get this data? > You > need to care about signature lifetimes which are measured in days. Where do you get this data? I have been tracking both of the above (and putting it online for others to see) for years and my view does not match yours. > A web server SSL cert with an embedded DNSSEC trust chain needs to be > regenerated daily at least. ... Because it cannot be allowed to become stale... However, this WILL happen as an operational inevitability. These things will get out of sync and will become an attack vector. Adding this level of indirection weakens the security of the system. Eric From eosterweil@verisign.com Wed Jul 6 10:34:58 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FC0121F891F for ; Wed, 6 Jul 2011 10:34:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.366 X-Spam-Level: X-Spam-Status: No, score=-6.366 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x1DdUNrFd+Px for ; Wed, 6 Jul 2011 10:34:57 -0700 (PDT) Received: from exprod6og109.obsmtp.com (exprod6og109.obsmtp.com [64.18.1.23]) by ietfa.amsl.com (Postfix) with ESMTP id E168D21F8910 for ; Wed, 6 Jul 2011 10:34:51 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob109.postini.com ([64.18.5.12]) with SMTP ID DSNKThScu2nQDqXlcOIeBNqlvixmEPTbid3u@postini.com; Wed, 06 Jul 2011 10:34:56 PDT Received: from dul1wnexcn01.vcorp.ad.vrsn.com (dul1wnexcn01.vcorp.ad.vrsn.com [10.170.12.138]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id p66HYof8009677; Wed, 6 Jul 2011 13:34:50 -0400 Received: from DUL1WNEXMB11.vcorp.ad.vrsn.com ([10.170.13.11]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 6 Jul 2011 13:34:50 -0400 Received: from 10.131.30.110 ([10.131.30.110]) by DUL1WNEXMB11.vcorp.ad.vrsn.com ([10.170.13.11]) with Microsoft Exchange Server HTTP-DAV ; Wed, 6 Jul 2011 17:34:34 +0000 User-Agent: Microsoft-Entourage/12.29.0.110113 Date: Wed, 06 Jul 2011 13:34:31 -0400 From: "Osterweil, Eric" To: Message-ID: Thread-Topic: [dane] Draft for serializing DNSSEC chains Thread-Index: Acw3ZA5vottRjrL3Sh+McwnJ7wifjQEnugMV In-Reply-To: <201106302026.p5UKQVt6023244@fs4113.wdf.sap.corp> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 06 Jul 2011 17:34:50.0169 (UTC) FILETIME=[01EBA290:01CC3C03] Cc: agl@imperialviolet.org, dane@ietf.org Subject: Re: [dane] Draft for serializing DNSSEC chains X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 17:34:58 -0000 On 6/30/11 4:26 PM, "Martin Rex" wrote: > Osterweil, Eric wrote: >> >>> >>> I believe the RRSIG validitiy is more in the matter of hours to days. >> >> It varies, and is set by each zone. Look at this for the current spectrum: >> http://secspider.cs.ucla.edu/images/key-lifetimes.png >> >>> >>> And for DNSSEC to work smoothly, there are transistion periods for >>> DNS key rollover, so that when correctly rebuilding the to-be-signed >>> data from currently valid data (rather than blindly resigning old >>> data when RRSIG expires), the problem you are describing might not >>> exist. >> >> >> In DNSSEC, yes, rollovers are handled "smoothly", but what keeps the cert in >> sync? If a cert exists for (say) a month, but a key rollover happens on >> week 1 of the cert's lifetime, then the rollover will have completed long >> before someone plans to re-examine and regenerate their cert. Moreover, how >> often do people roll their certs now? I ask because the existing behavior >> is a much better indicator of future behavior than what one _hopes_ people >> will do. Why do you think cert owners will suddenly know how to manage the >> cross system dependencies? > > > For use with DANE, you really want your X.509 Validity to be far far far > into the future so that it will NEVER happen that you have to replace > your certificate because of PKIX-style expiration. If you're using > a cert issued by a CA (such as from the TLS X.509 PKI) then the > server cert lifetime will be subject to their policies, of course. Then, I read from this that if you use a cert in DANE, then your cert will have an increasing increasing increasing divergence from the DNS chain of trust? > > The purpose of the original validity in X.509 is twofold > -- to maintain the commercial CA business model and invoicing > for a subscription model (recurring fee or slightly reduced fee > upfront for the entire period with no refund for unused time). > -- to limit the growth of CRLs and to allow CAs to eventually > dispose of their old keys and retire CRL publishing for a CA key. > > When a server certificate is _not_ from a traditional PKI, but from > your own CA or self-signed and distributed through DANE, then you > do NOT want any certificate validity to inflict unnecessary > administrative overhead. The validity of the certificate > is entirely governed by the existence of a signed DANE record > refering to that cert. And the cert becomes automaticlly invalid > as soon as its DANE record is deleted from the DNS zone and the > RRSIG of any existing/published DNS records expire. I see two issues with the above: 1 - Not wanting to "inflict unnecessary administrative overhead" is a very good goal, but it is not achieved just because you say so. My whole point is that this approach causes the implicit NEED for additional overhead. Operators now need to track additional information external to the cert in order to know when they need to change it! Using DNS for DNSSEC obviates the need for this additional overhead. 2 - The cert becoming invalid when the DANE record removed has no bearing on the concern I raised. The concern comes from the way in which the record is validated. If you use the embedded chain of trust that has been compromised and mended in the DNS, then the cert is out of date. Eric From mlarson@verisign.com Wed Jul 6 15:20:31 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20DB921F88A0 for ; Wed, 6 Jul 2011 15:20:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tcduWDHjExUb for ; Wed, 6 Jul 2011 15:20:30 -0700 (PDT) Received: from exprod6og113.obsmtp.com (exprod6og113.obsmtp.com [64.18.1.31]) by ietfa.amsl.com (Postfix) with ESMTP id 447EE21F889D for ; Wed, 6 Jul 2011 15:20:30 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob113.postini.com ([64.18.5.12]) with SMTP ID DSNKThTfrRmCsktShJYpssu16ZkQdJu3se22@postini.com; Wed, 06 Jul 2011 15:20:30 PDT Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id p66MKSLi022222 for ; Wed, 6 Jul 2011 18:20:28 -0400 Received: from DUL1MLARSON-M2 ([10.100.0.227]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 6 Jul 2011 18:20:28 -0400 Date: Wed, 6 Jul 2011 18:20:32 -0400 From: Matt Larson To: dane@ietf.org Message-ID: <20110706222032.GH6770@DUL1MLARSON-M2.vcorp.ad.vrsn.com> References: <4E1175F1.4080201@nlnetlabs.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-OriginalArrivalTime: 06 Jul 2011 22:20:28.0301 (UTC) FILETIME=[E90B0BD0:01CC3C2A] Subject: Re: [dane] Draft for serializing DNSSEC chains (01) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 22:20:31 -0000 On Wed, 06 Jul 2011, Adam Langley wrote: > In order to keep the simplicity I'm giving the algorithm rollover > problem to another layer. This scares me. > Unlike serving DNSSEC data using the DNS protocol, there's the > possibility of choosing a different serialization for different > clients. This also scares me. > Negotiation of acceptable algorithms can thus be done by the higher > layers. And this. > Yes, I believe that DNAMEs would be simple to add but I've hesitated > so far Aside from the fact that using X.509 as a transport for DNS resource records is a grievous layer violation, statements such as above (no DNAME support yet) show the complexity of forcing this square peg into this round hole. And taking into account Eric's legitimate concerns about stale information and operational complexity, I'm concerned about this protocol. Matt From hallam@gmail.com Wed Jul 6 15:58:36 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28E4021F8922 for ; Wed, 6 Jul 2011 15:58:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.568 X-Spam-Level: X-Spam-Status: No, score=-3.568 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LTyEW8yqi5qY for ; Wed, 6 Jul 2011 15:58:35 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id ED01A21F8920 for ; Wed, 6 Jul 2011 15:58:34 -0700 (PDT) Received: by gyd5 with SMTP id 5so205701gyd.31 for ; Wed, 06 Jul 2011 15:58:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=eYJtiEaIa0dBTPnK4Brxy6A8V0xTr6azmdnY3hI/Kf0=; b=cujdkrNUhpb6hG/LRVpnxopE2tpS3RnJGXkSF1VExqaAPz1xp6QXYpX3zi+ruNqZ8p qLAJmkO+lfFEKllpWx9e7Wt0YulNkMoIwM8nzKBb+PwcUONFPc4dqRx/JzIBcGVdIT0u dVdxalXo4ATtoMU0znB/Rny48XO26bLqxBFyQ= MIME-Version: 1.0 Received: by 10.101.180.22 with SMTP id h22mr111859anp.80.1309993114001; Wed, 06 Jul 2011 15:58:34 -0700 (PDT) Received: by 10.100.93.12 with HTTP; Wed, 6 Jul 2011 15:58:33 -0700 (PDT) In-Reply-To: <20110706222032.GH6770@DUL1MLARSON-M2.vcorp.ad.vrsn.com> References: <4E1175F1.4080201@nlnetlabs.nl> <20110706222032.GH6770@DUL1MLARSON-M2.vcorp.ad.vrsn.com> Date: Wed, 6 Jul 2011 18:58:33 -0400 Message-ID: From: Phillip Hallam-Baker To: Matt Larson Content-Type: multipart/alternative; boundary=001636c9258537e0a504a76e8a0d Cc: dane@ietf.org Subject: Re: [dane] Draft for serializing DNSSEC chains (01) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 22:58:36 -0000 --001636c9258537e0a504a76e8a0d Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jul 6, 2011 at 6:20 PM, Matt Larson wrote: > On Wed, 06 Jul 2011, Adam Langley wrote: > > In order to keep the simplicity I'm giving the algorithm rollover > > problem to another layer. > > This scares me. Why, specify your fears. We have to solve the algorithm rollover problem for SSL in any case. > Unlike serving DNSSEC data using the DNS protocol, there's the > > possibility of choosing a different serialization for different > > clients. > > This also scares me. There is a really really bad history of people making arguments based on fears or the state of their gut. > > Negotiation of acceptable algorithms can thus be done by the higher > > layers. > > And this. Why, do you understand how SSL negotiation works? It is pretty well established at this point. People have been doing it for 15 years now. > > Yes, I believe that DNAMEs would be simple to add but I've hesitated > > so far > > Aside from the fact that using X.509 as a transport for DNS resource > records is a grievous layer violation, statements such as above (no > DNAME support yet) show the complexity of forcing this square peg into > this round hole. And taking into account Eric's legitimate concerns > about stale information and operational complexity, I'm concerned > about this protocol. I don't see it as a layer violation. Its just another transport instead of DNS query response. It is a much simpler form of transport than messing with DNS queries, it avoids the need for asynchronous response handling and is equivalent to caching the DNS data. If DNAME is the criteria, Adam is a lot closer to a solution than the Hoffman draft is. I can modify Adam's proposal to support DNAME quite simply. Making prefix records work with DNAME is a known incompatibility. Arguments based on complexity sound rather hollow to me having spent the past few weeks writing DNS resolution code. The DNS chain is simply a PKI cert chain in a format other than ASN.1. I find it hard to see how that is a 'layer violation'. I didn't get this approach until last week either. But it all makes sense to me and it is better for key distribution than my proposal was. There is 16 years of history that has flowed under that particular bridge. Any new mechanism for key distribution has to work at least as well in practice as the existing scheme. Adam is the only person that has proposed such a scheme. It does look like a bit of a hack, but it is probably the least uggly solution that is going to work at least as well as the existing scheme. That still leaves security policy as an area where the 'get the info from the DNS' approach is the only game in town. So it is not like embracing Adam's scheme means that the need for DNSSEC aware resolvers goes away. -- Website: http://hallambaker.com/ --001636c9258537e0a504a76e8a0d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Jul 6, 2011 at 6:20 PM, Matt Larson = <mlarson@veris= ign.com> wrote:
On Wed, 06 Jul 2011, Adam Langley wrote:
> In order to keep the simplicity I'm giving the algorithm rollover<= br> > problem to another layer.

This scares me.

Why, specify your fea= rs.

We have to solve the algorithm rollover proble= m for SSL in any case. =A0

> Unlike serving DNSSEC data using the DNS protocol, there's the
> possibility of choosing a different serialization for different
> clients.

This also scares me.

There is a reall= y really bad history of people making arguments based on fears or the state= of their gut.=A0

=A0
> Negotiation of acceptable algorithms can thus be done by the higher > layers.

And this.

Why, do you understand how = SSL negotiation works? It is pretty well established at this point. People = have been doing it for 15 years now.

=A0
> Yes, I believe that DNAMEs would be simple to add but I've hesitat= ed
> so far

Aside from the fact that using X.509 as a transport for DNS resource<= br> records is a grievous layer violation, statements such as above (no
DNAME support yet) show the complexity of forcing this square peg into
this round hole. =A0And taking into account Eric's legitimate concerns<= br> about stale information and operational complexity, I'm concerned
about this protocol.

I don't see it as = a layer violation. Its just another transport instead of DNS query response= .=A0

It is a much simpler form of transport than m= essing with DNS queries, it avoids the need for asynchronous response handl= ing and is equivalent to caching the DNS data.

If DNAME is the criteria, Adam is a lot closer to a sol= ution than the Hoffman draft is. I can modify Adam's proposal to suppor= t DNAME quite simply. Making prefix records work with DNAME is a known inco= mpatibility.


Arguments based on complexity sound rath= er hollow to me having spent the past few weeks writing DNS resolution code= .=A0

The DNS chain is simply a PKI cert chain in a= format other than ASN.1. I find it hard to see how that is a 'layer vi= olation'.=A0


I didn't get this approach until las= t week either. But it all makes sense to me and it is better for key distri= bution than my proposal was.

There is 16 years of = history that has flowed under that particular bridge. Any new mechanism for= key distribution has to work at least as well in practice as the existing = scheme. Adam is the only person that has proposed such a scheme. It does lo= ok like a bit of a hack, but it is probably the least uggly solution that i= s going to work at least as well as the existing scheme.


That still leaves security policy as an = area where the 'get the info from the DNS' approach is the only gam= e in town. So it is not like embracing Adam's scheme means that the nee= d for DNSSEC aware resolvers goes away.


--
Website: http://hallambaker.com/

--001636c9258537e0a504a76e8a0d-- From matt@mattmccutchen.net Wed Jul 6 16:54:41 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B4B021F8B87 for ; Wed, 6 Jul 2011 16:54:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WBsSs4SeMMN0 for ; Wed, 6 Jul 2011 16:54:40 -0700 (PDT) Received: from homiemail-a37.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id 5275621F8B85 for ; Wed, 6 Jul 2011 16:54:40 -0700 (PDT) Received: from homiemail-a37.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a37.g.dreamhost.com (Postfix) with ESMTP id 06985208071; Wed, 6 Jul 2011 16:54:40 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=ZwqtEGYgM1oFOigz40tmm/GDQLULOh05o8e49Rn8GZL qDjlPYCXtmVFP7wRicfyGrufpyQXAPWbqVXEbNgVg+lXibQ6+7/7bhlFybkEtoNa 68FhTdtDzyFFAVJfD0T8JmkAYm4EGnEzsEk18prChLfnsZe0i+I3Xb6wz4+Ozm00 = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=JlYbIEALVmecdSdtAbP7WplN4nc=; b=Ork025fDPZ 73r3eQHOVlGwZJ+qYkZaEsvXvqrWqaewCJoRxGB4xI4FSk8HN0I5C5pQMIGGauOA Sfs5FLGTeJtyokGYZrVeK8sFULQ/PeSWFvGD8SazdGOPiG8Xfd1KQrjGZwRW158Y nmz/oEOaMHmDkzEtXjoxWu/TCFRfCKetM= Received: from [192.168.1.40] (pool-74-96-125-150.washdc.east.verizon.net [74.96.125.150]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a37.g.dreamhost.com (Postfix) with ESMTPSA id 8473E20806F; Wed, 6 Jul 2011 16:54:39 -0700 (PDT) From: Matt McCutchen To: "Osterweil, Eric" In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Date: Wed, 06 Jul 2011 19:54:36 -0400 Message-ID: <1309996476.2140.23.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 Content-Transfer-Encoding: 7bit Cc: dane@ietf.org Subject: Re: [dane] Draft for serializing DNSSEC chains X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 23:54:41 -0000 On Wed, 2011-07-06 at 13:34 -0400, Osterweil, Eric wrote: > It's when the cert takes a snapshot of the DNS and says, "trust what I saw > back when this was valid" that worries me. The attack is that an adversary > who compromises a key can re-use that key as long as a browser doesn't look > into DNS an just trusts the cert. Which is no different from the adversary intercepting the browser's DNS queries and responding with the old chain. Security-wise, there is nothing magic about the DNSSEC distributed database. Freshness of DNSSEC data is governed by RRSIG validity, no matter how the data is obtained. The stapled chain is a cache and, as such, it can affect availability, though if the hypothetical mod_dnssec_staple is used there is no reason to think it would fail any more often than any other TTL-based cache. DNSSEC RRSIGs are properly analogous to OCSP responses; they provide the same functionality. (DNSSEC just skipped the intermediate stage of signed long-term certificates because offline operation was not a goal.) The motivations and security considerations for DNSSEC chain stapling are much the same as those for OCSP stapling. (Which raises another point. OCSP stapling uses a TLS extension. This is a more appropriate design than embedding the data in the cert; additionally, the latter is impossible to do backward-compatibly with a CA-signed cert. For DNSSEC chain stapling, embedding is possible. Chromium may find the ability to use externally automated DNSSEC chain stapling with existing web servers to be sufficient justification for choosing the poorer design, but does IETF?) -- Matt From matt@mattmccutchen.net Wed Jul 6 17:09:53 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 198D621F8B25 for ; Wed, 6 Jul 2011 17:09:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pwhaOE0S9-1E for ; Wed, 6 Jul 2011 17:09:52 -0700 (PDT) Received: from homiemail-a2.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id 2C20C21F8B16 for ; Wed, 6 Jul 2011 17:09:52 -0700 (PDT) Received: from homiemail-a2.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a2.g.dreamhost.com (Postfix) with ESMTP id DA58D280075; Wed, 6 Jul 2011 17:09:51 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=gw+w30PctQC5KbLHALwFjZp3XQeoG70O551p/voW1N2 T353geEULClGKR9h0/zoV9m27sshDAPIrvsoBBWlq72M5zknVSXsK+SsVbauQpRj nw1gmK5qW6y04hUBZA0wz9gQAdOlkcTPtgWiO2g1IBwuLacI3QhbdpPu+ioQwX0Y = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=tw2b5sy2HZ7jVGWvcLZrhmEwVPI=; b=WP2KSNFisN 5jQdlPdVmu+izBrYFj0Ie2awtPbzzvysWU/KcnNIP2USZTppvH6cFNxt8T07BKOx sYCKh8BuopxM3lXOIbjWdknmi9W4fyNdLW6aW0j7Xndai5MxSequ5a9ar9Xy2EIX THo1aTUZCpiE5lEMxGNJ+qpIzv3git6T0= Received: from [192.168.1.40] (pool-74-96-125-150.washdc.east.verizon.net [74.96.125.150]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a2.g.dreamhost.com (Postfix) with ESMTPSA id 6C71B280063; Wed, 6 Jul 2011 17:09:51 -0700 (PDT) From: Matt McCutchen To: Phillip Hallam-Baker In-Reply-To: References: <201106301842.p5UIgdjK017407@fs4113.wdf.sap.corp> Content-Type: text/plain; charset="UTF-8" Date: Wed, 06 Jul 2011 20:09:49 -0400 Message-ID: <1309997389.2140.36.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 Content-Transfer-Encoding: 7bit Cc: dane@ietf.org Subject: Re: [dane] Draft for serializing DNSSEC chains X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 00:09:53 -0000 On Thu, 2011-06-30 at 15:04 -0400, Phillip Hallam-Baker wrote: > This approach solve the use cases and requirements stated in the Use > cases and requirements document. It does so without requiring the end > point client to have access to a DNSSEC enabled resolver. For positive assertions (assurances), yes. > It appear to me that it is considerably better than the scheme > proposed in the Hoffman et. al. draft Better in that the client doesn't have to talk to DNS servers. draft-ietf-dane-protocol is better in that the server's cooperation is not needed. E.g., my mail client is using DANE for mail.mattmccutchen.net, which points to a DreamHost mail server with a self-signed cert I don't control. > and it has the benefit of actual deployed code. Depends on whether you count my use of nss-dane for my personal browsing and email as "deployment". :) > It does not address the issue of security policy, promiscuous use of > SSL, strict security etc. Correct. > but that is not a necessity. Not sure what you mean by "necessity". Restriction of TLS server credentials is in the use cases doc. Assurance and restriction of TLS server credentials could conceivably be achieved via separate mechanisms, but I support the WG's current approach of doing those two together and leaving the other kinds of restrictions out of scope. > The question that comes up as far as security policy is concerned is > how recent a signature should be to be recognized. Should this type of > self signed cert be valid for an hour, a day a week, a year, a decade? Why should we second-guess the RRSIG validity? Or, if fancier semantics are desired, why should they be specific to DANE, rather than incorporated into DNSSEC? -- Matt From eosterweil@verisign.com Wed Jul 6 17:24:47 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5D6C21F8768 for ; Wed, 6 Jul 2011 17:24:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.384 X-Spam-Level: X-Spam-Status: No, score=-6.384 tagged_above=-999 required=5 tests=[AWL=0.215, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hW0RAQkbzB3g for ; Wed, 6 Jul 2011 17:24:46 -0700 (PDT) Received: from exprod6og102.obsmtp.com (exprod6og102.obsmtp.com [64.18.1.183]) by ietfa.amsl.com (Postfix) with ESMTP id 4063721F875C for ; Wed, 6 Jul 2011 17:24:41 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob102.postini.com ([64.18.5.12]) with SMTP ID DSNKThT8x5Kb+PDRpnnCj4BkV9KZzCHQcMTo@postini.com; Wed, 06 Jul 2011 17:24:41 PDT Received: from dul1wnexcn01.vcorp.ad.vrsn.com (dul1wnexcn01.vcorp.ad.vrsn.com [10.170.12.138]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id p670OcLn027975; Wed, 6 Jul 2011 20:24:39 -0400 Received: from DUL1WNEXMB11.vcorp.ad.vrsn.com ([10.170.13.11]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 6 Jul 2011 20:24:38 -0400 Received: from 10.100.0.144 ([10.100.0.144]) by DUL1WNEXMB11.vcorp.ad.vrsn.com ([10.170.13.11]) with Microsoft Exchange Server HTTP-DAV ; Thu, 7 Jul 2011 00:21:52 +0000 User-Agent: Microsoft-Entourage/12.29.0.110113 Date: Wed, 06 Jul 2011 20:21:50 -0400 From: "Osterweil, Eric" To: Matt McCutchen Message-ID: Thread-Topic: [dane] Draft for serializing DNSSEC chains Thread-Index: Acw8OBx/gC70NQegQZmqIiabtd7A8AAA8DFZ In-Reply-To: <1309996476.2140.23.camel@localhost> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 07 Jul 2011 00:24:38.0706 (UTC) FILETIME=[41D4A120:01CC3C3C] Cc: dane@ietf.org Subject: Re: [dane] Draft for serializing DNSSEC chains X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 00:24:47 -0000 On 7/6/11 7:54 PM, "Matt McCutchen" wrote: > On Wed, 2011-07-06 at 13:34 -0400, Osterweil, Eric wrote: >> It's when the cert takes a snapshot of the DNS and says, "trust what I saw >> back when this was valid" that worries me. The attack is that an adversary >> who compromises a key can re-use that key as long as a browser doesn't look >> into DNS an just trusts the cert. > > Which is no different from the adversary intercepting the browser's DNS > queries and responding with the old chain. Wrong. First, the parent can re-delegate to a new DS pointing to a new KSK, or or the KSK can sign a new ZSK (whichever got popped), and the rev bit can be set in the zone. Then, the keys are served at multiple servers over multiple network paths. Thus, you get better freshness AND better path diversity over DNS. The vector is much more complex in DNS than it is over HTTP. I can send u some closed-form analysis discussing this, but the gist of it is that this statement is a very severe oversimplification (and the analysis is quite long). > > Security-wise, there is nothing magic about the DNSSEC distributed > database. Agreed, but it has rules, and its security is in the same place as its data. This has the effect of reducing consistency problems. Thus, the DB is not magic, but it IS authoritative for its own data. That's a big difference. > Freshness of DNSSEC data is governed by RRSIG validity, no > matter how the data is obtained. The stapled chain is a cache and, as > such, it can affect availability, though if the hypothetical > mod_dnssec_staple is used there is no reason to think it would fail any > more often than any other TTL-based cache. This is very untrue. First, this is not a cache because it's ability to be updated neither follows the rules of the DNS protocol, nor is updated with the state of that authoritative source (the name servers). Second, you continue to miss the main point I'm trying to make: the more complexity you add, the more things _will_ break. I understand that a hypothetical/non-existent/could-be-universally-deployed Apache mod could address this, but it is not designed/built/deployed and even if it were, we have not seen how it behaved operationally (regenerating certs on the fly sounds... Problematic to me). More generally, this would be a serious operational problem, imo. > > DNSSEC RRSIGs are properly analogous to OCSP responses; they provide the > same functionality. (DNSSEC just skipped the intermediate stage of > signed long-term certificates because offline operation was not a goal.) > The motivations and security considerations for DNSSEC chain stapling > are much the same as those for OCSP stapling. Why would you say that? The two protocols are immensely different and they have much different goals. Please provide details if you feel this is in err. > > (Which raises another point. OCSP stapling uses a TLS extension. This > is a more appropriate design than embedding the data in the cert; > additionally, the latter is impossible to do backward-compatibly with a > CA-signed cert. OK, so let's discuss this. Are you aware of any operational hurdles that may have hampered OCSP (for what it was intended, let alone for something new)? > For DNSSEC chain stapling, embedding is possible. > Chromium may find the ability to use externally automated DNSSEC chain > stapling with existing web servers to be sufficient justification for > choosing the poorer design, but does IETF?) This will lead to disaster, and opens up new attack vectors. Eric From mrex@sap.com Wed Jul 6 18:00:00 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C71F321F89C3 for ; Wed, 6 Jul 2011 18:00:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.194 X-Spam-Level: X-Spam-Status: No, score=-10.194 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2uLITTJ6Jc-e for ; Wed, 6 Jul 2011 18:00:00 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 07E0D21F89C0 for ; Wed, 6 Jul 2011 17:59:59 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p670xw6U003966 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 7 Jul 2011 02:59:58 +0200 (MEST) From: Martin Rex Message-Id: <201107070059.p670xwTa010344@fs4113.wdf.sap.corp> To: mlarson@verisign.com (Matt Larson) Date: Thu, 7 Jul 2011 02:59:58 +0200 (MEST) In-Reply-To: <20110706222032.GH6770@DUL1MLARSON-M2.vcorp.ad.vrsn.com> from "Matt Larson" at Jul 6, 11 06:20:32 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: dane@ietf.org Subject: Re: [dane] Draft for serializing DNSSEC chains (01) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 01:00:00 -0000 Matt Larson wrote: > > Aside from the fact that using X.509 as a transport for DNS resource > records is a grievous layer violation, statements such as above (no > DNAME support yet) show the complexity of forcing this square peg into > this round hole. And taking into account Eric's legitimate concerns > about stale information and operational complexity, I'm concerned > about this protocol. There a the reasonable concern that accessibility to DNSSEC records might not be available to a non-marginal fraction TLS client for quite a while (some middle boxes, such as home DSL routers or other DNS proxies filtering them away). In-band signalling of all relevant DNSSEC records within the TLS protocol might be one possible solution to this. While tunneling the information within X.509v3 extensions of the server certificate would obviate changes to the server and changes to the TLS protocol, it has the disadvantage that it can not transport all DANE record types, needs frequent refreshing of the server certificate and can not be used with X.509v1 self-signed server certs. Personally, I think I would prefer an approach more like the stapled OCSP responses TLS extension, where the server could send the client all relevant DNSSEC records for verifying the server certificate. A server that constantly changes it certificate is fairly unusable with a pre-DANE TLS client, because you can not preconfigure the trust explicitly for the server's cert. I really would like to see browser memorizing server certs on first encounter and warn when the server cert changes -- at least as an expert option. -Martin From hallam@gmail.com Wed Jul 6 18:32:11 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D28FA21F8A10 for ; Wed, 6 Jul 2011 18:32:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.57 X-Spam-Level: X-Spam-Status: No, score=-3.57 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rKlZOA1tVtur for ; Wed, 6 Jul 2011 18:32:11 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id D12F221F8A00 for ; Wed, 6 Jul 2011 18:32:10 -0700 (PDT) Received: by yie30 with SMTP id 30so246439yie.31 for ; Wed, 06 Jul 2011 18:32:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=K1Aw98Px4rJQer1lEbYy6HBZDqG6WZs5+vKddQ9XXpE=; b=rGaN9qIe82K/ocHj7Vlu8r9PX37qPiyCcrEfUW5Ox5ZAdamFlaQ3TkGL/zb2roeKm8 5ddtmYiUDEJX0s2zObgQzh1Xjsm8o4joRGAD9vkgOS51YP3T9XFN67RR8ht4d8jHAs0X 6wfCXrzuiBHK+RRnbb+KxFOPrHqG6XHt1v7Ps= MIME-Version: 1.0 Received: by 10.101.168.5 with SMTP id v5mr190228ano.14.1310002330256; Wed, 06 Jul 2011 18:32:10 -0700 (PDT) Received: by 10.100.93.12 with HTTP; Wed, 6 Jul 2011 18:32:10 -0700 (PDT) In-Reply-To: <1309997389.2140.36.camel@localhost> References: <201106301842.p5UIgdjK017407@fs4113.wdf.sap.corp> <1309997389.2140.36.camel@localhost> Date: Wed, 6 Jul 2011 21:32:10 -0400 Message-ID: From: Phillip Hallam-Baker To: Matt McCutchen Content-Type: multipart/alternative; boundary=0016368e35a48cc56e04a770af17 Cc: dane@ietf.org Subject: Re: [dane] Draft for serializing DNSSEC chains X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 01:32:12 -0000 --0016368e35a48cc56e04a770af17 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jul 6, 2011 at 8:09 PM, Matt McCutchen wrote: > > > The question that comes up as far as security policy is concerned is > > how recent a signature should be to be recognized. Should this type of > > self signed cert be valid for an hour, a day a week, a year, a decade? > > Why should we second-guess the RRSIG validity? Or, if fancier semantics > are desired, why should they be specific to DANE, rather than > incorporated into DNSSEC? > Because the RRSIG validity could outlast the ownership of the name and because there is no revocation mechanism. If RRSIGs are valid for a decade, one compromise of one private key at one time in history can poison all future use of that domain. A domainer could create themselves some chains then sell the domain name. I think that pretty much excludes respecting chains for more than a year. A PKI chain of trust is merely an assertion. The rules of PKIX and/or DNSSEC merely define the consistency of the statement. The job of deciding what inferences to draw from a valid chain lies with the browser. -- Website: http://hallambaker.com/ --0016368e35a48cc56e04a770af17 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Jul 6, 2011 at 8:09 PM, Matt McC= utchen <matt= @mattmccutchen.net> wrote:

> The question that comes up as far as security policy is concerned is > how recent a signature should be to be recognized. Should this type of=
> self signed cert be valid for an hour, a day a week, a year, a decade?=

Why should we second-guess the RRSIG validity? =A0Or, if fancier sema= ntics
are desired, why should they be specific to DANE, rather than
incorporated into DNSSEC?

Because the R= RSIG validity could outlast the ownership of the name and because there is = no revocation mechanism.

If RRSIGs are valid for a= decade, one compromise of one private key at one time in history can poiso= n all future use of that domain.

A domainer could create themselves some chains then sel= l the domain name.

I think that pretty much exclud= es respecting =A0chains for more than a year.


A PKI chain of trust is merely an assertion. The rules of PKIX and= /or DNSSEC merely define the consistency of the statement. The job of decid= ing what inferences to draw from a valid chain lies with the browser.

--0016368e35a48cc56e04a770af17-- From mrex@sap.com Wed Jul 6 18:37:12 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C02B421F8783 for ; Wed, 6 Jul 2011 18:37:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.197 X-Spam-Level: X-Spam-Status: No, score=-10.197 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PLABXicF5u42 for ; Wed, 6 Jul 2011 18:37:12 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id DFC0521F8780 for ; Wed, 6 Jul 2011 18:37:11 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p671b5fj015888 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 7 Jul 2011 03:37:10 +0200 (MEST) From: Martin Rex Message-Id: <201107070137.p671b47i012741@fs4113.wdf.sap.corp> To: eosterweil@verisign.com (Osterweil Eric) Date: Thu, 7 Jul 2011 03:37:04 +0200 (MEST) In-Reply-To: from "Osterweil, Eric" at Jul 6, 11 08:21:50 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: dane@ietf.org Subject: Re: [dane] Draft for serializing DNSSEC chains X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 01:37:12 -0000 Osterweil, Eric wrote: > > "Matt McCutchen" wrote: > > > > DNSSEC RRSIGs are properly analogous to OCSP responses; they provide the > > same functionality. (DNSSEC just skipped the intermediate stage of > > signed long-term certificates because offline operation was not a goal.) > > The motivations and security considerations for DNSSEC chain stapling > > are much the same as those for OCSP stapling. > > Why would you say that? The two protocols are immensely different and they > have much different goals. Please provide details if you feel this is in > err. I agree with Matt (I hadn't noticed he had already suggested this when I wrote my last message). Processing stapled OCSP responses is similar to processing stapled DNSSEC records, although the scope of DANE records is slightly broader than OCSP (because it may include issues server endpoint identification). > > > (Which raises another point. OCSP stapling uses a TLS extension. This > > is a more appropriate design than embedding the data in the cert; > > additionally, the latter is impossible to do backward-compatibly with a > > CA-signed cert. > > OK, so let's discuss this. Are you aware of any operational hurdles that > may have hampered OCSP (for what it was intended, let alone for something > new)? AFAIK, the original TLS extension was a single OCSP response, and then all CAs added intermediate certs so that a single OCSP response was no longer sufficient to validate a server certificate. The proposal for a new TLS extension to carry more than a single OCSP reponse is still an internet draft: https://datatracker.ietf.org/doc/draft-pettersen-tls-ext-multiple-ocsp/ > > > For DNSSEC chain stapling, embedding is possible. > > Chromium may find the ability to use externally automated DNSSEC chain > > stapling with existing web servers to be sufficient justification for > > choosing the poorer design, but does IETF?) > > This will lead to disaster, and opens up new attack vectors. Could you elaborate? I fail to follow. The security design of DANE does not have a dependency on the transport that is used to convey the signed DNS records. Neither does OCSP and CRLs. -Martin From fanf2@hermes.cam.ac.uk Thu Jul 7 02:40:01 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15CF221F878F for ; Thu, 7 Jul 2011 02:40:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BX8kLY7JqLRF for ; Thu, 7 Jul 2011 02:40:00 -0700 (PDT) Received: from ppsw-51.csi.cam.ac.uk (ppsw-51.csi.cam.ac.uk [131.111.8.151]) by ietfa.amsl.com (Postfix) with ESMTP id 44F5721F8752 for ; Thu, 7 Jul 2011 02:40:00 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:43869) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:fanf2) id 1Qel3s-0001pg-XZ (Exim 4.72) (return-path ); Thu, 07 Jul 2011 10:39:56 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1Qel3s-0000M0-Cm (Exim 4.67) (return-path ); Thu, 07 Jul 2011 10:39:56 +0100 Date: Thu, 7 Jul 2011 10:39:56 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: "Osterweil, Eric" In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: dane@ietf.org Subject: Re: [dane] Draft for serializing DNSSEC chains X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 09:40:01 -0000 Osterweil, Eric wrote: > > > Freshness of DNSSEC data is governed by RRSIG validity, no > > matter how the data is obtained. Actually RRset TTL. > > The stapled chain is a cache and, as such, it can affect availability, > > though if the hypothetical mod_dnssec_staple is used there is no > > reason to think it would fail any more often than any other TTL-based > > cache. > > This is very untrue. First, this is not a cache because it's ability to be > updated neither follows the rules of the DNS protocol, nor is updated with > the state of that authoritative source (the name servers). DNS caches are also not updated by authority servers. The serialized records should include their TTLs and the time that they were fetched, so that clients can obey DNS lifetime semantics. If you use exact DNS wire format then you can just append a timestamp covering the whole bundle. Tony. -- f.anthony.n.finch http://dotat.at/ Humber, Thames, Dover: South or southeast 5 to 7, decreasing 4 for a time. Moderate or rough. Showers, occasionally squally. Moderate or good. From fanf2@hermes.cam.ac.uk Thu Jul 7 02:49:07 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3593121F8749 for ; Thu, 7 Jul 2011 02:49:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uwJiOeF1fXOC for ; Thu, 7 Jul 2011 02:49:06 -0700 (PDT) Received: from ppsw-50.csi.cam.ac.uk (ppsw-50.csi.cam.ac.uk [131.111.8.150]) by ietfa.amsl.com (Postfix) with ESMTP id D5B4C21F86B6 for ; Thu, 7 Jul 2011 02:49:05 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:59842) by ppsw-50.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1QelCg-0005hJ-qa (Exim 4.72) (return-path ); Thu, 07 Jul 2011 10:49:02 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1QelCg-0001mz-9P (Exim 4.67) (return-path ); Thu, 07 Jul 2011 10:49:02 +0100 Date: Thu, 7 Jul 2011 10:49:02 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Phillip Hallam-Baker In-Reply-To: Message-ID: References: <201106301842.p5UIgdjK017407@fs4113.wdf.sap.corp> <1309997389.2140.36.camel@localhost> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: dane@ietf.org Subject: Re: [dane] Draft for serializing DNSSEC chains X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 09:49:07 -0000 Phillip Hallam-Baker wrote: > > If RRSIGs are valid for a decade, one compromise of one private key at one > time in history can poison all future use of that domain. No, because the validity period for signatures in parent zones isn't that long. For instance root zone signatures last just over a week. Tony. -- f.anthony.n.finch http://dotat.at/ Shannon: Northwesterly, becoming cyclonic for a time in north, 5 to 7, decreasing 4 in west later. Rough or very rough, becoming moderate or rough. Rain or squally showers. Moderate or good. From hallam@gmail.com Thu Jul 7 06:24:22 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7991F1F0C3E for ; Thu, 7 Jul 2011 06:24:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.574 X-Spam-Level: X-Spam-Status: No, score=-3.574 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x-oX40RSAgWo for ; Thu, 7 Jul 2011 06:24:21 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8B6801F0C3D for ; Thu, 7 Jul 2011 06:24:21 -0700 (PDT) Received: by gyd5 with SMTP id 5so438837gyd.31 for ; Thu, 07 Jul 2011 06:24:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QH58Ei1oIfya0YHXB+uNoJMZci6GWUe7PKHYyUqfQKM=; b=qWLpQ3zRs0+BGfYd2drSwZ6RrSIf2D3Hof4jTmS59Ed9BgQakOX+5rdJOC4dx+cnM5 7CW5FYyEDa2zLzFu+zKwMg6Mx4urzwTZ7tgBDchXlL8Co0lexxJCS1KAYXiKgt7zNPpv rYHRVN8VmTySsYwcivSa4N9sbJQoPW3qj/XyU= MIME-Version: 1.0 Received: by 10.101.168.32 with SMTP id v32mr236124ano.36.1310045060873; Thu, 07 Jul 2011 06:24:20 -0700 (PDT) Received: by 10.100.93.12 with HTTP; Thu, 7 Jul 2011 06:24:20 -0700 (PDT) In-Reply-To: References: <201106301842.p5UIgdjK017407@fs4113.wdf.sap.corp> <1309997389.2140.36.camel@localhost> Date: Thu, 7 Jul 2011 09:24:20 -0400 Message-ID: From: Phillip Hallam-Baker To: Tony Finch Content-Type: multipart/alternative; boundary=001636c5969c7e3dd504a77aa279 Cc: dane@ietf.org Subject: Re: [dane] Draft for serializing DNSSEC chains X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 13:24:22 -0000 --001636c5969c7e3dd504a77aa279 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jul 7, 2011 at 5:49 AM, Tony Finch wrote: > Phillip Hallam-Baker wrote: > > > > If RRSIGs are valid for a decade, one compromise of one private key at > one > > time in history can poison all future use of that domain. > > No, because the validity period for signatures in parent zones isn't that > long. For instance root zone signatures last just over a week. The attack can be easily defeated if DNS registrars use different keys for every DNSSEC hosted domain and roll them when required. That requires a greater degree of competence on the part of registrars than is likely to exist. Many registrars are pure marketing. I know of at least one that does not have a single member of technical staff. If the root zone is going to roll every week it is going to be necessary for these certs to constantly re-issue in any case. Taking up another thread, the point about compatibility with existing uses of self-signed certs is well taken. OCSP is going to work much better as a technical basis for the scheme. It also works much better in terms of pulling through technologies that are valuable and useful for other purposes. To make this approach to DANE work, servers are going to have to deploy code to staple OCSP responses and refresh their OCSP tokens from an appropriate source (DNS records or pull from the CA). I think I can see a collection of mechanisms here that present a win-win for all concerned. Nobody gets everything they might want in the way they prefer, but everyone gets something of value and everyone gets the functionality they want. -- Website: http://hallambaker.com/ --001636c5969c7e3dd504a77aa279 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Jul 7, 2011 at 5:49 AM, Tony Finch <dot@dotat.at> wrote:
Phillip Hallam-Baker <hallam@gmail.com> wrote:
>
> If RRSIGs are valid for a decade, one compromi= se of one private key at one
> time in history can poison all future use of that domain.

No, because the validity period for signatures in parent zones isn= 9;t that
long. For instance root zone signatures last just over a week.
=

The attack can be easily defeated if DNS registrars use= different keys for every DNSSEC hosted domain and roll them when required.=

That requires a greater degree of competence on the par= t of registrars than is likely to exist. Many registrars are pure marketing= . I know of at least one that does not have a single member of technical st= aff.

If the root zone is going to roll every week it is goin= g to be necessary for these certs to constantly re-issue in any case.
=


Taking up another thread, the point abou= t compatibility with existing uses of self-signed certs is well taken.=A0

OCSP is going to work much better as a technical basis = for the scheme. It also works much better in terms of pulling through techn= ologies that are valuable and useful for other purposes. To make this appro= ach to DANE work, servers are going to have to deploy code to staple OCSP r= esponses and refresh their OCSP tokens from an appropriate source (DNS reco= rds or pull from the CA).

I think I can see a collection of mechanisms here that = present a win-win for all concerned. Nobody gets everything they might want= in the way they prefer, but everyone gets something of value and everyone = gets the functionality they want.





--=
Website: http://hallambaker.com/

--001636c5969c7e3dd504a77aa279-- From fanf2@hermes.cam.ac.uk Thu Jul 7 07:00:25 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E420921F8739 for ; Thu, 7 Jul 2011 07:00:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZbvhiNs5PBrx for ; Thu, 7 Jul 2011 07:00:25 -0700 (PDT) Received: from ppsw-51.csi.cam.ac.uk (ppsw-51.csi.cam.ac.uk [131.111.8.151]) by ietfa.amsl.com (Postfix) with ESMTP id DD80821F8734 for ; Thu, 7 Jul 2011 07:00:24 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:39554) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:fanf2) id 1Qep7u-000723-YU (Exim 4.72) (return-path ); Thu, 07 Jul 2011 15:00:22 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1Qep7u-0007Pd-Lv (Exim 4.67) (return-path ); Thu, 07 Jul 2011 15:00:22 +0100 Date: Thu, 7 Jul 2011 15:00:22 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Phillip Hallam-Baker In-Reply-To: Message-ID: References: <201106301842.p5UIgdjK017407@fs4113.wdf.sap.corp> <1309997389.2140.36.camel@localhost> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: dane@ietf.org Subject: Re: [dane] Draft for serializing DNSSEC chains X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 14:00:26 -0000 Phillip Hallam-Baker wrote: > > The attack can be easily defeated if DNS registrars use different keys for > every DNSSEC hosted domain and roll them when required. Registrars have no control over a zone's keys. That is a matter for the DNS hosting provider. > If the root zone is going to roll every week it is going to be necessary for > these certs to constantly re-issue in any case. No, the root zone is re-signed weekly. The root ZSK is rolled quarterly. But yes, I have already said you have to reconstruct a serialized DNSSEC chains of trust frequently. Remember that DNS keys have no explicit lifetime. The validity period is part of the signatures, and you control replay attacks by the frequency of re-signing. Rolling keys is only a prophylactic for disaster recovery. Tony. -- f.anthony.n.finch http://dotat.at/ Sole, Lundy, Fastnet: West or southwest 5 to 7, decreasing 4 at times. Rough or very rough. Rain or squally showers. Moderate or good. From ogud@ogud.com Thu Jul 7 07:08:20 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE3969E8009 for ; Thu, 7 Jul 2011 07:08:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.475 X-Spam-Level: X-Spam-Status: No, score=-106.475 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KdGyvDWZeOOm for ; Thu, 7 Jul 2011 07:08:20 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id 66B1A11E8072 for ; Thu, 7 Jul 2011 07:08:19 -0700 (PDT) Received: from [IPv6:::1] (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p67E8GQr037149 for ; Thu, 7 Jul 2011 10:08:16 -0400 (EDT) (envelope-from ogud@ogud.com) Message-ID: <4E15BDCE.7040609@ogud.com> Date: Thu, 07 Jul 2011 10:08:14 -0400 From: Olafur Gudmundsson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: dane@ietf.org References: <201106301842.p5UIgdjK017407@fs4113.wdf.sap.corp> <1309997389.2140.36.camel@localhost> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Subject: Re: [dane] Draft for serializing DNSSEC chains X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 14:08:20 -0000 On 06/07/2011 9:32 PM, Phillip Hallam-Baker wrote: > > > On Wed, Jul 6, 2011 at 8:09 PM, Matt McCutchen > wrote: > > > > The question that comes up as far as security policy is concerned is > > how recent a signature should be to be recognized. Should this > type of > > self signed cert be valid for an hour, a day a week, a year, a > decade? > > Why should we second-guess the RRSIG validity? Or, if fancier semantics > are desired, why should they be specific to DANE, rather than > incorporated into DNSSEC? > > > Because the RRSIG validity could outlast the ownership of the name and > because there is no revocation mechanism. If the ownership of the name changes then the contents of the DS should have changed in such a way that the old KSK that authorized the DNSKEY in the old operators zone is not listed anymore --> all old signatures will not be accepted i.e. revoked. > > If RRSIGs are valid for a decade, one compromise of one private key at > one time in history can poison all future use of that domain. > in practice it is hard. There are two dimensions to look at here: How long can a record remain in a cache? No signed record will be cached for longer than the TTL on the record. In addition number of resolvers cap how long a record can be stored (think day or few days). In addition oldest records are thrown away when allowed memory is exhausted. In addition most resolvers forget the contents of the cache when restarted. How long can a signed record be "replayed" by an attacker after the record has been removed from the authoritative servers? In this case the the "old" set will be believed if the attacker can inject it into the resolver, i.e. the attacker needs to see the query traffic or use blast of answers and hope it wins the race. If the attacker can see the query traffic, RFC 3833 says in that case all bets are off as to get the answer but a validating resolver should detect what is going on and not proceed. The open issue is "does the current DS set in parent say the key signing the old DNSKEY set is to be believed?" If the answer is yes then then the old set will be accepted. The moral of this is to strongly suggest in an operating guide/BCP: a) do not sign records with signature lifetime greater than X days in the range [5..60]. b) if there is any concern with long lived DNSKEY signed set do a KSK rollover c) Recommend that resolver do not believe a signed RRset past Y days signature inception day Y in the range [60..90] > A domainer could create themselves some chains then sell the domain name. > > I think that pretty much excludes respecting chains for more than a year. IMHO one year is too long. Olafur From mrex@sap.com Thu Jul 7 08:45:14 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF15421F88E7 for ; Thu, 7 Jul 2011 08:45:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.199 X-Spam-Level: X-Spam-Status: No, score=-10.199 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4qKegT9Y0rWG for ; Thu, 7 Jul 2011 08:45:14 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id CFE5B21F88DF for ; Thu, 7 Jul 2011 08:45:13 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p67Fj9h2004790 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 7 Jul 2011 17:45:09 +0200 (MEST) From: Martin Rex Message-Id: <201107071545.p67Fj91L000591@fs4113.wdf.sap.corp> To: hallam@gmail.com (Phillip Hallam-Baker) Date: Thu, 7 Jul 2011 17:45:09 +0200 (MEST) In-Reply-To: from "Phillip Hallam-Baker" at Jul 7, 11 09:24:20 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: dane@ietf.org Subject: Re: [dane] Draft for serializing DNSSEC chains X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 15:45:14 -0000 Phillip Hallam-Baker wrote: > > Tony Finch wrote: > > > Phillip Hallam-Baker wrote: > > > > > > If RRSIGs are valid for a decade, one compromise of one private key > > > at one time in history can poison all future use of that domain. > > > > No, because the validity period for signatures in parent zones isn't > > that long. For instance root zone signatures last just over a week. > > The attack can be easily defeated if DNS registrars use different keys for > every DNSSEC hosted domain and roll them when required. Existing, signed and long-lived RRSETs for a domain can be invalidated by rolling the zone's signing key(s) in the parent zone. Revocation mechanisms are notoriously complex, painful and unreliable. Similar to (real-world) Kerberos, DNSSEC uses short-lived authorizations and regular key replacement/rolling to obviate revocation entirely. -Martin From hallam@gmail.com Thu Jul 7 08:48:06 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37DEE21F88FE for ; Thu, 7 Jul 2011 08:48:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.575 X-Spam-Level: X-Spam-Status: No, score=-3.575 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GrWK6NFcchOu for ; Thu, 7 Jul 2011 08:48:04 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id 66B8521F88ED for ; Thu, 7 Jul 2011 08:48:04 -0700 (PDT) Received: by yie30 with SMTP id 30so518103yie.31 for ; Thu, 07 Jul 2011 08:48:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=YLR0HcxU5hIe4m5yqN4+XJF7/am+a9qm/SyHNcstwfE=; b=lU+8DVqzS/CEhExOWhaEuMY0i0947uKM6wwdRl1GESB6L9DC1bHCbFqoZqqbztdGVo v9rVeOs7xryXncLgZUY+DCG40kaj3Q4uGqBd4+KgqNqfzxO6CPJvwDPs9iv6q/C9PUVZ /U3aylxlERZ9Ry1e+1e36OXyFMo89uRwGibho= MIME-Version: 1.0 Received: by 10.101.168.5 with SMTP id v5mr811877ano.14.1310053683840; Thu, 07 Jul 2011 08:48:03 -0700 (PDT) Received: by 10.100.93.12 with HTTP; Thu, 7 Jul 2011 08:48:03 -0700 (PDT) Date: Thu, 7 Jul 2011 11:48:03 -0400 Message-ID: From: Phillip Hallam-Baker To: dane@ietf.org Content-Type: multipart/alternative; boundary=0016368e35a476451e04a77ca4fc Subject: [dane] The Win-Win-Win proposition X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 15:48:06 -0000 --0016368e35a476451e04a77ca4fc Content-Type: text/plain; charset=ISO-8859-1 As stated in my previous post, I think that if we combine various approaches and suggestions we can arrive at a proposition where everyone gets the functionality they require and everyone gets a protocol gain that they are looking for. Before responding 'I don't want to do it that way', please ask yourself if you can live with the approach proposed. We are dealing with an infrastructure that is now two decades old and there are many legacy constraints that prevent a clean approach working for important sections of the community. First, we separate the problem into two halves: Key Distribution, Issuer Accreditation and Security Policy. *Key Distribution* Admin generates a self signed certificate with a long expiry date. Web server generates an OCSP token with the DNSSEC cert chain pickled in as proposed Web server returns OCSP token as a stapled response when appropriate client extension request is received * Applications can choose to acquire the DNSSEC chain from the OCSP token or direct from the DNS. * OCSP tokens limited in validity to the expiry of the pickled DNSSEC chain. Thus it is invalid for a token containing an RRSIG expiring in a week to claim to be valid for a year. Pros: * Is compatible with legacy browser use of self signed certificates. * Works when the browser does not have access to a source of DNSSEC data (e.g. resolver does not forward RRSIG records). * Changes to client and server require support for OCSP stapling, a feature that is highly desirable for use in EV cert handling. * No scripting support is required at the Web server or DNS administration, the only operation requiring a change to the DNS information is a change of key. * Rolling the crypto algorithm can be performed using the TLS negotiation alone. It is not necessary to wait on the cross product of DNSSEC and TLS algorithm rollover. * Fast, the data is returned in the TLS negotiation which is performed inside an established TCP/IP stream. * Obviates problems caused by data lengths exceeding the UDP/DNS packet length. * Approach is fully compatible with the original concept for OCSP developed by Mike Moore, Warwick Ford and myself. In SAML terms, the DNSSEC chain is a form of 'Advice'. The advice slot in SAML was designed to support proofs. * Extensible to an archive format to provide proof that a particular network action was justified at the time it was taken. * Allows browser performance constraints for the key distribution case to be addressed with full support for wildcards and aliases without the need for special casing HTTP. Cons: * Slightly more complex than pickling the DNSSEC chain into the cert * Cannot address security policy a-priori as the whole mechanism is optional. To Do: * Write down mechanisms for handling CNAME, DNAME, Wildcards. This is actually quite straightforward if the signer knows the full scope for which Web service is being claimed. A server can even synthesize an OCSP token on the fly if required. * Write down a mechanism to enable use in a hierarchical structure. *Issuer Accreditation* Domain holder publishes CAA record with policy and/or path properties. Certificate Issuers verify consistency of requests during issue. Record MAY be published at the domain delegation point (example.com) or the specific domain name Pros: * Is defined, appears to work fine *Security Policy* Security policy MAY be specified at the domain name level, be specific to a particular service at that domain or a particular port on a particular host offering that service Examples: This site always offers TLS, this site requires TLS Examples: This Web server always offers TLS In the Web case we really have two separate security policy interests associated with TLS * Promiscuous security: This site always offers TLS, please use it. * Strict security: This site never accepts insecure connections except to give a redirect to a secure one. google.com is an example of a site that might use the first approach. paypal.com is an example of a site where the second would be more appropriate. Rationale: We know that we require greater granularity than domain names Specifying greater granularity requires use of prefixes Use of prefix records only works in the expected manner if the prefix is applied to a canonical name. DNS Solution: Resolution of security policy is multi phase. First phase looks for a DNS record that never takes a prefix (e.g. CAA) this approach is thus compatible with wildcards and aliases, including possible new alias forms that may be created. If a record is found it will either be at a canonical name or the result of a wildcard match. In either case there is a canonical name at which to continue resolution if necessary If the result of the first phase indicates that greater granularity is required, the appropriate prefix is applied to the canonical name resulting from the last lookup. This solution would be an additional method of distributing the information proposed for distribution in HTTP headers. The difference being that this approach permits action to apply on every connection, not just secure after first connection. Pros: * Provides a comprehensive framework for addressing all aspects of security policy * Allows extended discovery to be addressed in the same framework * Full support for Wildcards, CNAME, DNAME * Extensible to support negotiation of Web Service protocols and Internet protocols. Can greatly simplify protocol management. Cons: * Obtaining security policy information will require extra DNS lookups and DNS processing on every single transaction to a domain for which there is no existing cached data whether HTTPS is indicated or not. * Depends on the client having access to DNSSEC data. *Deployment* I see three potential deployment communities, Web Browsers, Web Services and CAs. *CAs* CAs will deploy CAA because it is their best protection against being extorted. I did not want to raise that particular interest before the attackers did, but that was one of my concerns. CAs have a big stake in making OCSP stapling happening. This proposal will be highly sympathetic to that goal. *Web Browsers* Deployment in Web Browsers is more difficult than many suppose. While there are comparatively few browsers and deployment by three or four major players can get deployment to happen quickly, getting any change agreed can take a very, very long time. Getting anything to happen in the browser world first requires the gate keeper at at least one browser provider to accept the proposal. Unfortunately this is a necessary, not a sufficient step. While most of the gatekeepers have the ability to veto a proposal very few if any have the power to say yes. Modern browsers are written by teams of hundreds of people. In many cases the teams cross organizational boundaries (e.g. calling WebKit, OpenSSL). Thinking of the problem from a gatekeeper's perspective, I could see myself writing some code and getting the organization to accept it. Getting the organization to accept a dependency on a new external code development project is a much, much tougher sell. DNS libraries are big and they are complex. The code that I have been looking at in the past few weeks does not remotely match the type of security requirements I place on code. Strings are allocated from static memory, unsafe buffer handling abounds, use of sprintf, etc. etc. Auditing one of the proposed libraries to ensure compliance with code quality requirements would be a huge undertaking. The Key Distribution proposal described is presented in a form that allows for immediate use to address the Key Distribution issue. It is maximally compatible with the existing code paths. If a self signed cert is presented, the browser simply calls up validation for the stapled OCSP response. Mainstream Web browsers may adopt the Security Policy proposal over time as it is applied in other areas. But it can't be relied on as an early adopter. I would however hope that we could persuade groups like Tor that serve communities under particular threat of a sophisticated downgrade attack to be early adopters of this approach. *Web Services* Deployment for some Web Services and for some Web Service platforms is much easier than for browsers. * New Web Service protocols are developed every day. * Every developer is going to either use an existing platform or write one. * There is competition among platform developers * The DNS based security policy approach allows security and administration to be greatly simplified. * The Security Policy approach is extensible to support protocol and service negotiation. I believe that if the right tools are offered, Web Services could start using this approach very quickly. It solves problems that are currently not addressed at all or only addressed through proprietary approaches. *Roadmap*. The Internet is large, there are a billion users. Deployment of any technology takes time. It is important to be realistic in setting expectations. The approach proposed allows immediate progress on the Key Distribution and Issuer Accreditation fronts. Progress on the Security Policy side will take a little longer as we will probably need to have a spec for the first two settled before we start work on the second. -- Website: http://hallambaker.com/ --0016368e35a476451e04a77ca4fc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable As stated in my previous post, I think that if we combine various approache= s and suggestions we can arrive at a proposition where everyone gets the fu= nctionality they require and everyone gets a protocol gain that they are lo= oking for.

Before responding 'I don't want to do it that way= 9;, please ask yourself if you can live with the approach proposed. We are = dealing with an infrastructure that is now two decades old and there are ma= ny legacy constraints that prevent a clean approach working for important s= ections of the community.


First, we separate the problem into two = halves: Key Distribution, Issuer Accreditation and Security Policy.



* Applications can choose to acquire the DNSSEC chain f= rom the OCSP token or direct from the DNS.
* OCSP tokens limited = in validity to the expiry of the pickled DNSSEC chain. Thus it is invalid f= or a token containing an RRSIG expiring in a week to claim to be valid for = a year.

Pros:

* Is compatible with leg= acy browser use of self signed certificates.
* Works when the bro= wser does not have access to a source of DNSSEC data (e.g. resolver does no= t forward RRSIG records).
* Changes to client and server require support for OCSP stapling, a fe= ature that is highly desirable for use in EV cert handling.
* No = scripting support is required at the Web server or DNS administration, the = only operation requiring a change to the DNS information is a change of key= .
* Rolling the crypto algorithm can be performed using the TLS negotiat= ion alone. It is not necessary to wait on the cross product of DNSSEC and T= LS algorithm rollover.
* Fast, the data is returned in the TLS ne= gotiation which is performed inside an established TCP/IP stream.=A0
* Obviates problems caused by data lengths exceeding the UDP/DNS packe= t length.=A0
* Approach is fully compatible with the original con= cept for OCSP developed by Mike Moore, Warwick Ford and myself. In SAML ter= ms, the DNSSEC chain is a form of 'Advice'. The advice slot in SAML= was designed to support proofs.
* Extensible to an archive format to provide proof that a particular n= etwork action was justified at the time it was taken.
* Allows br= owser performance constraints for the key distribution case to be addressed= with full support for wildcards and aliases without the need for special c= asing HTTP.

Cons:

* Slightly more complex = than pickling the DNSSEC chain into the cert
* Cannot address sec= urity policy a-priori as the whole mechanism is optional.

To Do:

* Write down mechanisms for hand= ling CNAME, DNAME, Wildcards. This is actually quite straightforward if the= signer knows the full scope for which Web service is being claimed. A serv= er can even synthesize an OCSP token on the fly if required.
* Write down a mechanism to enable use in a hierarchical structure.


Issuer Accreditation

Domain holder publishes CAA record with policy and/or path = properties.
Certificate Issuers verify consistency of requests during issue.
=
Pros:

* Is defined, appears to work fin= e


Security Policy
=
Security policy MAY be specified at the domain name level, b= e specific to a particular service at that domain or a particular port on a= particular host offering that service

Examples: This site always offers TLS, this site requir= es TLS
Examples: This Web server always offers TLS

=
In the Web case we really have two separate security policy inte= rests associated with TLS

* Promiscuous security: This site always offers TLS, pl= ease use it.
* Strict security: This site never accepts insecure = connections except to give a redirect to a secure one.

google.com is an example of a site t= hat might use the first approach. paypal.com<= /a> is an example of a site where the second would be more appropriate.

Rationale:

We know that we req= uire greater granularity than domain names
Specifying greater gra= nularity requires use of prefixes
Use of prefix records only work= s in the expected manner if the prefix is applied to a canonical name.

DNS Solution:

Resolution of se= curity policy is multi phase.
First phase looks for a DNS record = that never takes a prefix (e.g. CAA) this approach is thus compatible with = wildcards and aliases, including possible new alias forms that may be creat= ed.
If a record is found it will either be at a canonical name or the resu= lt of a wildcard match. In either case there is a canonical name at which t= o continue resolution if necessary
If the result of the first pha= se indicates that greater granularity is required, the appropriate prefix i= s applied to the canonical name resulting from the last lookup.

This solution would be an additional method of distribu= ting the information proposed for distribution in HTTP headers. The differe= nce being that this approach permits action to apply on every connection, n= ot just secure after first connection.


Pros:

* Provide= s a comprehensive framework for addressing all aspects of security policy
* Allows extended discovery to be addressed in the same framework<= /div>
* Full support for Wildcards, CNAME, DNAME
* Extensible to s= upport negotiation of Web Service protocols and Internet protocols. Can gre= atly simplify protocol management.

Cons:

* Obtaining security policy information will require ex= tra DNS lookups and DNS processing on every single transaction to a domain = for which there is no existing cached data whether HTTPS is indicated or no= t.
* Depends on the client having access to DNSSEC data.


Deployment

I see th= ree potential deployment communities, Web Browsers, Web Services and CAs.


CAs

CAs = will deploy CAA because it is their best protection against being extorted.= I did not want to raise that particular interest before the attackers did,= but that was one of my concerns.

CAs have a big stake in making OCSP stapling happening.= This proposal will be highly sympathetic to that goal.


Web Browsers

Deploymen= t in Web Browsers is more difficult than many suppose. While there are comp= aratively few browsers and deployment by three or four major players can ge= t deployment to happen quickly, getting any change agreed can take a very, = very long time.

Getting anything to happen in the browser world first r= equires the gate keeper at at least one browser provider to accept the prop= osal. Unfortunately this is a necessary, not a sufficient step. While most = of the gatekeepers have the ability to veto a proposal very few if any have= the power to say yes. Modern browsers are written by teams of hundreds of = people. In many cases the teams cross organizational boundaries (e.g. calli= ng WebKit, OpenSSL).

Thinking of the problem from a gatekeeper's perspec= tive, I could see myself writing some code and getting the organization to = accept it. Getting the organization to accept a dependency on a new externa= l code development project is a much, much tougher sell. DNS libraries are = big and they are complex.=A0

The code that I have been looking at in the past few we= eks does not remotely match the type of security requirements I place on co= de. Strings are allocated from static memory, unsafe buffer handling abound= s, use of sprintf, etc. etc. Auditing one of the proposed libraries to ensu= re compliance with code quality requirements would be a huge undertaking.

The Key Distribution proposal described is presented in= a form that allows for immediate use to address the Key Distribution issue= . It is maximally compatible with the existing code paths. If a self signed= cert is presented, the browser simply calls up validation for the stapled = OCSP response.

Mainstream Web browsers may adopt the Security Policy p= roposal over time as it is applied in other areas. But it can't be reli= ed on as an early adopter.

I would however hope th= at we could persuade groups like Tor that serve communities under particula= r threat of a sophisticated downgrade attack to be early adopters of this a= pproach.


Web Services

=
Deployment for some Web Services and for some Web Service platforms is= much easier than for browsers.

* New Web Service = protocols are developed every day.
* Every developer is going to either use an existing platform or write= one.
* There is competition among platform developers
= * The DNS based security policy approach allows security and administration= to be greatly simplified.
* The Security Policy approach is extensible to support protocol and s= ervice negotiation.

I=A0believe=A0that if the righ= t tools are offered, Web Services could start using this approach very quic= kly. It solves problems that are currently not addressed at all or only add= ressed through proprietary approaches.


Roadmap.

The Internet is large, there are a billion users. Deployment of any techno= logy takes time. It is important to be realistic in setting expectations.

The approach proposed allows immediate progress on the = Key Distribution and Issuer Accreditation fronts. Progress on the Security = Policy side will take a little longer as we will probably need to have a sp= ec for the first two settled before we start work on the second.

 --0016368e35a476451e04a77ca4fc-- From mlarson@verisign.com Thu Jul 7 08:53:33 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 763A211E8074 for ; Thu, 7 Jul 2011 08:53:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SYKPApfkF+jV for ; Thu, 7 Jul 2011 08:53:32 -0700 (PDT) Received: from exprod6og101.obsmtp.com (exprod6og101.obsmtp.com [64.18.1.181]) by ietfa.amsl.com (Postfix) with ESMTP id 5439411E8072 for ; Thu, 7 Jul 2011 08:53:32 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob101.postini.com ([64.18.5.12]) with SMTP ID DSNKThXWezQ7SnX5gsxB1Eh+gXcGgooOHiHq@postini.com; Thu, 07 Jul 2011 08:53:32 PDT Received: from dul1wnexcn01.vcorp.ad.vrsn.com (dul1wnexcn01.vcorp.ad.vrsn.com [10.170.12.138]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id p67FrV9O012020 for ; Thu, 7 Jul 2011 11:53:31 -0400 Received: from DUL1MLARSON-M2 ([10.100.0.227]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 7 Jul 2011 11:53:30 -0400 Date: Thu, 7 Jul 2011 11:53:30 -0400 From: Matt Larson To: dane@ietf.org Message-ID: <20110707155330.GI16425@DUL1MLARSON-M2.vcorp.ad.vrsn.com> References: <4E1175F1.4080201@nlnetlabs.nl> <20110706222032.GH6770@DUL1MLARSON-M2.vcorp.ad.vrsn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-OriginalArrivalTime: 07 Jul 2011 15:53:30.0266 (UTC) FILETIME=[046DCFA0:01CC3CBE] Subject: Re: [dane] Draft for serializing DNSSEC chains (01) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 15:53:33 -0000 On Wed, 06 Jul 2011, Phillip Hallam-Baker wrote: > On Wed, Jul 6, 2011 at 6:20 PM, Matt Larson wrote: > > > On Wed, 06 Jul 2011, Adam Langley wrote: > > > In order to keep the simplicity I'm giving the algorithm rollover > > > problem to another layer. > > > > This scares me. > > > Why, specify your fears. The protocol, as I understand it, extracts a specific trust path to embed in the cert, which may then supply algorithms to a client that it can't understand. Using standard DNS transport, the client gets all records and can use what it needs and understands. It sounds to me that rather than addressing the issue that supplying a single trust chain may be problematic, this proposal kicks that can down the road for someone else. Well, who? > We have to solve the algorithm rollover problem for SSL in any case. I think we're probably not understanding each other. Are you suggesting that some kind of negotiation would need to be added that would allow the client to get a trust path it can understand? If so, that's yet more complexity that will cause operational issues, as Eric has been pointing out. If that's not it, then this issue (a single trust path that's possibly not usuable by the client) is not solved. Both of those choices (yet more complexity or an unsolved issue) are troubling. > > Unlike serving DNSSEC data using the DNS protocol, there's the > > > possibility of choosing a different serialization for different > > > clients. > > > > This also scares me. > > There is a really really bad history of people making arguments based on > fears or the state of their gut. My objections here are the same as above: increased complexity that's yet unspecified in this protocol. > > > Negotiation of acceptable algorithms can thus be done by the higher > > > layers. > > > > And this. > > Why, do you understand how SSL negotiation works? It is pretty well > established at this point. People have been doing it for 15 years now. Yes, I understand SSL negotiation. I'm not suggesting negotiation is impossible, but that it appears that as this protocol is being investigated, more issues are getting uncovered. Using an alternate transport for DNS records that might require some negotiation for the client to get the right trust path is undisputably more complicated than a DNS lookup to retrieve the same information. > > > Yes, I believe that DNAMEs would be simple to add but I've hesitated > > > so far > > > > Aside from the fact that using X.509 as a transport for DNS resource > > records is a grievous layer violation, statements such as above (no > > DNAME support yet) show the complexity of forcing this square peg into > > this round hole. And taking into account Eric's legitimate concerns > > about stale information and operational complexity, I'm concerned > > about this protocol. > > > I don't see it as a layer violation. Its just another transport instead of > DNS query response. We might have to disagree. > It is a much simpler form of transport than messing with DNS queries, it > avoids the need for asynchronous response handling and is equivalent to > caching the DNS data. It's only equivalent to caching DNS data if it has the exact same properties as a DNS cache regarding expiry. I don't believe this protocol can do that without fantastic complexity. > If DNAME is the criteria, Adam is a lot closer to a solution than the > Hoffman draft is. I can modify Adam's proposal to support DNAME quite > simply. Making prefix records work with DNAME is a known incompatibility. > > > Arguments based on complexity sound rather hollow to me having spent the > past few weeks writing DNS resolution code. Code complexity is different than operational complexity, which is the position Eric and I are arguing from. I believe my background and current responsibilities allow me to opine on operational complexity. > There is 16 years of history that has flowed under that particular bridge. > Any new mechanism for key distribution has to work at least as well in > practice as the existing scheme. Adam is the only person that has proposed > such a scheme. It does look like a bit of a hack, but it is probably the > least uggly solution that is going to work at least as well as the existing > scheme. I'm not arguing that, from an expediency standpoint based on deployed code, it may well be easier to get DNSSEC information to a client using an SSL cert as transport rather than a standard DNS lookup. What I am suggesting is that it would be operationally very complicated and introduce new caching semantics. It is operationally inevitable that trust paths will be frozen in SSL certs leading to validation failures. Using only the DNS infrastructure, there is no place for data to become that stale. > That still leaves security policy as an area where the 'get the info from > the DNS' approach is the only game in town. So it is not like embracing > Adam's scheme means that the need for DNSSEC aware resolvers goes away. You are presuming an objection I didn't make. Matt From hallam@gmail.com Thu Jul 7 08:53:47 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F1A311E8087 for ; Thu, 7 Jul 2011 08:53:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.577 X-Spam-Level: X-Spam-Status: No, score=-3.577 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rjnhxFQrjXfk for ; Thu, 7 Jul 2011 08:53:46 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 87D6711E8072 for ; Thu, 7 Jul 2011 08:53:46 -0700 (PDT) Received: by ywp31 with SMTP id 31so503811ywp.31 for ; Thu, 07 Jul 2011 08:53:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Rq9NAo/LEEyjOekoHB2gkmKJLJX5CUndQ9jv0zonIXM=; b=iItiwXZzVNFVF4cdWAqwvt0IPAIkfHNMS+sUw/c/evqqfuVoDfyT+694NDMziEqFZB ROpuFLiscprv4YRXQ6Xe+Dxe6YZFngtmgIvMQvAU0r8qUvB1ACEQrUmX2iiilP5IOJnH HwWn7jy8zM64urYDGeDS+0WhgNk4YjwBT2yuU= MIME-Version: 1.0 Received: by 10.101.162.11 with SMTP id p11mr772205ano.159.1310054026032; Thu, 07 Jul 2011 08:53:46 -0700 (PDT) Received: by 10.100.93.12 with HTTP; Thu, 7 Jul 2011 08:53:45 -0700 (PDT) In-Reply-To: <201107071545.p67Fj91L000591@fs4113.wdf.sap.corp> References: <201107071545.p67Fj91L000591@fs4113.wdf.sap.corp> Date: Thu, 7 Jul 2011 11:53:45 -0400 Message-ID: From: Phillip Hallam-Baker To: mrex@sap.com Content-Type: multipart/alternative; boundary=001636ed6c7fdbb79304a77cb8fa Cc: dane@ietf.org Subject: Re: [dane] Draft for serializing DNSSEC chains X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 15:53:47 -0000 --001636ed6c7fdbb79304a77cb8fa Content-Type: text/plain; charset=ISO-8859-1 I agree that revocation mechanisms are a big pain. I was not arguing for a revocation mechanism, I was arguing against a long lived key. I much, much prefer to have short lived keys than a revocation mechanism. If we were to redesign PKI from scratch I would get rid of the revocation mechanism entirely and require certs to be valid for no more than 24 hours. In a key centric model like XKMS, certs are not necessary at all. I think we are all in violent agreement here. On Thu, Jul 7, 2011 at 11:45 AM, Martin Rex wrote: > Phillip Hallam-Baker wrote: > > > > Tony Finch wrote: > > > > > Phillip Hallam-Baker wrote: > > > > > > > > If RRSIGs are valid for a decade, one compromise of one private key > > > > at one time in history can poison all future use of that domain. > > > > > > No, because the validity period for signatures in parent zones isn't > > > that long. For instance root zone signatures last just over a week. > > > > The attack can be easily defeated if DNS registrars use different keys > for > > every DNSSEC hosted domain and roll them when required. > > Existing, signed and long-lived RRSETs for a domain can be invalidated > by rolling the zone's signing key(s) in the parent zone. > > Revocation mechanisms are notoriously complex, painful and unreliable. > Similar to (real-world) Kerberos, DNSSEC uses short-lived authorizations > and regular key replacement/rolling to obviate revocation entirely. > > -Martin > -- Website: http://hallambaker.com/ --001636ed6c7fdbb79304a77cb8fa Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I agree that revocation mechanisms are a big pain. I was not arguing for a = revocation mechanism, I was arguing against a long lived key.

I much, much prefer to have short lived keys than a revocation mechan= ism. If we were to redesign PKI from scratch I would get rid of the revocat= ion mechanism entirely and require certs to be valid for no more than 24 ho= urs. In a key centric model like XKMS, certs are not necessary at all.

I think we are all in violent agreement here.

=

On Thu, Jul 7, 2011 at= 11:45 AM, Martin Rex <mrex@sap.com> wrote:
Phillip Hallam-Baker wrote:
>
> Tony Finch wrote:
>
> > Phillip Hallam-Baker wrote:
> > >
> > > If RRSIGs are valid for a decade, one compromise of one priv= ate key
> > > at one time in history can poison all future use of that dom= ain.
> >
> > No, because the validity period for signatures in parent zones is= n't
> > that long. For instance root zone signatures last just over a wee= k.
>
> The attack can be easily defeated if DNS registrars use different keys= for
> every DNSSEC hosted domain and roll them when required.

Existing, signed and long-lived RRSETs for a domain can be invalidate= d
by rolling the zone's signing key(s) in the parent zone.

Revocation mechanisms are notoriously complex, painful and unreliable.
Similar to (real-world) Kerberos, DNSSEC uses short-lived authorizations and regular key replacement/rolling to obviate revocation entirely.

-Martin



--
Website: http://hallambaker.com/

--001636ed6c7fdbb79304a77cb8fa-- From hallam@gmail.com Thu Jul 7 09:48:09 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B54311E8072 for ; Thu, 7 Jul 2011 09:48:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HRakB83w8XyK for ; Thu, 7 Jul 2011 09:48:07 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6769421F861E for ; Thu, 7 Jul 2011 09:48:07 -0700 (PDT) Received: by gxk19 with SMTP id 19so466961gxk.31 for ; Thu, 07 Jul 2011 09:48:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6sXJtxpqZjBrx/Pp7SXcyrcJMlZ+WzAlCcB7ZsyCILU=; b=B/xLUikqWkXGXT2QE5Z5gV8ZLUUZUV6jlahyOYeh3fqfX7RRe4zsL7xQchhZp4OeOY IlOFO/yisVyt1yZoKHyJkF4RHi7zqBPC3667dKGKiTNZGKU8DgdRnx0c1wU7cQ1pqMqz R0+2IpDLG17Z4DQRM0K1LiyAsjZfEcb8MK6uI= MIME-Version: 1.0 Received: by 10.101.180.22 with SMTP id h22mr891146anp.80.1310057286593; Thu, 07 Jul 2011 09:48:06 -0700 (PDT) Received: by 10.100.93.12 with HTTP; Thu, 7 Jul 2011 09:48:06 -0700 (PDT) In-Reply-To: <20110707155330.GI16425@DUL1MLARSON-M2.vcorp.ad.vrsn.com> References: <4E1175F1.4080201@nlnetlabs.nl> <20110706222032.GH6770@DUL1MLARSON-M2.vcorp.ad.vrsn.com> <20110707155330.GI16425@DUL1MLARSON-M2.vcorp.ad.vrsn.com> Date: Thu, 7 Jul 2011 12:48:06 -0400 Message-ID: From: Phillip Hallam-Baker To: Matt Larson Content-Type: multipart/alternative; boundary=001636c9258533eebe04a77d7bbe Cc: dane@ietf.org Subject: Re: [dane] Draft for serializing DNSSEC chains (01) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 16:48:09 -0000 --001636c9258533eebe04a77d7bbe Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jul 7, 2011 at 11:53 AM, Matt Larson wrote: > On Wed, 06 Jul 2011, Phillip Hallam-Baker wrote: > > On Wed, Jul 6, 2011 at 6:20 PM, Matt Larson > wrote: > > > > > On Wed, 06 Jul 2011, Adam Langley wrote: > > > > In order to keep the simplicity I'm giving the algorithm rollover > > > > problem to another layer. > > > > > > This scares me. > > > > > > Why, specify your fears. > > The protocol, as I understand it, extracts a specific trust path to > embed in the cert, which may then supply algorithms to a client that > it can't understand. Using standard DNS transport, the client gets > all records and can use what it needs and understands. > > It sounds to me that rather than addressing the issue that supplying a > single trust chain may be problematic, this proposal kicks that can > down the road for someone else. Well, who? The whole attraction of DNSSEC as a PKI is that it only allows assertions to be made with respect to the namespace and the namespace is strictly hierarchical. Getting all the DNS records does not make life easier for the client in any way. It kicks the client back to the problem of performing PKI paths and path-math. While there are circumstances in which the DNS hierarchy can become ambiguous, those are essentially doomsday scenarios involving state level conflicts. One of the attractions of this approach is precisely the fact that it still continues to work in the case that the Shanghai Cooperation Organization countries make good on their treaty commitments and decide to set up their own DNS root and block external access to the ICANN root. > > We have to solve the algorithm rollover problem for SSL in any case. > > I think we're probably not understanding each other. Are you > suggesting that some kind of negotiation would need to be added that > would allow the client to get a trust path it can understand? If so, > that's yet more complexity that will cause operational issues, as Eric > has been pointing out. > No, the problem is that SSL currently has no viable strategy for upgrading from use of SHA1 to a new algorithm whatsoever. If we can't use SHA2 or SHA3 in the browser, the ability to use it in DNSSEC is irrelevant. Simply deploying SHA2 in new browsers and waiting for old ones to stop being used is a naive approach to deployment that is certain to fail. Cert customers measure the value of a certificate by the amount of customers and business it helps generate, not the amount of risk it mitigates. In fact they are entirely uninterested in the risk of the cert being hijacked during transport as that is not a risk that they are likely to be held liable for in any circumstance. Under the existing upgrade proposal a site that deploys a SHA2 signed certificate is guaranteed to loose some percentage of their business. At the moment that would be around 40% due to the widespread use of Windows XP and older. This problem is not necessarily improving. Mobile phones are becoming more popular and many of them have very restricted PKI. No business is going to sacrifice 40% of their business to upgrade to SHA2. They wouldn't even do that if SHA1 was broken. No business is going to sacrifice 5% or even 1%. Hence there is a requirement for a better solution. The problem comes from the fact that the legacy protocol, the servers and browsers are built around the assumption that there is one certificate per site. The certificate is presented at the wrong stage in the SSL negotiation. There is thus an existing problem that the TLS world has to solve. One approach that works very well is to put a flag in the cert to say 'you can pull this OCSP response and get a SHA2 digest of me in it. This would all have been avoided if OCSP had specified the certificate whose status is being reported by means of a message digest of the cert as originally proposed and not the CertID being the serial number of the cert being reported on: CertID ::= SEQUENCE { hashAlgorithm AlgorithmIdentifier, issuerNameHash OCTET STRING, -- Hash of Issuer's DN issuerKeyHash OCTET STRING, -- Hash of Issuers public key serialNumber CertificateSerialNumber } I missed that change when the spec was converted into ASN.1. It has two hashes and neither is the right one. If that's not it, then this issue (a single trust path that's possibly > not usuable by the client) is not solved. > > Both of those choices (yet more complexity or an unsolved issue) are > troubling. You seem to use the term 'complexity' as meaning 'things I am not familiar with'. PKI is complex, browsers are even more complex. The proposal made by Adam has no more complexity than the alternative and is considerably simpler to administer and code. > > > Unlike serving DNSSEC data using the DNS protocol, there's the > > > > possibility of choosing a different serialization for different > > > > clients. > > > > > > This also scares me. > > > > There is a really really bad history of people making arguments based on > > fears or the state of their gut. > > My objections here are the same as above: increased complexity that's > yet unspecified in this protocol. There are empirical measures of complexity: The number of FSM states, the number of places where consistency between data stored in different places is required. The proposal made by Adam involves fewer FSM states than the existing code according to my analysis. The relying party has only one path to validate and the data is presented in a fashion that permits the validation to be performed by a simple for loop with a fixed number of state variables carried from one iteration to the next. The complexity is thus O (n) The existing DANE draft inescapably requires PKI path construction to be performed which is a graph matching problem and is thus complex and has O(n ln (n)) complexity at best, O (n^2) for a typical implementation. It is thus less complex according to my objective criteria. > > > > Negotiation of acceptable algorithms can thus be done by the higher > > > > layers. > > > > > > And this. > > > > Why, do you understand how SSL negotiation works? It is pretty well > > established at this point. People have been doing it for 15 years now. > > Yes, I understand SSL negotiation. I'm not suggesting negotiation is > impossible, but that it appears that as this protocol is being > investigated, more issues are getting uncovered. None of the issues uncovered give me the slightest concern. SSL negotiation is a tool that is designed to be used. If someone is proposing a new way to do SSL that is not making use of the SSL negotiation mechanism there is probably something wrong. > Using an alternate > transport for DNS records that might require some negotiation for the > client to get the right trust path is undisputably more complicated > than a DNS lookup to retrieve the same information. No, it isn't. What is indisputable is that O(n) is less than O(n ln (n)) and that a for loop is much less complex than graph matching which is known to be worst case np-complete. > > > > Yes, I believe that DNAMEs would be simple to add but I've hesitated > > > > so far > > > > > > Aside from the fact that using X.509 as a transport for DNS resource > > > records is a grievous layer violation, statements such as above (no > > > DNAME support yet) show the complexity of forcing this square peg into > > > this round hole. And taking into account Eric's legitimate concerns > > > about stale information and operational complexity, I'm concerned > > > about this protocol. > > > > > > I don't see it as a layer violation. Its just another transport instead > of > > DNS query response. > > We might have to disagree. I can't see how you can assert this as a layer violation without also asserting that any inclusion of application PKI data in the DNS is a layer violation. > > If DNAME is the criteria, Adam is a lot closer to a solution than the > > Hoffman draft is. I can modify Adam's proposal to support DNAME quite > > simply. Making prefix records work with DNAME is a known incompatibility. > > > > > > Arguments based on complexity sound rather hollow to me having spent the > > past few weeks writing DNS resolution code. > > Code complexity is different than operational complexity, which is the > position Eric and I are arguing from. I believe my background and > current responsibilities allow me to opine on operational complexity. We may have to disagree. The proposal made by Adam works in the existing DNS infrastructure without assuming any further deployment. The proposal you appear to be backing depends on clients being able to access DNSSEC data. Support for that is well short of 100% and is highly unlikely to ever reach a level that makes use of a security scheme that depends on that access being practical. >From an operational point of view I prefer the approach that is guaranteed to work with my WiFi router than the one that is likely to force an upgrade. > There is 16 years of history that has flowed under that particular bridge. > > Any new mechanism for key distribution has to work at least as well in > > practice as the existing scheme. Adam is the only person that has > proposed > > such a scheme. It does look like a bit of a hack, but it is probably the > > least uggly solution that is going to work at least as well as the > existing > > scheme. > > I'm not arguing that, from an expediency standpoint based on deployed > code, it may well be easier to get DNSSEC information to a client > using an SSL cert as transport rather than a standard DNS lookup. > What I am suggesting is that it would be operationally very > complicated and introduce new caching semantics. It is operationally > inevitable that trust paths will be frozen in SSL certs leading to > validation failures. Using only the DNS infrastructure, there is no > place for data to become that stale. Does caching in the OCSP token work better for you? The OCSP token is separate from the cert and validity can be limited to the expiry of the RRSig expiring earliest. -- Website: http://hallambaker.com/ --001636c9258533eebe04a77d7bbe Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, Jul 7, 2011 at 11:53 AM, Matt La= rson <mlarson@= verisign.com> wrote:
On Wed, 06 Jul 2011, Phillip Hallam-Baker wrote:
> On Wed, Jul 6, 2011 at 6:20 PM, Matt Larson <mlarson@verisign.com> wrote:
>
> > On Wed, 06 Jul 2011, Adam Langley wrote:
> > > In order to keep the simplicity I'm giving the algorithm= rollover
> > > problem to another layer.
> >
> > This scares me.
>
>
> Why, specify your fears.

The protocol, as I understand it, extracts a specific trust path to embed in the cert, which may then supply algorithms to a client that
it can't understand. =A0Using standard DNS transport, the client gets all records and can use what it needs and understands.

It sounds to me that rather than addressing the issue that supplying a
single trust chain may be problematic, this proposal kicks that can
down the road for someone else. =A0Well, who?

The whole attraction of DNSSEC as a PKI is that it only allows assertion= s to be made with respect to the namespace and the namespace is strictly hi= erarchical.

Getting all the DNS records does not make life easier f= or the client in any way. It kicks the client back to the problem of perfor= ming PKI paths and path-math.=A0

While there are c= ircumstances in which the DNS hierarchy can become ambiguous, those are ess= entially doomsday scenarios involving state level conflicts. One of the att= ractions of this approach is precisely the fact that it still continues to = work in the case that the Shanghai Cooperation Organization countries make = good on their treaty commitments and decide to set up their own DNS root an= d block external access to the ICANN root.

=A0
> We have to solve the algorithm rollover problem for SSL in any case.
I think we're probably not understanding each other. =A0Are you suggesting that some kind of negotiation would need to be added that
would allow the client to get a trust path it can understand? =A0If so,
that's yet more complexity that will cause operational issues, as Eric<= br> has been pointing out.

No, the problem = is that SSL currently has no viable strategy for upgrading from use of SHA1= to a new algorithm whatsoever.=A0

If we can't= use SHA2 or SHA3 in the browser, the ability to use it in DNSSEC is irrele= vant.

Simply deploying SHA2 in new browsers and waiting for o= ld ones to stop being used is a naive approach to deployment that is certai= n to fail. Cert customers measure the value of a certificate by the amount = of customers and business it helps generate, not the amount of risk it miti= gates. In fact they are entirely uninterested in the risk of the cert being= hijacked during transport as that is not a risk that they are likely to be= held liable for in any circumstance.

Under the existing upgrade proposal a site that deploys= a SHA2 signed certificate is guaranteed to loose some percentage of their = business. At the moment that would be around 40% due to the widespread use = of Windows XP and older. This problem is not necessarily improving. Mobile = phones are becoming more popular and many of them have very restricted PKI.=

No business is going to sacrifice 40% of their business= to upgrade to SHA2. They wouldn't even do that if SHA1 was broken. No = business is going to sacrifice 5% or even 1%. Hence there is a requirement = for a better solution.


The problem comes from the fact that the= legacy protocol, the servers and browsers are built around the assumption = that there is one certificate per site. The certificate is presented at the= wrong stage in the SSL negotiation.

There is thus an existing problem that the TLS world ha= s to solve.

One approach that works very well is t= o put a flag in the cert to say 'you can pull this OCSP response and ge= t a SHA2 digest of me in it.

This would all have been avoided if OCSP had specified = the certificate whose status is being reported by means of a message digest= of the cert as originally proposed and not the CertID being the serial num= ber of the cert being reported on:

CertID ::=3D SEQUENCE {
    hashAlgorithm            AlgorithmIdentifier,
    issuerNameHash     OCTET STRING, -- Hash of Issuer's DN
    issuerKeyHash      OCTET STRING, -- Hash of Issuers public key
    serialNumber       CertificateSerialNumber }
=A0=

I missed that change when the spec was converted = into ASN.1.

It has two hashes and neither is the r= ight one.


If that's not it, then this issue (a single trust path that's possi= bly
not usuable by the client) is not solved.

Both of those choices (yet more complexity or an unsolved issue) are
troubling.

You seem to use the term 'co= mplexity' as meaning 'things I am not familiar with'.

PKI is complex, browsers are even more complex. The proposa= l made by Adam has no more complexity than the alternative and is considera= bly simpler to administer and code.

=A0
> > Unlike serving DNSSEC data using the DNS protocol, there's th= e
> > > possibility of choosing a different serialization for differ= ent
> > > clients.
> >
> > This also scares me.
>
> There is a really really bad history of people making arguments based = on
> fears or the state of their gut.

My objections here are the same as above: increased complexity that&#= 39;s
yet unspecified in this protocol.

There are= empirical measures of complexity: The number of FSM states, the number of = places where consistency between data stored in different places is require= d.

The proposal made by Adam involves fewer FSM states tha= n the existing code according to my analysis. The relying party has only on= e path to validate and the data is presented in a fashion that permits the = validation to be performed by a simple for loop with a fixed number of stat= e variables carried from one iteration to the next. The complexity is thus = O (n) The existing DANE draft inescapably requires PKI path construction to= be performed which is a graph matching problem and is thus complex and has= O(n ln (n)) complexity at best, O (n^2) for a typical implementation.

It is thus less complex according to my objective crite= ria.


=A0
> > > Negotiation of acceptable algorithms can thus be done by the= higher
> > > layers.
> >
> > And this.
>
> Why, do you understand how SSL negotiation works? It is pretty well > established at this point. People have been doing it for 15 years now.=

Yes, I understand SSL negotiation. =A0I'm not suggesting negotiat= ion is
impossible, but that it appears that as this protocol is being
investigated, more issues are getting uncovered.

None of the issues uncovered give me the slightest concern. SSL negot= iation is a tool that is designed to be used.

If someone is proposing a new way to do SSL that is not making use of the S= SL negotiation mechanism there is probably something wrong.
=A0
=A0Using an alternate
transport for DNS records that might require some negotiation for the
client to get the right trust path is undisputably more complicated
than a DNS lookup to retrieve the same information.

No, it isn't.

What is indisputable is= that O(n) is less than O(n ln (n)) and that a for loop is much less comple= x than graph matching which is known to be worst case np-complete.


=A0
> > > Yes, I believe that DNAMEs would be simple to add but I'= ve hesitated
> > > so far
> >
> > Aside from the fact that using X.509 as a transport for DNS resou= rce
> > records is a grievous layer violation, statements such as above (= no
> > DNAME support yet) show the complexity of forcing this square peg= into
> > this round hole. =A0And taking into account Eric's legitimate= concerns
> > about stale information and operational complexity, I'm conce= rned
> > about this protocol.
>
>
> I don't see it as a layer violation. Its just another transport in= stead of
> DNS query response.

We might have to disagree.

I can'= t see how you can assert this as a layer violation without also asserting t= hat any inclusion of application PKI data in the DNS is a layer violation.<= /div>

=A0
=A0
=
> If DNAME is the criteria, Adam is a lot closer to a solution than the<= br> > Hoffman draft is. I can modify Adam's proposal to support DNAME qu= ite
> simply. Making prefix records work with DNAME is a known incompatibili= ty.
>
>
> Arguments based on complexity sound rather hollow to me having spent t= he
> past few weeks writing DNS resolution code.

Code complexity is different than operational complexity, which is th= e
position Eric and I are arguing from. =A0I believe my background and
current responsibilities allow me to opine on operational complexity.

We may have to disagree.=A0

=
The proposal made by Adam works in the existing DNS infrastructure wit= hout assuming any further deployment.

The proposal you appear to be backing depends on client= s being able to access DNSSEC data. Support for that is well short of 100% = and is highly unlikely to ever reach a level that makes use of a security s= cheme that depends on that access being practical.=A0

From an operational point of view I prefer the approach= that is guaranteed to work with my WiFi router than the one that is likely= to force an upgrade.
=A0

> There is 16 years of history that has flowed under that particular bri= dge.
> Any new mechanism for key distribution has to work at least as well in=
> practice as the existing scheme. Adam is the only person that has prop= osed
> such a scheme. It does look like a bit of a hack, but it is probably t= he
> least uggly solution that is going to work at least as well as the exi= sting
> scheme.

I'm not arguing that, from an expediency standpoint based on depl= oyed
code, it may well be easier to get DNSSEC information to a client
using an SSL cert as transport rather than a standard DNS lookup.
What I am suggesting is that it would be operationally very
complicated and introduce new caching semantics. =A0It is operationally
inevitable that trust paths will be frozen in SSL certs leading to
validation failures. =A0Using only the DNS infrastructure, there is no
place for data to become that stale.

Does c= aching in the OCSP token work better for you?

The = OCSP token is separate from the cert and validity can be limited to the exp= iry of the RRSig expiring earliest.

=A0
--
Website: http://hallambaker.com/

--001636c9258533eebe04a77d7bbe-- From eosterweil@verisign.com Thu Jul 7 13:36:35 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 563BB11E809E for ; Thu, 7 Jul 2011 13:36:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.399 X-Spam-Level: X-Spam-Status: No, score=-6.399 tagged_above=-999 required=5 tests=[AWL=0.199, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N1bgxvx6F1QM for ; Thu, 7 Jul 2011 13:36:34 -0700 (PDT) Received: from exprod6og101.obsmtp.com (exprod6og101.obsmtp.com [64.18.1.181]) by ietfa.amsl.com (Postfix) with ESMTP id A38D511E807C for ; Thu, 7 Jul 2011 13:36:31 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob101.postini.com ([64.18.5.12]) with SMTP ID DSNKThYYzV+rckO1lWMTCYJQx5oxgWnXk3C1@postini.com; Thu, 07 Jul 2011 13:36:33 PDT Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id p67KaSJZ026513; Thu, 7 Jul 2011 16:36:28 -0400 Received: from [10.131.30.110] ([10.131.30.110]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 7 Jul 2011 16:36:28 -0400 Message-ID: <4E1618C7.7060908@verisign.com> Date: Thu, 07 Jul 2011 16:36:23 -0400 From: Eric Osterweil User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: mrex@sap.com References: <201107070137.p671b47i012741@fs4113.wdf.sap.corp> In-Reply-To: <201107070137.p671b47i012741@fs4113.wdf.sap.corp> Content-Type: multipart/alternative; boundary="------------010104080700030107050104" X-OriginalArrivalTime: 07 Jul 2011 20:36:28.0203 (UTC) FILETIME=[8C1167B0:01CC3CE5] Cc: dane@ietf.org Subject: Re: [dane] Draft for serializing DNSSEC chains X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 20:36:35 -0000 This is a multi-part message in MIME format. --------------010104080700030107050104 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 7/6/11 9:37 PM, Martin Rex wrote: > > Osterweil, Eric wrote: > > > > "Matt McCutchen" wrote: > > > > > > DNSSEC RRSIGs are properly analogous to OCSP responses; they > provide the > > > same functionality. (DNSSEC just skipped the intermediate stage of > > > signed long-term certificates because offline operation was not a > goal.) > > > The motivations and security considerations for DNSSEC chain stapling > > > are much the same as those for OCSP stapling. > > > > Why would you say that? The two protocols are immensely different > and they > > have much different goals. Please provide details if you feel this > is in > > err. > > I agree with Matt (I hadn't noticed he had already suggested this > when I wrote my last message). > > Processing stapled OCSP responses is similar to processing stapled > DNSSEC records, although the scope of DANE records is slightly broader > than OCSP (because it may include issues server endpoint identification). > > > > > > (Which raises another point. OCSP stapling uses a TLS extension. > This > > > is a more appropriate design than embedding the data in the cert; > > > additionally, the latter is impossible to do backward-compatibly > with a > > > CA-signed cert. > > > > OK, so let's discuss this. Are you aware of any operational hurdles > that > > may have hampered OCSP (for what it was intended, let alone for > something > > new)? > > AFAIK, the original TLS extension was a single OCSP response, and then > all CAs added intermediate certs so that a single OCSP response was > no longer sufficient to validate a server certificate. > > The proposal for a new TLS extension to carry more than a single > OCSP reponse is still an internet draft: > https://datatracker.ietf.org/doc/draft-pettersen-tls-ext-multiple-ocsp/ > Yes, but are you aware of the _operational_ problems? Is the distinction between design complexity and operational complexity not clear? If so, is anyone else on the list concerned? > > > > > > For DNSSEC chain stapling, embedding is possible. > > > Chromium may find the ability to use externally automated DNSSEC chain > > > stapling with existing web servers to be sufficient justification for > > > choosing the poorer design, but does IETF?) > > > > This will lead to disaster, and opens up new attack vectors. > > Could you elaborate? I fail to follow. > I think (having restated the same position in multiple different ways over the last several days) I have outlined the objection pretty clearly. If you are not clear on them, please re-read my previous emails and I can clarify any specific points you don't follow. > > The security design of DANE does not have a dependency on the transport > that is used to convey the signed DNS records. Neither does OCSP and > CRLs. > Actually, it very much does. If operational issues open attack vectors (which they will in this case), then I think the security design (by definition) has a dependency. Is the vector still unclear? Eric --------------010104080700030107050104 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 7/6/11 9:37 PM, Martin Rex wrote:
Re: [dane] Draft for serializing DNSSEC chains

Osterweil, Eric wrote:
>
> "Matt McCutchen" <matt@mattmccutchen.net> wrote:
> >
> > DNSSEC RRSIGs are properly analogous to OCSP responses; they provide the
> > same functionality.  (DNSSEC just skipped the intermediate stage of
> > signed long-term certificates because offline operation was not a goal.)
> > The motivations and security considerations for DNSSEC chain stapling
> > are much the same as those for OCSP stapling.
>
> Why would you say that?  The two protocols are immensely different and they
> have much different goals.  Please provide details if you feel this is in
> err.

I agree with Matt (I hadn't noticed he had already suggested this
when I wrote my last message).

Processing stapled OCSP responses is similar to processing stapled
DNSSEC records, although the scope of DANE records is slightly broader
than OCSP (because it may include issues server endpoint identification).

>
> > (Which raises another point.  OCSP stapling uses a TLS extension.  This
> > is a more appropriate design than embedding the data in the cert;
> > additionally, the latter is impossible to do backward-compatibly with a
> > CA-signed cert. 
>
> OK, so let's discuss this.  Are you aware of any operational hurdles that
> may have hampered OCSP (for what it was intended, let alone for something
> new)?

AFAIK, the original TLS extension was a single OCSP response, and then
all CAs added intermediate certs so that a single OCSP response was
no longer sufficient to validate a server certificate.

The proposal for a new TLS extension to carry more than a single
OCSP reponse is still an internet draft:
   https://datatracker.ietf.org/doc/draft-pettersen-tls-ext-multiple-ocsp/


Yes, but are you aware of the _operational_ problems?  Is the distinction between design complexity and operational complexity not clear?  If so, is anyone else on the list concerned?


>
> > For DNSSEC chain stapling, embedding is possible.
> > Chromium may find the ability to use externally automated DNSSEC chain
> > stapling with existing web servers to be sufficient justification for
> > choosing the poorer design, but does IETF?)
>
> This will lead to disaster, and opens up new attack vectors.

Could you elaborate?  I fail to follow.

I think (having restated the same position in multiple different ways over the last several days) I have outlined the objection pretty clearly.  If you are not clear on them, please re-read my previous emails and I can clarify any specific points you don't follow.


The security design of DANE does not have a dependency on the transport
that is used to convey the signed DNS records.  Neither does OCSP and CRLs.

Actually, it very much does.  If operational issues open attack vectors (which they will in this case), then I think the security design (by definition) has a dependency.  Is the vector still unclear?

Eric
--------------010104080700030107050104-- From eosterweil@verisign.com Thu Jul 7 13:41:34 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0952B11E80B8 for ; Thu, 7 Jul 2011 13:41:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.413 X-Spam-Level: X-Spam-Status: No, score=-6.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jl82gilxlSVl for ; Thu, 7 Jul 2011 13:41:33 -0700 (PDT) Received: from exprod6og102.obsmtp.com (exprod6og102.obsmtp.com [64.18.1.183]) by ietfa.amsl.com (Postfix) with ESMTP id 0627011E80A4 for ; Thu, 7 Jul 2011 13:41:30 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob102.postini.com ([64.18.5.12]) with SMTP ID DSNKThYZ+afH7PhrYVz+Hp7IYKS0qAl+zHdw@postini.com; Thu, 07 Jul 2011 13:41:33 PDT Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id p67KfSIc001038; Thu, 7 Jul 2011 16:41:29 -0400 Received: from [10.131.30.110] ([10.131.30.110]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 7 Jul 2011 16:41:28 -0400 Message-ID: <4E1619F8.3020505@verisign.com> Date: Thu, 07 Jul 2011 16:41:28 -0400 From: Eric Osterweil User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Tony Finch References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Jul 2011 20:41:28.0595 (UTC) FILETIME=[3F1D9630:01CC3CE6] Cc: dane@ietf.org Subject: Re: [dane] Draft for serializing DNSSEC chains X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 20:41:34 -0000 On 7/7/11 5:39 AM, Tony Finch wrote: > Osterweil, Eric wrote: >>> Freshness of DNSSEC data is governed by RRSIG validity, no >>> matter how the data is obtained. > Actually RRset TTL. Actually, both. ;) > >>> The stapled chain is a cache and, as such, it can affect availability, >>> though if the hypothetical mod_dnssec_staple is used there is no >>> reason to think it would fail any more often than any other TTL-based >>> cache. >> This is very untrue. First, this is not a cache because it's ability to be >> updated neither follows the rules of the DNS protocol, nor is updated with >> the state of that authoritative source (the name servers). > DNS caches are also not updated by authority servers. They may or may not be, but they are designed to get their data from them (as opposed to a perl script). > > > The serialized records should include their TTLs and the time that they > were fetched, so that clients can obey DNS lifetime semantics. If you use > exact DNS wire format then you can just append a timestamp covering the > whole bundle. Sooo... Putting this in a spec is the same as having all implementations honor it? Misconfigurations are no more common? I think there's a lot of evidence that many DNS caches still get this wrong, why would external code automatically overcome the same issues? I think the point here is that any realistic proposition must face the inevitability that implementations will break, and operations will too. The problem here is there are suddenly a LOT more moving parts to get broken, and an insufficient discussion on how to mitigate this. Eric From rbarnes@bbn.com Thu Jul 7 13:59:27 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7402221F8841 for ; Thu, 7 Jul 2011 13:59:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3FvKm0MKn0IF for ; Thu, 7 Jul 2011 13:59:27 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id DE7B621F883A for ; Thu, 7 Jul 2011 13:59:26 -0700 (PDT) Received: from [192.1.255.156] (port=56296 helo=col-dhcp-192-1-255-156.bbn.com) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QevfO-000GjS-Lh; Thu, 07 Jul 2011 16:59:22 -0400 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <4E1619F8.3020505@verisign.com> Date: Thu, 7 Jul 2011 16:59:20 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <28E814AA-D026-4719-A04E-3B0F2EB98D12@bbn.com> References: <4E1619F8.3020505@verisign.com> To: Eric Osterweil X-Mailer: Apple Mail (2.1082) Cc: dane@ietf.org Subject: Re: [dane] Draft for serializing DNSSEC chains X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 20:59:27 -0000 I'm a little confused by how overwhelmed you are by the operational = impact here. =20 On the server side, there just needs to be a script that runs every few = minutes to generate a certificate and tell the web server about it. = This is basically already done, in the code Adam has published; the only = thing missing is a timer and the code to read the TTLs to figure out how = to set the timer. On the client side, it's just an extension to normal certificate = validation; there's only more code here, not any big operational change. ISTM that given the above, the biggest operational impact will be = swapping out the server cert every so often. I'll grant that that could = be a major challenge for large, distributed sites (although you could = refresh disparate servers independently), but for small-to-medium scale = instances, it doesn't seem all that onerous. Am I missing something here? --Richard On Jul 7, 2011, at 4:41 PM, Eric Osterweil wrote: > On 7/7/11 5:39 AM, Tony Finch wrote: >> Osterweil, Eric wrote: >>>> Freshness of DNSSEC data is governed by RRSIG validity, no >>>> matter how the data is obtained. >> Actually RRset TTL. > Actually, both. ;) >=20 >>=20 >>>> The stapled chain is a cache and, as such, it can affect = availability, >>>> though if the hypothetical mod_dnssec_staple is used there is no >>>> reason to think it would fail any more often than any other = TTL-based >>>> cache. >>> This is very untrue. First, this is not a cache because it's = ability to be >>> updated neither follows the rules of the DNS protocol, nor is = updated with >>> the state of that authoritative source (the name servers). >> DNS caches are also not updated by authority servers. >=20 > They may or may not be, but they are designed to get their data from = them (as opposed to a perl script). >>=20 >>=20 >> The serialized records should include their TTLs and the time that = they >> were fetched, so that clients can obey DNS lifetime semantics. If you = use >> exact DNS wire format then you can just append a timestamp covering = the >> whole bundle. > Sooo... Putting this in a spec is the same as having all = implementations honor it? Misconfigurations are no more common? >=20 > I think there's a lot of evidence that many DNS caches still get this = wrong, why would external code automatically overcome the same issues? = I think the point here is that any realistic proposition must face the = inevitability that implementations will break, and operations will too. = The problem here is there are suddenly a LOT more moving parts to get = broken, and an insufficient discussion on how to mitigate this. >=20 > Eric > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From hallam@gmail.com Thu Jul 7 14:05:28 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEDD29E8018 for ; Thu, 7 Jul 2011 14:05:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id esH+B6CFQ+q4 for ; Thu, 7 Jul 2011 14:05:27 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id A68489E8010 for ; Thu, 7 Jul 2011 14:05:27 -0700 (PDT) Received: by gwb20 with SMTP id 20so657722gwb.31 for ; Thu, 07 Jul 2011 14:05:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TtDMNKBE2p5NS63Ygf1hlzyFE9w23uJC2Q20VtgfNyw=; b=eRijTr8JKO7BAYa/7MGihOtdXizx3T62LmXT9KfmMi0sfgcwYadRppu88hWzNtGSig iAku9xHwsFmqTxaEd/CVd5i4adck5nMRvSl7FLRNuVupdxKuT2bjiAz0tOlg890k6zwQ UxjLUfaWimh1tm/sEazcAZcPOtaUp6TsTUTug= MIME-Version: 1.0 Received: by 10.101.168.32 with SMTP id v32mr696116ano.36.1310072724076; Thu, 07 Jul 2011 14:05:24 -0700 (PDT) Received: by 10.100.93.12 with HTTP; Thu, 7 Jul 2011 14:05:23 -0700 (PDT) In-Reply-To: <4E1618C7.7060908@verisign.com> References: <201107070137.p671b47i012741@fs4113.wdf.sap.corp> <4E1618C7.7060908@verisign.com> Date: Thu, 7 Jul 2011 17:05:23 -0400 Message-ID: From: Phillip Hallam-Baker To: Eric Osterweil Content-Type: multipart/alternative; boundary=001636c5969c59376704a781136d Cc: dane@ietf.org Subject: Re: [dane] Draft for serializing DNSSEC chains X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 21:05:29 -0000 --001636c5969c59376704a781136d Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jul 7, 2011 at 4:36 PM, Eric Osterweil wrote: > On 7/6/11 9:37 PM, Martin Rex wrote: > > > > (Which raises another point. OCSP stapling uses a TLS extension. > This > > > is a more appropriate design than embedding the data in the cert; > > > additionally, the latter is impossible to do backward-compatibly with a > > > CA-signed cert. > > > > OK, so let's discuss this. Are you aware of any operational hurdles that > > may have hampered OCSP (for what it was intended, let alone for something > > new)? > > AFAIK, the original TLS extension was a single OCSP response, and then > all CAs added intermediate certs so that a single OCSP response was > no longer sufficient to validate a server certificate. > > The proposal for a new TLS extension to carry more than a single > OCSP reponse is still an internet draft: > https://datatracker.ietf.org/doc/draft-pettersen-tls-ext-multiple-ocsp/ > > > Yes, but are you aware of the _operational_ problems? Is the distinction > between design complexity and operational complexity not clear? If so, is > anyone else on the list concerned? > Well if any such problems exist it should be possible to state them with specificity. Otherwise the assertion is FUD pure and simple. The distinction between design complexity and operational complexity was not originally clear because no such distinction had been proposed. It was only after I pointed out that there are empirical criteria for design complexity that Matt decided that he was talking about operational complexity. There are empirical criteria for operational complexity as well: * Number of administrative actions required to perform an operation * Number of independent services that must be configured to achieve an action * Dependence on support for specific capabilities in deployed infrastructure * State that must be maintained at services Adam's proposal is better than the previous one on each of these criteria above. The proposal to use the pickled chain in an OCSP token is better still. > > > For DNSSEC chain stapling, embedding is possible. > > > Chromium may find the ability to use externally automated DNSSEC chain > > > stapling with existing web servers to be sufficient justification for > > > choosing the poorer design, but does IETF?) > > > > This will lead to disaster, and opens up new attack vectors. > > Could you elaborate? I fail to follow. > > I think (having restated the same position in multiple different ways over > the last several days) I have outlined the objection pretty clearly. If you > are not clear on them, please re-read my previous emails and I can clarify > any specific points you don't follow. > Well the purported issue is not at all clear to me and I have twenty years experience of PKI. I don't think that the issue you claim exist is real. I am certain that you have not substantiated your claim. If you really think that there is a problem explain it to your CTO and then let him tell us that he thinks there is a problem. If you and Matt really think there is a problem you should be able to explain it to Burt. In terms of years of experience he out-ranks everyone here as far as I am aware. If Burt is willing to state that he is sure that there is a problem then I am willing to re-read your messages. If Burt is not willing to endorse your claim or you do not have sufficient confidence in it to take it to him then I am not willing to attempt to decipher your claims either. The security design of DANE does not have a dependency on the transport > that is used to convey the signed DNS records. Neither does OCSP and CRLs. > > Actually, it very much does. If operational issues open attack vectors > (which they will in this case), then I think the security design (by > definition) has a dependency. Is the vector still unclear? > I don't think that you understand the TLS protocol or the proposal being made. All the pickled DNSSEC chain provides is one means of establishing the validity of the key. It does not have to be the only means. The problem of Internet time synchronization means that there is an intrinsic uncertainty of +- 25 hours associated with any validation operation applied to statically signed data. It is pretty clear to me that any ambiguities that may arise as a result of DNS operations are going to be of the same order which is not surprising as they have much the same underlying causes. Thus I do not see the concerns you appear to be raising as being valid. -- Website: http://hallambaker.com/ --001636c5969c59376704a781136d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Jul 7, 2011 at 4:36 PM, Eric Osterweil <eosterweil@verisign.com>= wrote:
=20 =20 =20
On 7/6/11 9:37 PM, Martin Rex wrote:

=20 =20 =20 =20

> > (Which raises another point.=A0 OCSP stapling uses a TLS extension.=A0 This
> > is a more appropriate design than embedding the data in the cert;
> > additionally, the latter is impossible to do backward-compatibly with a
> > CA-signed cert.=A0
>
> OK, so let's discuss this.=A0 Are you aware of any operational hurdles that
> may have hampered OCSP (for what it was intended, let alone for something
> new)?

AFAIK, the original TLS extension was a single OCSP response, and then
all CAs added intermediate certs so that a single OCSP response was
no longer sufficient to validate a server certificate.

The proposal for a new TLS extension to carry more than a single
OCSP reponse is still an internet draft:
=A0=A0 https://datatracker.ietf.org/do= c/draft-pettersen-tls-ext-multiple-ocsp/


Yes, but are you aware of the _operational_ problems?=A0 Is the distinction between design complexity and operational complexity not clear?=A0 If so, is anyone else on the list concerned?

Well if any such problems exist it should be possible= to state them with specificity. Otherwise the assertion is FUD pure and si= mple.

The distinction between design complexity and operation= al complexity was not originally clear because no such distinction had been= proposed. It was only after I pointed out that there are empirical criteri= a for design complexity that Matt decided that he was talking about operati= onal complexity.

There are empirical criteria for operational complexity= as well:

* Number of administrative actions requi= red to perform an operation
* Number of independent services that= must be configured to achieve an action
* Dependence on support for specific capabilities in deployed infrastr= ucture
* State that must be maintained at services

=
Adam's proposal is better than the previous one on each of t= hese criteria above. The proposal to use the pickled chain in an OCSP token= is better still.


=A0

> > For DNSSEC chain stapling, embedding is possible.
> > Chromium may find the ability to use externally automated DNSSEC chain
> > stapling with existing web servers to be sufficient justification for
> > choosing the poorer design, but does IETF?)
>
> This will lead to disaster, and opens up new attack vectors.

Could you elaborate?=A0 I fail to follow.

I think (having restated the same position in multiple different ways over the last several days) I have outlined the objection pretty clearly.=A0 If you are not clear on them, please re-read my previous emails and I can clarify any specific points you don't follow.

Well the purported issue = is not at all clear to me and I have twenty years experience of PKI.
<= div>
I don't think that the issue you claim exist is real= . I am certain that you have not substantiated your claim.

If you really think that there is a problem explain it = to your CTO and then let him tell us that he thinks there is a problem. If = you and Matt really think there is a problem you should be able to explain = it to Burt. In terms of years of experience he out-ranks everyone here as f= ar as I am aware.

If Burt is willing to state that he is sure that there = is a problem then I am willing to re-read your messages.

If Burt is not willing to endorse your claim or you do not have suff= icient confidence in it to take it to him then I am not willing to attempt = to decipher your claims either.

=20 The security design of DANE does not have a dependency on the transport
that is used to convey the signed DNS records.=A0 Neither does OCSP and CRLs.

Actually, it very much does.=A0 If operational issues open attack vectors (which they will in this case), then I think the security design (by definition) has a dependency.=A0 Is the vector still unclear?

I don't th= ink that you understand the TLS protocol or the proposal being made.
<= br clear=3D"all">All the pickled DNSSEC chain provides is one means of esta= blishing the validity of the key. It does not have to be the only means.=A0=

The problem of Internet time synchronization means that ther= e is an intrinsic uncertainty of +- 25 hours associated with any validation= operation applied to statically signed data.

It is pretty clear to me that any ambiguities that may arise as a result of= DNS operations are going to be of the same order which is not surprising a= s they have much the same underlying causes.

Thus = I do not see the concerns you appear to be raising as being valid.=A0

--001636c5969c59376704a781136d-- From eosterweil@verisign.com Thu Jul 7 14:18:55 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD22E21F8959 for ; Thu, 7 Jul 2011 14:18:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.424 X-Spam-Level: X-Spam-Status: No, score=-6.424 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b-U99PCoF70f for ; Thu, 7 Jul 2011 14:18:55 -0700 (PDT) Received: from exprod6og109.obsmtp.com (exprod6og109.obsmtp.com [64.18.1.23]) by ietfa.amsl.com (Postfix) with ESMTP id E8EE021F894F for ; Thu, 7 Jul 2011 14:18:52 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob109.postini.com ([64.18.5.12]) with SMTP ID DSNKThYiuBqpyc0Ig1CtRB5oMPiWARAxnOSp@postini.com; Thu, 07 Jul 2011 14:18:55 PDT Received: from dul1wnexcn01.vcorp.ad.vrsn.com (dul1wnexcn01.vcorp.ad.vrsn.com [10.170.12.138]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id p67LIlAG028611; Thu, 7 Jul 2011 17:18:47 -0400 Received: from [10.131.30.110] ([10.131.30.110]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 7 Jul 2011 17:18:47 -0400 Message-ID: <4E1622B7.5030006@verisign.com> Date: Thu, 07 Jul 2011 17:18:47 -0400 From: Eric Osterweil User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: "Richard L. Barnes" References: <4E1619F8.3020505@verisign.com> <28E814AA-D026-4719-A04E-3B0F2EB98D12@bbn.com> In-Reply-To: <28E814AA-D026-4719-A04E-3B0F2EB98D12@bbn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Jul 2011 21:18:47.0265 (UTC) FILETIME=[75778510:01CC3CEB] Cc: dane@ietf.org Subject: Re: [dane] Draft for serializing DNSSEC chains X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 21:18:56 -0000 On 7/7/11 4:59 PM, Richard L. Barnes wrote: > I'm a little confused by how overwhelmed you are by the operational impact here. > > On the server side, there just needs to be a script that runs every few minutes to generate a certificate and tell the web server about it. This is basically already done, in the code Adam has published; the only thing missing is a timer and the code to read the TTLs to figure out how to set the timer. > > On the client side, it's just an extension to normal certificate validation; there's only more code here, not any big operational change. > > ISTM that given the above, the biggest operational impact will be swapping out the server cert every so often. I'll grant that that could be a major challenge for large, distributed sites (although you could refresh disparate servers independently), but for small-to-medium scale instances, it doesn't seem all that onerous. > > Am I missing something here? > Sorry, but yes. How will you be sure that people understand, deploy, and maintain the operational status of all of these scripts? Seriously, can you tell us that you're sure user-error won't lead to outages when the data in two places (DNS and certs) diverges? I completely buy that _you_ can do this. However, what about people interested in adopting who are just as likely to get burned as to understand the increasing complexity? Can _you_ be sure that _they_ will do all of this right? Eric From eosterweil@verisign.com Thu Jul 7 14:35:34 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4967221F8837 for ; Thu, 7 Jul 2011 14:35:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.434 X-Spam-Level: X-Spam-Status: No, score=-6.434 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y2tx4gE5FoNw for ; Thu, 7 Jul 2011 14:35:33 -0700 (PDT) Received: from exprod6og106.obsmtp.com (exprod6og106.obsmtp.com [64.18.1.191]) by ietfa.amsl.com (Postfix) with ESMTP id EF9F421F8834 for ; Thu, 7 Jul 2011 14:35:30 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob106.postini.com ([64.18.5.12]) with SMTP ID DSNKThYmnA9YpIXHBSTmpEB/zRl7gzZwGXGD@postini.com; Thu, 07 Jul 2011 14:35:32 PDT Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id p67LZNVm029371; Thu, 7 Jul 2011 17:35:23 -0400 Received: from [10.131.30.110] ([10.131.30.110]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 7 Jul 2011 17:35:23 -0400 Message-ID: <4E16269A.30105@verisign.com> Date: Thu, 07 Jul 2011 17:35:22 -0400 From: Eric Osterweil User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Phillip Hallam-Baker References: <201107070137.p671b47i012741@fs4113.wdf.sap.corp> <4E1618C7.7060908@verisign.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------040406020806070705090504" X-OriginalArrivalTime: 07 Jul 2011 21:35:23.0194 (UTC) FILETIME=[C71639A0:01CC3CED] Cc: dane@ietf.org Subject: Re: [dane] Draft for serializing DNSSEC chains X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 21:35:34 -0000 This is a multi-part message in MIME format. --------------040406020806070705090504 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 7/7/11 5:05 PM, Phillip Hallam-Baker wrote: > On Thu, Jul 7, 2011 at 4:36 PM, Eric Osterweil > > wrote: > > On 7/6/11 9:37 PM, Martin Rex wrote: > >> > > (Which raises another point. OCSP stapling uses a TLS >> extension. This >> > > is a more appropriate design than embedding the data in the cert; >> > > additionally, the latter is impossible to do >> backward-compatibly with a >> > > CA-signed cert. >> > >> > OK, so let's discuss this. Are you aware of any operational >> hurdles that >> > may have hampered OCSP (for what it was intended, let alone for >> something >> > new)? >> >> AFAIK, the original TLS extension was a single OCSP response, and >> then >> all CAs added intermediate certs so that a single OCSP response was >> no longer sufficient to validate a server certificate. >> >> The proposal for a new TLS extension to carry more than a single >> OCSP reponse is still an internet draft: >> https://datatracker.ietf.org/doc/draft-pettersen-tls-ext-multiple-ocsp/ >> > > Yes, but are you aware of the _operational_ problems? Is the > distinction between design complexity and operational complexity > not clear? If so, is anyone else on the list concerned? > > > Well if any such problems exist it should be possible to state them > with specificity. Otherwise the assertion is FUD pure and simple. OK. I don't want my concerns on this to be misconstrued as a litany of problems. So, just some "complications" (no judgements), and not intended to be comprehensive: - Does someone need to provision an OCSP server now when they want to use a cert? Large companies (I wonder who would be a good example? :-P ) spend a lot of operational capital provisioning their OCSP services, and pay for it (bandwidth if nothing else). Now web server operators get to do that too. - Now, I can take this new list of OCSP servers as a new attack vector: pop a DNSKEY, DoS an OCSP server, voila... I'm not bagging on OCSP, I'm trying to point out that the protocol is associated w/ real operational overheads and liabilities, and should _not_ be underestimated. > > The distinction between design complexity and operational complexity > was not originally clear because no such distinction had been > proposed. It was only after I pointed out that there are empirical > criteria for design complexity that Matt decided that he was talking > about operational complexity. I think you need to re-read that thread. A late understanding of a point does not imply a correspondingly late assertion of that point. :) > > There are empirical criteria for operational complexity as well: > > * Number of administrative actions required to perform an operation > * Number of independent services that must be configured to achieve an > action > * Dependence on support for specific capabilities in deployed > infrastructure > * State that must be maintained at services More than this. Operations (unfortunately for them) must account for all of the corner cases that were (and were not) foreseen. This is the main reason for the KISS principle that engineers (i.e. us) follow. > > Adam's proposal is better than the previous one on each of these > criteria above. The proposal to use the pickled chain in an OCSP token > is better still. Again, aside from rather obvious layer violations, I still think you are underestimating the points I outlined (even in this email). Eric --------------040406020806070705090504 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 7/7/11 5:05 PM, Phillip Hallam-Baker wrote:
On Thu, Jul 7, 2011 at 4:36 PM, Eric Osterweil <eosterweil@verisign.com> wrote:
On 7/6/11 9:37 PM, Martin Rex wrote:

> > (Which raises another point.  OCSP stapling uses a TLS extension.  This
> > is a more appropriate design than embedding the data in the cert;
> > additionally, the latter is impossible to do backward-compatibly with a
> > CA-signed cert. 
>
> OK, so let's discuss this.  Are you aware of any operational hurdles that
> may have hampered OCSP (for what it was intended, let alone for something
> new)?

AFAIK, the original TLS extension was a single OCSP response, and then
all CAs added intermediate certs so that a single OCSP response was
no longer sufficient to validate a server certificate.

The proposal for a new TLS extension to carry more than a single
OCSP reponse is still an internet draft:
   https://datatracker.ietf.org/doc/draft-pettersen-tls-ext-multiple-ocsp/


Yes, but are you aware of the _operational_ problems?  Is the distinction between design complexity and operational complexity not clear?  If so, is anyone else on the list concerned?

Well if any such problems exist it should be possible to state them with specificity. Otherwise the assertion is FUD pure and simple.

OK.  I don't want my concerns on this to be misconstrued as a litany of problems.  So, just some "complications" (no judgements), and not intended to be comprehensive:
- Does someone need to provision an OCSP server now when they want to use a cert?  Large companies (I wonder who would be a good example? :-P ) spend a lot of operational capital provisioning their OCSP services, and pay for it (bandwidth if nothing else).  Now web server operators get to do that too.
- Now, I can take this new list of OCSP servers as a new attack vector: pop a DNSKEY, DoS an OCSP server, voila...

I'm not bagging on OCSP, I'm trying to point out that the protocol is associated w/ real operational overheads and liabilities, and should _not_ be underestimated.

The distinction between design complexity and operational complexity was not originally clear because no such distinction had been proposed. It was only after I pointed out that there are empirical criteria for design complexity that Matt decided that he was talking about operational complexity.

I think you need to re-read that thread.  A late understanding of a point does not imply a correspondingly late assertion of that point. :)


There are empirical criteria for operational complexity as well:

* Number of administrative actions required to perform an operation
* Number of independent services that must be configured to achieve an action
* Dependence on support for specific capabilities in deployed infrastructure
* State that must be maintained at services
More than this.  Operations (unfortunately for them) must account for all of the corner cases that were (and were not) foreseen.  This is the main reason for the KISS principle that engineers (i.e. us) follow.


Adam's proposal is better than the previous one on each of these criteria above. The proposal to use the pickled chain in an OCSP token is better still.

Again, aside from rather obvious layer violations, I still think you are underestimating the points I outlined (even in this email).

Eric

<bait removed>

--------------040406020806070705090504-- From rbarnes@bbn.com Thu Jul 7 14:41:41 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4AA09E8024 for ; Thu, 7 Jul 2011 14:41:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ofFDn8kgbeSg for ; Thu, 7 Jul 2011 14:41:41 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 64C689E8022 for ; Thu, 7 Jul 2011 14:41:39 -0700 (PDT) Received: from [192.1.255.156] (port=56637 helo=col-dhcp-192-1-255-156.bbn.com) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QewK6-000H2W-43; Thu, 07 Jul 2011 17:41:26 -0400 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <4E1622B7.5030006@verisign.com> Date: Thu, 7 Jul 2011 17:41:24 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E1619F8.3020505@verisign.com> <28E814AA-D026-4719-A04E-3B0F2EB98D12@bbn.com> <4E1622B7.5030006@verisign.com> To: Eric Osterweil X-Mailer: Apple Mail (2.1082) Cc: dane@ietf.org Subject: Re: [dane] Draft for serializing DNSSEC chains X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 21:41:41 -0000 As far as "understand and deploy", well, that sounds like an area where = web server vendors could add value. In principle, all the user would = need to do is provision/sign the DANE record and turn the feature on; = the rest is algorithmic. As far as "maintain operational status": Consider what happens if the = "cert refresh" script breaks. At worst, the cert won't validate. = Recognizing stapling as a shortcut, though, even that breakage doesn't = need to happen -- if the DANE record has a hash of the public key or the = cert, the client can always go back to the DNS to check that everthing's = OK. So really, when things break, you just lose the optimization. It seems like the question is just whether people are willing to trade = some risk of breakage/delay some of the time for an optimization the = rest of the time. --Richard On Jul 7, 2011, at 5:18 PM, Eric Osterweil wrote: > On 7/7/11 4:59 PM, Richard L. Barnes wrote: >> I'm a little confused by how overwhelmed you are by the operational = impact here. >>=20 >> On the server side, there just needs to be a script that runs every = few minutes to generate a certificate and tell the web server about it. = This is basically already done, in the code Adam has published; the only = thing missing is a timer and the code to read the TTLs to figure out how = to set the timer. >>=20 >> On the client side, it's just an extension to normal certificate = validation; there's only more code here, not any big operational change. >>=20 >> ISTM that given the above, the biggest operational impact will be = swapping out the server cert every so often. I'll grant that that could = be a major challenge for large, distributed sites (although you could = refresh disparate servers independently), but for small-to-medium scale = instances, it doesn't seem all that onerous. >>=20 >> Am I missing something here? >>=20 >=20 > Sorry, but yes. How will you be sure that people understand, deploy, = and maintain the operational status of all of these scripts? Seriously, = can you tell us that you're sure user-error won't lead to outages when = the data in two places (DNS and certs) diverges? I completely buy that = _you_ can do this. However, what about people interested in adopting = who are just as likely to get burned as to understand the increasing = complexity? Can _you_ be sure that _they_ will do all of this right? >=20 > Eric From mrex@sap.com Thu Jul 7 14:44:01 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FF949E8017 for ; Thu, 7 Jul 2011 14:44:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.201 X-Spam-Level: X-Spam-Status: No, score=-10.201 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rS1HLJifQDO3 for ; Thu, 7 Jul 2011 14:44:01 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id DB2F621F8512 for ; Thu, 7 Jul 2011 14:44:00 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p67Lhxru006402 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 7 Jul 2011 23:43:59 +0200 (MEST) From: Martin Rex Message-Id: <201107072143.p67Lhwjk021117@fs4113.wdf.sap.corp> To: eosterweil@verisign.com (Eric Osterweil) Date: Thu, 7 Jul 2011 23:43:58 +0200 (MEST) In-Reply-To: <4E1618C7.7060908@verisign.com> from "Eric Osterweil" at Jul 7, 11 04:36:23 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: dane@ietf.org Subject: Re: [dane] Draft for serializing DNSSEC chains X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 21:44:01 -0000 Eric Osterweil wrote: > > > > > AFAIK, the original TLS extension was a single OCSP response, and then > > all CAs added intermediate certs so that a single OCSP response was > > no longer sufficient to validate a server certificate. > > > > The proposal for a new TLS extension to carry more than a single > > OCSP reponse is still an internet draft: > > https://datatracker.ietf.org/doc/draft-pettersen-tls-ext-multiple-ocsp/ > > > > Yes, but are you aware of the _operational_ problems? Is the > distinction between design complexity and operational complexity not > clear? If so, is anyone else on the list concerned? I do not see any (additional) operational problems. The server is *ALWAYS* in a better position to obtain OCSP responses for his own server cert and cache it, and the same goes for DANE records. So from the operational standpoint, using a TLS extension to convey the information significantly facilitates the communication with the _correct_ server. It doesn't help when talking to an attempted imposter. > > > > > The security design of DANE does not have a dependency on the transport > > that is used to convey the signed DNS records. Neither does OCSP and > > CRLs. > > Actually, it very much does. If operational issues open attack vectors > (which they will in this case), then I think the security design (by > definition) has a dependency. Is the vector still unclear? Nope, it does not. The only things in dane that is security-relevant during verification is the signed records and the the RRSIG lifetimes. The transport as well as all TTLs are completely irrelevant. -Martin From hallam@gmail.com Thu Jul 7 15:14:12 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B3AB21F890C for ; Thu, 7 Jul 2011 15:14:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.579 X-Spam-Level: X-Spam-Status: No, score=-3.579 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id srlWWnx9hO1g for ; Thu, 7 Jul 2011 15:14:11 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 185EA21F87A3 for ; Thu, 7 Jul 2011 15:14:11 -0700 (PDT) Received: by ywp31 with SMTP id 31so666355ywp.31 for ; Thu, 07 Jul 2011 15:14:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=iMZjrQ2g9FMkErBLqAaLdm63SXxRgFf9VSN5xJahGlU=; b=rWLYYv4PJXcS7M9ecwvj6tCz2HQU4/UqMXbOmJbildRpv4jYhW9WhWpEizZRudpo58 cOPl/IqKOK8eiugbwWhItXMnsME4xQeGx4Dq6G0bqIhESEvctXAcd19P3NkToVQcV9hI bL8nTyS+koDxG1uIUSYj+Xd1NlUOX3z0asdiU= MIME-Version: 1.0 Received: by 10.101.168.32 with SMTP id v32mr745274ano.36.1310076850561; Thu, 07 Jul 2011 15:14:10 -0700 (PDT) Received: by 10.100.93.12 with HTTP; Thu, 7 Jul 2011 15:14:10 -0700 (PDT) In-Reply-To: <4E16269A.30105@verisign.com> References: <201107070137.p671b47i012741@fs4113.wdf.sap.corp> <4E1618C7.7060908@verisign.com> <4E16269A.30105@verisign.com> Date: Thu, 7 Jul 2011 18:14:10 -0400 Message-ID: From: Phillip Hallam-Baker To: Eric Osterweil Content-Type: multipart/alternative; boundary=001636c5969c4e62ba04a78209b7 Cc: dane@ietf.org Subject: Re: [dane] Draft for serializing DNSSEC chains X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 22:14:12 -0000 --001636c5969c4e62ba04a78209b7 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jul 7, 2011 at 5:35 PM, Eric Osterweil wrote: > On 7/7/11 5:05 PM, Phillip Hallam-Baker wrote: > > On Thu, Jul 7, 2011 at 4:36 PM, Eric Osterweil wrote: > >> On 7/6/11 9:37 PM, Martin Rex wrote: >> > > OK. I don't want my concerns on this to be misconstrued as a litany of > problems. So, just some "complications" (no judgements), and not intended > to be comprehensive: > - Does someone need to provision an OCSP server now when they want to use a > cert? > No, the proposal is to mandate client support for stapling for this application. The OCSP token is then simply a piece of data that is exchanged in the normal TLS channel. Use of a standalone OCSP service is not something I had considered. But it might well be simpler in some deployments. If an enterprise does not want to upgrade their existing Apache server to one that supports stapling they could deploy OCSP as an additional service. The OCSP in question being written to create the OCSP tokens from the DNSSEC data as required. > Large companies (I wonder who would be a good example? :-P ) spend a lot of > operational capital provisioning their OCSP services, and pay for it > (bandwidth if nothing else). Now web server operators get to do that too. > Since one of the objectives here is to pull through support for OCSP stapling, the overall bandwidth requirement should decline. > - Now, I can take this new list of OCSP servers as a new attack vector: pop > a DNSKEY, DoS an OCSP server, voila... > Nope, the proposal was to use stapling. There are empirical criteria for operational complexity as well: > > * Number of administrative actions required to perform an operation > * Number of independent services that must be configured to achieve an > action > * Dependence on support for specific capabilities in deployed > infrastructure > * State that must be maintained at services > > More than this. Operations (unfortunately for them) must account for all > of the corner cases that were (and were not) foreseen. This is the main > reason for the KISS principle that engineers (i.e. us) follow. > Expect the unexpected is not actionable advice. PKIX is a twenty year old legacy. DNSSEC is a to-be-deployed addition to a twenty year old legacy. Both ponds have the same amount of mud in them. The only difference being that the DNS pond has been stirred harder and more recently. Thus the degree of visibility is much better in the PKIX pond than the other one. Thus if we are going to go by known unknowns it would seem that you are arguing to rely on as little DNSSEC infrastructure as is possible. Adam's proposal is better than the previous one on each of these criteria > above. The proposal to use the pickled chain in an OCSP token is better > still. > > > Again, aside from rather obvious layer violations, I still think you are > underestimating the points I outlined (even in this email). > I don't see any layer violation. As you might be aware, the layering model was developed for OSI. DNS protocol is the Internet equivalent of X.500 in OSI terms. DNSSEC is to DNS what X.509 is to X.500. Ergo if you believe in layers the two schemes are at the exact same level. Trying to understand IETF protocols in terms of layers is probably a mistake in any case. IETF protocols are frequently recursive. TLS is a transport protocol but it calls OCSP which is an application protocol. There is an architecture there but it is not the OSI model. -- Website: http://hallambaker.com/ --001636c5969c4e62ba04a78209b7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, Jul 7, 2011 at 5:35 PM, Eric Ost= erweil <eos= terweil@verisign.com> wrote:
=20 =20 =20
On 7/7/11 5:05 PM, Phillip Hallam-Baker wrote:
On Thu, Jul 7, 2011 at 4:36 PM, Eric Osterwei= l <eosterweil@verisign.com> wrote:
On 7/6/11 9:37 PM, Martin Rex wrote:

OK.=A0 I don't want my concerns on this to be misconstrued as a lit= any of problems.=A0 So, just some "complications" (no judgements)= , and not intended to be comprehensive:
- Does someone need to provision an OCSP server now when they want to use a cert?=A0

No, the proposa= l is to mandate client support for stapling for this application.

The OCSP token is then simply a piece of data that is excha= nged in the normal TLS channel.


Use of a standalone OCSP service is not = something I had considered. But it might well be simpler in some deployment= s. If an enterprise does not want to upgrade their existing Apache server t= o one that supports stapling they could deploy OCSP as an additional servic= e. The OCSP in question being written to create the OCSP tokens from the DN= SSEC data as required.

=A0
Large companies (I wonder who would be a goo= d example? :-P ) spend a lot of operational capital provisioning their OCSP services, and pay for it (bandwidth if nothing else).=A0 Now web server operators get to do that too.

Since one of the objectives here is to pull through support for OCS= P stapling, the overall bandwidth requirement should decline.

=A0
- Now, I can take this new list of OCSP servers as a new attack vector: pop a DNSKEY, DoS an OCSP server, voila...

Nope, the proposal was to use stapling.

=20
There are empirical criteria for operational complexity as well:

* Number of administrative actions required to perform an operation
* Number of independent services that must be configured to achieve an action
* Dependence on support for specific capabilities in deployed infrastructure
* State that must be maintained at services
More than this.=A0 Operations (unfortunately for them) must account for all of the corner cases that were (and were not) foreseen.=A0 This is the main reason for the KISS principle that engineers (i.e. us) follow.

Expect the unexpected is = not actionable advice.

PKIX is a twenty year old l= egacy. DNSSEC is a to-be-deployed addition to a twenty year old legacy. Bot= h ponds have the same amount of mud in them. The only difference being that= the DNS pond has been stirred harder and more recently. Thus the degree of= visibility is much better in the PKIX pond than the other one.

Thus if we are going to go by known unknowns it would s= eem that you are arguing to rely on as little DNSSEC infrastructure as is p= ossible.

=20
Adam's proposal is better than the previous one on each of these criteria above. The proposal to use the pickled chain in an OCSP token is better still.

Again, aside from rather obvious layer violations, I still think you are underestimating the points I outlined (even in this email).

I don't see any layer violation.=A0<= /div>

As you might be aware, the layering model was deve= loped for OSI.=A0DNS protocol is the Internet equivalent of X.500 in OSI te= rms. DNSSEC is to DNS what X.509 is to X.500. Ergo if you believe in layers= the two schemes are at the exact same level.

Trying to understand IETF protocols in terms of l= ayers is probably a mistake in any case. IETF protocols are frequently recu= rsive. TLS is a transport protocol but it calls OCSP which is an applicatio= n protocol. There is an architecture there but it is not the OSI model.=A0<= /div>
--
Website: http://hallambaker.= com/

--001636c5969c4e62ba04a78209b7-- From eosterweil@verisign.com Thu Jul 7 15:31:06 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A19FC11E80B1 for ; Thu, 7 Jul 2011 15:31:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.444 X-Spam-Level: X-Spam-Status: No, score=-6.444 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hf4m3bM4YFUE for ; Thu, 7 Jul 2011 15:31:06 -0700 (PDT) Received: from exprod6og106.obsmtp.com (exprod6og106.obsmtp.com [64.18.1.191]) by ietfa.amsl.com (Postfix) with ESMTP id 1361711E809C for ; Thu, 7 Jul 2011 15:31:04 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob106.postini.com ([64.18.5.12]) with SMTP ID DSNKThYzpcUrtYvM6LSTF4QzVtweCokvyn/J@postini.com; Thu, 07 Jul 2011 15:31:05 PDT Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id p67MV0S6006199; Thu, 7 Jul 2011 18:31:00 -0400 Received: from [10.100.0.144] ([10.100.0.144]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 7 Jul 2011 18:30:58 -0400 Message-ID: <4E1633A0.4040405@verisign.com> Date: Thu, 07 Jul 2011 18:30:56 -0400 From: Eric Osterweil User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: "Richard L. Barnes" References: <4E1619F8.3020505@verisign.com> <28E814AA-D026-4719-A04E-3B0F2EB98D12@bbn.com> <4E1622B7.5030006@verisign.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Jul 2011 22:30:59.0278 (UTC) FILETIME=[8B8C3EE0:01CC3CF5] Cc: dane@ietf.org Subject: Re: [dane] Draft for serializing DNSSEC chains X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 22:31:06 -0000 On 7/7/11 5:41 PM, Richard L. Barnes wrote: > As far as "understand and deploy", well, that sounds like an area where web server vendors could add value. In principle, all the user would need to do is provision/sign the DANE record and turn the feature on; the rest is algorithmic. As I said (much earlier), this adds an architectural disconnect between data authorities (DNS name servers), and clients (web browsers). The cert generation has no protocol interaction with the DNS servers. Rather than restate the above, please look at the email I sent describing it (it seems more appropriate than retyping it). > > As far as "maintain operational status": Consider what happens if the "cert refresh" script breaks. At worst, the cert won't validate. No, at worse, an attack vector has been opened or we come to the case where people fail to understand why validation is failing and simply remove DANE security. This, imho, is the much more likely case, and could lead to larger groups rejecting the approach as overcomplicated. Of course, this is an operational issue that would only avail itself of us at scale if we don't anticipate it. > Recognizing stapling as a shortcut, though, even that breakage doesn't need to happen -- if the DANE record has a hash of the public key or the cert, the client can always go back to the DNS to check that everthing's OK. So really, when things break, you just lose the optimization. That doesn't stop the attack vector. > > It seems like the question is just whether people are willing to trade some risk of breakage/delay some of the time for an optimization the rest of the time. There is also the question of non-experts trying to catch up and realizing the propensity for this approach to fall out of sync can lead to major consequences (attacks, removing security, etc). One very possible outcome is that people stop trying to use the DANE protocol altogether because "it" seems to often be out of sync. Eric > > --Richard > > > > > > On Jul 7, 2011, at 5:18 PM, Eric Osterweil wrote: > >> On 7/7/11 4:59 PM, Richard L. Barnes wrote: >>> I'm a little confused by how overwhelmed you are by the operational impact here. >>> >>> On the server side, there just needs to be a script that runs every few minutes to generate a certificate and tell the web server about it. This is basically already done, in the code Adam has published; the only thing missing is a timer and the code to read the TTLs to figure out how to set the timer. >>> >>> On the client side, it's just an extension to normal certificate validation; there's only more code here, not any big operational change. >>> >>> ISTM that given the above, the biggest operational impact will be swapping out the server cert every so often. I'll grant that that could be a major challenge for large, distributed sites (although you could refresh disparate servers independently), but for small-to-medium scale instances, it doesn't seem all that onerous. >>> >>> Am I missing something here? >>> >> Sorry, but yes. How will you be sure that people understand, deploy, and maintain the operational status of all of these scripts? Seriously, can you tell us that you're sure user-error won't lead to outages when the data in two places (DNS and certs) diverges? I completely buy that _you_ can do this. However, what about people interested in adopting who are just as likely to get burned as to understand the increasing complexity? Can _you_ be sure that _they_ will do all of this right? >> >> Eric From mrex@sap.com Thu Jul 7 16:00:32 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB33D21F89BA for ; Thu, 7 Jul 2011 16:00:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.203 X-Spam-Level: X-Spam-Status: No, score=-10.203 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z5JeRpRK4aQ2 for ; Thu, 7 Jul 2011 16:00:32 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id F288E21F89AB for ; Thu, 7 Jul 2011 16:00:31 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p67N0T1d019436 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 8 Jul 2011 01:00:29 +0200 (MEST) From: Martin Rex Message-Id: <201107072300.p67N0SxH025333@fs4113.wdf.sap.corp> To: eosterweil@verisign.com (Eric Osterweil) Date: Fri, 8 Jul 2011 01:00:28 +0200 (MEST) In-Reply-To: <4E16269A.30105@verisign.com> from "Eric Osterweil" at Jul 7, 11 05:35:22 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: dane@ietf.org Subject: Re: [dane] Draft for serializing DNSSEC chains X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 23:00:32 -0000 Eric Osterweil wrote: > > OK. I don't want my concerns on this to be misconstrued as a litany of > problems. So, just some "complications" (no judgements), and not > intended to be comprehensive: > - Does someone need to provision an OCSP server now when they want to > use a cert? Admittedly I have zero experience with the use of OCSP, so I'm trying to do some logical guessing here. I guess the presence of an AIA-OCSP extension in the server certificate is a prerequisite, and the signature on the OCSP response must be either from the certificate issuer itself or from a designated OCSP responder signed by the certificate issuer and explicitly included in the OCSP response certs container. The idea is that OCSP response stapling only makes sense when it reliably allows the TLS client to perform revocation checking on the server certificate without any additional external information. > > Large companies (I wonder who would be a good example? :-P > ) spend a lot of operational capital provisioning their OCSP services, > and pay for it (bandwidth if nothing else). Now web server operators > get to do that too. It should be up to the that issued the server's certificate to provide fresh OCSP responses for the server's cert (chain) on a regular basis. I believe it is undesirable for a business to have clients fail server authentication in indeterministic fashions, without the server knowing when, why and how to fix it. > > I'm not bagging on OCSP, I'm trying to point out that the protocol is > associated w/ real operational overheads and liabilities, and should > _not_ be underestimated. If there is any value in certificate revocation checking at all, then the most efficient, most reliable and most manageable fashion is to have the server obtain the OCSP responses and convey them stapled and in-band to the communication peer. "It's a dirty job, but somebody's got to do it". Chasing OCSP for the server certificate on the client is a design flaw. There are no performance and connectivity problems -- the server admin is free to choose a CA with an OCSP responder that meets the server operators desired service levels, availability and response times, caching OCSP responses for its own certificate(s) is easy for the server. New OCSP responses can be checked before replacing the existing ones, so the admin has a head start on knowing about the problem and fixing it before it affects operations, and the server admin remains in full control of everything. -Martin From hallam@gmail.com Thu Jul 7 16:08:08 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BDCD11E80C1 for ; Thu, 7 Jul 2011 16:08:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.523 X-Spam-Level: X-Spam-Status: No, score=-3.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kn3rOguPUYEP for ; Thu, 7 Jul 2011 16:08:07 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6B75111E8080 for ; Thu, 7 Jul 2011 16:08:07 -0700 (PDT) Received: by gwb20 with SMTP id 20so696250gwb.31 for ; Thu, 07 Jul 2011 16:08:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PNapeaj9L37/jCoJHtoMCsFYGRwTygHWLuk5V308Bn4=; b=tUuLb50KNWWln/jzNM1OO7snehySbOWGzi7loGdMEAEURXA461xhKJyTmHnIcbvh1T wUfpiY8m4oc9GXLqrF1ufB0tERuITEyo+BGpaVQARg8Pd7esBtA1ItWO9IA+wDKzTFU4 pnGxbxqRqc0gIqwcfDwwXYlcqc2/5cVYWCol4= MIME-Version: 1.0 Received: by 10.101.180.22 with SMTP id h22mr1234972anp.80.1310080086742; Thu, 07 Jul 2011 16:08:06 -0700 (PDT) Received: by 10.100.93.12 with HTTP; Thu, 7 Jul 2011 16:08:06 -0700 (PDT) In-Reply-To: <4E1633A0.4040405@verisign.com> References: <4E1619F8.3020505@verisign.com> <28E814AA-D026-4719-A04E-3B0F2EB98D12@bbn.com> <4E1622B7.5030006@verisign.com> <4E1633A0.4040405@verisign.com> Date: Thu, 7 Jul 2011 19:08:06 -0400 Message-ID: From: Phillip Hallam-Baker To: Eric Osterweil Content-Type: multipart/alternative; boundary=001636c925853295f404a782ca10 Cc: dane@ietf.org Subject: Re: [dane] Draft for serializing DNSSEC chains X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 23:08:08 -0000 --001636c925853295f404a782ca10 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jul 7, 2011 at 6:30 PM, Eric Osterweil wrote: > >> There is also the question of non-experts trying to catch up and > realizing the propensity for this approach to fall out of sync can lead to > major consequences (attacks, removing security, etc). One very possible > outcome is that people stop trying to use the DANE protocol altogether > because "it" seems to often be out of sync. Scripts suck, a solution that can only be implemented using scripts is likely to break. The point here is that the solution does not depend on the use of scripts at all. It is quite easy to implement this in the Web Server alone. The only change the Web server needs is: 1) Determine that it should send the server generated OCSP token. 2) Check the expiry of the token. 3) If the token has expired, generate a fresh one. 4) Staple the OCSP token into the response 3a) Alternatively schedule an internal action to generate the fresh token pro-actively. That is a code set that is quite easy to add into the .NET TLS handling code. I would imagine the OpenSSL code to be very similar but have not checked that as recently. Since the token is part of the negotiation it is also an input to the master secret. An alternative would be to implement the scheme as a standalone OCSP service. This has the advantage that the existing Web Server does not need to be touched at all. This feature could even be implemented as an extension to the Web Server itself (i.e. an ISAPI or fastCGI type extension, not one that requires a recompile). So this does not have to even require support for a new service. -- Website: http://hallambaker.com/ --001636c925853295f404a782ca10 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Jul 7, 2011 at 6:30 PM, Eric Osterweil <eosterweil@verisign.com>= wrote:

There is also the question of non-experts trying to catch up and realizing = the propensity for this approach to fall out of sync can lead to major cons= equences (attacks, removing security, etc). =A0One very possible outcome is= that people stop trying to use the DANE protocol altogether because "= it" seems to often be out of sync.

Scripts suck, a solution that can only be implemented u= sing scripts is likely to break.

The point here is= that the solution does not depend on the use of scripts at all.=A0


It is quite easy to implement this in th= e Web Server alone. The only change the Web server needs is:

=
1) Determine that it should send the server generated OCSP token= .
2) Check the expiry of the token.
3) If the token has expire= d, generate a fresh one.
4) Staple the OCSP token into the respon= se

3a) Alternatively schedule an internal action t= o generate the fresh token pro-actively.

That is a code set that is quite easy to add into the .= NET TLS handling code. I would imagine the OpenSSL code to be very similar = but have not checked that as recently.

Since the t= oken is part of the negotiation it is also an input to the master secret.


An alternative would be to implement the= scheme as a standalone OCSP service. This has the advantage that the exist= ing Web Server does not need to be touched at all.

This feature could even be implemented as an extension to the Web Serv= er itself (i.e. an ISAPI or fastCGI type extension, not one that requires a= recompile). So this does not have to even require support for a new servic= e.



--
Website: http://hallambaker.com/

--001636c925853295f404a782ca10-- From gnu@toad.com Thu Jul 7 18:04:35 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75A1D21F8A53 for ; Thu, 7 Jul 2011 18:04:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.097 X-Spam-Level: X-Spam-Status: No, score=0.097 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_NJABL_RELAY=2.696] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 57KvsyjXfWov for ; Thu, 7 Jul 2011 18:04:34 -0700 (PDT) Received: from new.toad.com (new.toad.com [209.237.225.253]) by ietfa.amsl.com (Postfix) with ESMTP id A56E821F8A63 for ; Thu, 7 Jul 2011 18:04:34 -0700 (PDT) Received: from new.toad.com (localhost.localdomain [127.0.0.1]) by new.toad.com (8.12.9/8.12.9) with ESMTP id p6814WsV022693; Thu, 7 Jul 2011 18:04:32 -0700 Message-Id: <201107080104.p6814WsV022693@new.toad.com> To: mrex@sap.com In-reply-to: <201107072300.p67N0SxH025333@fs4113.wdf.sap.corp> References: <201107072300.p67N0SxH025333@fs4113.wdf.sap.corp> Comments: In-reply-to Martin Rex message dated "Fri, 08 Jul 2011 01:00:28 +0200." Date: Thu, 07 Jul 2011 18:04:32 -0700 From: John Gilmore Cc: dane@ietf.org Subject: Re: [dane] Draft for serializing DNSSEC chains X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 01:04:35 -0000 I'm a little confused here. > It should be up to the that issued the server's certificate to > provide fresh OCSP responses for the server's cert (chain) > on a regular basis. We don't trust the CAs, so we are asking that DNSSEC-provided keys be served up to end users via OCSP, run by the CAs? No, that would be too straightforward. Instead the proposal is that CAs would serve OSCP to the secured web servers, which would cache them and serve them up to the clients via some kind of SSL extension. Why does this smell to me like a scheme by CAs to make secure web sites keep paying CAs? What was wrong with clients just doing DNS lookups to get DNSSEC records, rather than proxying them through two intermediaries using two separate protocols? If there IS a problem with being able to do DNSSEC lookups, like perhaps no good asynchronous library implementation that does it, then let's fix that, rather than convoluting the protocols and adding unnecessary middlemen. John From mrex@sap.com Thu Jul 7 19:15:12 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BF4C21F895B for ; Thu, 7 Jul 2011 19:15:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.204 X-Spam-Level: X-Spam-Status: No, score=-10.204 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lwXh6GCB2nkC for ; Thu, 7 Jul 2011 19:15:11 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 63AF621F894E for ; Thu, 7 Jul 2011 19:15:11 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p682F9ii024838 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 8 Jul 2011 04:15:09 +0200 (MEST) From: Martin Rex Message-Id: <201107080215.p682F8F1006443@fs4113.wdf.sap.corp> To: gnu@toad.com (John Gilmore) Date: Fri, 8 Jul 2011 04:15:08 +0200 (MEST) In-Reply-To: <201107080104.p6814WsV022693@new.toad.com> from "John Gilmore" at Jul 7, 11 06:04:32 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: dane@ietf.org Subject: Re: [dane] Draft for serializing DNSSEC chains X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 02:15:12 -0000 John Gilmore wrote: > > I'm a little confused here. > > > It should be up to [CA] the that issued the server's certificate to > > provide fresh OCSP responses for the server's cert (chain) > > on a regular basis. > > We don't trust the CAs, so we are asking that DNSSEC-provided keys be > served up to end users via OCSP, run by the CAs? I'm sorry for causing confusion. Let me retry. This was an answer question who would be issuing/signing OCSP responses that the server can staple into a multiple-OCSP-responses TLS extension (and whether that would/could be a company OCSP server) and applies only to CA-issued server certificates (that IMHO ought to have an AIA OCSP extension in case OCSP is desired). In the general case, the server should not make any assumptions about which OCSP responders the TLS client might trust, and for simplicity only send OCSP responses that were either signed directly by the certificate issuer or alternatively by an OCSP issuer authorized by the certificate issuer and its OCSP issuer cert contained in the OCSP response, i.e. _everything_ conveyed inline. If the server additionally has his server certificate authorized by DANE TLSA records, it should use a different TLS extension, similar to the OCSP response extension, to convey _ALL_ DNSSEC records that are necessary for a validation of the server certificate. So if someone uses an organizational CA (that does not chain to the TLS X.509 PKI, he could still use OCSP for the TLS server cert if he really wanted to (or was required to by some policy or regulation). > > What was wrong with clients just doing DNS lookups to get DNSSEC > records, rather than proxying them through two intermediaries using > two separate protocols? The purpose is twofold: supply TLS clients behind broken DNS proxies (of which there seem to be quite a lot in the installed base), as well as clients in private DNS universe networks connecting through HTTP(S) proxies with the CONNECT method (basically every browser in a company with a sensibly firewalled internal network). (how does the root key rollover work for those DNS-disconnected clients?) The other idea is that the client does not need any additional network connection other than that to the server in order to retrieve all information that is necessary to validate the server's certificate. It is the most efficient if everyone, and servers in particular, provide the non-revocation proofs (OCSP) or DNSSEC confirmation (DANE) that they're using a valid certificate. > > If there IS a problem with being able to do > DNSSEC lookups, like perhaps no good asynchronous library > implementation that does it, then let's fix that, rather than > convoluting the protocols and adding unnecessary middlemen. Personally, I consider the asynchronous library implementation a total non-issue. If there are folks using fancy programming environments where they don't have that readily available, then they should either write it themselves (which should be easy if they're Pros and their fancy environment is at least remotely useful), or they should switch to a more adequate environment when their current one just doesn't cut it. -Martin From fanf2@hermes.cam.ac.uk Fri Jul 8 01:52:18 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B923221F8616 for ; Fri, 8 Jul 2011 01:52:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zj2pafIK0QSS for ; Fri, 8 Jul 2011 01:52:16 -0700 (PDT) Received: from ppsw-41.csi.cam.ac.uk (ppsw-41.csi.cam.ac.uk [131.111.8.141]) by ietfa.amsl.com (Postfix) with ESMTP id C317721F85AB for ; Fri, 8 Jul 2011 01:52:13 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from [91.125.158.24] (port=61173 helo=[192.168.0.3]) by ppsw-41.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:587) with esmtpsa (PLAIN:fanf2) (TLSv1:AES128-SHA:128) id 1Qf6nD-0003AY-Qv (Exim 4.72) (return-path ); Fri, 08 Jul 2011 09:52:11 +0100 References: <201107080215.p682F8F1006443@fs4113.wdf.sap.corp> In-Reply-To: <201107080215.p682F8F1006443@fs4113.wdf.sap.corp> Mime-Version: 1.0 (iPhone Mail 8F190) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (8F190) From: Tony Finch Date: Fri, 8 Jul 2011 09:52:06 +0100 To: "mrex@sap.com" Sender: Tony Finch Cc: "dane@ietf.org" Subject: Re: [dane] Draft for serializing DNSSEC chains X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 08:52:18 -0000 On 8 Jul 2011, at 03:15, Martin Rex wrote: >=20 > (how does the root key rollover work for those DNS-disconnected clients?) It doesn't work for lots of clients, e.g. software on the shelf. The current= planned timing for root key rollovers is MUCH too short - basically the min= imum allowed by RFC 5011. If a root key rollover ever happens it will probab= ly have to be done via software updates. Tony. -- f.anthony.n.finch http://dotat.at/ From paul@xelerance.com Fri Jul 8 10:28:29 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FEAB21F8B71 for ; Fri, 8 Jul 2011 10:28:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.469 X-Spam-Level: X-Spam-Status: No, score=-6.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L8f3+YDB1rfD for ; Fri, 8 Jul 2011 10:28:28 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by ietfa.amsl.com (Postfix) with ESMTP id 87D1721F8AE1 for ; Fri, 8 Jul 2011 10:28:28 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 677DF570E7; Fri, 8 Jul 2011 13:28:25 -0400 (EDT) Date: Fri, 8 Jul 2011 13:28:25 -0400 (EDT) From: Paul Wouters To: John Gilmore In-Reply-To: <201107080104.p6814WsV022693@new.toad.com> Message-ID: References: <201107072300.p67N0SxH025333@fs4113.wdf.sap.corp> <201107080104.p6814WsV022693@new.toad.com> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dane@ietf.org Subject: Re: [dane] Draft for serializing DNSSEC chains X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 17:28:29 -0000 On Thu, 7 Jul 2011, John Gilmore wrote: > I'm a little confused here. > >> It should be up to the that issued the server's certificate to >> provide fresh OCSP responses for the server's cert (chain) >> on a regular basis. > > We don't trust the CAs, so we are asking that DNSSEC-provided keys be > served up to end users via OCSP, run by the CAs? No, that would be > too straightforward. Instead the proposal is that CAs would serve > OSCP to the secured web servers, which would cache them and serve them > up to the clients via some kind of SSL extension. I agree that this is not buying us much. The energy is better invested in locating and fixing the hypothetical systems that cannot be configured to do DNSSEC with their upstreams. Heck, DNSSEC-over-HTTP from Kaminsky would beat this chaining dnssec inside certificate hacks. The big issue with OCSP is the loss of privacy to a third party, and while I trust organisations like google and mozilla more then I trust the CAs, I don't really want to need to trust them for this - and I know some of these trusted organisastions prefer not to have to run these things either. On top of it, there is a port 80 to 443 untrusted leap when doing this. Paul From jakob@kirei.se Fri Jul 8 10:43:19 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11BFC21F8BBB for ; Fri, 8 Jul 2011 10:43:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_SE=0.35, MIME_QP_LONG_LINE=1.396, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gUx5Xap0iev6 for ; Fri, 8 Jul 2011 10:43:18 -0700 (PDT) Received: from spg.kirei.se (spg.kirei.se [IPv6:2001:67c:394:15::9]) by ietfa.amsl.com (Postfix) with ESMTP id D782B21F8BB9 for ; Fri, 8 Jul 2011 10:43:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kirei.se; s=spg20100524; h=received:references:in-reply-to:mime-version:content-transfer-encoding: content-type:message-id:cc:x-mailer:from:subject:date:to; bh=ri2m6RM9bnvB3MNaSZdH0ybkVKhwX8Aqb/+XxBHk26w=; b=FVaNezWq8TIX8D4tv3k1u0+pKfupn/EvCT7CGpFgzVoSDwhR6NrvJxzSp7ThZ2bizrLMhM3jBnQgM y4NR11vbUF0T5VsWMGKUG2G0TFxOQSrARAVhGCY52hveaG/LQmIMR+cTf8jfeG5kQEzwq08xZ5wwC6 Lkt6ck9he/sGKsWg= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg-relay.kirei.se (Halon Mail Gateway) with ESMTPS; Fri, 8 Jul 2011 19:43:14 +0200 (CEST) References: <201107080215.p682F8F1006443@fs4113.wdf.sap.corp> In-Reply-To: Mime-Version: 1.0 (iPad Mail 8J3) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <407C5BC6-DE01-4235-B242-1414F0D594FC@kirei.se> X-Mailer: iPad Mail (8J3) From: Jakob Schlyter Date: Fri, 8 Jul 2011 19:43:16 +0200 To: Tony Finch Cc: "dane@ietf.org" Subject: Re: [dane] Draft for serializing DNSSEC chains X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 17:43:19 -0000 8 jul 2011 kl. 10:52 skrev Tony Finch : > On 8 Jul 2011, at 03:15, Martin Rex wrote: >>=20 >> (how does the root key rollover work for those DNS-disconnected clients?)= >=20 > It doesn't work for lots of clients, e.g. software on the shelf. The curre= nt planned timing for root key rollovers is MUCH too short - basically the m= inimum allowed by RFC 5011. > If a root key rollover ever happens it will probably have to be done via s= oftware updates. Please elaborate on why it would not work, I'd be most interested why. And w= hy you did not present these findings when we asked for feedback more than a= year ago.=20 Jakob (speaking as one of the people who choose the parameters)= From mrex@sap.com Fri Jul 8 10:56:18 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C394221F8C32 for ; Fri, 8 Jul 2011 10:56:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.211 X-Spam-Level: X-Spam-Status: No, score=-10.211 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h5VvfOvEdplR for ; Fri, 8 Jul 2011 10:56:18 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 1824621F8C1E for ; Fri, 8 Jul 2011 10:56:17 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p68HuGC2026337 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 8 Jul 2011 19:56:16 +0200 (MEST) From: Martin Rex Message-Id: <201107081756.p68HuF9Q029794@fs4113.wdf.sap.corp> To: paul@xelerance.com (Paul Wouters) Date: Fri, 8 Jul 2011 19:56:15 +0200 (MEST) In-Reply-To: from "Paul Wouters" at Jul 8, 11 01:28:25 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: dane@ietf.org Subject: Re: [dane] Draft for serializing DNSSEC chains X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 17:56:18 -0000 Paul Wouters wrote: > > The big issue with OCSP is the loss of privacy to a third party, The privacy issue with OCSP exists only when trying to collect OCSP responses for someone else's certificate. There is no privacy issue when obtaining OCSP responses for your own cert. This is one of the reasons why I want to see servers sending OCSP responses for their own server cert in-band through a TLS extension. It is much more robust, much more efficient and there is no privacy issue. On all my browsers I have server cert revocation checking disabled, because it creates huge new security problems without really solving any, and it kills your privacy. -Martin From hallam@gmail.com Fri Jul 8 11:04:34 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7601221F8B9D for ; Fri, 8 Jul 2011 11:04:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.564 X-Spam-Level: X-Spam-Status: No, score=-3.564 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jnlR3u53zK1U for ; Fri, 8 Jul 2011 11:04:33 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 78E8521F8B7D for ; Fri, 8 Jul 2011 11:04:33 -0700 (PDT) Received: by gxk19 with SMTP id 19so405433gxk.31 for ; Fri, 08 Jul 2011 11:04:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=WxI1UCd32tQ1dvJOv6E0WPDQA6cYg7ReayV9gkgNQ3w=; b=baj8RYIjJcCqdBsgc8jOC7M4rMV2VM+hxtPW6/wyv9JUloCi9LciF57QeTRkcl3YBN 1x0v+jkjxb4uR2CMuPeRNdaANIqn1hmpCACmtDMwhs6igisEp3FpufjZ7u7ih3BR9u93 sUMDjGGClx1TgdTI0+UY/JO6Jgz/I4C6uaRzQ= MIME-Version: 1.0 Received: by 10.101.179.7 with SMTP id g7mr1995414anp.102.1310148270609; Fri, 08 Jul 2011 11:04:30 -0700 (PDT) Received: by 10.100.93.12 with HTTP; Fri, 8 Jul 2011 11:04:30 -0700 (PDT) In-Reply-To: <407C5BC6-DE01-4235-B242-1414F0D594FC@kirei.se> References: <201107080215.p682F8F1006443@fs4113.wdf.sap.corp> <407C5BC6-DE01-4235-B242-1414F0D594FC@kirei.se> Date: Fri, 8 Jul 2011 14:04:30 -0400 Message-ID: From: Phillip Hallam-Baker To: Jakob Schlyter Content-Type: multipart/alternative; boundary=001636c9266445d48304a792aa7f Cc: "dane@ietf.org" Subject: Re: [dane] Draft for serializing DNSSEC chains X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 18:04:34 -0000 --001636c9266445d48304a792aa7f Content-Type: text/plain; charset=ISO-8859-1 I think that the problem is that deployed software has a service life between 3 months and up to 15 years. There is a lot of infrastructure about that cannot upgrade its firmware and you really wouldn't want it to either. The plotter in my office is 15 years old. A replacement would cost me $4500 and wouldn't let me refill my own cartridges. There is a lot of embedded infrastructure out there that can't update firmware or parameters easily. So its a problem, but not one that we can't solve. The approach I prefer is to make the root of trust for an enterprise a key that is under their control. So they would use the CSR supplied by IANA to sign the ICANN root under their private CA and then place the resulting cert plus their root cert in a CERT record at their own zone apex. The root of trust would also be their KSK or be used to sign it. Applications would embed that root as their ultimate root of trust. The result of that approach is that the enterprise can choose all the roots of trust it is willing to rely on. On Fri, Jul 8, 2011 at 1:43 PM, Jakob Schlyter wrote: > 8 jul 2011 kl. 10:52 skrev Tony Finch : > > > On 8 Jul 2011, at 03:15, Martin Rex wrote: > >> > >> (how does the root key rollover work for those DNS-disconnected > clients?) > > > > It doesn't work for lots of clients, e.g. software on the shelf. The > current planned timing for root key rollovers is MUCH too short - basically > the minimum allowed by RFC 5011. > > If a root key rollover ever happens it will probably have to be done via > software updates. > > Please elaborate on why it would not work, I'd be most interested why. And > why you did not present these findings when we asked for feedback more than > a year ago. > > Jakob (speaking as one of the people who choose the parameters) > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > -- Website: http://hallambaker.com/ --001636c9266445d48304a792aa7f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I think that the problem is that deployed software has a service life betwe= en 3 months and up to 15 years.

There is a lot of infrastructur= e about that cannot upgrade its firmware and you really wouldn't want i= t to either. The plotter in my office is 15 years old. A replacement would = cost me $4500 and wouldn't let me refill my own cartridges.

There is a lot of embedded infrastructure out there tha= t can't update firmware or parameters easily.

=
So its a problem, but not one that we can't solve.=A0

The approach I prefer is to make the root of trust for = an enterprise a key that is under their control. So they would use the CSR = supplied by IANA to sign the ICANN root under their private CA and then pla= ce the resulting cert plus their root cert in a CERT record at their own zo= ne apex.

The root of trust would also be their KSK or be used to= sign it.

Applications would embed that root as th= eir ultimate root of trust.


The res= ult of that approach is that the enterprise can choose all the roots of tru= st it is willing to rely on.=A0


On Fri, Jul 8, 2011 at 1= :43 PM, Jakob Schlyter <jakob@kirei.se> wrote:
8 jul 2011 kl. 10:52 skrev Tony Finch <d= ot@dotat.at>:

> On 8 Jul 2011, at 03:15, Martin Rex <mrex@sap.com> wrote:
>>
>> (how does the root key rollover work for those DNS-disconnected cl= ients?)
>
> It doesn't work for lots of clients, e.g. software on the shelf. T= he current planned timing for root key rollovers is MUCH too short - basica= lly the minimum allowed by RFC 5011.
> If a root key rollover ever happens it will probably have to be done v= ia software updates.

Please elaborate on why it would not work, I'd be most interested= why. And why you did not present these findings when we asked for feedback= more than a year ago.

=A0Jakob (speaking as one of the people who choose the parameters)
_________________________________________= ______
dane mailing list
dane@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/dane



--
Website: http://hallambaker.com/

--001636c9266445d48304a792aa7f-- From warren@kumari.net Fri Jul 8 11:24:49 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF96B21F8B50 for ; Fri, 8 Jul 2011 11:24:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6QNY44y6QXuS for ; Fri, 8 Jul 2011 11:24:49 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 39FD421F8AAA for ; Fri, 8 Jul 2011 11:24:48 -0700 (PDT) Received: from [192.168.0.197] (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id 4CAA71B40599 for ; Fri, 8 Jul 2011 14:24:48 -0400 (EDT) From: Warren Kumari Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 8 Jul 2011 14:24:46 -0400 Message-Id: <4A953B0A-3910-4DEC-BE13-9B6F2E0815B2@kumari.net> To: dane@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [dane] Opening issues... X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 18:24:50 -0000 Hi all, So, as many of you know, I've been traveling -- this has led me to slip = behind on my email and I apologize for not being more on top of = things... I'm glad to see that there is all of this discussion on the list, but = shocked (shocked I tell you) that there are not open issues to track = these discussions. I realize that a lot of bright folk are putting lots = of time, effort and thought into these discussions, but all this effort = is wasted if we don't a: know what it is we are actually discussing and = b: track and record what we actually decide[0]. So, *please*, if you have a useful issue or are discussing something of = import, please toss it in the issues tracker -- = http://trac.tools.ietf.org/wg/dane/trac/report (I'll also try summarize = the actual issues under discussion and toss them in, but if y'all do so = they'll better capture the crux). If we don't get some new issues to discuss (yes, and get around to = resolving outstanding ones): 1: I'll have to decide that we are all done and move things off to WGLC. and=20 2: We'll all end up sitting around in a big room in Quebec with nothing = to talk about or do - if this happens (and to make sure that everyone = gets value from their registration fee) I'll have to break out the = Karaoke machine.... *Please*, don't make me break out the karaoke = machine... W [0]: Yes, I realize that all of the email is nicely archived and = searchable -- I'm choosing to ignore this point as it a: doesn't = support my case and b: interferes with my ranty tone. :-P From paul.hoffman@vpnc.org Fri Jul 8 13:02:24 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2169121F8C7A for ; Fri, 8 Jul 2011 13:02:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.723 X-Spam-Level: X-Spam-Status: No, score=-102.723 tagged_above=-999 required=5 tests=[AWL=-0.124, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xnTU7wDHy89T for ; Fri, 8 Jul 2011 13:02:23 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 5B5E321F8C6D for ; Fri, 8 Jul 2011 13:02:23 -0700 (PDT) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4] (may be forged)) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p68K2C9v064250 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 8 Jul 2011 13:02:13 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 8 Jul 2011 13:02:21 -0700 Message-Id: To: DANE WG Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [dane] Using serialized DNSSEC info X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 20:02:24 -0000 Greetings again. Many people on the previous long thread titled "Draft = for serializing DNSSEC chains" made many assumptions that were not, in = fact, reflected in the draft. The biggest of these is how the serialized = DNSSEC info would appear in TLS. The draft is *completely silent* on = this. If people want to discuss particular places where such info would appear = in TLS and how that would related to DANE, it would be good to open = individual tracker issues on it. That will, at least, help differentiate = the proposal by issue number. --Paul Hoffman From alangley@gmail.com Fri Jul 8 13:49:31 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AAAC21F8B66 for ; Fri, 8 Jul 2011 13:49:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.94 X-Spam-Level: X-Spam-Status: No, score=-2.94 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ir9sgytwYntn for ; Fri, 8 Jul 2011 13:49:26 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 711AA21F8B59 for ; Fri, 8 Jul 2011 13:49:26 -0700 (PDT) Received: by iwn39 with SMTP id 39so2538505iwn.31 for ; Fri, 08 Jul 2011 13:49:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=vJgefoA0O9UCnVYizO7gH0F85OwPvoDxzHe6s2DHHVg=; b=IThlbnjBzne0nrT0LrbUcFVQ8knAs8oRw6VQLD/yYhnWs+usOL9br7WwIYE4Sbhm68 nQ+/SpBD5WPHvlGOlj7qzmasKMncqnqv97I3NW8GVhax+WtMRT508+gTN0Ty1xLlLMzS gTOEFywAdwYyJR4ZGKpMt6H0Vyh+Vj+vDQAqM= MIME-Version: 1.0 Received: by 10.42.133.66 with SMTP id g2mr2357292ict.388.1310158157338; Fri, 08 Jul 2011 13:49:17 -0700 (PDT) Sender: alangley@gmail.com Received: by 10.42.213.9 with HTTP; Fri, 8 Jul 2011 13:49:17 -0700 (PDT) In-Reply-To: References: Date: Fri, 8 Jul 2011 16:49:17 -0400 X-Google-Sender-Auth: lEXVXigKgBNIdnwpskMWyggoI2U Message-ID: From: Adam Langley To: Paul Hoffman Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: DANE WG Subject: Re: [dane] Using serialized DNSSEC info X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 20:49:31 -0000 On Fri, Jul 8, 2011 at 4:02 PM, Paul Hoffman wrote: > Greetings again. Many people on the previous long thread titled "Draft fo= r serializing DNSSEC chains" made many assumptions that were not, in fact, = reflected in the draft. The biggest of these is how the serialized DNSSEC i= nfo would appear in TLS. The draft is *completely silent* on this. It has also been pointed out to me that people are questioning the idea that a serialization persists until the first RRSIG expiry. I had been misunderstanding their point of view. Of course, like any DNSSEC client, freshness is only guaranteed within the window of the RRSIG, however I will put language similar to the following in the next draft: "Since a serialization is effectively a DNS cache, it MUST be regenerated based on the TTL of the records. In additional, the serializer SHOULD refetch all records when any of them expire." Cheers AGL --=20 Adam Langley agl@imperialviolet.org http://www.imperialviolet.org From paul.hoffman@vpnc.org Fri Jul 8 13:58:05 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF2F921F8B89 for ; Fri, 8 Jul 2011 13:58:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.714 X-Spam-Level: X-Spam-Status: No, score=-102.714 tagged_above=-999 required=5 tests=[AWL=-0.115, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WsED44EhwlAT for ; Fri, 8 Jul 2011 13:58:05 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 30AD921F8B85 for ; Fri, 8 Jul 2011 13:58:04 -0700 (PDT) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4] (may be forged)) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p68Kvs9k066291 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 8 Jul 2011 13:57:55 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Fri, 8 Jul 2011 13:58:03 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <23F64CBF-2E64-456C-AB6C-E0C7DCF65534@vpnc.org> References: To: Adam Langley X-Mailer: Apple Mail (2.1084) Cc: DANE WG Subject: Re: [dane] Using serialized DNSSEC info X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 20:58:06 -0000 On Jul 8, 2011, at 1:49 PM, Adam Langley wrote: > On Fri, Jul 8, 2011 at 4:02 PM, Paul Hoffman = wrote: >> Greetings again. Many people on the previous long thread titled = "Draft for serializing DNSSEC chains" made many assumptions that were = not, in fact, reflected in the draft. The biggest of these is how the = serialized DNSSEC info would appear in TLS. The draft is *completely = silent* on this. >=20 > It has also been pointed out to me that people are questioning the > idea that a serialization persists until the first RRSIG expiry. I had > been misunderstanding their point of view. Of course, like any DNSSEC > client, freshness is only guaranteed within the window of the RRSIG, > however I will put language similar to the following in the next > draft: >=20 > "Since a serialization is effectively a DNS cache, it MUST be > regenerated based on the TTL of the records. In additional, the > serializer SHOULD refetch all records when any of them expire." Works for me. --Paul Hoffman From warren@kumari.net Tue Jul 12 09:23:10 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D55C321F8D1D for ; Tue, 12 Jul 2011 09:23:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1pTPRNra7yeL for ; Tue, 12 Jul 2011 09:23:10 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 52A1721F8D1B for ; Tue, 12 Jul 2011 09:23:10 -0700 (PDT) Received: from dot.her.corp.google.com (unknown [74.202.225.33]) by vimes.kumari.net (Postfix) with ESMTPSA id EE9C31B40484; Tue, 12 Jul 2011 12:23:09 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warren Kumari In-Reply-To: <4A953B0A-3910-4DEC-BE13-9B6F2E0815B2@kumari.net> Date: Tue, 12 Jul 2011 12:23:09 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4A953B0A-3910-4DEC-BE13-9B6F2E0815B2@kumari.net> To: Warren Kumari X-Mailer: Apple Mail (2.1084) Cc: dane@ietf.org Subject: Re: [dane] Opening issues... X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 16:23:10 -0000 On Jul 8, 2011, at 2:24 PM, Warren Kumari wrote: > Hi all, >=20 > So, as many of you know, I've been traveling -- this has led me to = slip behind on my email and I apologize for not being more on top of = things... >=20 > I'm glad to see that there is all of this discussion on the list, but = shocked (shocked I tell you) that there are not open issues to track = these discussions. I realize that a lot of bright folk are putting lots = of time, effort and thought into these discussions, but all this effort = is wasted if we don't a: know what it is we are actually discussing and = b: track and record what we actually decide[0]. >=20 > So, *please*, if you have a useful issue or are discussing something = of import, please toss it in the issues tracker -- = http://trac.tools.ietf.org/wg/dane/trac/report (I'll also try summarize = the actual issues under discussion and toss them in, but if y'all do so = they'll better capture the crux). >=20 > If we don't get some new issues to discuss (yes, and get around to = resolving outstanding ones): > 1: I'll have to decide that we are all done and move things off to = WGLC. > and=20 > 2: We'll all end up sitting around in a big room in Quebec with = nothing to talk about or do - if this happens (and to make sure that = everyone gets value from their registration fee) I'll have to break out = the Karaoke machine.... *Please*, don't make me break out the karaoke = machine... I think that the Working Group has made some really good progress with = the Use Case doc (thanks Richard, and everyone who contributed) and we = stopped work on the Protocol doc to make sure it addressed the use cases = correctly. Since then we have not made much progress (other than some interesting = discussions re: serializing DNSSEC chains) and so we might just not have = enough to talk about to justify using people's tine in Quebec. So, if we don't get some issues of substance by Thursday (or requests = from folk to present), we'll may just cancel the face-to-face meeting in = Quebec... People's time is valuable, and if we don't have anything to = discuss we can free some of this up so folk can a: attend other sessions = or b: see some of Quebec... W >=20 > W >=20 > [0]: Yes, I realize that all of the email is nicely archived and = searchable -- I'm choosing to ignore this point as it a: doesn't = support my case and b: interferes with my ranty tone. :-P >=20 >=20 >=20 From eosterweil@verisign.com Tue Jul 12 10:51:59 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2BDD21F8B09 for ; Tue, 12 Jul 2011 10:51:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.452 X-Spam-Level: X-Spam-Status: No, score=-6.452 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bKz9aJA80wBF for ; Tue, 12 Jul 2011 10:51:57 -0700 (PDT) Received: from exprod6og105.obsmtp.com (exprod6og105.obsmtp.com [64.18.1.189]) by ietfa.amsl.com (Postfix) with ESMTP id E632121F899D for ; Tue, 12 Jul 2011 10:51:55 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob105.postini.com ([64.18.5.12]) with SMTP ID DSNKThyJuiyT8sN1fdXR9IMqu3SMk+Y5POpE@postini.com; Tue, 12 Jul 2011 10:51:57 PDT Received: from dul1wnexcn01.vcorp.ad.vrsn.com (dul1wnexcn01.vcorp.ad.vrsn.com [10.170.12.138]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id p6CHpsAd001562; Tue, 12 Jul 2011 13:51:54 -0400 Received: from [10.131.30.110] ([10.131.30.110]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 12 Jul 2011 13:51:53 -0400 Message-ID: <4E1C89B9.8030100@verisign.com> Date: Tue, 12 Jul 2011 13:51:53 -0400 From: Eric Osterweil User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Warren Kumari References: <4A953B0A-3910-4DEC-BE13-9B6F2E0815B2@kumari.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Jul 2011 17:51:53.0890 (UTC) FILETIME=[62959020:01CC40BC] Cc: dane@ietf.org Subject: Re: [dane] Opening issues... X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 17:51:59 -0000 On 7/12/11 12:23 PM, Warren Kumari wrote: > On Jul 8, 2011, at 2:24 PM, Warren Kumari wrote: > >> Hi all, >> >> So, as many of you know, I've been traveling -- this has led me to slip behind on my email and I apologize for not being more on top of things... >> >> I'm glad to see that there is all of this discussion on the list, but shocked (shocked I tell you) that there are not open issues to track these discussions. I realize that a lot of bright folk are putting lots of time, effort and thought into these discussions, but all this effort is wasted if we don't a: know what it is we are actually discussing and b: track and record what we actually decide[0]. >> >> So, *please*, if you have a useful issue or are discussing something of import, please toss it in the issues tracker -- http://trac.tools.ietf.org/wg/dane/trac/report (I'll also try summarize the actual issues under discussion and toss them in, but if y'all do so they'll better capture the crux). >> >> If we don't get some new issues to discuss (yes, and get around to resolving outstanding ones): >> 1: I'll have to decide that we are all done and move things off to WGLC. >> and >> 2: We'll all end up sitting around in a big room in Quebec with nothing to talk about or do - if this happens (and to make sure that everyone gets value from their registration fee) I'll have to break out the Karaoke machine.... *Please*, don't make me break out the karaoke machine... > I think that the Working Group has made some really good progress with the Use Case doc (thanks Richard, and everyone who contributed) and we stopped work on the Protocol doc to make sure it addressed the use cases correctly. > Since then we have not made much progress (other than some interesting discussions re: serializing DNSSEC chains) and so we might just not have enough to talk about to justify using people's tine in Quebec. > > So, if we don't get some issues of substance by Thursday (or requests from folk to present), we'll may just cancel the face-to-face meeting in Quebec... People's time is valuable, and if we don't have anything to discuss we can free some of this up so folk can a: attend other sessions or b: see some of Quebec... > > I think it would be quite valuable to talk about the serialization issue that you alluded to above. Eric From fanf2@hermes.cam.ac.uk Tue Jul 12 11:15:26 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7ADE21F8E47 for ; Tue, 12 Jul 2011 11:15:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8AmAx2w+f6Lr for ; Tue, 12 Jul 2011 11:15:22 -0700 (PDT) Received: from ppsw-41.csi.cam.ac.uk (ppsw-41.csi.cam.ac.uk [131.111.8.141]) by ietfa.amsl.com (Postfix) with ESMTP id 9566C21F8D6F for ; Tue, 12 Jul 2011 11:15:22 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:60896) by ppsw-41.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:fanf2) id 1QghUN-0005jE-St (Exim 4.72) (return-path ); Tue, 12 Jul 2011 19:15:19 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1QghUN-0008Iw-UN (Exim 4.67) (return-path ); Tue, 12 Jul 2011 19:15:19 +0100 Date: Tue, 12 Jul 2011 19:15:19 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Jakob Schlyter In-Reply-To: <407C5BC6-DE01-4235-B242-1414F0D594FC@kirei.se> Message-ID: References: <201107080215.p682F8F1006443@fs4113.wdf.sap.corp> <407C5BC6-DE01-4235-B242-1414F0D594FC@kirei.se> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: "dane@ietf.org" Subject: Re: [dane] Draft for serializing DNSSEC chains X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 18:15:26 -0000 Jakob Schlyter wrote: > 8 jul 2011 kl. 10:52 skrev Tony Finch : > > On 8 Jul 2011, at 03:15, Martin Rex wrote: > >> > >> (how does the root key rollover work for those DNS-disconnected clients?) > > > > It doesn't work for lots of clients, e.g. software on the shelf. The > > current planned timing for root key rollovers is MUCH too short - > > basically the minimum allowed by RFC 5011. If a root key rollover ever > > happens it will probably have to be done via software updates. > > Please elaborate on why it would not work, I'd be most interested why. > And why you did not present these findings when we asked for feedback > more than a year ago. I have discussed this at length several times on the DNSOP list. See for instance the thread starting with http://www.ietf.org/mail-archive/web/dnsop/current/msg08603.html The essential problem is that ICANN doesn't provide any way for a device to bootstrap trust if it misses an RFC 5011 rollover, and the rollover timing is very short so this will be a very common problem. ICANN say that vendors have to solve the bootstrap problem for themselves, since the published signatures for the root KSK don't have any published security properties or lifetime or service level. This problem isn't necessary: RFC 5011 allows you to prepare and pre-publish a standby KSK well in advance, in a way that fits in with typical software release and support schedules. If this was done for the root KSK then everyone could obtain and verify the next trust anchor and the problem would basically go away. Tony. -- f.anthony.n.finch http://dotat.at/ Bailey: Southeast 3 or 4, increasing 5 or 6 later. Slight or moderate. Fair, rain later. Good. From paul.hoffman@vpnc.org Tue Jul 12 11:30:16 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4781221F8E0C for ; Tue, 12 Jul 2011 11:30:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.701 X-Spam-Level: X-Spam-Status: No, score=-102.701 tagged_above=-999 required=5 tests=[AWL=-0.102, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id axXzcVNxNEv7 for ; Tue, 12 Jul 2011 11:30:15 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 92D5F21F8DEB for ; Tue, 12 Jul 2011 11:30:15 -0700 (PDT) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4] (may be forged)) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p6CIU48w064798 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 12 Jul 2011 11:30:05 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Paul Hoffman In-Reply-To: <4E1C89B9.8030100@verisign.com> Date: Tue, 12 Jul 2011 11:30:13 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4A953B0A-3910-4DEC-BE13-9B6F2E0815B2@kumari.net> <4E1C89B9.8030100@verisign.com> To: DANE WG X-Mailer: Apple Mail (2.1084) Subject: Re: [dane] Opening issues... X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 18:30:16 -0000 On Jul 12, 2011, at 10:51 AM, Eric Osterweil wrote: > I think it would be quite valuable to talk about the serialization = issue that you alluded to above. While the serializing DNSSEC thread is interesting, is it at all a DANE = issue? It feels much more like a TLS issue, since it answers the = question "how do I reduce latency in starting up TLS". --Paul Hoffman From hallam@gmail.com Tue Jul 12 11:30:34 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A80C121F8E16 for ; Tue, 12 Jul 2011 11:30:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.735 X-Spam-Level: X-Spam-Status: No, score=-2.735 tagged_above=-999 required=5 tests=[AWL=-0.803, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t+KYSY-FYB+9 for ; Tue, 12 Jul 2011 11:30:30 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id A380A21F8DEB for ; Tue, 12 Jul 2011 11:30:30 -0700 (PDT) Received: by gxk19 with SMTP id 19so1822480gxk.31 for ; Tue, 12 Jul 2011 11:30:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=GyQVZ2nc92eX2oJOpo8ukb2d/OcPNQhizqGVBzqY9N8=; b=JNmlQHuwhSfyQ8M9jkRlYetIbSrGsxqWCE4CJZQbPJKy20DFDtndMb/BgV8sN/Kr08 yrojWgQCFR+loHEsgL13L0N6PZzPp1qhWkvIj5VWsIWTt8y1gzK18uCTZt4L9IhXzCwo JJOtwgYWoIIbh1ny+pbS3sf0e8jhC3yIK5SoE= MIME-Version: 1.0 Received: by 10.101.152.34 with SMTP id e34mr254463ano.124.1310495429867; Tue, 12 Jul 2011 11:30:29 -0700 (PDT) Received: by 10.100.93.12 with HTTP; Tue, 12 Jul 2011 11:30:29 -0700 (PDT) In-Reply-To: <4E1C89B9.8030100@verisign.com> References: <4A953B0A-3910-4DEC-BE13-9B6F2E0815B2@kumari.net> <4E1C89B9.8030100@verisign.com> Date: Tue, 12 Jul 2011 14:30:29 -0400 Message-ID: From: Phillip Hallam-Baker To: Eric Osterweil Content-Type: multipart/alternative; boundary=001636c5bd6993b91104a7e37e2f Cc: dane@ietf.org Subject: Re: [dane] Opening issues... X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 18:30:34 -0000 --001636c5bd6993b91104a7e37e2f Content-Type: text/plain; charset=ISO-8859-1 I think it would be useful to talk about serialization. At the moment it seems to be being attacked as not meeting some abstract model of how the DNS should work. It seems to me that it is a perfectly reasonable transition strategy. We can do the problem of distributing keys in the DNS right now and start building up a user base and operating experience. Chain serialization is not what I would want as an ultimate solution, but it solves the initial problem and gets some runs on the board. If people are going to use DANE at all it has to work 100% of the time when the user has a DANE aware browser and server. That is already a pretty high bar to deployment. If we add in a third deployment dependency the likely outcome is no deployment at all. Once we get some deployment we can start looking at the problem of how to get round non-DNSSEC-functional resolvers as a secondary question. On Tue, Jul 12, 2011 at 1:51 PM, Eric Osterweil wrote: > On 7/12/11 12:23 PM, Warren Kumari wrote: > >> On Jul 8, 2011, at 2:24 PM, Warren Kumari wrote: >> >> Hi all, >>> >>> So, as many of you know, I've been traveling -- this has led me to slip >>> behind on my email and I apologize for not being more on top of things... >>> >>> I'm glad to see that there is all of this discussion on the list, but >>> shocked (shocked I tell you) that there are not open issues to track these >>> discussions. I realize that a lot of bright folk are putting lots of time, >>> effort and thought into these discussions, but all this effort is wasted if >>> we don't a: know what it is we are actually discussing and b: track and >>> record what we actually decide[0]. >>> >>> So, *please*, if you have a useful issue or are discussing something of >>> import, please toss it in the issues tracker -- >>> http://trac.tools.ietf.org/wg/**dane/trac/report(I'll also try summarize the actual issues under discussion and toss them >>> in, but if y'all do so they'll better capture the crux). >>> >>> If we don't get some new issues to discuss (yes, and get around to >>> resolving outstanding ones): >>> 1: I'll have to decide that we are all done and move things off to WGLC. >>> and >>> 2: We'll all end up sitting around in a big room in Quebec with nothing >>> to talk about or do - if this happens (and to make sure that everyone gets >>> value from their registration fee) I'll have to break out the Karaoke >>> machine.... *Please*, don't make me break out the karaoke machine... >>> >> I think that the Working Group has made some really good progress with the >> Use Case doc (thanks Richard, and everyone who contributed) and we stopped >> work on the Protocol doc to make sure it addressed the use cases correctly. >> Since then we have not made much progress (other than some interesting >> discussions re: serializing DNSSEC chains) and so we might just not have >> enough to talk about to justify using people's tine in Quebec. >> >> So, if we don't get some issues of substance by Thursday (or requests from >> folk to present), we'll may just cancel the face-to-face meeting in >> Quebec... People's time is valuable, and if we don't have anything to >> discuss we can free some of this up so folk can a: attend other sessions or >> b: see some of Quebec... >> >> >> I think it would be quite valuable to talk about the serialization issue > that you alluded to above. > > Eric > > ______________________________**_________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/**listinfo/dane > -- Website: http://hallambaker.com/ --001636c5bd6993b91104a7e37e2f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I think it would be useful to talk about serialization.

= At the moment it seems to be being attacked as not meeting some abstract mo= del of how the DNS should work.

It seems to me tha= t it is a perfectly reasonable transition strategy. We can do the problem o= f distributing keys in the DNS right now and start building up a user base = and operating experience.

Chain serialization is not what I would want as an ulti= mate solution, but it solves the initial problem and gets some runs on the = board.


If people are going to use D= ANE at all it has to work 100% of the time when the user has a DANE aware b= rowser and server. That is already a pretty high bar to deployment. If we a= dd in a third deployment dependency the likely outcome is no deployment at = all.

Once we get some deployment we can start looking at the= problem of how to get round non-DNSSEC-functional resolvers as a secondary= question.


On Tue, = Jul 12, 2011 at 1:51 PM, Eric Osterweil <eosterweil@verisign.com> wrote:=
On 7/12/11 12:23 PM, Warr= en Kumari wrote:
On Jul 8, 2011, at 2:24 PM, Warren Kumari wrote:

Hi all,

So, as many of you know, I've been traveling -- this has led me to slip= behind on my email and I apologize for not being more on top of things...<= br>
I'm glad to see that there is all of this discussion on the list, but s= hocked (shocked I tell you) that there are not open issues to track these d= iscussions. I realize that a lot of bright folk are putting lots of time, e= ffort and thought into these discussions, but all this effort is wasted if = we don't a: know what it is we are actually discussing and b: track and= record what we actually decide[0].

So, *please*, if you have a useful issue or are discussing something of imp= ort, please toss it in the issues tracker -- http://trac.tools.ietf.org/w= g/dane/trac/report (I'll also try summarize the actual issue= s under discussion and toss them in, but if y'all do so they'll bet= ter capture the crux).

If we don't get some new issues to discuss (yes, and get around to reso= lving outstanding ones):
1: I'll have to decide that we are all done and move things off to WGLC= .
and
2: We'll all end up sitting around in a big room in Quebec with nothing= to talk about or do - if this happens (and to make sure that everyone gets= value from their registration fee) I'll have to break out the Karaoke = machine.... *Please*, don't make me break out the karaoke machine...
I think that the Working Group has made some really good progress with the = Use Case doc (thanks Richard, and everyone who contributed) and we stopped = work on the Protocol doc to make sure it addressed the use cases correctly.=
Since then we have not made much progress (other than some interesting disc= ussions re: serializing DNSSEC chains) and so we might just not have enough= to talk about to justify using people's tine in Quebec.

So, if we don't get some issues of substance by Thursday (or requests f= rom folk to present), we'll may just cancel the face-to-face meeting in= Quebec... People's time is valuable, and if we don't have anything= to discuss we can free some of this up so folk can a: attend other session= s or b: see some of Quebec...


I think it would be quite valuable to talk about the serialization issue th= at you alluded to above.

Eric

_______________________________________________
dane mailing list
dane@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/dane



--
Website: http://hallambaker.com/

--001636c5bd6993b91104a7e37e2f-- From paul@xelerance.com Tue Jul 12 11:55:46 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14FE521F8ECF for ; Tue, 12 Jul 2011 11:55:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.481 X-Spam-Level: X-Spam-Status: No, score=-6.481 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lmvb6JOh-aQq for ; Tue, 12 Jul 2011 11:55:45 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by ietfa.amsl.com (Postfix) with ESMTP id 758A621F8ECE for ; Tue, 12 Jul 2011 11:55:45 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 8428CBF8A; Tue, 12 Jul 2011 14:55:55 -0400 (EDT) Date: Tue, 12 Jul 2011 14:55:55 -0400 (EDT) From: Paul Wouters To: Phillip Hallam-Baker In-Reply-To: Message-ID: References: <4A953B0A-3910-4DEC-BE13-9B6F2E0815B2@kumari.net> <4E1C89B9.8030100@verisign.com> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dane@ietf.org Subject: Re: [dane] Opening issues... X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 18:55:46 -0000 On Tue, 12 Jul 2011, Phillip Hallam-Baker wrote: > Chain serialization is not what I would want as an ultimate solution, but it solves the initial problem and gets some runs on the board. I don't think it solves "the problem". In fact, I think it is trying to address multiple problems, and not doing a good job of any. 1) do DNSSEC even if the OS has no secure resolver 2) secure TLS using DNSSEC 3) reduce DNS(SEC) latency The problem with 1) is that it seems a lot of work only to protect against passive attacks (active attacks will leave the vulnerable client on port 80) The problem with 3) is that if you don't use an DHCP resolver with dnssec or one running on localhost, every application will need its own "from the root down" dnssec processing and every app is taking the latency hit and not sharing the cache IMHO, the enduser is better of running a dnssec validator to reduce DNSSEC latency with using the DHCP nameserver as forwarder. Shunting dnssec over http, or worse, inline some certificate container, seems like a lot more code that is very specific to the application, and does not allow for caching. People have shown recent statistics saying that EDNS0 / DO bit is not really a problem at large, so using DNSSEC-chains over alternative transports, while NOT feeding them back into a dnssec validator on localhost for sharing, does not actually buy us much. It does save us DNS latency, but I'd address that by keeping a caching resolver on the stub. Doing that also means each browser does not have to ship a dnssec validator library. Paul From hallam@gmail.com Tue Jul 12 14:34:17 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D022721F8C52 for ; Tue, 12 Jul 2011 14:34:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.539 X-Spam-Level: X-Spam-Status: No, score=-3.539 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y0s9cdD4WA39 for ; Tue, 12 Jul 2011 14:34:13 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id B1B0821F8C3C for ; Tue, 12 Jul 2011 14:34:13 -0700 (PDT) Received: by yxp4 with SMTP id 4so2670962yxp.31 for ; Tue, 12 Jul 2011 14:34:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=r5P+W3c9zVVitjw+/jSaISpP83C+H6dYngh9pbaeOjk=; b=l4uv5StsnruR3tMKEKSFMlW0EL/eyPLbvqs8SAxNczlAIAs9Zqe/ysNSK2G3NoB6Yq P2L2bbhtfLFaRKhOLlC0OGHwd1UCfDGJPWh0xAv8tZnRnoSdzIrSbK7MW5kyIQPFlsqZ c0IMsEt1foLAoCGc0nXr18txdQLX8FO2RievI= MIME-Version: 1.0 Received: by 10.101.106.25 with SMTP id i25mr454159anm.80.1310506453198; Tue, 12 Jul 2011 14:34:13 -0700 (PDT) Received: by 10.100.93.12 with HTTP; Tue, 12 Jul 2011 14:34:10 -0700 (PDT) In-Reply-To: References: <4A953B0A-3910-4DEC-BE13-9B6F2E0815B2@kumari.net> Date: Tue, 12 Jul 2011 17:34:10 -0400 Message-ID: From: Phillip Hallam-Baker To: Warren Kumari Content-Type: multipart/alternative; boundary=001636c9257f9e65fc04a7e60faa Cc: dane@ietf.org Subject: Re: [dane] Opening issues... X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 21:34:17 -0000 --001636c9257f9e65fc04a7e60faa Content-Type: text/plain; charset=ISO-8859-1 Another topic I think we should discuss is the mechanics of how to support fine grain assertions about keys (e.g. per port or per protocol) which appear to require use of prefixes to be scalable and support for wildcards/aliases. Thus far I see the following options on the table 1) Do not use prefixes [Does not provide sufficient granularity, deploying DANE on your mail server will clobber your Web server] 2) Use only prefixes [Not compatible with wildcards due to the ambiguity problem, use of aliases is problematic] 3) Use a multi-stage resolution in which the first stage is unprefixed and subsequent stages have additional detail. [Saves the appearances but requires two round trips if granularity is required] 4) Use the DNSSEC trust hierarchy without using DNS (e.g. chain approach]. On Tue, Jul 12, 2011 at 12:23 PM, Warren Kumari wrote: > > On Jul 8, 2011, at 2:24 PM, Warren Kumari wrote: > > > Hi all, > > > > So, as many of you know, I've been traveling -- this has led me to slip > behind on my email and I apologize for not being more on top of things... > > > > I'm glad to see that there is all of this discussion on the list, but > shocked (shocked I tell you) that there are not open issues to track these > discussions. I realize that a lot of bright folk are putting lots of time, > effort and thought into these discussions, but all this effort is wasted if > we don't a: know what it is we are actually discussing and b: track and > record what we actually decide[0]. > > > > So, *please*, if you have a useful issue or are discussing something of > import, please toss it in the issues tracker -- > http://trac.tools.ietf.org/wg/dane/trac/report (I'll also try summarize > the actual issues under discussion and toss them in, but if y'all do so > they'll better capture the crux). > > > > If we don't get some new issues to discuss (yes, and get around to > resolving outstanding ones): > > 1: I'll have to decide that we are all done and move things off to WGLC. > > and > > 2: We'll all end up sitting around in a big room in Quebec with nothing > to talk about or do - if this happens (and to make sure that everyone gets > value from their registration fee) I'll have to break out the Karaoke > machine.... *Please*, don't make me break out the karaoke machine... > > I think that the Working Group has made some really good progress with the > Use Case doc (thanks Richard, and everyone who contributed) and we stopped > work on the Protocol doc to make sure it addressed the use cases correctly. > Since then we have not made much progress (other than some interesting > discussions re: serializing DNSSEC chains) and so we might just not have > enough to talk about to justify using people's tine in Quebec. > > So, if we don't get some issues of substance by Thursday (or requests from > folk to present), we'll may just cancel the face-to-face meeting in > Quebec... People's time is valuable, and if we don't have anything to > discuss we can free some of this up so folk can a: attend other sessions or > b: see some of Quebec... > > > W > > > > W > > > > [0]: Yes, I realize that all of the email is nicely archived and > searchable -- I'm choosing to ignore this point as it a: doesn't support my > case and b: interferes with my ranty tone. :-P > > > > > > > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > -- Website: http://hallambaker.com/ --001636c9257f9e65fc04a7e60faa Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Another topic I think we should discuss is the mechanics of how to support = fine grain assertions about keys (e.g. per port or per protocol) which appe= ar to require use of prefixes to be scalable and support for wildcards/alia= ses.

Thus far I see the following options on the table
=
1) Do not use prefixes
=A0 =A0[Does not provide su= fficient granularity, deploying DANE on your mail server will clobber your = Web server]

2) Use only prefixes
=A0 =A0[Not compatible w= ith wildcards due to the ambiguity problem, use of aliases is problematic]<= /div>

3) Use a multi-stage resolution in which the first= stage is unprefixed and subsequent stages have additional detail.
=A0 =A0[Saves the appearances but requires two round trips if granular= ity is required]

4) Use the DNSSEC trust hierarchy without us= ing DNS (e.g. chain approach].



On Tue, Jul 12, 2011 at 12:23 PM, Warren Kumari = <warren@kumari.ne= t> wrote:

On Jul 8, 2011, at 2:24 PM, Warren Kumari wrote:

> Hi all,
>
> So, as many of you know, I've been traveling -- this has led me to= slip behind on my email and I apologize for not being more on top of thing= s...
>
> I'm glad to see that there is all of this discussion on the list, = but shocked (shocked I tell you) that there are not open issues to track th= ese discussions. I realize that a lot of bright folk are putting lots of ti= me, effort and thought into these discussions, but all this effort is waste= d if we don't a: know what it is we are actually discussing and b: trac= k and record what we actually decide[0].
>
> So, *please*, if you have a useful issue or are discussing something o= f import, please toss it in the issues tracker -- http://trac.tools.ietf.= org/wg/dane/trac/report (I'll also try summarize the actual issues = under discussion and toss them in, but if y'all do so they'll bette= r capture the crux).
>
> If we don't get some new issues to discuss (yes, and get around to= resolving outstanding ones):
> 1: I'll have to decide that we are all done and move things off to= WGLC.
> and
> 2: We'll all end up sitting around in a big room in Quebec with no= thing to talk about or do - if this happens (and to make sure that everyone= gets value from their registration fee) I'll have to break out the Kar= aoke machine.... *Please*, don't make me break out the karaoke machine.= ..

I think that the Working Group has made some really good progress wit= h the Use Case doc (thanks Richard, and everyone who contributed) and we st= opped work on the Protocol doc to make sure it addressed the use cases corr= ectly.
Since then we have not made much progress (other than some interesting disc= ussions re: serializing DNSSEC chains) and so we might just not have enough= to talk about to justify using people's tine in Quebec.

So, if we don't get some issues of substance by Thursday (or requests f= rom folk to present), we'll may just cancel the face-to-face meeting in= Quebec... People's time is valuable, and if we don't have anything= to discuss we can free some of this up so folk can a: attend other session= s or b: see some of Quebec...


W
>
> W
>
> [0]: Yes, I realize that all of the email is nicely archived and searc= hable -- =A0I'm choosing to ignore this point as it a: doesn't supp= ort my case and b: interferes with my ranty tone. :-P
>
>
>

_______________________________________________
dane mailing list
dane@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/dane



--
Website: http://hallambaker.com/

--001636c9257f9e65fc04a7e60faa-- From rbarnes@bbn.com Tue Jul 12 14:42:04 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C05221F8A4F for ; Tue, 12 Jul 2011 14:42:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.587 X-Spam-Level: X-Spam-Status: No, score=-106.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s52AtphdaJBB for ; Tue, 12 Jul 2011 14:42:03 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 3BF1021F8A35 for ; Tue, 12 Jul 2011 14:42:03 -0700 (PDT) Received: from [128.89.252.233] (port=50455 helo=[10.45.1.98]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QgkiQ-000Hac-Fe; Tue, 12 Jul 2011 17:42:02 -0400 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: Date: Tue, 12 Jul 2011 17:42:01 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <80D54E0F-2F9F-48CC-B1B4-963FFAC011C5@bbn.com> References: <4A953B0A-3910-4DEC-BE13-9B6F2E0815B2@kumari.net> <4E1C89B9.8030100@verisign.com> To: Paul Hoffman X-Mailer: Apple Mail (2.1082) Cc: DANE WG Subject: Re: [dane] Opening issues... X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 21:42:04 -0000 Thus it seems appropriate to have some discussion about (1) whether = there's interest in stapling/serialization and (2) whether it should be = done in DANE vs. PKIX vs. TLS. --Richard On Jul 12, 2011, at 2:30 PM, Paul Hoffman wrote: > On Jul 12, 2011, at 10:51 AM, Eric Osterweil wrote: >=20 >> I think it would be quite valuable to talk about the serialization = issue that you alluded to above. >=20 >=20 > While the serializing DNSSEC thread is interesting, is it at all a = DANE issue? It feels much more like a TLS issue, since it answers the = question "how do I reduce latency in starting up TLS". >=20 > --Paul Hoffman >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From jakob@kirei.se Tue Jul 12 14:43:36 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AB0F21F8A4F for ; Tue, 12 Jul 2011 14:43:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.349 X-Spam-Level: X-Spam-Status: No, score=-0.349 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_SE=0.35, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5eWoqN3btsvV for ; Tue, 12 Jul 2011 14:43:31 -0700 (PDT) Received: from spg.kirei.se (spg.kirei.se [IPv6:2001:67c:394:15::9]) by ietfa.amsl.com (Postfix) with ESMTP id F2E2321F8A35 for ; Tue, 12 Jul 2011 14:43:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kirei.se; s=spg20100524; h=received:subject:mime-version:content-type:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to:x-mailer; bh=m4JvNhDzuZ6JWXPodUbXXjo/z77kmyt699MTNX3U5Yg=; b=0Y9KXEPtvyOdZCiwLSAYkpAe0tqqjaEL4gBRBkvR14vuaKAzHcPUsyJXw0ThJIwXAw5B6spX/UoXB xiCCTdrhRS3v7L9T4oz/F5CRXvC1yb13wL+k3d+WjakcUxpIE/dLJv/pwPnFxYYKQXS3/ylPmBpZLC Wf8G+9A6fdhXZPPY= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg-relay.kirei.se (Halon Mail Gateway) with ESMTPS; Tue, 12 Jul 2011 23:43:19 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Jakob Schlyter In-Reply-To: Date: Tue, 12 Jul 2011 23:43:17 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201107080215.p682F8F1006443@fs4113.wdf.sap.corp> <407C5BC6-DE01-4235-B242-1414F0D594FC@kirei.se> To: Tony Finch X-Mailer: Apple Mail (2.1084) Cc: "dane@ietf.org" Subject: Re: [dane] Draft for serializing DNSSEC chains X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 21:43:36 -0000 On 12 jul 2011, at 20.15, Tony Finch wrote: > The essential problem is that ICANN doesn't provide any way for a = device > to bootstrap trust if it misses an RFC 5011 rollover, and the rollover > timing is very short so this will be a very common problem. ICANN publish each root KSK signed with its own long term X.509 CA. = Vendors who do not want to use this mechanism, may choose to use their = own CA to sign the root KSK CSR. Using these mechanisms is being = implemented, e.g. verifying new root KSKs with the ICANN DNSSEC CA is = implemented in later versions of Unbound. > This problem isn't necessary: RFC 5011 allows you to prepare and > pre-publish a standby KSK well in advance, in a way that fits in with > typical software release and support schedules. If this was done for = the > root KSK then everyone could obtain and verify the next trust anchor = and > the problem would basically go away. This has been considered and rejected as part of the design . Depending = on how the production KSK would be compromised, a standby KSK needs to = protected using a similar set of security controls (but not the very = same) as the production KSK and/or need to use another algorithm (but we = don't now which yet). Yes, it possible to design something that would = work in theory, but combining this with the current mechanisms to = provide transparency (trusted community representatives et al.) does not = make sense.=20 jakob From warren@kumari.net Tue Jul 12 14:49:46 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3495121F8C5E for ; Tue, 12 Jul 2011 14:49:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9oF941lNRkxD for ; Tue, 12 Jul 2011 14:49:42 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 39CF521F8BEC for ; Tue, 12 Jul 2011 14:49:41 -0700 (PDT) Received: from dot.her.corp.google.com (unknown [74.202.225.33]) by vimes.kumari.net (Postfix) with ESMTPSA id 7B9671B4173D; Tue, 12 Jul 2011 17:49:41 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warren Kumari In-Reply-To: Date: Tue, 12 Jul 2011 17:49:40 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <0F145B3E-8BE1-41B3-8702-BC77E5FCECFF@kumari.net> References: <4A953B0A-3910-4DEC-BE13-9B6F2E0815B2@kumari.net> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1084) Cc: dane@ietf.org Subject: Re: [dane] Opening issues... X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 21:49:46 -0000 On Jul 12, 2011, at 5:34 PM, Phillip Hallam-Baker wrote: > Another topic I think we should discuss is the mechanics of how to = support fine grain assertions about keys (e.g. per port or per protocol) = which appear to require use of prefixes to be scalable and support for = wildcards/aliases. >=20 > Thus far I see the following options on the table >=20 > 1) Do not use prefixes > [Does not provide sufficient granularity, deploying DANE on your = mail server will clobber your Web server] >=20 > 2) Use only prefixes > [Not compatible with wildcards due to the ambiguity problem, use of = aliases is problematic] >=20 > 3) Use a multi-stage resolution in which the first stage is unprefixed = and subsequent stages have additional detail. > [Saves the appearances but requires two round trips if granularity = is required] >=20 > 4) Use the DNSSEC trust hierarchy without using DNS (e.g. chain = approach]. >=20 >=20 I believe that we have already discussed (and resolved) this topic: http://trac.tools.ietf.org/wg/dane/trac/ticket/19 "I believe that this issue has been addressed, both in numerous = discussions and in version -05 of the draft, section 2.1 ("Requested Domain Name") No-one has objected to the text in the section, so I'm closing this = issue. =20 If you do object to the text, you must offer alternative (better!) = text... W " This is exactly why having issues in the tracker is useful -- a lot of = stuff happens on the list, and it is easy to forget what consensus was = reached (this was ~5 months ago!). Having a quick place to refer to is = nice... W >=20 > On Tue, Jul 12, 2011 at 12:23 PM, Warren Kumari = wrote: >=20 > On Jul 8, 2011, at 2:24 PM, Warren Kumari wrote: >=20 > > Hi all, > > > > So, as many of you know, I've been traveling -- this has led me to = slip behind on my email and I apologize for not being more on top of = things... > > > > I'm glad to see that there is all of this discussion on the list, = but shocked (shocked I tell you) that there are not open issues to track = these discussions. I realize that a lot of bright folk are putting lots = of time, effort and thought into these discussions, but all this effort = is wasted if we don't a: know what it is we are actually discussing and = b: track and record what we actually decide[0]. > > > > So, *please*, if you have a useful issue or are discussing something = of import, please toss it in the issues tracker -- = http://trac.tools.ietf.org/wg/dane/trac/report (I'll also try summarize = the actual issues under discussion and toss them in, but if y'all do so = they'll better capture the crux). > > > > If we don't get some new issues to discuss (yes, and get around to = resolving outstanding ones): > > 1: I'll have to decide that we are all done and move things off to = WGLC. > > and > > 2: We'll all end up sitting around in a big room in Quebec with = nothing to talk about or do - if this happens (and to make sure that = everyone gets value from their registration fee) I'll have to break out = the Karaoke machine.... *Please*, don't make me break out the karaoke = machine... >=20 > I think that the Working Group has made some really good progress with = the Use Case doc (thanks Richard, and everyone who contributed) and we = stopped work on the Protocol doc to make sure it addressed the use cases = correctly. > Since then we have not made much progress (other than some interesting = discussions re: serializing DNSSEC chains) and so we might just not have = enough to talk about to justify using people's tine in Quebec. >=20 > So, if we don't get some issues of substance by Thursday (or requests = from folk to present), we'll may just cancel the face-to-face meeting in = Quebec... People's time is valuable, and if we don't have anything to = discuss we can free some of this up so folk can a: attend other sessions = or b: see some of Quebec... >=20 >=20 > W > > > > W > > > > [0]: Yes, I realize that all of the email is nicely archived and = searchable -- I'm choosing to ignore this point as it a: doesn't = support my case and b: interferes with my ranty tone. :-P > > > > > > >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane >=20 >=20 >=20 > --=20 > Website: http://hallambaker.com/ >=20 From warren@kumari.net Tue Jul 12 14:51:49 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7822D21F85A8 for ; Tue, 12 Jul 2011 14:51:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lHfWEZo689vY for ; Tue, 12 Jul 2011 14:51:45 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 4CC3321F8C5E for ; Tue, 12 Jul 2011 14:51:45 -0700 (PDT) Received: from dot.her.corp.google.com (unknown [74.202.225.33]) by vimes.kumari.net (Postfix) with ESMTPSA id C5B5E1B400BE; Tue, 12 Jul 2011 17:51:44 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warren Kumari In-Reply-To: <0F145B3E-8BE1-41B3-8702-BC77E5FCECFF@kumari.net> Date: Tue, 12 Jul 2011 17:51:44 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <1AB568F1-9AE3-4E72-B871-65D799206CA7@kumari.net> References: <4A953B0A-3910-4DEC-BE13-9B6F2E0815B2@kumari.net> <0F145B3E-8BE1-41B3-8702-BC77E5FCECFF@kumari.net> To: Warren Kumari X-Mailer: Apple Mail (2.1084) Cc: IETF DANE WG list Subject: Re: [dane] Opening issues... X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 21:51:49 -0000 On Jul 12, 2011, at 5:49 PM, Warren Kumari wrote: >=20 > On Jul 12, 2011, at 5:34 PM, Phillip Hallam-Baker wrote: >=20 >> Another topic I think we should discuss is the mechanics of how to = support fine grain assertions about keys (e.g. per port or per protocol) = which appear to require use of prefixes to be scalable and support for = wildcards/aliases. >>=20 >> Thus far I see the following options on the table >>=20 >> 1) Do not use prefixes >> [Does not provide sufficient granularity, deploying DANE on your = mail server will clobber your Web server] >>=20 >> 2) Use only prefixes >> [Not compatible with wildcards due to the ambiguity problem, use of = aliases is problematic] >>=20 >> 3) Use a multi-stage resolution in which the first stage is = unprefixed and subsequent stages have additional detail. >> [Saves the appearances but requires two round trips if granularity = is required] >>=20 >> 4) Use the DNSSEC trust hierarchy without using DNS (e.g. chain = approach]. >>=20 >>=20 >=20 > I believe that we have already discussed (and resolved) this topic: > http://trac.tools.ietf.org/wg/dane/trac/ticket/19 >=20 > "I believe that this issue has been addressed, both in numerous = discussions > and in version -05 of the draft, section 2.1 ("Requested Domain Name") >=20 > No-one has objected to the text in the section, so I'm closing this = issue. =20 > If you do object to the text, you must offer alternative (better!) = text... >=20 > W > " >=20 >=20 Ooops, I mean to include Issue #1 as well:=20 http://trac.tools.ietf.org/wg/dane/trac/ticket/1 "The rough consensus is that we use a prefix (as opposed to looking up = the name and getting back a list of records with ports in them). Now we just need to settle on the prefix that we will be using - a = separate issue (Issue #19 - = http://trac.tools.ietf.org/wg/dane/trac/ticket/19 ) has been created to = decide on this." W > This is exactly why having issues in the tracker is useful -- a lot of = stuff happens on the list, and it is easy to forget what consensus was = reached (this was ~5 months ago!). Having a quick place to refer to is = nice... >=20 > W >=20 >=20 >>=20 >> On Tue, Jul 12, 2011 at 12:23 PM, Warren Kumari = wrote: >>=20 >> On Jul 8, 2011, at 2:24 PM, Warren Kumari wrote: >>=20 >>> Hi all, >>>=20 >>> So, as many of you know, I've been traveling -- this has led me to = slip behind on my email and I apologize for not being more on top of = things... >>>=20 >>> I'm glad to see that there is all of this discussion on the list, = but shocked (shocked I tell you) that there are not open issues to track = these discussions. I realize that a lot of bright folk are putting lots = of time, effort and thought into these discussions, but all this effort = is wasted if we don't a: know what it is we are actually discussing and = b: track and record what we actually decide[0]. >>>=20 >>> So, *please*, if you have a useful issue or are discussing something = of import, please toss it in the issues tracker -- = http://trac.tools.ietf.org/wg/dane/trac/report (I'll also try summarize = the actual issues under discussion and toss them in, but if y'all do so = they'll better capture the crux). >>>=20 >>> If we don't get some new issues to discuss (yes, and get around to = resolving outstanding ones): >>> 1: I'll have to decide that we are all done and move things off to = WGLC. >>> and >>> 2: We'll all end up sitting around in a big room in Quebec with = nothing to talk about or do - if this happens (and to make sure that = everyone gets value from their registration fee) I'll have to break out = the Karaoke machine.... *Please*, don't make me break out the karaoke = machine... >>=20 >> I think that the Working Group has made some really good progress = with the Use Case doc (thanks Richard, and everyone who contributed) and = we stopped work on the Protocol doc to make sure it addressed the use = cases correctly. >> Since then we have not made much progress (other than some = interesting discussions re: serializing DNSSEC chains) and so we might = just not have enough to talk about to justify using people's tine in = Quebec. >>=20 >> So, if we don't get some issues of substance by Thursday (or requests = from folk to present), we'll may just cancel the face-to-face meeting in = Quebec... People's time is valuable, and if we don't have anything to = discuss we can free some of this up so folk can a: attend other sessions = or b: see some of Quebec... >>=20 >>=20 >> W >>>=20 >>> W >>>=20 >>> [0]: Yes, I realize that all of the email is nicely archived and = searchable -- I'm choosing to ignore this point as it a: doesn't = support my case and b: interferes with my ranty tone. :-P >>>=20 >>>=20 >>>=20 >>=20 >> _______________________________________________ >> dane mailing list >> dane@ietf.org >> https://www.ietf.org/mailman/listinfo/dane >>=20 >>=20 >>=20 >> --=20 >> Website: http://hallambaker.com/ >>=20 >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane >=20 From hallam@gmail.com Tue Jul 12 15:56:08 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B27511E80A0 for ; Tue, 12 Jul 2011 15:56:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.541 X-Spam-Level: X-Spam-Status: No, score=-3.541 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZD1nI2xR4edX for ; Tue, 12 Jul 2011 15:56:04 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1C51B11E809F for ; Tue, 12 Jul 2011 15:56:04 -0700 (PDT) Received: by yie30 with SMTP id 30so2583495yie.31 for ; Tue, 12 Jul 2011 15:56:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1X+RPJNn2COUI2Hb5vlXQ4lu58UCUu0b652Owysx4is=; b=Ny4tkCnM0bBlmg7PaOHv655XQTWAdpN9TnwS9XDAg4GCoCbEHqvfaSge5yqk5RIGQI w8NqRQBXqUNOMXwdwcXNOGcHyWHSzC01Nq+secLNp28UqdNtDqI6FbBIrY9ybrW4x4VJ P/2aaRqAmUC1sVUpij++8pwQXFUiPHAN10P5o= MIME-Version: 1.0 Received: by 10.101.106.25 with SMTP id i25mr509026anm.80.1310511363532; Tue, 12 Jul 2011 15:56:03 -0700 (PDT) Received: by 10.100.93.12 with HTTP; Tue, 12 Jul 2011 15:56:03 -0700 (PDT) In-Reply-To: <1AB568F1-9AE3-4E72-B871-65D799206CA7@kumari.net> References: <4A953B0A-3910-4DEC-BE13-9B6F2E0815B2@kumari.net> <0F145B3E-8BE1-41B3-8702-BC77E5FCECFF@kumari.net> <1AB568F1-9AE3-4E72-B871-65D799206CA7@kumari.net> Date: Tue, 12 Jul 2011 18:56:03 -0400 Message-ID: From: Phillip Hallam-Baker To: Warren Kumari Content-Type: multipart/alternative; boundary=001636c9257f4c29a004a7e73459 Cc: IETF DANE WG list Subject: Re: [dane] Opening issues... X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 22:56:08 -0000 --001636c9257f4c29a004a7e73459 Content-Type: text/plain; charset=ISO-8859-1 We decided against 1. However we have since done a requirements exercise. One of the questions raised in that exercise was how DANE would interact with wildcards and aliases. The current proposal does not support the correct DNS semantics. Since the original rationale for not doing the two phase resolution was the need to have low latency, and since the party that raised that has found another solution it would seem reasonable to discuss this issue again. On Tue, Jul 12, 2011 at 5:51 PM, Warren Kumari wrote: > > On Jul 12, 2011, at 5:49 PM, Warren Kumari wrote: > > > > > On Jul 12, 2011, at 5:34 PM, Phillip Hallam-Baker wrote: > > > >> Another topic I think we should discuss is the mechanics of how to > support fine grain assertions about keys (e.g. per port or per protocol) > which appear to require use of prefixes to be scalable and support for > wildcards/aliases. > >> > >> Thus far I see the following options on the table > >> > >> 1) Do not use prefixes > >> [Does not provide sufficient granularity, deploying DANE on your mail > server will clobber your Web server] > >> > >> 2) Use only prefixes > >> [Not compatible with wildcards due to the ambiguity problem, use of > aliases is problematic] > >> > >> 3) Use a multi-stage resolution in which the first stage is unprefixed > and subsequent stages have additional detail. > >> [Saves the appearances but requires two round trips if granularity is > required] > >> > >> 4) Use the DNSSEC trust hierarchy without using DNS (e.g. chain > approach]. > >> > >> > > > > I believe that we have already discussed (and resolved) this topic: > > http://trac.tools.ietf.org/wg/dane/trac/ticket/19 > > > > "I believe that this issue has been addressed, both in numerous > discussions > > and in version -05 of the draft, section 2.1 ("Requested Domain Name") > > > > No-one has objected to the text in the section, so I'm closing this > issue. > > If you do object to the text, you must offer alternative (better!) > text... > > > > W > > " > > > > > > Ooops, I mean to include Issue #1 as well: > > http://trac.tools.ietf.org/wg/dane/trac/ticket/1 > > "The rough consensus is that we use a prefix (as opposed to looking up the > name and getting back a list of records with ports in them). > > Now we just need to settle on the prefix that we will be using - a separate > issue (Issue #19 - http://trac.tools.ietf.org/wg/dane/trac/ticket/19 ) has > been created to decide on this." > > W > > > > This is exactly why having issues in the tracker is useful -- a lot of > stuff happens on the list, and it is easy to forget what consensus was > reached (this was ~5 months ago!). Having a quick place to refer to is > nice... > > > > W > > > > > >> > >> On Tue, Jul 12, 2011 at 12:23 PM, Warren Kumari > wrote: > >> > >> On Jul 8, 2011, at 2:24 PM, Warren Kumari wrote: > >> > >>> Hi all, > >>> > >>> So, as many of you know, I've been traveling -- this has led me to slip > behind on my email and I apologize for not being more on top of things... > >>> > >>> I'm glad to see that there is all of this discussion on the list, but > shocked (shocked I tell you) that there are not open issues to track these > discussions. I realize that a lot of bright folk are putting lots of time, > effort and thought into these discussions, but all this effort is wasted if > we don't a: know what it is we are actually discussing and b: track and > record what we actually decide[0]. > >>> > >>> So, *please*, if you have a useful issue or are discussing something of > import, please toss it in the issues tracker -- > http://trac.tools.ietf.org/wg/dane/trac/report (I'll also try summarize > the actual issues under discussion and toss them in, but if y'all do so > they'll better capture the crux). > >>> > >>> If we don't get some new issues to discuss (yes, and get around to > resolving outstanding ones): > >>> 1: I'll have to decide that we are all done and move things off to > WGLC. > >>> and > >>> 2: We'll all end up sitting around in a big room in Quebec with nothing > to talk about or do - if this happens (and to make sure that everyone gets > value from their registration fee) I'll have to break out the Karaoke > machine.... *Please*, don't make me break out the karaoke machine... > >> > >> I think that the Working Group has made some really good progress with > the Use Case doc (thanks Richard, and everyone who contributed) and we > stopped work on the Protocol doc to make sure it addressed the use cases > correctly. > >> Since then we have not made much progress (other than some interesting > discussions re: serializing DNSSEC chains) and so we might just not have > enough to talk about to justify using people's tine in Quebec. > >> > >> So, if we don't get some issues of substance by Thursday (or requests > from folk to present), we'll may just cancel the face-to-face meeting in > Quebec... People's time is valuable, and if we don't have anything to > discuss we can free some of this up so folk can a: attend other sessions or > b: see some of Quebec... > >> > >> > >> W > >>> > >>> W > >>> > >>> [0]: Yes, I realize that all of the email is nicely archived and > searchable -- I'm choosing to ignore this point as it a: doesn't support my > case and b: interferes with my ranty tone. :-P > >>> > >>> > >>> > >> > >> _______________________________________________ > >> dane mailing list > >> dane@ietf.org > >> https://www.ietf.org/mailman/listinfo/dane > >> > >> > >> > >> -- > >> Website: http://hallambaker.com/ > >> > > > > _______________________________________________ > > dane mailing list > > dane@ietf.org > > https://www.ietf.org/mailman/listinfo/dane > > > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > -- Website: http://hallambaker.com/ --001636c9257f4c29a004a7e73459 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable We decided against 1.

However we have since done a requi= rements exercise.

One of the questions raised in t= hat exercise was how DANE would interact with wildcards and aliases. The cu= rrent proposal does not support the correct DNS semantics.


Since the original rationale for not doi= ng the two phase resolution was the need to have low latency, and since the= party that raised that has found another solution it would seem reasonable= to discuss this issue again.


On Tue, Jul 12, 2011 at 5:51 PM, Wa= rren Kumari <warr= en@kumari.net> wrote:

On Jul 12, 2011, at 5:49 PM, Warren Kumari wrote:

>
> On Jul 12, 2011, at 5:34 PM, Phillip Hallam-Baker wrote:
>
>> Another topic I think we should discuss is the mechanics of how to= support fine grain assertions about keys (e.g. per port or per protocol) w= hich appear to require use of prefixes to be scalable and support for wildc= ards/aliases.
>>
>> Thus far I see the following options on the table
>>
>> 1) Do not use prefixes
>> =A0 [Does not provide sufficient granularity, deploying DANE on yo= ur mail server will clobber your Web server]
>>
>> 2) Use only prefixes
>> =A0 [Not compatible with wildcards due to the ambiguity problem, u= se of aliases is problematic]
>>
>> 3) Use a multi-stage resolution in which the first stage is unpref= ixed and subsequent stages have additional detail.
>> =A0 [Saves the appearances but requires two round trips if granula= rity is required]
>>
>> 4) Use the DNSSEC trust hierarchy without using DNS (e.g. chain ap= proach].
>>
>>
>
> I believe that we have already discussed (and resolved) this topic: > http://trac.tools.ietf.org/wg/dane/trac/ticket/19
>
> "I believe that this issue has been addressed, both in numerous d= iscussions
> and in version -05 of the draft, section 2.1 ("Requested Domain N= ame")
>
> No-one has objected to the text in the section, so I'm closing thi= s issue.
> If you do object to the text, you must offer alternative (better!) =A0= text...
>
> W
> "
>
>

Ooops, I mean to include Issue #1 as well:

http://trac.tools.ietf.org/wg/dane/trac/ticket/1

"The rough consensus is that we use a prefix (as opposed to look= ing up the name and getting back a list of records with ports in them).

Now we just need to settle on the prefix that we will be using - a separate= issue (Issue #19 - http://trac.tools.ietf.org/wg/dane/trac/ticket/19<= /a> ) has been created to decide on this."

W


> This is exactly why having issues in the tracker is useful -- a lot of= stuff happens on the list, and it is easy to forget what consensus was rea= ched (this was ~5 months ago!). Having a quick place to refer to is nice...=
>
> W
>
>
>>
>> On Tue, Jul 12, 2011 at 12:23 PM, Warren Kumari <warren@kumari.net> wrote:
>>
>> On Jul 8, 2011, at 2:24 PM, Warren Kumari wrote:
>>
>>> Hi all,
>>>
>>> So, as many of you know, I've been traveling -- this has l= ed me to slip behind on my email and I apologize for not being more on top = of things...
>>>
>>> I'm glad to see that there is all of this discussion on th= e list, but shocked (shocked I tell you) that there are not open issues to = track these discussions. I realize that a lot of bright folk are putting lo= ts of time, effort and thought into these discussions, but all this effort = is wasted if we don't a: know what it is we are actually discussing and= b: track and record what we actually decide[0].
>>>
>>> So, *please*, if you have a useful issue or are discussing som= ething of import, please toss it in the issues tracker -- http://trac.too= ls.ietf.org/wg/dane/trac/report (I'll also try summarize the actual= issues under discussion and toss them in, but if y'all do so they'= ll better capture the crux).
>>>
>>> If we don't get some new issues to discuss (yes, and get a= round to resolving outstanding ones):
>>> 1: I'll have to decide that we are all done and move thing= s off to WGLC.
>>> and
>>> 2: We'll all end up sitting around in a big room in Quebec= with nothing to talk about or do - if this happens (and to make sure that = everyone gets value from their registration fee) I'll have to break out= the Karaoke machine.... *Please*, don't make me break out the karaoke = machine...
>>
>> I think that the Working Group has made some really good progress = with the Use Case doc (thanks Richard, and everyone who contributed) and we= stopped work on the Protocol doc to make sure it addressed the use cases c= orrectly.
>> Since then we have not made much progress (other than some interes= ting discussions re: serializing DNSSEC chains) and so we might just not ha= ve enough to talk about to justify using people's tine in Quebec.
>>
>> So, if we don't get some issues of substance by Thursday (or r= equests from folk to present), we'll may just cancel the face-to-face m= eeting in Quebec... People's time is valuable, and if we don't have= anything to discuss we can free some of this up so folk can a: attend othe= r sessions or b: see some of Quebec...
>>
>>
>> W
>>>
>>> W
>>>
>>> [0]: Yes, I realize that all of the email is nicely archived a= nd searchable -- =A0I'm choosing to ignore this point as it a: doesn= 9;t support my case and b: interferes with my ranty tone. :-P
>>>
>>>
>>>
>>
>> _______________________________________________
>> dane mailing list
>> dane@ietf.org
>> https://www.ietf.org/mailman/listinfo/dane
>>
>>
>>
>> --
>> Website: htt= p://hallambaker.com/
>>
>
> _______________________________________________
> dane mailing list
> dane@ietf.org
> https://www.ietf.org/mailman/listinfo/dane
>

_______________________________________________
dane mailing list
dane@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/dane



--
Website: http://hallambaker.com/

--001636c9257f4c29a004a7e73459-- From paul.hoffman@vpnc.org Tue Jul 12 16:35:29 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78FC521F8B7D for ; Tue, 12 Jul 2011 16:35:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.699 X-Spam-Level: X-Spam-Status: No, score=-102.699 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AlgX5A9O5Vxd for ; Tue, 12 Jul 2011 16:35:29 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id AA66C21F8B7A for ; Tue, 12 Jul 2011 16:35:28 -0700 (PDT) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4] (may be forged)) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p6CNZDu5082119 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 12 Jul 2011 16:35:13 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Tue, 12 Jul 2011 16:35:21 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4F163F5A-D10B-4482-A0D5-5068F6C9FD5C@vpnc.org> References: <4A953B0A-3910-4DEC-BE13-9B6F2E0815B2@kumari.net> <0F145B3E-8BE1-41B3-8702-BC77E5FCECFF@kumari.net> <1AB568F1-9AE3-4E72-B871-65D799206CA7@kumari.net> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1084) Cc: IETF DANE WG list Subject: Re: [dane] Opening issues... X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 23:35:29 -0000 On Jul 12, 2011, at 3:56 PM, Phillip Hallam-Baker wrote: > We decided against 1. >=20 > However we have since done a requirements exercise. >=20 > One of the questions raised in that exercise was how DANE would = interact with wildcards and aliases. The current proposal does not = support the correct DNS semantics. Jakob and I believe that it does. We asked a handful of DNS folks about = this, and the result of that discussion is that our usage in the current = draft (and the past few drafts) supports CNAMEs just fine. We didn't put = this discussion in the current draft, but it is feeling like we should = do so in an appendix. In the meantime (we can't update the draft for about two weeks), if you = have specific things from the DNS protocol that you think we are doing = wrong, please bring them to the list. --Paul Hoffman From demoss.matt@gmail.com Wed Jul 13 03:10:23 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C20621F8794 for ; Wed, 13 Jul 2011 03:10:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IxAQYR4bB92X for ; Wed, 13 Jul 2011 03:10:22 -0700 (PDT) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by ietfa.amsl.com (Postfix) with ESMTP id 4606621F8799 for ; Wed, 13 Jul 2011 03:10:21 -0700 (PDT) Received: by fxe4 with SMTP id 4so7257943fxe.27 for ; Wed, 13 Jul 2011 03:10:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rjSb2K8i4dEPenPTQJZJvam8T6oefbHQmDUmU9B60n4=; b=flXrcZIU8P0vOmlIc/ICZAtAMkon5uWExE21xFJgkm0ViFh854bvqpG+Vr8SNf580F ANDFqasYn/L83Hbrq8/N+R1V6f1+Ss2N289BNasdkUdN0QMLbPTMqOrYS4o0dA8oNVB/ lQ2tUrt/HIo113U/7OI56k4bt//iBV6wjBYR4= MIME-Version: 1.0 Received: by 10.223.100.197 with SMTP id z5mr1485304fan.46.1310551820227; Wed, 13 Jul 2011 03:10:20 -0700 (PDT) Received: by 10.223.112.4 with HTTP; Wed, 13 Jul 2011 03:10:20 -0700 (PDT) In-Reply-To: References: <4A953B0A-3910-4DEC-BE13-9B6F2E0815B2@kumari.net> <4E1C89B9.8030100@verisign.com> Date: Wed, 13 Jul 2011 06:10:20 -0400 Message-ID: From: Matt DeMoss To: Paul Wouters Content-Type: multipart/alternative; boundary=001517491f5ab4550304a7f09f11 Cc: dane@ietf.org Subject: Re: [dane] Opening issues... X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2011 10:10:23 -0000 --001517491f5ab4550304a7f09f11 Content-Type: text/plain; charset=ISO-8859-1 > > 1) do DNSSEC even if the OS has no secure resolverThe problem with 1) is > that it seems a lot of work only to protect against passive attacks > (active attacks will leave the vulnerable client on port 80) > (active attacks will leave the vulnerable client on port 80) Could that use case better addressed by HSTS? Where the client does support DNSSEC or some other secure communication from a trusted authority (or authorities) I could see ways around the initial request problem, but ultimately you're relying on the user to respond correctly to some UI cue whether it is the domain name that's displayed or a lock icon. --001517491f5ab4550304a7f09f11 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
1) do DNSSEC even if the OS ha= s no secure resolverThe= problem with 1) is that it seems a lot of work only to protect against pas= sive attacks
(active attacks will leave the vulnerable client on port 80)
(active= attacks will leave the vulnerable client on port 80)

Could that use case better addressed by HSTS?

Where the client does support DNSSEC or some other secure c= ommunication from a trusted authority (or authorities) I could see ways aro= und the initial request problem, but ultimately you're relying on the u= ser to respond correctly to some UI cue whether it is the domain name that&= #39;s displayed or a lock icon.
--001517491f5ab4550304a7f09f11-- From ondrej.sury@nic.cz Wed Jul 13 05:39:21 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43F4C21F8782 for ; Wed, 13 Jul 2011 05:39:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.77 X-Spam-Level: X-Spam-Status: No, score=-0.77 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OhUvTCj1feD4 for ; Wed, 13 Jul 2011 05:39:16 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 2420021F8787 for ; Wed, 13 Jul 2011 05:39:16 -0700 (PDT) Received: from [IPv6:2001:1488:ac14:1400:224:e8ff:fea9:f617] (unknown [IPv6:2001:1488:ac14:1400:224:e8ff:fea9:f617]) by mail.nic.cz (Postfix) with ESMTPSA id E61012A2D3E; Wed, 13 Jul 2011 14:39:14 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1310560755; bh=DwqvHiB7/mlMIQlvXXzXwiykMAtw4gdzjXcFUxkxqO4=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=gaa5d1CybHa4j1dI+krBaklqJ6Y9NIUG4HbesI0jmbBWa+PuW8FS0VJvnwJd0AsWc edpbTnF5p3Jfhq6LE2+V/II7FNj4+UmCgx+bJRl4nD9Zy6vPzT2tAVreggBlgBCWEO Yl40PdgUmI3l2ahW0c31hA9XhjvXdEUURIyu3ycQ= Message-ID: <4E1D91F2.7090109@nic.cz> Date: Wed, 13 Jul 2011 14:39:14 +0200 From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= User-Agent: Mozilla/5.0 (X11; Linux i686; rv:5.0) Gecko/20110627 Thunderbird/5.0 MIME-Version: 1.0 To: Paul Hoffman References: <4A953B0A-3910-4DEC-BE13-9B6F2E0815B2@kumari.net> <4E1C89B9.8030100@verisign.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: DANE WG Subject: Re: [dane] Opening issues... X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2011 12:39:21 -0000 On 12.7.2011 20:30, Paul Hoffman wrote: > On Jul 12, 2011, at 10:51 AM, Eric Osterweil wrote: > >> I think it would be quite valuable to talk about the serialization >> issue that you alluded to above. > > While the serializing DNSSEC thread is interesting, is it at all a > DANE issue? It feels much more like a TLS issue, since it answers the > question "how do I reduce latency in starting up TLS". I tend to agree (with chair-hat on) with Paul here. O. -- Ondřej Surý vedoucí výzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- From hallam@gmail.com Wed Jul 13 05:52:59 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EED021F855B for ; Wed, 13 Jul 2011 05:52:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.022 X-Spam-Level: X-Spam-Status: No, score=-3.022 tagged_above=-999 required=5 tests=[AWL=-0.324, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yFqOx+o1Jk9L for ; Wed, 13 Jul 2011 05:52:54 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id BD5FB21F84C7 for ; Wed, 13 Jul 2011 05:52:54 -0700 (PDT) Received: by gwb20 with SMTP id 20so2802239gwb.31 for ; Wed, 13 Jul 2011 05:52:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/UqeC+W7wgh6RZaVJ7wyNKSxXl0dxPOsgjcg+0MDHTM=; b=DqJQnwORBYpuXMPlLA7PHX24PGbZEBr2PX03GgU+V0bDU4nI5BFQgvx5CD8KgEWe6E kpIJroLpGrW/vx3eoJ5eB5JgJntDckOq8Jby5BWYtgj3IIdJjXuO0mX2Tnn3tgllgFrF jNH8vEj6IPf6hyMSdUZIIizhklliMzGErByCs= MIME-Version: 1.0 Received: by 10.101.145.12 with SMTP id x12mr1026724ann.168.1310561574185; Wed, 13 Jul 2011 05:52:54 -0700 (PDT) Received: by 10.100.93.12 with HTTP; Wed, 13 Jul 2011 05:52:53 -0700 (PDT) In-Reply-To: <4E1D91F2.7090109@nic.cz> References: <4A953B0A-3910-4DEC-BE13-9B6F2E0815B2@kumari.net> <4E1C89B9.8030100@verisign.com> <4E1D91F2.7090109@nic.cz> Date: Wed, 13 Jul 2011 08:52:53 -0400 Message-ID: From: Phillip Hallam-Baker To: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= Content-Type: multipart/alternative; boundary=0016e68fd02b15ec3604a7f2e5a8 Cc: Paul Hoffman , DANE WG Subject: Re: [dane] Opening issues... X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2011 12:52:59 -0000 --0016e68fd02b15ec3604a7f2e5a8 Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable Then lets shut DANE down completely and fold it into TLS. On Wed, Jul 13, 2011 at 8:39 AM, Ond=F8ej Sur=FD wrote= : > On 12.7.2011 20:30, Paul Hoffman wrote: > > On Jul 12, 2011, at 10:51 AM, Eric Osterweil wrote: > > > >> I think it would be quite valuable to talk about the serialization > >> issue that you alluded to above. > > > > While the serializing DNSSEC thread is interesting, is it at all a > > DANE issue? It feels much more like a TLS issue, since it answers the > > question "how do I reduce latency in starting up TLS". > > I tend to agree (with chair-hat on) with Paul here. > > O. > -- > Ond=F8ej Sur=FD > vedouc=ED v=FDzkumu/Head of R&D department > ------------------------------------------- > CZ.NIC, z.s.p.o. -- Laborato=F8e CZ.NIC > Americka 23, 120 00 Praha 2, Czech Republic > mailto:ondrej.sury@nic.cz http://nic.cz/ > tel:+420.222745110 fax:+420.222745112 > ------------------------------------------- > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > --=20 Website: http://hallambaker.com/ --0016e68fd02b15ec3604a7f2e5a8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Then lets shut DANE down completely and fold it into TLS.




On Wed, Jul 13, 20= 11 at 8:39 AM, Ond=C5=99ej Sur=C3=BD <ondrej.sury@nic.cz> wrote:
On 12.7.2011 20:30, Paul = Hoffman wrote:
> On Jul 12, 2011, at 10:51 AM, Eric Osterweil wrote:
>
>> I think it would be quite valuable to talk about the serialization=
>> issue that you alluded to above.
>
> While the serializing DNSSEC thread is interesting, is it at all a
> DANE issue? =C2=A0It feels much more like a TLS issue, since it answer= s the
> question "how do I reduce latency in starting up TLS".

I tend to agree (with chair-hat on) with Paul here.

O.
--
=C2=A0Ond=C5=99ej Sur=C3=BD
=C2=A0vedouc=C3=AD v=C3=BDzkumu/Head of R&D department
=C2=A0-------------------------------------------
=C2=A0CZ.NIC, z.s.p.o. =C2=A0 =C2=A0-- =C2=A0 =C2=A0Laborato=C5=99e CZ.NIC<= br> =C2=A0Americka 23, 120 00 Praha 2, Czech Republic
=C2=A0mailto:ondrej.sury@nic.cz = =C2=A0 =C2=A0http://nic.cz/
=C2=A0tel:+420.222= 745110 =C2=A0 =C2=A0 =C2=A0 fax:+420.222745112
=C2=A0-------------------------------------------
__________________________________= _____________
dane mailing list
dane@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/dane



--
Website: http://hallambaker.com/

--0016e68fd02b15ec3604a7f2e5a8-- From ondrej.sury@nic.cz Wed Jul 13 06:06:29 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F8D921F84EE for ; Wed, 13 Jul 2011 06:06:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RH5oCYxWUDFo for ; Wed, 13 Jul 2011 06:06:24 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 8DB1121F84E6 for ; Wed, 13 Jul 2011 06:01:58 -0700 (PDT) Received: from [IPv6:2001:1488:ac14:1400:224:e8ff:fea9:f617] (unknown [IPv6:2001:1488:ac14:1400:224:e8ff:fea9:f617]) by mail.nic.cz (Postfix) with ESMTPSA id AEC252A2D42; Wed, 13 Jul 2011 15:01:57 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1310562117; bh=0qIOh32VlAZEx7Xc4gY9IjGZhdl4Y0/BLqmDxOQJO1M=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=QY3Kq8mHB26QHk2EDq6HmqK7KEhRqf86vcSRpcJXNHJZEhAKgaJiCiNyqUYUZ/FoT BYspYlHg0LbnDMuST7MoFp5dzPCB3pZgG3sBrhzeMZhVOYN5I/tIB2GD62vrld8DEp Rgs4W9YsqkKRHWKiXSoz21vbj8tGn7QyvkOrJNYo= Message-ID: <4E1D9745.4070802@nic.cz> Date: Wed, 13 Jul 2011 15:01:57 +0200 From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= User-Agent: Mozilla/5.0 (X11; Linux i686; rv:5.0) Gecko/20110627 Thunderbird/5.0 MIME-Version: 1.0 To: Phillip Hallam-Baker References: <4A953B0A-3910-4DEC-BE13-9B6F2E0815B2@kumari.net> <4E1C89B9.8030100@verisign.com> <4E1D91F2.7090109@nic.cz> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: Paul Hoffman , DANE WG Subject: Re: [dane] Opening issues... X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2011 13:06:29 -0000 On 13.7.2011 14:52, Phillip Hallam-Baker wrote: > Then lets shut DANE down completely and fold it into TLS. Please don't do that. It's not very constructive. The serializing DNSSEC into TLS is interesting, but I don't think it fits into our charter. We could always recharter if the working group wants it. We always have that option. O. > On Wed, Jul 13, 2011 at 8:39 AM, Ondřej Surý wrote: > >> On 12.7.2011 20:30, Paul Hoffman wrote: >>> On Jul 12, 2011, at 10:51 AM, Eric Osterweil wrote: >>> >>>> I think it would be quite valuable to talk about the serialization >>>> issue that you alluded to above. >>> >>> While the serializing DNSSEC thread is interesting, is it at all a >>> DANE issue? It feels much more like a TLS issue, since it answers the >>> question "how do I reduce latency in starting up TLS". >> >> I tend to agree (with chair-hat on) with Paul here. >> >> O. >> -- >> Ondřej Surý >> vedoucí výzkumu/Head of R&D department >> ------------------------------------------- >> CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC >> Americka 23, 120 00 Praha 2, Czech Republic >> mailto:ondrej.sury@nic.cz http://nic.cz/ >> tel:+420.222745110 fax:+420.222745112 >> ------------------------------------------- >> _______________________________________________ >> dane mailing list >> dane@ietf.org >> https://www.ietf.org/mailman/listinfo/dane >> > > > -- Ondřej Surý vedoucí výzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- From hallam@gmail.com Wed Jul 13 06:37:44 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7DE711E8083 for ; Wed, 13 Jul 2011 06:37:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.393 X-Spam-Level: X-Spam-Status: No, score=-3.393 tagged_above=-999 required=5 tests=[AWL=-0.095, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1pW7jiTr9J4V for ; Wed, 13 Jul 2011 06:37:40 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 44FF221F8880 for ; Wed, 13 Jul 2011 06:37:40 -0700 (PDT) Received: by yxp4 with SMTP id 4so2975822yxp.31 for ; Wed, 13 Jul 2011 06:37:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=paO0c0OoxodOpi1VwS2BgX2OkmMzW4yMTsxxu+iF0Do=; b=IdfdgKIXjoWAt7KaaDA7hP1sJ23WiLuCsjqC8ZS+zcnc9o9ReRWHay3Ua3B4A1q/BS I/U5lkZsxmr7qltYVcqYceKwMNvbtp4gOA0JyloBE9YJXJhd13mBXdDPPjGiYp2LnrTP oQsZ3u9NawDBLfLyuI3AFPxiXE9mbIMTnUgrU= MIME-Version: 1.0 Received: by 10.101.168.32 with SMTP id v32mr1078984ano.36.1310564259722; Wed, 13 Jul 2011 06:37:39 -0700 (PDT) Received: by 10.100.93.12 with HTTP; Wed, 13 Jul 2011 06:37:39 -0700 (PDT) In-Reply-To: <4E1D9745.4070802@nic.cz> References: <4A953B0A-3910-4DEC-BE13-9B6F2E0815B2@kumari.net> <4E1C89B9.8030100@verisign.com> <4E1D91F2.7090109@nic.cz> <4E1D9745.4070802@nic.cz> Date: Wed, 13 Jul 2011 09:37:39 -0400 Message-ID: From: Phillip Hallam-Baker To: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= Content-Type: multipart/alternative; boundary=001636c5969c27f46f04a7f38523 Cc: Paul Hoffman , DANE WG Subject: Re: [dane] Opening issues... X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2011 13:37:44 -0000 --001636c5969c27f46f04a7f38523 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Jul 13, 2011 at 9:01 AM, Ond=C5=99ej Sur=C3=BD = wrote: > On 13.7.2011 14:52, Phillip Hallam-Baker wrote: > > Then lets shut DANE down completely and fold it into TLS. > > Please don't do that. It's not very constructive. > > The serializing DNSSEC into TLS is interesting, but I don't think it > fits into our charter. > I look at a WG as being directed to solve a problem Your view seems to be that a WG is defined by the means of addressing that problem. That second approach is fine if you have a problem that can be addressed cleanly in the current architecture. Jabber for example is pretty straightforward as it sits on existing platforms and has minimal dependencies. I don't think that approach works at all well here where there is a trivial problem (putting keys into the DNS) and a very hard problem (making use of those keys practical under real world constraints). From the start this group has only wanted to look at the trivial problem. Attempts to address the practical problems have been rejected as 'out of scope'. When I have a hard problem and a trivial one I want to be able to use whatever flexibility I have in solving the trivial one to give me room to maneuver on the hard one. I don't think it is at all helpful for a clique to insist that it is only going to solve the trivial problem and that they are going to ignore the practical problem completely. Adam has actual measurements to back up his claim that support for unknown records is absent in a prohibitively large number of places. The only thing that surprises me about his numbers is that I expected them to be much worse. That is possibly an artifact of doing the measurements on Linux. We could always recharter if the working group wants it. We always have > that option. No, you have that option as long as the ADs decide that you have it. The only reason that you would need to recharter to look at the DNSSEC chai= n would be if your AD was telling you that was necessary. And if the AD is telling you that they are likely telling you 'don't do it' anyway. --=20 Website: http://hallambaker.com/ --001636c5969c27f46f04a7f38523 Content-Type: text/html; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable

On Wed, Jul 13, 2011 at 9:01 AM, Ond=F8e= j Sur=FD <ondrej= .sury@nic.cz> wrote:
On 13.7.2011 14:52, Phillip Hallam-Baker wrote:
> Then lets shut DANE down completely and fold it into TLS.

Please don't do that. =A0It's not very constructive.

The serializing DNSSEC into TLS is interesting, but I don't think it fits into our charter.

I look at a WG a= s being directed to solve a problem

Your view seem= s to be that a WG is defined by the means of addressing that problem.


That second approach is fine if you have= a problem that can be addressed cleanly in the current architecture. Jabbe= r for example is pretty straightforward as it sits on existing platforms an= d has minimal dependencies.

I don't think that approach works at all well here = where there is a trivial problem (putting keys into the DNS) and a very har= d problem (making use of those keys practical under real world constraints)= . From the start this group has only wanted to look at the trivial problem.= Attempts to address the practical problems have been rejected as 'out = of scope'.

When I have a hard problem and a trivial one I want to = be able to use whatever flexibility I have in solving the trivial one to gi= ve me room to maneuver on the hard one.

I don'= t think it is at all helpful for a clique to insist that it is only going t= o solve the trivial problem and that they are going to ignore the practical= problem completely.


Adam has actual measurements to back up = his claim that support for unknown records is absent in a prohibitively lar= ge number of places. The only thing that surprises me about his numbers is = that I expected them to be much worse. That is possibly an artifact of doin= g the measurements on Linux.


We could always recharter if the working group wants it. =A0We always have<= br> that option.

No, you have that option as lo= ng as the ADs decide that you have it.

The only re= ason that you would need to recharter to look at the DNSSEC chain would be = if your AD was telling you that was necessary. And if the AD is telling you= that they are likely telling you 'don't do it' anyway.

=A0
--
Website: http://hallambaker.com/

--001636c5969c27f46f04a7f38523-- From nweaver@icsi.berkeley.edu Wed Jul 13 07:24:50 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF26221F87FA for ; Wed, 13 Jul 2011 07:24:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8rR-eBSZrYFt for ; Wed, 13 Jul 2011 07:24:46 -0700 (PDT) Received: from taffy.ICSI.Berkeley.EDU (taffy.ICSI.Berkeley.EDU [192.150.187.26]) by ietfa.amsl.com (Postfix) with ESMTP id C393A21F86E9 for ; Wed, 13 Jul 2011 07:24:46 -0700 (PDT) Received: from gala.icir.org (gala.ICIR.org [192.150.187.49]) (Authenticated sender: nweaver) by taffy.ICSI.Berkeley.EDU (Postfix) with ESMTP id E5B6936A37A; Wed, 13 Jul 2011 07:24:45 -0700 (PDT) References: <4A953B0A-3910-4DEC-BE13-9B6F2E0815B2@kumari.net> <4E1C89B9.8030100@verisign.com> <4E1D91F2.7090109@nic.cz> <4E1D9745.4070802@nic.cz> In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii Message-Id: Content-Transfer-Encoding: quoted-printable From: Nicholas Weaver Date: Wed, 13 Jul 2011 07:24:45 -0700 To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1084) Cc: Paul Hoffman , DANE WG Subject: Re: [dane] Opening issues... X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2011 14:24:50 -0000 On Jul 13, 2011, at 6:37 AM, Phillip Hallam-Baker wrote: > Adam has actual measurements to back up his claim that support for = unknown records is absent in a prohibitively large number of places. The = only thing that surprises me about his numbers is that I expected them = to be much worse. That is possibly an artifact of doing the measurements = on Linux. Its better than you think, but not great, when measured through = Netalyzr. = http://www.icir.org/christian/publications/2011-satin-netalyzr.pdf As importantly, its basically the same as TXT records, and its the same = ones which fail. But more importantly, although we don't have the code to test for it = yet, I suspect that the same set of resolvers that can't handle unknown = resource records is the same set that strips/chokes on DNSSEC records so = you can't get DS records, NSEC/NSEC3, etc... Client resolvers for DNSSEC MUST validate locally (the recursive = resolver can't be trusted, full stop), and MUST be willing to bypass the = recursive resolver infrastructure (the recursive resolver may fail to = pass DNSSEC-related records properly). As such, new RRTYPEs work just fine most of the time from the recursive = resolver, and when they don't, its highly unlikely that the client can = get the DNSSEC records to validate ANYTHING from the configured = resolver. =20 So new RRTYPEs should not be viewed as a particular problem for = DNSSEC-based DNS usages. From hallam@gmail.com Wed Jul 13 07:48:20 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 804D011E80E5 for ; Wed, 13 Jul 2011 07:48:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.44 X-Spam-Level: X-Spam-Status: No, score=-3.44 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nXk2hkor7Uv2 for ; Wed, 13 Jul 2011 07:48:15 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id A242811E8082 for ; Wed, 13 Jul 2011 07:48:15 -0700 (PDT) Received: by gwb20 with SMTP id 20so2861594gwb.31 for ; Wed, 13 Jul 2011 07:48:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CIK+GXABufInhJhkZgJOo1aGCbWkvYZkzhE0D1Era+c=; b=yFU93gEM7vYW/kUpy+CmXodqYRCjM4LQg1PtjWndljnQflCvOd4Fa0+a69GJqEXWIl tJp7JVDKvw6Yfr6ZP+6AHfV/N8JErJF6/3r6nIVkbCprlTrLsAX3DkRjAivA1rNq0lmG PIlSiWbS4RLzfcEsJoOUBdJWxSvBv+qpSff2E= MIME-Version: 1.0 Received: by 10.101.168.5 with SMTP id v5mr1172227ano.14.1310568494976; Wed, 13 Jul 2011 07:48:14 -0700 (PDT) Received: by 10.100.93.12 with HTTP; Wed, 13 Jul 2011 07:48:14 -0700 (PDT) In-Reply-To: References: <4A953B0A-3910-4DEC-BE13-9B6F2E0815B2@kumari.net> <4E1C89B9.8030100@verisign.com> <4E1D91F2.7090109@nic.cz> <4E1D9745.4070802@nic.cz> Date: Wed, 13 Jul 2011 10:48:14 -0400 Message-ID: From: Phillip Hallam-Baker To: Nicholas Weaver Content-Type: multipart/alternative; boundary=0016368e35a498cf8904a7f481bb Cc: Paul Hoffman , DANE WG Subject: Re: [dane] Opening issues... X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2011 14:48:20 -0000 --0016368e35a498cf8904a7f481bb Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jul 13, 2011 at 10:24 AM, Nicholas Weaver wrote: > > On Jul 13, 2011, at 6:37 AM, Phillip Hallam-Baker wrote: > > Adam has actual measurements to back up his claim that support for > unknown records is absent in a prohibitively large number of places. The > only thing that surprises me about his numbers is that I expected them to be > much worse. That is possibly an artifact of doing the measurements on Linux. > > Its better than you think, but not great, when measured through Netalyzr. > http://www.icir.org/christian/publications/2011-satin-netalyzr.pdf Systematic bias in the measurement approach is going to be an issue. The range of browsers touching ICSI etc is going to be a biased set. I prefer a direct measurement. > As importantly, its basically the same as TXT records, and its the same > ones which fail. > > But more importantly, although we don't have the code to test for it yet, I > suspect that the same set of resolvers that can't handle unknown resource > records is the same set that strips/chokes on DNSSEC records so you can't > get DS records, NSEC/NSEC3, etc... > I agree. But that is not the issue that concerns me. If DANE is going to be of use it has to work reliably when it is deployed. That means having a story for how to make it work close to 100% of the time. We have the following options: 1) Just use DANE records in DNS (Expect 98% success rate) 2a) Use DNSSEC chain in long life cert (Expect 100% success rate but chain data supporting cert will expire before cert does) 2b) Use DNSSEC chain in short life cert (Expect 100% success rate with new browser but now an old browser will be pestered to re-install the self signed cert every visit) 3) Use DNSSEC chain in OCSP response 3a) Expect 100% success if OCSP response is stapled 3b) Expect 99% success if OCSP response is from separate server. 4) Use DNS information if available, otherwise attempt to pull OCSP response as backup. Expect 99.99% success rate > Client resolvers for DNSSEC MUST validate locally (the recursive resolver > can't be trusted, full stop), and MUST be willing to bypass the recursive > resolver infrastructure (the recursive resolver may fail to pass > DNSSEC-related records properly). > Where does it say that in the DNSSEC specs? The delegated PKI model is very well established and is in use in environments with very high security requirements. In control systems design we have to be able to secure communications with devices that cannot perform public key at all. Odd as it may seem, it is quite possible to have a device like a $1 PIC controller using TLS without any onboard public key capability. [Ob Disclaimer: author holds IP in this area, no license granted, etc.] In the larger enterprise the PKI parameters are going to be centrally controlled in any case. The security policy that matters is the one for the site and not what the individual user might think should be the policy. In that case it is much more efficient to make the decision centrally and tell the client what to do. The client is not going to receive any data direct from an untrusted source. -- Website: http://hallambaker.com/ --0016368e35a498cf8904a7f481bb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Jul 13, 2011 at 10:24 AM, Nichol= as Weaver <nweaver@icsi.berkeley.edu> wrote:

On Jul 13, 2011, at 6:37 AM, Phillip Hallam-Baker wrote:
> Adam has actual measurements to back up his claim that support for unk= nown records is absent in a prohibitively large number of places. The only = thing that surprises me about his numbers is that I expected them to be muc= h worse. That is possibly an artifact of doing the measurements on Linux.
Its better than you think, but not great, when measured through Netal= yzr. =A0http://www.icir.org/christian/publications/20= 11-satin-netalyzr.pdf

Systematic bias in the measurement approach is going to= be an issue. The range of browsers touching ICSI etc is going to be a bias= ed set.

I prefer a direct measurement.

=A0
As importantly, its= basically the same as TXT records, and its the same ones which fail.

But more importantly, although we don't have the code to test for it ye= t, I suspect that the same set of resolvers that can't handle unknown r= esource records is the same set that strips/chokes on DNSSEC records so you= can't get DS records, NSEC/NSEC3, etc...

I agree. But that is not the issue that co= ncerns me.

If DANE is going to be of use it has to= work reliably when it is deployed. That means having a story for how to ma= ke it work close to 100% of the time.

We have the following options:

1) Just use DANE records in DNS =A0(Expect 98% success rate)
2a) Use DNSSEC chain in long life cert (Expect 100% success rat= e but chain data supporting cert will expire before cert does)

2b) Use DNSSEC chain in short life cert (Expect 100% su= ccess rate with new browser but now an old browser will be pestered to re-i= nstall the self signed cert every visit)

3) Use DN= SSEC chain in OCSP response

3a) Expect 100% success if OCSP response is stapled

3b) Expect 99% success if OCSP response is from separ= ate server.

4) Use DNS information if available, o= therwise attempt to pull OCSP response as backup.

Expect 99.99% success rate

=A0
Client resolvers for DNSSEC MUST validate locally (the recursive resolver c= an't be trusted, full stop), and MUST be willing to bypass the recursiv= e resolver infrastructure (the recursive resolver may fail to pass DNSSEC-r= elated records properly).

Where does it say that in the DNSSEC specs= ?

The delegated PKI model is very well established= and is in use in environments with very high security requirements.

In control systems design we have to be able to secure = communications with devices that cannot perform public key at all. Odd as i= t may seem, it is quite possible to have a device like a $1 PIC controller = using TLS without any onboard public key capability.

[Ob Disclaimer: author holds IP in this area, no licens= e granted, etc.]


In the larger ent= erprise the PKI parameters are going to be centrally controlled in any case= . The security policy that matters is the one for the site and not what the= individual user might think should be the policy.=A0

In that case it is much more efficient to make the decision = centrally and tell the client what to do. The client is not going to receiv= e any data direct from an untrusted source.


--0016368e35a498cf8904a7f481bb-- From eosterweil@verisign.com Wed Jul 13 07:51:09 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 556B611E8082 for ; Wed, 13 Jul 2011 07:51:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.459 X-Spam-Level: X-Spam-Status: No, score=-6.459 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p2QuKAX7QWSC for ; Wed, 13 Jul 2011 07:51:05 -0700 (PDT) Received: from exprod6og112.obsmtp.com (exprod6og112.obsmtp.com [64.18.1.29]) by ietfa.amsl.com (Postfix) with ESMTP id B0A0811E80FA for ; Wed, 13 Jul 2011 07:51:02 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob112.postini.com ([64.18.5.12]) with SMTP ID DSNKTh2w0akdZ8K0sZN0jz/tL4IBaA374Min@postini.com; Wed, 13 Jul 2011 07:51:02 PDT Received: from dul1wnexcn01.vcorp.ad.vrsn.com (dul1wnexcn01.vcorp.ad.vrsn.com [10.170.12.138]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id p6DEouJY012795; Wed, 13 Jul 2011 10:50:56 -0400 Received: from dul1eosterwe-m1.vcorp.ad.vrsn.com ([10.131.30.110]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 13 Jul 2011 10:50:56 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Eric Osterweil In-Reply-To: Date: Wed, 13 Jul 2011 10:46:28 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4A953B0A-3910-4DEC-BE13-9B6F2E0815B2@kumari.net> <4E1C89B9.8030100@verisign.com> <4E1D91F2.7090109@nic.cz> <4E1D9745.4070802@nic.cz> To: Nicholas Weaver X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 13 Jul 2011 14:50:56.0383 (UTC) FILETIME=[456B38F0:01CC416C] Cc: Paul Hoffman , DANE WG Subject: Re: [dane] Opening issues... X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2011 14:51:09 -0000 On Jul 13, 2011, at 10:24 AM, Nicholas Weaver wrote: >=20 > On Jul 13, 2011, at 6:37 AM, Phillip Hallam-Baker wrote: >> Adam has actual measurements to back up his claim that support for = unknown records is absent in a prohibitively large number of places. The = only thing that surprises me about his numbers is that I expected them = to be much worse. That is possibly an artifact of doing the measurements = on Linux. >=20 > Its better than you think, but not great, when measured through = Netalyzr. = http://www.icir.org/christian/publications/2011-satin-netalyzr.pdf >=20 > As importantly, its basically the same as TXT records, and its the = same ones which fail. >=20 > But more importantly, although we don't have the code to test for it = yet, I suspect that the same set of resolvers that can't handle unknown = resource records is the same set that strips/chokes on DNSSEC records so = you can't get DS records, NSEC/NSEC3, etc... >=20 >=20 > Client resolvers for DNSSEC MUST validate locally (the recursive = resolver can't be trusted, full stop), and MUST be willing to bypass the = recursive resolver infrastructure (the recursive resolver may fail to = pass DNSSEC-related records properly). This "full stop" issue may, or may not, be true but one thing I think = deserves a "full stop" is that embedding part of DNSSEC's logic in a = place that is _not_ DNS suffers a lot of architectural and operational = complexity. Trusting resolvers is one issue, putting data in a = different protocols and trying to cobble DNSSEC-like-validation into = remote protocols is the issue I think needs attention. We've seen a lot = of one-off DNS resolver implementations and I would argue a lot of = _those_ are responsible for the brokeness that you have measured. Thus, = let's be very weary of adding new points of brokeness that report to = support DNSSEC-like semantics and then fail to keep up w/ the protocol's = evolution. Eric >=20 >=20 > As such, new RRTYPEs work just fine most of the time from the = recursive resolver, and when they don't, its highly unlikely that the = client can get the DNSSEC records to validate ANYTHING from the = configured resolver. =20 >=20 > So new RRTYPEs should not be viewed as a particular problem for = DNSSEC-based DNS usages. >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From eosterweil@verisign.com Wed Jul 13 07:51:45 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DBD911E80FB for ; Wed, 13 Jul 2011 07:51:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.459 X-Spam-Level: X-Spam-Status: No, score=-6.459 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZBb2mK2lu-c9 for ; Wed, 13 Jul 2011 07:51:45 -0700 (PDT) Received: from exprod6og112.obsmtp.com (exprod6og112.obsmtp.com [64.18.1.29]) by ietfa.amsl.com (Postfix) with ESMTP id E014A11E80FA for ; Wed, 13 Jul 2011 07:51:43 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob112.postini.com ([64.18.5.12]) with SMTP ID DSNKTh2w/KTcdbKmnbyB9QziHHRUfwrIx0kW@postini.com; Wed, 13 Jul 2011 07:51:44 PDT Received: from dul1wnexcn01.vcorp.ad.vrsn.com (dul1wnexcn01.vcorp.ad.vrsn.com [10.170.12.138]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id p6DEpdEu012849; Wed, 13 Jul 2011 10:51:39 -0400 Received: from dul1eosterwe-m1.vcorp.ad.vrsn.com ([10.131.30.110]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 13 Jul 2011 10:51:39 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Eric Osterweil In-Reply-To: Date: Wed, 13 Jul 2011 10:51:39 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <7C5C375F-3C8B-4A59-9E1B-0CF6A63D8E9F@verisign.com> References: <4A953B0A-3910-4DEC-BE13-9B6F2E0815B2@kumari.net> <4E1C89B9.8030100@verisign.com> <4E1D91F2.7090109@nic.cz> <4E1D9745.4070802@nic.cz> To: Nicholas Weaver X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 13 Jul 2011 14:51:39.0149 (UTC) FILETIME=[5EE8CBD0:01CC416C] Cc: Paul Hoffman , DANE WG Subject: Re: [dane] Opening issues... X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2011 14:51:45 -0000 On Jul 13, 2011, at 10:24 AM, Nicholas Weaver wrote: >=20 > On Jul 13, 2011, at 6:37 AM, Phillip Hallam-Baker wrote: >> Adam has actual measurements to back up his claim that support for = unknown records is absent in a prohibitively large number of places. The = only thing that surprises me about his numbers is that I expected them = to be much worse. That is possibly an artifact of doing the measurements = on Linux. >=20 > Its better than you think, but not great, when measured through = Netalyzr. = http://www.icir.org/christian/publications/2011-satin-netalyzr.pdf >=20 > As importantly, its basically the same as TXT records, and its the = same ones which fail. >=20 > But more importantly, although we don't have the code to test for it = yet, I suspect that the same set of resolvers that can't handle unknown = resource records is the same set that strips/chokes on DNSSEC records so = you can't get DS records, NSEC/NSEC3, etc... >=20 >=20 > Client resolvers for DNSSEC MUST validate locally (the recursive = resolver can't be trusted, full stop), and MUST be willing to bypass the = recursive resolver infrastructure (the recursive resolver may fail to = pass DNSSEC-related records properly). This "full stop" issue may, or may not, be true but one thing I think = deserves a "full stop" is that embedding part of DNSSEC's logic in a = place that is _not_ DNS suffers a lot of architectural and operational = complexity. Trusting resolvers is one issue, putting data in a = different protocols and trying to cobble DNSSEC-like-validation into = remote protocols is the issue I think needs attention. We've seen a lot = of one-off DNS resolver implementations and I would argue a lot of = _those_ are responsible for the brokeness that you have measured. Thus, = let's be very weary of adding new points of brokeness that report to = support DNSSEC-like semantics and then fail to keep up w/ the protocol's = evolution. Eric >=20 >=20 > As such, new RRTYPEs work just fine most of the time from the = recursive resolver, and when they don't, its highly unlikely that the = client can get the DNSSEC records to validate ANYTHING from the = configured resolver. =20 >=20 > So new RRTYPEs should not be viewed as a particular problem for = DNSSEC-based DNS usages. >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From hallam@gmail.com Wed Jul 13 08:50:22 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A64111E813F for ; Wed, 13 Jul 2011 08:50:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.24 X-Spam-Level: X-Spam-Status: No, score=-3.24 tagged_above=-999 required=5 tests=[AWL=-0.242, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id epxWJJsGoBMQ for ; Wed, 13 Jul 2011 08:50:17 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id EA24311E8132 for ; Wed, 13 Jul 2011 08:50:16 -0700 (PDT) Received: by yxp4 with SMTP id 4so3057209yxp.31 for ; Wed, 13 Jul 2011 08:50:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2U89It/xoCHTGvICXaT8MKnXC7rtry1BApmaNF9XdgE=; b=C46AZiOPMUkhI01M5hLLtzlau0bl3stL1HD6XknHAlP2kNeLYh/YKgpLBZ0FCPmX8d NZgqmZIzgrjH9GmQ813bUKeh+Fhb5Tzb1GmF6URCCdB4hVaGl+S5hmTojf4xTvG75kam zbBZjfx3F+AEmeCMaWSyciQiLGn/24EmeqeEs= MIME-Version: 1.0 Received: by 10.101.179.7 with SMTP id g7mr1212367anp.102.1310572216403; Wed, 13 Jul 2011 08:50:16 -0700 (PDT) Received: by 10.100.93.12 with HTTP; Wed, 13 Jul 2011 08:50:16 -0700 (PDT) In-Reply-To: References: <4A953B0A-3910-4DEC-BE13-9B6F2E0815B2@kumari.net> <4E1C89B9.8030100@verisign.com> <4E1D91F2.7090109@nic.cz> <4E1D9745.4070802@nic.cz> Date: Wed, 13 Jul 2011 11:50:16 -0400 Message-ID: From: Phillip Hallam-Baker To: Eric Osterweil Content-Type: multipart/alternative; boundary=001636c926646947eb04a7f55f98 Cc: Paul Hoffman , DANE WG Subject: Re: [dane] Opening issues... X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2011 15:50:22 -0000 --001636c926646947eb04a7f55f98 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jul 13, 2011 at 10:46 AM, Eric Osterweil wrote: > > On Jul 13, 2011, at 10:24 AM, Nicholas Weaver wrote: > > > > > On Jul 13, 2011, at 6:37 AM, Phillip Hallam-Baker wrote: > >> Adam has actual measurements to back up his claim that support for > unknown records is absent in a prohibitively large number of places. The > only thing that surprises me about his numbers is that I expected them to be > much worse. That is possibly an artifact of doing the measurements on Linux. > > > > Its better than you think, but not great, when measured through Netalyzr. > http://www.icir.org/christian/publications/2011-satin-netalyzr.pdf > > > > As importantly, its basically the same as TXT records, and its the same > ones which fail. > > > > But more importantly, although we don't have the code to test for it yet, > I suspect that the same set of resolvers that can't handle unknown resource > records is the same set that strips/chokes on DNSSEC records so you can't > get DS records, NSEC/NSEC3, etc... > > > > > > Client resolvers for DNSSEC MUST validate locally (the recursive resolver > can't be trusted, full stop), and MUST be willing to bypass the recursive > resolver infrastructure (the recursive resolver may fail to pass > DNSSEC-related records properly). > > This "full stop" issue may, or may not, be true but one thing I think > deserves a "full stop" is that embedding part of DNSSEC's logic in a place > that is _not_ DNS suffers a lot of architectural and operational complexity. > Trusting resolvers is one issue, putting data in a different protocols and > trying to cobble DNSSEC-like-validation into remote protocols is the issue I > think needs attention. We've seen a lot of one-off DNS resolver > implementations and I would argue a lot of _those_ are responsible for the > brokeness that you have measured. Thus, let's be very weary of adding new > points of brokeness that report to support DNSSEC-like semantics and then > fail to keep up w/ the protocol's evolution. We saw the same sort of thing with deployment of SET, or rather the non-deployment as it turned out. Certain deployment decisions by certain parties meant that we only got one chance to deploy SET. By the time we had real world experience and knew the bits that needed fixing we were unable to make changes there or anywhere else. PKI systems are inherently complex because they are the interface to the trust infrastructure of the real world and the real world is complex. Rather than having people quote what they imagine the end to end principle to be, I would encourage them to read what David Clark actually wrote. It is an argument about complexity and in particular the best places to manage that complexity. I don;t want to be speaking for David here, but he is not a rigid ideologue by any stretch of the imagination. The end to end argument is an argument about practicality and it applies to a specific situation 20 years ago. It was never intended to be stated as an absolute truth. It is not an argument about security either. 'End to end' security predated the Internet and was and is acknowledged to be a form of security that is desirable in an abstract sense but frequently impractical. One Time Pads provide provably unbreakable security, Quantum Cryptography is theoretically unbreakable, but systems built around those schemes have turned out to fail in the real world because it is just not practical to build and use them in a perfect way. At the time the paper was written a computer system capable of running IP protocols was $200K and up. Micros existed but they were limited to 64Kb of memory, not really what you want to be writing an IP stack in. The telephone system has the complexity in the middle because it is a 100 year old system and the middle is the only place that could be easily changed. It was also at the time the design was chosen a system operated by one single entity. The 'end to end' argument is really an argument that you don't want to put complexity into the inter-network. At the time the client endpoint was the only other place it could go. For the past 10-15 years we have seen the difficulty of making changes at the client increase to the point that it is very difficult to achieve. The DNS resolver is my preferred point to put DNSSEC processing because it means that I can upgrade my DNSSEC processing by upgrading that one single piece of infrastructure. That means that I have to have a secure means of communicating with my trusted resolver, but that is a solvable problem (e.g. DPLS). It is one thing to say that we will not address issues like DPLS and chains in certs or OCSP, quite another to state that we will write a spec that insists that the only valid deployment is one that is totally impractical. The only valid requirement for DANE is that the DNSSEC records MUST have been validated in a trustworthy fashion. Going beyond that is ideology. Security reacts really badly to ideology. -- Website: http://hallambaker.com/ --001636c926646947eb04a7f55f98 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Jul 13, 2011 at 10:46 AM, Eric Osterweil <eosterweil@verisign.com> wrote:

On Jul 13, 2011, at 10:24 AM, Nicholas Weaver wrote:

>
> On Jul 13, 2011, at 6:37 AM, Phillip Hallam-Baker wrote:
>> Adam has actual measurements to back up his claim that support for= unknown records is absent in a prohibitively large number of places. The o= nly thing that surprises me about his numbers is that I expected them to be= much worse. That is possibly an artifact of doing the measurements on Linu= x.
>
> Its better than you think, but not great, when measured through Netaly= zr. =A0http://www.icir.org/christian/publications/201= 1-satin-netalyzr.pdf
>
> As importantly, its basically the same as TXT records, and its the sam= e ones which fail.
>
> But more importantly, although we don't have the code to test for = it yet, I suspect that the same set of resolvers that can't handle unkn= own resource records is the same set that strips/chokes on DNSSEC records s= o you can't get DS records, NSEC/NSEC3, etc...
>
>
> Client resolvers for DNSSEC MUST validate locally (the recursive resol= ver can't be trusted, full stop), and MUST be willing to bypass the rec= ursive resolver infrastructure (the recursive resolver may fail to pass DNS= SEC-related records properly).

This "full stop" issue may, or may not, be true but one thi= ng I think deserves a "full stop" is that embedding part of DNSSE= C's logic in a place that is _not_ DNS suffers a lot of architectural a= nd operational complexity. =A0Trusting resolvers is one issue, putting data= in a different protocols and trying to cobble DNSSEC-like-validation into = remote protocols is the issue I think needs attention. =A0We've seen a = lot of one-off DNS resolver implementations and I would argue a lot of _tho= se_ are responsible for the brokeness that you have measured. =A0Thus, let&= #39;s be very weary of adding new points of brokeness that report to suppor= t DNSSEC-like semantics and then fail to keep up w/ the protocol's evol= ution.

We saw the same sort of thing with deployment of SET, o= r rather the non-deployment as it turned out.

Cert= ain deployment decisions by certain parties meant that we only got one chan= ce to deploy SET. By the time we had real world experience and knew the bit= s that needed fixing we were unable to make changes there or anywhere else.=


PKI systems are inherently complex becau= se they are the interface to the trust infrastructure of the real world and= the real world is complex.

Rather than having peo= ple quote what they imagine the end to end principle to be, I would encoura= ge them to read what David Clark actually wrote. It is an argument about co= mplexity and in particular the best places to manage that complexity.=A0

I don;t want to be speaking for David here, but he is n= ot a rigid ideologue by any stretch of the imagination. The end to end argu= ment is an argument about practicality and it applies to a specific situati= on 20 years ago. It was never intended to be stated as an absolute truth.

It is not an argument about security either. 'End t= o end' security predated the Internet and was and is acknowledged to be= a form of security that is desirable in an abstract sense but frequently i= mpractical. One Time Pads provide provably unbreakable security, Quantum Cr= yptography is theoretically unbreakable, but systems built around those sch= emes have turned out to fail in the real world because it is just not pract= ical to build and use them in a perfect way.


At the time the paper was written a comp= uter system capable of running IP protocols was $200K and up. Micros existe= d but they were limited to 64Kb of memory, not really what you want to be w= riting an IP stack in.

The telephone system has the complexity in the middle b= ecause it is a 100 year old system and the middle is the only place that co= uld be easily changed. It was also at the time the design was chosen a syst= em operated by one single entity.


The 'end to end' argument is rea= lly an argument that you don't want to put complexity into the inter-ne= twork. At the time the client endpoint was the only other place it could go= . For the past 10-15 years we have seen the difficulty of making changes at= the client increase to the point that it is very difficult to achieve.=A0<= /div>

The DNS resolver is my preferred point to put DNSSEC pr= ocessing because it means that I can upgrade my DNSSEC processing by upgrad= ing that one single piece of infrastructure. That means that I have to have= a secure means of communicating with my trusted resolver, but that is a so= lvable problem (e.g. DPLS).


It is one thing to say that we will not = address issues like DPLS and chains in certs or OCSP, quite another to stat= e that we will write a spec that insists that the only valid deployment is = one that is totally impractical.

The only valid requirement for DANE is that the DNSSEC = records MUST have been validated in a trustworthy fashion. Going beyond tha= t is ideology. Security reacts really badly to ideology.
=A0
--
Website: http://hallambake= r.com/

--001636c926646947eb04a7f55f98-- From eosterweil@verisign.com Wed Jul 13 09:11:46 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57E5421F8A30 for ; Wed, 13 Jul 2011 09:11:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.166 X-Spam-Level: X-Spam-Status: No, score=-6.166 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HuosKmkBm4uA for ; Wed, 13 Jul 2011 09:11:45 -0700 (PDT) Received: from exprod6og108.obsmtp.com (exprod6og108.obsmtp.com [64.18.1.21]) by ietfa.amsl.com (Postfix) with ESMTP id AF57C21F8A35 for ; Wed, 13 Jul 2011 09:11:44 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob108.postini.com ([64.18.5.12]) with SMTP ID DSNKTh3DvOsLjkIeIVK1bBSFsLv+Vi4nP8bB@postini.com; Wed, 13 Jul 2011 09:11:44 PDT Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id p6DGBdGw008218; Wed, 13 Jul 2011 12:11:39 -0400 Received: from dul1eosterwe-m1.vcorp.ad.vrsn.com ([10.131.30.110]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 13 Jul 2011 12:11:38 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Eric Osterweil In-Reply-To: Date: Wed, 13 Jul 2011 12:11:33 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4A953B0A-3910-4DEC-BE13-9B6F2E0815B2@kumari.net> <4E1C89B9.8030100@verisign.com> <4E1D91F2.7090109@nic.cz> <4E1D9745.4070802@nic.cz> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 13 Jul 2011 16:11:38.0667 (UTC) FILETIME=[8BA51FB0:01CC4177] Cc: Paul Hoffman , DANE WG Subject: Re: [dane] Opening issues... X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2011 16:11:46 -0000 I'm not sure who brought up the e2e principle here (before you Phil), = but I don't think it is pertinent (oh, btw, I suspect a non-negligible = number of us have read that paper). In fact, I can't quite tell how = your argument below is congruent with your earlier arguments. If you = want a deployed resolver that you can control, great. I didn't see = anyone tell you to (or not to) have that. It simply wasn't a position = on this thread.=20 Further, your argument about putting processing in one place so that = upgrades can be more operationally realistic sounds quite right to me. = Hence, I think having DNSSEC validation done outside of the the = validating resolver cuts against the position you have stated below. = Perhaps this will be easier to address in person in Quebec? Eric On Jul 13, 2011, at 11:50 AM, Phillip Hallam-Baker wrote: > On Wed, Jul 13, 2011 at 10:46 AM, Eric Osterweil = wrote: >=20 > On Jul 13, 2011, at 10:24 AM, Nicholas Weaver wrote: >=20 > > > > On Jul 13, 2011, at 6:37 AM, Phillip Hallam-Baker wrote: > >> Adam has actual measurements to back up his claim that support for = unknown records is absent in a prohibitively large number of places. The = only thing that surprises me about his numbers is that I expected them = to be much worse. That is possibly an artifact of doing the measurements = on Linux. > > > > Its better than you think, but not great, when measured through = Netalyzr. = http://www.icir.org/christian/publications/2011-satin-netalyzr.pdf > > > > As importantly, its basically the same as TXT records, and its the = same ones which fail. > > > > But more importantly, although we don't have the code to test for it = yet, I suspect that the same set of resolvers that can't handle unknown = resource records is the same set that strips/chokes on DNSSEC records so = you can't get DS records, NSEC/NSEC3, etc... > > > > > > Client resolvers for DNSSEC MUST validate locally (the recursive = resolver can't be trusted, full stop), and MUST be willing to bypass the = recursive resolver infrastructure (the recursive resolver may fail to = pass DNSSEC-related records properly). >=20 > This "full stop" issue may, or may not, be true but one thing I think = deserves a "full stop" is that embedding part of DNSSEC's logic in a = place that is _not_ DNS suffers a lot of architectural and operational = complexity. Trusting resolvers is one issue, putting data in a = different protocols and trying to cobble DNSSEC-like-validation into = remote protocols is the issue I think needs attention. We've seen a lot = of one-off DNS resolver implementations and I would argue a lot of = _those_ are responsible for the brokeness that you have measured. Thus, = let's be very weary of adding new points of brokeness that report to = support DNSSEC-like semantics and then fail to keep up w/ the protocol's = evolution. >=20 > We saw the same sort of thing with deployment of SET, or rather the = non-deployment as it turned out. >=20 > Certain deployment decisions by certain parties meant that we only got = one chance to deploy SET. By the time we had real world experience and = knew the bits that needed fixing we were unable to make changes there or = anywhere else. >=20 >=20 > PKI systems are inherently complex because they are the interface to = the trust infrastructure of the real world and the real world is = complex. >=20 > Rather than having people quote what they imagine the end to end = principle to be, I would encourage them to read what David Clark = actually wrote. It is an argument about complexity and in particular the = best places to manage that complexity.=20 >=20 > I don;t want to be speaking for David here, but he is not a rigid = ideologue by any stretch of the imagination. The end to end argument is = an argument about practicality and it applies to a specific situation 20 = years ago. It was never intended to be stated as an absolute truth. >=20 > It is not an argument about security either. 'End to end' security = predated the Internet and was and is acknowledged to be a form of = security that is desirable in an abstract sense but frequently = impractical. One Time Pads provide provably unbreakable security, = Quantum Cryptography is theoretically unbreakable, but systems built = around those schemes have turned out to fail in the real world because = it is just not practical to build and use them in a perfect way. >=20 >=20 > At the time the paper was written a computer system capable of running = IP protocols was $200K and up. Micros existed but they were limited to = 64Kb of memory, not really what you want to be writing an IP stack in. >=20 > The telephone system has the complexity in the middle because it is a = 100 year old system and the middle is the only place that could be = easily changed. It was also at the time the design was chosen a system = operated by one single entity. >=20 >=20 > The 'end to end' argument is really an argument that you don't want to = put complexity into the inter-network. At the time the client endpoint = was the only other place it could go. For the past 10-15 years we have = seen the difficulty of making changes at the client increase to the = point that it is very difficult to achieve.=20 >=20 > The DNS resolver is my preferred point to put DNSSEC processing = because it means that I can upgrade my DNSSEC processing by upgrading = that one single piece of infrastructure. That means that I have to have = a secure means of communicating with my trusted resolver, but that is a = solvable problem (e.g. DPLS). >=20 >=20 > It is one thing to say that we will not address issues like DPLS and = chains in certs or OCSP, quite another to state that we will write a = spec that insists that the only valid deployment is one that is totally = impractical. >=20 > The only valid requirement for DANE is that the DNSSEC records MUST = have been validated in a trustworthy fashion. Going beyond that is = ideology. Security reacts really badly to ideology. > =20 > --=20 > Website: http://hallambaker.com/ >=20 From ondrej.sury@nic.cz Wed Jul 13 09:17:44 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C15D11E8070 for ; Wed, 13 Jul 2011 09:17:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.09 X-Spam-Level: X-Spam-Status: No, score=-1.09 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_31=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ag+tjs9sPTRJ for ; Wed, 13 Jul 2011 09:17:43 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 942CF21F8726 for ; Wed, 13 Jul 2011 09:17:42 -0700 (PDT) Received: from [IPv6:2001:1488:ac14:1400:224:e8ff:fea9:f617] (unknown [IPv6:2001:1488:ac14:1400:224:e8ff:fea9:f617]) by mail.nic.cz (Postfix) with ESMTPSA id AA8DD2A2C10 for ; Wed, 13 Jul 2011 18:17:41 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1310573861; bh=IHJsBjZGi+qIYOk0ZSO2Dv61tt/Icfwzo44KU+7+V5U=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=kT55YtjWvTDkRfvjcfZ1XDxGevkqPsRIRyFAJOOQ8Fl7bgH6RCYuVoSZAxEABwC4Q OTNDK0VV4plWyYiuxDfvqEWkBlDE2MIsS0xDJV0ZWIfARxtPkR5vSluLYc6N+DLB7t JgrHvcLTPngp/EJ8yvmJzzZ2vaIESrWBCRAmvy0I= Message-ID: <4E1DC525.60008@nic.cz> Date: Wed, 13 Jul 2011 18:17:41 +0200 From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= User-Agent: Mozilla/5.0 (X11; Linux i686; rv:5.0) Gecko/20110627 Thunderbird/5.0 MIME-Version: 1.0 To: DANE WG References: <4A953B0A-3910-4DEC-BE13-9B6F2E0815B2@kumari.net> <4E1C89B9.8030100@verisign.com> <4E1D91F2.7090109@nic.cz> <4E1D9745.4070802@nic.cz> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Subject: Re: [dane] Opening issues... X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2011 16:17:44 -0000 Hi all, you must excuse me, but I fail to see how this text relates to the subject of the email and the question if we have any open issues we want to discuss in Quebec. Could we please a) stick to the subject (or change the subject of the email) and b) stick to the WG topic. Also I would recommend re-reading the charter (which we agreed on when creating this working group by reaching the consensus) again: > Description of Working Group: > > Objective: > > Specify mechanisms and techniques that allow Internet applications to > establish cryptographically secured communications by using information > distributed through DNSSEC for discovering and authenticating public > keys which are associated with a service located at a domain name. > > Problem Statement: > > Entities on the Internet are usually identified using domain names and > forming a cryptographically secured connection to the entity requires > the entity to authenticate its name. For instance, in HTTPS, a server > responding to a query for is expected to > authenticate as "www.example.com". Security protocols such as TLS and > IPsec accomplish this authentication by allowing an endpoint to prove > ownership of a private key whose corresponding public key is somehow > bound to the name being authenticated. As a pre-requisite for > authentication, then, these protocols require a mechanism for bindings > to be asserted between public keys and domain names. > > DNSSEC provides a mechanism for a zone operator to sign DNS > information directly, using keys that are bound to the domain by the > parent domain; relying parties can continue this chain up to any trust > anchor that they accept. In this way, bindings of keys to domains are > asserted not by external entities, but by the entities that operate the > DNS. In addition, this technique inherently limits the scope of any > given entity to the names in zones he controls. > > This working group will develop mechanisms for zone operators to > present bindings between names within their control and public keys, in > such a way that these bindings can be integrity-protected (and thus > shown to be authentically from the zone operator) using DNSSEC and > used as a basis for authentication in protocols that use domain names as > identifiers. Possible starting points for these deliverables include > draft-hallambaker-certhash, draft-hoffman-keys-linkage-from-dns, and > draft-josefsson-keyassure-tls. > > The mechanisms developed by this group will address bindings between > domain names and keys, allowing flexibility for all key-transport > mechanisms supported by the application protocols addressed (e.g., both > self-signed and CA-issued certificates for use in TLS). > > The solutions specified by this working group rely upon the security of > the DNS to provide source authentication for public keys. The decision > whether the chain of trust provided by DNSSEC is sufficient to trust the > key, or whether additional mechanisms are required to determine the > acceptability of a key, is left to the entity that uses the key > material. In addition to the protections afforded by DNSSEC, the > protocols and mechanisms designed by this working group require securing > the "last hop" by operating a local DNS resolver or securing the > connection to remote resolver - this WG will not specify new mechanisms > to secure that hop, but will reference existing specifications or > document existing methods in order to allow implementations to > interoperate securely. > > Initial deliverables for this working group are limited to distribution > of bindings between names within the zone operator's control and public > keys. More general statements of policy for a domain are out of scope, > and new tasks in this area may only be adopted through a re-chartering. > > The group may also create documents that describe how protocol entities > can discover and validate these bindings in the execution of specific > applications. This work would be done in coordination with the IETF > Working Groups responsible for the protocols. While I found Adam's draft interesting and worthy I really think it twists the problem around by putting DNSSEC into CERT, while we agreed to work on putting CERTs into DNSSEC. Also if we are to take "serialization issue" to Quebec then I would love to hear more opinions from people who *haven't spoken* yet. And this really applies to everybody - please cool your heads before replying. Thanks, O. On 13.7.2011 17:50, Phillip Hallam-Baker wrote: > On Wed, Jul 13, 2011 at 10:46 AM, Eric Osterweil wrote: > >> >> On Jul 13, 2011, at 10:24 AM, Nicholas Weaver wrote: >> >>> >>> On Jul 13, 2011, at 6:37 AM, Phillip Hallam-Baker wrote: >>>> Adam has actual measurements to back up his claim that support for >> unknown records is absent in a prohibitively large number of places. The >> only thing that surprises me about his numbers is that I expected them to be >> much worse. That is possibly an artifact of doing the measurements on Linux. >>> >>> Its better than you think, but not great, when measured through Netalyzr. >> http://www.icir.org/christian/publications/2011-satin-netalyzr.pdf >>> >>> As importantly, its basically the same as TXT records, and its the same >> ones which fail. >>> >>> But more importantly, although we don't have the code to test for it yet, >> I suspect that the same set of resolvers that can't handle unknown resource >> records is the same set that strips/chokes on DNSSEC records so you can't >> get DS records, NSEC/NSEC3, etc... >>> >>> >>> Client resolvers for DNSSEC MUST validate locally (the recursive resolver >> can't be trusted, full stop), and MUST be willing to bypass the recursive >> resolver infrastructure (the recursive resolver may fail to pass >> DNSSEC-related records properly). >> >> This "full stop" issue may, or may not, be true but one thing I think >> deserves a "full stop" is that embedding part of DNSSEC's logic in a place >> that is _not_ DNS suffers a lot of architectural and operational complexity. >> Trusting resolvers is one issue, putting data in a different protocols and >> trying to cobble DNSSEC-like-validation into remote protocols is the issue I >> think needs attention. We've seen a lot of one-off DNS resolver >> implementations and I would argue a lot of _those_ are responsible for the >> brokeness that you have measured. Thus, let's be very weary of adding new >> points of brokeness that report to support DNSSEC-like semantics and then >> fail to keep up w/ the protocol's evolution. > > > We saw the same sort of thing with deployment of SET, or rather the > non-deployment as it turned out. > > Certain deployment decisions by certain parties meant that we only got one > chance to deploy SET. By the time we had real world experience and knew the > bits that needed fixing we were unable to make changes there or anywhere > else. > > > PKI systems are inherently complex because they are the interface to the > trust infrastructure of the real world and the real world is complex. > > Rather than having people quote what they imagine the end to end principle > to be, I would encourage them to read what David Clark actually wrote. It is > an argument about complexity and in particular the best places to manage > that complexity. > > I don;t want to be speaking for David here, but he is not a rigid ideologue > by any stretch of the imagination. The end to end argument is an argument > about practicality and it applies to a specific situation 20 years ago. It > was never intended to be stated as an absolute truth. > > It is not an argument about security either. 'End to end' security predated > the Internet and was and is acknowledged to be a form of security that is > desirable in an abstract sense but frequently impractical. One Time Pads > provide provably unbreakable security, Quantum Cryptography is theoretically > unbreakable, but systems built around those schemes have turned out to fail > in the real world because it is just not practical to build and use them in > a perfect way. > > > At the time the paper was written a computer system capable of running IP > protocols was $200K and up. Micros existed but they were limited to 64Kb of > memory, not really what you want to be writing an IP stack in. > > The telephone system has the complexity in the middle because it is a 100 > year old system and the middle is the only place that could be easily > changed. It was also at the time the design was chosen a system operated by > one single entity. > > > The 'end to end' argument is really an argument that you don't want to put > complexity into the inter-network. At the time the client endpoint was the > only other place it could go. For the past 10-15 years we have seen the > difficulty of making changes at the client increase to the point that it is > very difficult to achieve. > > The DNS resolver is my preferred point to put DNSSEC processing because it > means that I can upgrade my DNSSEC processing by upgrading that one single > piece of infrastructure. That means that I have to have a secure means of > communicating with my trusted resolver, but that is a solvable problem (e.g. > DPLS). > > > It is one thing to say that we will not address issues like DPLS and chains > in certs or OCSP, quite another to state that we will write a spec that > insists that the only valid deployment is one that is totally impractical. > > The only valid requirement for DANE is that the DNSSEC records MUST have > been validated in a trustworthy fashion. Going beyond that is ideology. > Security reacts really badly to ideology. -- Ondřej Surý vedoucí výzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- From paul.hoffman@vpnc.org Wed Jul 13 09:28:39 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 752E111E8159 for ; Wed, 13 Jul 2011 09:28:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.545 X-Spam-Level: X-Spam-Status: No, score=-102.545 tagged_above=-999 required=5 tests=[AWL=-0.246, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5mirOE7ulihQ for ; Wed, 13 Jul 2011 09:28:39 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id CA1AE11E8154 for ; Wed, 13 Jul 2011 09:28:38 -0700 (PDT) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4] (may be forged)) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p6DGSSW1025933 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 13 Jul 2011 09:28:28 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=utf-8 From: Paul Hoffman In-Reply-To: <4E1DC525.60008@nic.cz> Date: Wed, 13 Jul 2011 09:28:38 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <445E74A0-05E4-47E0-95DB-27BF356BC296@vpnc.org> References: <4A953B0A-3910-4DEC-BE13-9B6F2E0815B2@kumari.net> <4E1C89B9.8030100@verisign.com> <4E1D91F2.7090109@nic.cz> <4E1D9745.4070802@nic.cz> <4E1DC525.60008@nic.cz> To: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= X-Mailer: Apple Mail (2.1084) Cc: DANE WG Subject: Re: [dane] Opening issues... X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2011 16:28:39 -0000 On Jul 13, 2011, at 9:17 AM, Ond=C5=99ej Sur=C3=BD wrote: > While I found Adam's draft interesting and worthy I really think it > twists the problem around by putting DNSSEC into CERT, while we agreed > to work on putting CERTs into DNSSEC. Again: Adam's draft does not mentions putting the DNSSEC information = anywhere. It is the serialization only. Others will propose where to put = that serialization. There are many proposals (with no drafts) so far. --Paul Hoffman From hallam@gmail.com Wed Jul 13 09:38:10 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EE0F21F87C7 for ; Wed, 13 Jul 2011 09:38:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.783 X-Spam-Level: X-Spam-Status: No, score=-2.783 tagged_above=-999 required=5 tests=[AWL=-0.685, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, J_CHICKENPOX_31=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id znNZoX8jef+K for ; Wed, 13 Jul 2011 09:38:08 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7C3D221F881B for ; Wed, 13 Jul 2011 09:38:08 -0700 (PDT) Received: by yie30 with SMTP id 30so2948788yie.31 for ; Wed, 13 Jul 2011 09:38:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JTVVZUSXh9YyhFgoMFZPpg8pP9abXMncZnwnCEZYQPA=; b=fpOZoB+IHM847tthb4t9yzh5+a87R2cgaHbn4+eT8ulixHEoFzk12pO6D3273N4gex EZcbkTDiIoASDXNYG/Lj+5xoo585kLCSu1idqqNiVvkvpzNSyTomlEftO5hEvDi59ulc 6vV5lwz1UAb5lPuO+CX3KsSwm5dOMn9I1ZYBI= MIME-Version: 1.0 Received: by 10.101.162.11 with SMTP id p11mr1231969ano.159.1310575087960; Wed, 13 Jul 2011 09:38:07 -0700 (PDT) Received: by 10.100.93.12 with HTTP; Wed, 13 Jul 2011 09:38:07 -0700 (PDT) In-Reply-To: <4E1DC525.60008@nic.cz> References: <4A953B0A-3910-4DEC-BE13-9B6F2E0815B2@kumari.net> <4E1C89B9.8030100@verisign.com> <4E1D91F2.7090109@nic.cz> <4E1D9745.4070802@nic.cz> <4E1DC525.60008@nic.cz> Date: Wed, 13 Jul 2011 12:38:07 -0400 Message-ID: From: Phillip Hallam-Baker To: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= Content-Type: multipart/alternative; boundary=001636ed6c7f91c2eb04a7f60a61 Cc: DANE WG Subject: Re: [dane] Opening issues... X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2011 16:38:10 -0000 --001636ed6c7f91c2eb04a7f60a61 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable It sounds to me like we are done. If there are no outstanding issues to discuss in Quebec we should ask the ADs to issue it as an RFC and declare victory. None of the other issues seem to fit into the charter as defined. There seems to be no interest whatsoever in even listening to any practical constraints on deployment, let alone addressing them. On Wed, Jul 13, 2011 at 12:17 PM, Ond=C5=99ej Sur=C3=BD wrote: > Hi all, > > you must excuse me, but I fail to see how this text relates to the > subject of the email and the question if we have any open issues we want > to discuss in Quebec. Could we please a) stick to the subject (or > change the subject of the email) and b) stick to the WG topic. > > Also I would recommend re-reading the charter (which we agreed on when > creating this working group by reaching the consensus) again: > > > Description of Working Group: > > > > Objective: > > > > Specify mechanisms and techniques that allow Internet applications to > > establish cryptographically secured communications by using informati= on > > distributed through DNSSEC for discovering and authenticating public > > keys which are associated with a service located at a domain name. > > > > Problem Statement: > > > > Entities on the Internet are usually identified using domain names an= d > > forming a cryptographically secured connection to the entity requires > > the entity to authenticate its name. For instance, in HTTPS, a server > > responding to a query for is expected to > > authenticate as "www.example.com". Security protocols such as TLS and > > IPsec accomplish this authentication by allowing an endpoint to prove > > ownership of a private key whose corresponding public key is somehow > > bound to the name being authenticated. As a pre-requisite for > > authentication, then, these protocols require a mechanism for binding= s > > to be asserted between public keys and domain names. > > > > DNSSEC provides a mechanism for a zone operator to sign DNS > > information directly, using keys that are bound to the domain by the > > parent domain; relying parties can continue this chain up to any trus= t > > anchor that they accept. In this way, bindings of keys to domains are > > asserted not by external entities, but by the entities that operate t= he > > DNS. In addition, this technique inherently limits the scope of any > > given entity to the names in zones he controls. > > > > This working group will develop mechanisms for zone operators to > > present bindings between names within their control and public keys, = in > > such a way that these bindings can be integrity-protected (and thus > > shown to be authentically from the zone operator) using DNSSEC and > > used as a basis for authentication in protocols that use domain names > as > > identifiers. Possible starting points for these deliverables include > > draft-hallambaker-certhash, draft-hoffman-keys-linkage-from-dns, and > > draft-josefsson-keyassure-tls. > > > > The mechanisms developed by this group will address bindings between > > domain names and keys, allowing flexibility for all key-transport > > mechanisms supported by the application protocols addressed (e.g., bo= th > > self-signed and CA-issued certificates for use in TLS). > > > > The solutions specified by this working group rely upon the security = of > > the DNS to provide source authentication for public keys. The decisio= n > > whether the chain of trust provided by DNSSEC is sufficient to trust > the > > key, or whether additional mechanisms are required to determine the > > acceptability of a key, is left to the entity that uses the key > > material. In addition to the protections afforded by DNSSEC, the > > protocols and mechanisms designed by this working group require > securing > > the "last hop" by operating a local DNS resolver or securing the > > connection to remote resolver - this WG will not specify new mechanis= ms > > to secure that hop, but will reference existing specifications or > > document existing methods in order to allow implementations to > > interoperate securely. > > > > Initial deliverables for this working group are limited to distributi= on > > of bindings between names within the zone operator's control and publ= ic > > keys. More general statements of policy for a domain are out of scop= e, > > and new tasks in this area may only be adopted through a re-charterin= g. > > > > The group may also create documents that describe how protocol entiti= es > > can discover and validate these bindings in the execution of specific > > applications. This work would be done in coordination with the IETF > > Working Groups responsible for the protocols. > > While I found Adam's draft interesting and worthy I really think it > twists the problem around by putting DNSSEC into CERT, while we agreed > to work on putting CERTs into DNSSEC. > > Also if we are to take "serialization issue" to Quebec then I would love > to hear more opinions from people who *haven't spoken* yet. And this > really applies to everybody - please cool your heads before replying. > > Thanks, > O. > > On 13.7.2011 17:50, Phillip Hallam-Baker wrote: > > On Wed, Jul 13, 2011 at 10:46 AM, Eric Osterweil < > eosterweil@verisign.com>wrote: > > > >> > >> On Jul 13, 2011, at 10:24 AM, Nicholas Weaver wrote: > >> > >>> > >>> On Jul 13, 2011, at 6:37 AM, Phillip Hallam-Baker wrote: > >>>> Adam has actual measurements to back up his claim that support for > >> unknown records is absent in a prohibitively large number of places. T= he > >> only thing that surprises me about his numbers is that I expected them > to be > >> much worse. That is possibly an artifact of doing the measurements on > Linux. > >>> > >>> Its better than you think, but not great, when measured through > Netalyzr. > >> http://www.icir.org/christian/publications/2011-satin-netalyzr.pdf > >>> > >>> As importantly, its basically the same as TXT records, and its the sa= me > >> ones which fail. > >>> > >>> But more importantly, although we don't have the code to test for it > yet, > >> I suspect that the same set of resolvers that can't handle unknown > resource > >> records is the same set that strips/chokes on DNSSEC records so you > can't > >> get DS records, NSEC/NSEC3, etc... > >>> > >>> > >>> Client resolvers for DNSSEC MUST validate locally (the recursive > resolver > >> can't be trusted, full stop), and MUST be willing to bypass the > recursive > >> resolver infrastructure (the recursive resolver may fail to pass > >> DNSSEC-related records properly). > >> > >> This "full stop" issue may, or may not, be true but one thing I think > >> deserves a "full stop" is that embedding part of DNSSEC's logic in a > place > >> that is _not_ DNS suffers a lot of architectural and operational > complexity. > >> Trusting resolvers is one issue, putting data in a different protocol= s > and > >> trying to cobble DNSSEC-like-validation into remote protocols is the > issue I > >> think needs attention. We've seen a lot of one-off DNS resolver > >> implementations and I would argue a lot of _those_ are responsible for > the > >> brokeness that you have measured. Thus, let's be very weary of adding > new > >> points of brokeness that report to support DNSSEC-like semantics and > then > >> fail to keep up w/ the protocol's evolution. > > > > > > We saw the same sort of thing with deployment of SET, or rather the > > non-deployment as it turned out. > > > > Certain deployment decisions by certain parties meant that we only got > one > > chance to deploy SET. By the time we had real world experience and knew > the > > bits that needed fixing we were unable to make changes there or anywher= e > > else. > > > > > > PKI systems are inherently complex because they are the interface to th= e > > trust infrastructure of the real world and the real world is complex. > > > > Rather than having people quote what they imagine the end to end > principle > > to be, I would encourage them to read what David Clark actually wrote. = It > is > > an argument about complexity and in particular the best places to manag= e > > that complexity. > > > > I don;t want to be speaking for David here, but he is not a rigid > ideologue > > by any stretch of the imagination. The end to end argument is an argume= nt > > about practicality and it applies to a specific situation 20 years ago. > It > > was never intended to be stated as an absolute truth. > > > > It is not an argument about security either. 'End to end' security > predated > > the Internet and was and is acknowledged to be a form of security that = is > > desirable in an abstract sense but frequently impractical. One Time Pad= s > > provide provably unbreakable security, Quantum Cryptography is > theoretically > > unbreakable, but systems built around those schemes have turned out to > fail > > in the real world because it is just not practical to build and use the= m > in > > a perfect way. > > > > > > At the time the paper was written a computer system capable of running = IP > > protocols was $200K and up. Micros existed but they were limited to 64K= b > of > > memory, not really what you want to be writing an IP stack in. > > > > The telephone system has the complexity in the middle because it is a 1= 00 > > year old system and the middle is the only place that could be easily > > changed. It was also at the time the design was chosen a system operate= d > by > > one single entity. > > > > > > The 'end to end' argument is really an argument that you don't want to > put > > complexity into the inter-network. At the time the client endpoint was > the > > only other place it could go. For the past 10-15 years we have seen the > > difficulty of making changes at the client increase to the point that i= t > is > > very difficult to achieve. > > > > The DNS resolver is my preferred point to put DNSSEC processing because > it > > means that I can upgrade my DNSSEC processing by upgrading that one > single > > piece of infrastructure. That means that I have to have a secure means = of > > communicating with my trusted resolver, but that is a solvable problem > (e.g. > > DPLS). > > > > > > It is one thing to say that we will not address issues like DPLS and > chains > > in certs or OCSP, quite another to state that we will write a spec that > > insists that the only valid deployment is one that is totally > impractical. > > > > The only valid requirement for DANE is that the DNSSEC records MUST hav= e > > been validated in a trustworthy fashion. Going beyond that is ideology. > > Security reacts really badly to ideology. > > > -- > Ond=C5=99ej Sur=C3=BD > vedouc=C3=AD v=C3=BDzkumu/Head of R&D department > ------------------------------------------- > CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC > Americka 23, 120 00 Praha 2, Czech Republic > mailto:ondrej.sury@nic.cz http://nic.cz/ > tel:+420.222745110 fax:+420.222745112 > ------------------------------------------- > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > --=20 Website: http://hallambaker.com/ --001636ed6c7f91c2eb04a7f60a61 Content-Type: text/html; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable It sounds to me like we are done.

If there are no outsta= nding issues to discuss in Quebec we should ask the ADs to issue it as an R= FC and declare victory.

None of the other issues s= eem to fit into the charter as defined. There seems to be no interest whats= oever in even listening to any practical constraints on deployment, let alo= ne addressing them.


On Wed, Jul 13, 2011 at = 12:17 PM, Ond=F8ej Sur=FD <ondrej.sury@nic.cz> wrote:
Hi all,

you must excuse me, but I fail to see how this text relates to the
subject of the email and the question if we have any open issues we want to discuss in Quebec. =A0Could we please a) stick to the subject (or
change the subject of the email) and b) stick to the WG topic.

Also I would recommend re-reading the charter (which we agreed on when
creating this working group by reaching the consensus) again:

> Description of Working Group:
>
> =A0 Objective:
>
> =A0 Specify mechanisms and techniques that allow Internet applications= to
> =A0 establish cryptographically secured communications by using inform= ation
> =A0 distributed through DNSSEC for discovering and authenticating publ= ic
> =A0 keys which are associated with a service located at a domain name.=
>
> =A0 Problem Statement:
>
> =A0 Entities on the Internet are usually identified using domain names= and
> =A0 forming a cryptographically secured connection to the entity requi= res
> =A0 the entity to authenticate its name. For instance, in HTTPS, a ser= ver
> =A0 responding to a query for <https://www.example.com> is expected to
> =A0 authenticate as "www.example.com". Security protocols such as TLS and
> =A0 IPsec accomplish this authentication by allowing an endpoint to pr= ove
> =A0 ownership of a private key whose corresponding public key is someh= ow
> =A0 bound to the name being authenticated. As a pre-requisite for
> =A0 authentication, then, these protocols require a mechanism for bind= ings
> =A0 to be asserted between public keys and domain names.
>
> =A0 DNSSEC provides a mechanism for a zone operator to sign DNS
> =A0 information directly, using keys that are bound to the domain by t= he
> =A0 parent domain; relying parties can continue this chain up to any t= rust
> =A0 anchor that they accept. In this way, bindings of keys to domains = are
> =A0 asserted not by external entities, but by the entities that operat= e the
> =A0 DNS. In addition, this technique inherently limits the scope of an= y
> =A0 given entity to the names in zones he controls.
>
> =A0 This working group will develop mechanisms for zone operators to > =A0 present bindings between names within their control and public key= s, in
> =A0 such a way that these bindings can be integrity-protected (and thu= s
> =A0 shown to be authentically from the zone operator) using DNSSEC and=
> =A0 used as a basis for authentication in protocols that use domain na= mes as
> =A0 identifiers. Possible starting points for these deliverables inclu= de
> =A0 draft-hallambaker-certhash, draft-hoffman-keys-linkage-from-dns, a= nd
> =A0 draft-josefsson-keyassure-tls.
>
> =A0 The mechanisms developed by this group will address bindings betwe= en
> =A0 domain names and keys, allowing flexibility for all key-transport<= br> > =A0 mechanisms supported by the application protocols addressed (e.g.,= both
> =A0 self-signed and CA-issued certificates for use in TLS).
>
> =A0 The solutions specified by this working group rely upon the securi= ty of
> =A0 the DNS to provide source authentication for public keys. The deci= sion
> =A0 whether the chain of trust provided by DNSSEC is sufficient to tru= st the
> =A0 key, or whether additional mechanisms are required to determine th= e
> =A0 acceptability of a key, is left to the entity that uses the key > =A0 material. =A0In addition to the protections afforded by DNSSEC, th= e
> =A0 protocols and mechanisms designed by this working group require se= curing
> =A0 the "last hop" by operating a local DNS resolver or secu= ring the
> =A0 connection to remote resolver - this WG will not specify new mecha= nisms
> =A0 to secure that hop, but will reference existing specifications or<= br> > =A0 document existing methods in order to allow implementations to
> =A0 interoperate securely.
>
> =A0 Initial deliverables for this working group are limited to distrib= ution
> =A0 of bindings between names within the zone operator's control a= nd public
> =A0 keys. =A0More general statements of policy for a domain are out of= scope,
> =A0 and new tasks in this area may only be adopted through a re-charte= ring.
>
> =A0 The group may also create documents that describe how protocol ent= ities
> =A0 can discover and validate these bindings in the execution of speci= fic
> =A0 applications. This work would be done in coordination with the IET= F
> =A0 Working Groups responsible for the protocols.

While I found Adam's draft interesting and worthy I really think it
twists the problem around by putting DNSSEC into CERT, while we agreed
to work on putting CERTs into DNSSEC.

Also if we are to take "serialization issue" to Quebec then I wou= ld love
to hear more opinions from people who *haven't spoken* yet. =A0And this=
really applies to everybody - please cool your heads before replying.

Thanks,
O.

On 13.7.2011 17:50, Phillip Hallam-Baker wrote:
> On Wed, Jul 13, 2011 at 10:46 AM, Eric Osterweil <eosterweil@verisign.com>wrote:
>
>>
>> On Jul 13, 2011, at 10:24 AM, Nicholas Weaver wrote:
>>
>>>
>>> On Jul 13, 2011, at 6:37 AM, Phillip Hallam-Baker wrote:
>>>> Adam has actual measurements to back up his claim that sup= port for
>> unknown records is absent in a prohibitively large number of place= s. The
>> only thing that surprises me about his numbers is that I expected = them to be
>> much worse. That is possibly an artifact of doing the measurements= on Linux.
>>>
>>> Its better than you think, but not great, when measured throug= h Netalyzr.
>> =A0http://www.icir.org/christian/publication= s/2011-satin-netalyzr.pdf
>>>
>>> As importantly, its basically the same as TXT records, and its= the same
>> ones which fail.
>>>
>>> But more importantly, although we don't have the code to t= est for it yet,
>> I suspect that the same set of resolvers that can't handle unk= nown resource
>> records is the same set that strips/chokes on DNSSEC records so yo= u can't
>> get DS records, NSEC/NSEC3, etc...
>>>
>>>
>>> Client resolvers for DNSSEC MUST validate locally (the recursi= ve resolver
>> can't be trusted, full stop), and MUST be willing to bypass th= e recursive
>> resolver infrastructure (the recursive resolver may fail to pass >> DNSSEC-related records properly).
>>
>> This "full stop" issue may, or may not, be true but one = thing I think
>> deserves a "full stop" is that embedding part of DNSSEC&= #39;s logic in a place
>> that is _not_ DNS suffers a lot of architectural and operational c= omplexity.
>> =A0Trusting resolvers is one issue, putting data in a different pr= otocols and
>> trying to cobble DNSSEC-like-validation into remote protocols is t= he issue I
>> think needs attention. =A0We've seen a lot of one-off DNS reso= lver
>> implementations and I would argue a lot of _those_ are responsible= for the
>> brokeness that you have measured. =A0Thus, let's be very weary= of adding new
>> points of brokeness that report to support DNSSEC-like semantics a= nd then
>> fail to keep up w/ the protocol's evolution.
>
>
> We saw the same sort of thing with deployment of SET, or rather the > non-deployment as it turned out.
>
> Certain deployment decisions by certain parties meant that we only got= one
> chance to deploy SET. By the time we had real world experience and kne= w the
> bits that needed fixing we were unable to make changes there or anywhe= re
> else.
>
>
> PKI systems are inherently complex because they are the interface to t= he
> trust infrastructure of the real world and the real world is complex.<= br> >
> Rather than having people quote what they imagine the end to end princ= iple
> to be, I would encourage them to read what David Clark actually wrote.= It is
> an argument about complexity and in particular the best places to mana= ge
> that complexity.
>
> I don;t want to be speaking for David here, but he is not a rigid ideo= logue
> by any stretch of the imagination. The end to end argument is an argum= ent
> about practicality and it applies to a specific situation 20 years ago= . It
> was never intended to be stated as an absolute truth.
>
> It is not an argument about security either. 'End to end' secu= rity predated
> the Internet and was and is acknowledged to be a form of security that= is
> desirable in an abstract sense but frequently impractical. One Time Pa= ds
> provide provably unbreakable security, Quantum Cryptography is theoret= ically
> unbreakable, but systems built around those schemes have turned out to= fail
> in the real world because it is just not practical to build and use th= em in
> a perfect way.
>
>
> At the time the paper was written a computer system capable of running= IP
> protocols was $200K and up. Micros existed but they were limited to 64= Kb of
> memory, not really what you want to be writing an IP stack in.
>
> The telephone system has the complexity in the middle because it is a = 100
> year old system and the middle is the only place that could be easily<= br> > changed. It was also at the time the design was chosen a system operat= ed by
> one single entity.
>
>
> The 'end to end' argument is really an argument that you don&#= 39;t want to put
> complexity into the inter-network. At the time the client endpoint was= the
> only other place it could go. For the past 10-15 years we have seen th= e
> difficulty of making changes at the client increase to the point that = it is
> very difficult to achieve.
>
> The DNS resolver is my preferred point to put DNSSEC processing becaus= e it
> means that I can upgrade my DNSSEC processing by upgrading that one si= ngle
> piece of infrastructure. That means that I have to have a secure means= of
> communicating with my trusted resolver, but that is a solvable problem= (e.g.
> DPLS).
>
>
> It is one thing to say that we will not address issues like DPLS and c= hains
> in certs or OCSP, quite another to state that we will write a spec tha= t
> insists that the only valid deployment is one that is totally impracti= cal.
>
> The only valid requirement for DANE is that the DNSSEC records MUST ha= ve
> been validated in a trustworthy fashion. Going beyond that is ideology= .
> Security reacts really badly to ideology.


--
=A0Ond=F8ej Sur=FD
=A0vedouc=ED v=FDzkumu/Head of R&D department
=A0-------------------------------------------
=A0CZ.NIC, z.s.p.o. =A0 =A0-- =A0 =A0Laborato=F8e CZ.NIC
=A0Americka 23, 120 00 Praha 2, Czech Republic
=A0mailto:ondrej.sury@nic.cz =A0 = =A0http://nic.cz/
=A0tel:+420.222745= 110 =A0 =A0 =A0 fax:+420.222745112
=A0-------------------------------------------
_______________________________________________



--
Website: http://hallambaker.com/

--001636ed6c7f91c2eb04a7f60a61-- From hallam@gmail.com Wed Jul 13 09:43:03 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A032811E817F for ; Wed, 13 Jul 2011 09:43:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.512 X-Spam-Level: X-Spam-Status: No, score=-3.512 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Pwnnb-0qxLP for ; Wed, 13 Jul 2011 09:43:02 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id D178911E816F for ; Wed, 13 Jul 2011 09:43:02 -0700 (PDT) Received: by gxk19 with SMTP id 19so2293693gxk.31 for ; Wed, 13 Jul 2011 09:43:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xJuGmFHYjYAx+FFHcPIROdHlLSIXLCyPC9rRwyNRGkM=; b=NZBPYtOvIGcqn7mpr5QdtY5fMa8A1IRso17I/J5bi9nbi+ksSA+UT3EhDEYkRa1xHM D0O97XOjXUYKeh53DQdr+ySNox6rJZ6J9tByN1di8/WFb0EU4xChWnIJJ8ClkXjdJwZZ p5Kg6EDbF50jn2RlEAM6iaMIsCQv+GS4YgMVI= MIME-Version: 1.0 Received: by 10.101.162.11 with SMTP id p11mr1236953ano.159.1310575382305; Wed, 13 Jul 2011 09:43:02 -0700 (PDT) Received: by 10.100.93.12 with HTTP; Wed, 13 Jul 2011 09:43:02 -0700 (PDT) In-Reply-To: <445E74A0-05E4-47E0-95DB-27BF356BC296@vpnc.org> References: <4A953B0A-3910-4DEC-BE13-9B6F2E0815B2@kumari.net> <4E1C89B9.8030100@verisign.com> <4E1D91F2.7090109@nic.cz> <4E1D9745.4070802@nic.cz> <4E1DC525.60008@nic.cz> <445E74A0-05E4-47E0-95DB-27BF356BC296@vpnc.org> Date: Wed, 13 Jul 2011 12:43:02 -0400 Message-ID: From: Phillip Hallam-Baker To: Paul Hoffman Content-Type: multipart/alternative; boundary=001636ed6c7f1d1b7904a7f61cfa Cc: DANE WG Subject: Re: [dane] Opening issues... X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2011 16:43:03 -0000 --001636ed6c7f1d1b7904a7f61cfa Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Jul 13, 2011 at 12:28 PM, Paul Hoffman wrote= : > On Jul 13, 2011, at 9:17 AM, Ond=C5=99ej Sur=C3=BD wrote: > > > While I found Adam's draft interesting and worthy I really think it > > twists the problem around by putting DNSSEC into CERT, while we agreed > > to work on putting CERTs into DNSSEC. > > Again: Adam's draft does not mentions putting the DNSSEC information > anywhere. It is the serialization only. Others will propose where to put > that serialization. There are many proposals (with no drafts) so far. Quite true. I suggest the following: * The Serialization Draft go to DNSEXT because the question at issue there is how to process a DNSSEC chain in isolation of DNS protocol. This is going to be an important and useful capability in its own right. Knowing what parts of the chain are necessary for archival purposes is essential if we are to achieve accountability or auditability. * The 'how to stick chain in PKIX' part goes to PKIX. This can be a relatively short draft consisting of extension declarations and security considerations, maybe some protocol. I don't see any part of this work really being a TLS issue so I would not propose it go there as others suggest. --=20 Website: http://hallambaker.com/ --001636ed6c7f1d1b7904a7f61cfa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Wed, Jul 13, 2011 at 12:28 PM, Paul H= offman <paul.= hoffman@vpnc.org> wrote:
On Jul 13, 2011, at 9:17 AM, Ond=C5=99ej Sur=C3=BD wrote:=

> While I found Adam's draft interesting and worthy I really think i= t
> twists the problem around by putting DNSSEC into CERT, while we agreed=
> to work on putting CERTs into DNSSEC.

Again: Adam's draft does not mentions putting the DNSSEC informat= ion anywhere. It is the serialization only. Others will propose where to pu= t that serialization. There are many proposals (with no drafts) so far.

Quite true.=C2=A0

I suggest th= e following:

* The Serialization Draft go to DNSEX= T because the question at issue there is how to process a DNSSEC chain in i= solation of DNS protocol.

This is going to be an important and useful capability = in its own right. Knowing what parts of the chain are necessary for archiva= l purposes is essential if we are to achieve accountability or auditability= .


* The 'how to stick chain in PKIX= 9; part goes to PKIX.=C2=A0

This can be a relative= ly short draft consisting of extension declarations and security considerat= ions, maybe some protocol.


I don't see any part of this work re= ally being a TLS issue so I would not propose it go there as others suggest= .

--
Website: http:/= /hallambaker.com/

--001636ed6c7f1d1b7904a7f61cfa-- From paul.hoffman@vpnc.org Wed Jul 13 09:54:01 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DDD721F8546 for ; Wed, 13 Jul 2011 09:54:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.69 X-Spam-Level: X-Spam-Status: No, score=-102.69 tagged_above=-999 required=5 tests=[AWL=-0.091, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ep14g1GBxSa for ; Wed, 13 Jul 2011 09:54:00 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 9F5B521F854B for ; Wed, 13 Jul 2011 09:53:58 -0700 (PDT) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4] (may be forged)) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p6DGrmcA026873 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 13 Jul 2011 09:53:48 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Paul Hoffman In-Reply-To: Date: Wed, 13 Jul 2011 09:53:57 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1A2105EC-F91D-489E-8A80-FAAA90D93FF2@vpnc.org> References: <4A953B0A-3910-4DEC-BE13-9B6F2E0815B2@kumari.net> <4E1C89B9.8030100@verisign.com> <4E1D91F2.7090109@nic.cz> <4E1D9745.4070802@nic.cz> <4E1DC525.60008@nic.cz> <445E74A0-05E4-47E0-95DB-27BF356BC296@vpnc.org> To: DANE WG X-Mailer: Apple Mail (2.1084) Subject: [dane] Serialization: where? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2011 16:54:01 -0000 On Jul 13, 2011, at 9:43 AM, Phillip Hallam-Baker wrote: > I suggest the following: >=20 > * The Serialization Draft go to DNSEXT because the question at issue = there is how to process a DNSSEC chain in isolation of DNS protocol. That is up to Adam, not us. > This is going to be an important and useful capability in its own = right. Knowing what parts of the chain are necessary for archival = purposes is essential if we are to achieve accountability or = auditability. Fully agree. > * The 'how to stick chain in PKIX' part goes to PKIX.=20 >=20 > This can be a relatively short draft consisting of extension = declarations and security considerations, maybe some protocol. You can propose that there. > I don't see any part of this work really being a TLS issue so I would = not propose it go there as others suggest. Others have suggested ways of using the serialization in TLS that does = not involve using PKIX. Those folks can take it to TLS. FWIW, I have requested a slot in the TLS WG meeting to do a lightning = review of the DNSSEC serialization draft and the proposed places where = it might appear (both PKIX and TLS). --Paul Hoffman From paul@xelerance.com Wed Jul 13 10:41:31 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5674C11E81E6 for ; Wed, 13 Jul 2011 10:41:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.476 X-Spam-Level: X-Spam-Status: No, score=-6.476 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3T0lm7-sZMw9 for ; Wed, 13 Jul 2011 10:41:30 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by ietfa.amsl.com (Postfix) with ESMTP id B4FD621F8A70 for ; Wed, 13 Jul 2011 10:41:30 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id F039DBF8A; Wed, 13 Jul 2011 13:41:44 -0400 (EDT) Date: Wed, 13 Jul 2011 13:41:44 -0400 (EDT) From: Paul Wouters To: Eric Osterweil In-Reply-To: Message-ID: References: <4A953B0A-3910-4DEC-BE13-9B6F2E0815B2@kumari.net> <4E1C89B9.8030100@verisign.com> <4E1D91F2.7090109@nic.cz> <4E1D9745.4070802@nic.cz> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: DANE WG Subject: [dane] readability, was Re: Opening issues... X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2011 17:41:31 -0000 On Wed, 13 Jul 2011, Eric Osterweil wrote: > thank you! I've kinda stopped trying to read people's postings made with the gmail web client. It takes me 30 seconds or more to find out if a block of text is new or quoted. If you want your postings to get proper attention, teach your MUA how to make readable posts without assuming coloured html blobs. Paul From warren@kumari.net Wed Jul 13 11:41:43 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1D7A11E80F3 for ; Wed, 13 Jul 2011 11:41:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_31=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id we9cJ2JuN380 for ; Wed, 13 Jul 2011 11:41:39 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id C5F2A11E80E7 for ; Wed, 13 Jul 2011 11:41:35 -0700 (PDT) Received: from dot.her.corp.google.com (unknown [74.202.225.33]) by vimes.kumari.net (Postfix) with ESMTPSA id 131341B409DA; Wed, 13 Jul 2011 14:41:35 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-2 From: Warren Kumari In-Reply-To: Date: Wed, 13 Jul 2011 14:41:34 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <3DC30742-6F0C-47FD-9EDD-B26F5936F56B@kumari.net> References: <4A953B0A-3910-4DEC-BE13-9B6F2E0815B2@kumari.net> <4E1C89B9.8030100@verisign.com> <4E1D91F2.7090109@nic.cz> <4E1D9745.4070802@nic.cz> <4E1DC525.60008@nic.cz> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1084) Cc: DANE WG Subject: Re: [dane] Opening issues... X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2011 18:41:43 -0000 On Jul 13, 2011, at 12:38 PM, Phillip Hallam-Baker wrote: > It sounds to me like we are done. >=20 > If there are no outstanding issues to discuss in Quebec we should ask = the ADs to issue it as an RFC and declare victory. I realize that you were (probably) being sarcastic here, but I'm = beginning to think that this may actually be the correct approach... Not to declare victory in the sense that the WG is all done[0], but the = protocol doc (draft-ietf-dane-protocol-08) looks to be close to fully = baked (Paul and Jakob have been integrating the WGs consensus as we = arrive at it, have bumped it after the Use Case document, and there have = been no real substantive comment received that affect *that* document). = The fact that we are revisiting closes issues, etc may mean that we are = starting to dink with things that should not be dunked... The last hop, etc issues may be better dealt with in another = document.... > None of the other issues seem to fit into the charter as defined. = There seems to be no interest whatsoever in even listening to any = practical constraints on deployment, let alone addressing them. You have repeatedly waved the deployability flag -- the working group = seems to feel that the current system *is* deployable, and there have = been numerous discussions on this topic.=20 There is nothing stopping launching, and then if a more deployable = solution presents itself / real world deployment issues *are* = encountered, releasing a "You do DANE, but with these additions / tweaks = / options for discovery / scaling / etc" document. W >=20 >=20 > On Wed, Jul 13, 2011 at 12:17 PM, Ond=F8ej Sur=FD = wrote: > Hi all, >=20 > you must excuse me, but I fail to see how this text relates to the > subject of the email and the question if we have any open issues we = want > to discuss in Quebec. Could we please a) stick to the subject (or > change the subject of the email) and b) stick to the WG topic. >=20 > Also I would recommend re-reading the charter (which we agreed on when > creating this working group by reaching the consensus) again: >=20 > > Description of Working Group: > > > > Objective: > > > > Specify mechanisms and techniques that allow Internet applications = to > > establish cryptographically secured communications by using = information > > distributed through DNSSEC for discovering and authenticating = public > > keys which are associated with a service located at a domain name. > > > > Problem Statement: > > > > Entities on the Internet are usually identified using domain names = and > > forming a cryptographically secured connection to the entity = requires > > the entity to authenticate its name. For instance, in HTTPS, a = server > > responding to a query for is expected to > > authenticate as "www.example.com". Security protocols such as TLS = and > > IPsec accomplish this authentication by allowing an endpoint to = prove > > ownership of a private key whose corresponding public key is = somehow > > bound to the name being authenticated. As a pre-requisite for > > authentication, then, these protocols require a mechanism for = bindings > > to be asserted between public keys and domain names. > > > > DNSSEC provides a mechanism for a zone operator to sign DNS > > information directly, using keys that are bound to the domain by = the > > parent domain; relying parties can continue this chain up to any = trust > > anchor that they accept. In this way, bindings of keys to domains = are > > asserted not by external entities, but by the entities that = operate the > > DNS. In addition, this technique inherently limits the scope of = any > > given entity to the names in zones he controls. > > > > This working group will develop mechanisms for zone operators to > > present bindings between names within their control and public = keys, in > > such a way that these bindings can be integrity-protected (and = thus > > shown to be authentically from the zone operator) using DNSSEC and > > used as a basis for authentication in protocols that use domain = names as > > identifiers. Possible starting points for these deliverables = include > > draft-hallambaker-certhash, draft-hoffman-keys-linkage-from-dns, = and > > draft-josefsson-keyassure-tls. > > > > The mechanisms developed by this group will address bindings = between > > domain names and keys, allowing flexibility for all key-transport > > mechanisms supported by the application protocols addressed (e.g., = both > > self-signed and CA-issued certificates for use in TLS). > > > > The solutions specified by this working group rely upon the = security of > > the DNS to provide source authentication for public keys. The = decision > > whether the chain of trust provided by DNSSEC is sufficient to = trust the > > key, or whether additional mechanisms are required to determine = the > > acceptability of a key, is left to the entity that uses the key > > material. In addition to the protections afforded by DNSSEC, the > > protocols and mechanisms designed by this working group require = securing > > the "last hop" by operating a local DNS resolver or securing the > > connection to remote resolver - this WG will not specify new = mechanisms > > to secure that hop, but will reference existing specifications or > > document existing methods in order to allow implementations to > > interoperate securely. > > > > Initial deliverables for this working group are limited to = distribution > > of bindings between names within the zone operator's control and = public > > keys. More general statements of policy for a domain are out of = scope, > > and new tasks in this area may only be adopted through a = re-chartering. > > > > The group may also create documents that describe how protocol = entities > > can discover and validate these bindings in the execution of = specific > > applications. This work would be done in coordination with the = IETF > > Working Groups responsible for the protocols. >=20 > While I found Adam's draft interesting and worthy I really think it > twists the problem around by putting DNSSEC into CERT, while we agreed > to work on putting CERTs into DNSSEC. >=20 > Also if we are to take "serialization issue" to Quebec then I would = love > to hear more opinions from people who *haven't spoken* yet. And this > really applies to everybody - please cool your heads before replying. >=20 > Thanks, > O. >=20 > On 13.7.2011 17:50, Phillip Hallam-Baker wrote: > > On Wed, Jul 13, 2011 at 10:46 AM, Eric Osterweil = wrote: > > > >> > >> On Jul 13, 2011, at 10:24 AM, Nicholas Weaver wrote: > >> > >>> > >>> On Jul 13, 2011, at 6:37 AM, Phillip Hallam-Baker wrote: > >>>> Adam has actual measurements to back up his claim that support = for > >> unknown records is absent in a prohibitively large number of = places. The > >> only thing that surprises me about his numbers is that I expected = them to be > >> much worse. That is possibly an artifact of doing the measurements = on Linux. > >>> > >>> Its better than you think, but not great, when measured through = Netalyzr. > >> http://www.icir.org/christian/publications/2011-satin-netalyzr.pdf > >>> > >>> As importantly, its basically the same as TXT records, and its the = same > >> ones which fail. > >>> > >>> But more importantly, although we don't have the code to test for = it yet, > >> I suspect that the same set of resolvers that can't handle unknown = resource > >> records is the same set that strips/chokes on DNSSEC records so you = can't > >> get DS records, NSEC/NSEC3, etc... > >>> > >>> > >>> Client resolvers for DNSSEC MUST validate locally (the recursive = resolver > >> can't be trusted, full stop), and MUST be willing to bypass the = recursive > >> resolver infrastructure (the recursive resolver may fail to pass > >> DNSSEC-related records properly). > >> > >> This "full stop" issue may, or may not, be true but one thing I = think > >> deserves a "full stop" is that embedding part of DNSSEC's logic in = a place > >> that is _not_ DNS suffers a lot of architectural and operational = complexity. > >> Trusting resolvers is one issue, putting data in a different = protocols and > >> trying to cobble DNSSEC-like-validation into remote protocols is = the issue I > >> think needs attention. We've seen a lot of one-off DNS resolver > >> implementations and I would argue a lot of _those_ are responsible = for the > >> brokeness that you have measured. Thus, let's be very weary of = adding new > >> points of brokeness that report to support DNSSEC-like semantics = and then > >> fail to keep up w/ the protocol's evolution. > > > > > > We saw the same sort of thing with deployment of SET, or rather the > > non-deployment as it turned out. > > > > Certain deployment decisions by certain parties meant that we only = got one > > chance to deploy SET. By the time we had real world experience and = knew the > > bits that needed fixing we were unable to make changes there or = anywhere > > else. > > > > > > PKI systems are inherently complex because they are the interface to = the > > trust infrastructure of the real world and the real world is = complex. > > > > Rather than having people quote what they imagine the end to end = principle > > to be, I would encourage them to read what David Clark actually = wrote. It is > > an argument about complexity and in particular the best places to = manage > > that complexity. > > > > I don;t want to be speaking for David here, but he is not a rigid = ideologue > > by any stretch of the imagination. The end to end argument is an = argument > > about practicality and it applies to a specific situation 20 years = ago. It > > was never intended to be stated as an absolute truth. > > > > It is not an argument about security either. 'End to end' security = predated > > the Internet and was and is acknowledged to be a form of security = that is > > desirable in an abstract sense but frequently impractical. One Time = Pads > > provide provably unbreakable security, Quantum Cryptography is = theoretically > > unbreakable, but systems built around those schemes have turned out = to fail > > in the real world because it is just not practical to build and use = them in > > a perfect way. > > > > > > At the time the paper was written a computer system capable of = running IP > > protocols was $200K and up. Micros existed but they were limited to = 64Kb of > > memory, not really what you want to be writing an IP stack in. > > > > The telephone system has the complexity in the middle because it is = a 100 > > year old system and the middle is the only place that could be = easily > > changed. It was also at the time the design was chosen a system = operated by > > one single entity. > > > > > > The 'end to end' argument is really an argument that you don't want = to put > > complexity into the inter-network. At the time the client endpoint = was the > > only other place it could go. For the past 10-15 years we have seen = the > > difficulty of making changes at the client increase to the point = that it is > > very difficult to achieve. > > > > The DNS resolver is my preferred point to put DNSSEC processing = because it > > means that I can upgrade my DNSSEC processing by upgrading that one = single > > piece of infrastructure. That means that I have to have a secure = means of > > communicating with my trusted resolver, but that is a solvable = problem (e.g. > > DPLS). > > > > > > It is one thing to say that we will not address issues like DPLS and = chains > > in certs or OCSP, quite another to state that we will write a spec = that > > insists that the only valid deployment is one that is totally = impractical. > > > > The only valid requirement for DANE is that the DNSSEC records MUST = have > > been validated in a trustworthy fashion. Going beyond that is = ideology. > > Security reacts really badly to ideology. >=20 >=20 > -- > Ond=F8ej Sur=FD > vedouc=ED v=FDzkumu/Head of R&D department > ------------------------------------------- > CZ.NIC, z.s.p.o. -- Laborato=F8e CZ.NIC > Americka 23, 120 00 Praha 2, Czech Republic > mailto:ondrej.sury@nic.cz http://nic.cz/ > tel:+420.222745110 fax:+420.222745112 > ------------------------------------------- > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane >=20 >=20 >=20 > --=20 > Website: http://hallambaker.com/ >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From zack.weinberg@gmail.com Wed Jul 13 13:24:28 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12BF211E80F1 for ; Wed, 13 Jul 2011 13:24:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TB0Cu3Rh8wpz for ; Wed, 13 Jul 2011 13:24:27 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6A23311E807D for ; Wed, 13 Jul 2011 13:24:27 -0700 (PDT) Received: by pzk5 with SMTP id 5so7217473pzk.31 for ; Wed, 13 Jul 2011 13:24:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Qz2m+S+41Ll4Inkdbih2sOFnljSytJwoWEObO8/2Anw=; b=p5oe5tK3pGIju98CkCJ0B++06qkf+vZefpBl211hcJKmYG0DqoqrUrAeYOpIR9ycs/ WXUsvySWErfpXPd0ILthULbFLVa2vB3z0kX6kXG/YDcV3LFrSzooHxwcNmLwZWdwabe0 rRSvcEV74HSgwHyT9TxAbV5dX1iAmUuOdkmEc= MIME-Version: 1.0 Received: by 10.68.4.68 with SMTP id i4mr1936365pbi.515.1310588666177; Wed, 13 Jul 2011 13:24:26 -0700 (PDT) Sender: zack.weinberg@gmail.com Received: by 10.68.55.137 with HTTP; Wed, 13 Jul 2011 13:24:26 -0700 (PDT) In-Reply-To: References: <4A953B0A-3910-4DEC-BE13-9B6F2E0815B2@kumari.net> <4E1C89B9.8030100@verisign.com> <4E1D91F2.7090109@nic.cz> <4E1D9745.4070802@nic.cz> Date: Wed, 13 Jul 2011 13:24:26 -0700 X-Google-Sender-Auth: sEJZX3dBGgREgYls65tSUXROrx0 Message-ID: From: Zack Weinberg To: Paul Wouters Content-Type: text/plain; charset=UTF-8 Cc: DANE WG Subject: Re: [dane] readability, was Re: Opening issues... X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2011 20:24:28 -0000 On Wed, Jul 13, 2011 at 10:41 AM, Paul Wouters wrote: > I've kinda stopped trying to read people's postings made with the gmail web > client. It takes me 30 seconds or more to find out if a block of text is new or > quoted. Folks who would like Gmail to behave more interoperably can persuade it to do so by clicking the "<< Plain Text" option at the top of any composition window. As far as I can tell, this setting is persistent; you should only have to do it once. It'll still put your cursor in the wrong place for replies, and there seems to be no way to get mail and composition windows in a monospace font, but those are not that big a deal. zw From jakob@kirei.se Thu Jul 14 02:52:32 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A156621F8A42 for ; Thu, 14 Jul 2011 02:52:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.465 X-Spam-Level: X-Spam-Status: No, score=-0.465 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_SE=0.35, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id REK5ds8YUZ2l for ; Thu, 14 Jul 2011 02:52:28 -0700 (PDT) Received: from spg.kirei.se (spg.kirei.se [IPv6:2001:67c:394:15::9]) by ietfa.amsl.com (Postfix) with ESMTP id E9F4421F8A1A for ; Thu, 14 Jul 2011 02:52:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kirei.se; s=spg20100524; h=received:subject:mime-version:content-type:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to:x-mailer; bh=y0SKtN2uMY5Y49NAh2EzWybNbKXKLOEIaC+1Lcbut6g=; b=bTyPdO2Hwlz5EPZ0GU0TXhoXziw+98ScgMPmBQy2+xPApi9u7ENTk3U/xxC/XO4ZIeXIr+GTZEQCb thZ1f5V73Fblu3IbVmR0yz0mQBh1dRO0eF/GItShSq0gGza7usTxHjoTWkc/ESFlSzCsN7gY6VDPnS bV7e1+ZDAgBas3+o= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg-relay.kirei.se (Halon Mail Gateway) with ESMTPS; Thu, 14 Jul 2011 11:52:17 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Jakob Schlyter In-Reply-To: Date: Thu, 14 Jul 2011 11:52:14 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <14C338B3-BBBE-4C23-BD63-E535E777EBFF@kirei.se> References: <4A953B0A-3910-4DEC-BE13-9B6F2E0815B2@kumari.net> <4E1C89B9.8030100@verisign.com> <4E1D91F2.7090109@nic.cz> <4E1D9745.4070802@nic.cz> <4E1DC525.60008@nic.cz> <445E74A0-05E4-47E0-95DB-27BF356BC296@vpnc.org> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1084) Cc: Paul Hoffman , DANE WG Subject: Re: [dane] Opening issues... X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2011 09:52:33 -0000 On 13 jul 2011, at 18.43, Phillip Hallam-Baker wrote: * The Serialization Draft go to DNSEXT because the question at issue = there is how to process a DNSSEC chain in isolation of DNS protocol. >=20 > This is going to be an important and useful capability in its own = right. Knowing what parts of the chain are necessary for archival = purposes is essential if we are to achieve accountability or = auditability. I agree (and this is indeed more of a DNS protocol issue than a DANE = issue). > * The 'how to stick chain in PKIX' part goes to PKIX.=20 >=20 > This can be a relatively short draft consisting of extension = declarations and security considerations, maybe some protocol. I agree (although it is up to PKIX to pick this up). jakob From hallam@gmail.com Sun Jul 17 07:17:42 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 469D621F85F6 for ; Sun, 17 Jul 2011 07:17:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.065 X-Spam-Level: X-Spam-Status: No, score=-3.065 tagged_above=-999 required=5 tests=[AWL=-0.351, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s+iqYDCWZbg2 for ; Sun, 17 Jul 2011 07:17:41 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3F4F221F85EA for ; Sun, 17 Jul 2011 07:17:38 -0700 (PDT) Received: by yie30 with SMTP id 30so1178245yie.31 for ; Sun, 17 Jul 2011 07:17:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=vKeG3Rmr1j9efwgYQxvp94rIajRs0UEacZ8ZgOu6Y+4=; b=vm3zKhYs9ajWjNqQiKeyMQC6ez04i/ognYbhsYHTeAhHXBKXVxVjXYJQr0o4TJdN9g 1KkBtjvRcCqWrfGdH48rAe0qC91pGEhyqBFNyL5ZSPnmUKgEobw02LI+1w6849yxqcoE 9Z1+P2nREVhEomnWhqKNQfVoTAAYlr43WB7kU= MIME-Version: 1.0 Received: by 10.101.214.10 with SMTP id r10mr4639080anq.115.1310912256500; Sun, 17 Jul 2011 07:17:36 -0700 (PDT) Received: by 10.100.134.9 with HTTP; Sun, 17 Jul 2011 07:17:36 -0700 (PDT) Date: Sun, 17 Jul 2011 10:17:36 -0400 Message-ID: From: Phillip Hallam-Baker To: dane@ietf.org Content-Type: multipart/alternative; boundary=00504502984361628804a8448bb4 Subject: [dane] Fixing DANE to resolve properly with DNS X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jul 2011 14:17:42 -0000 --00504502984361628804a8448bb4 Content-Type: text/plain; charset=ISO-8859-1 At present the draft makes no mention of CNAME, the only mention of wildcards is "Wild Cards -- Covered in the TLSA request syntax. Redirection -- Covered in the TLSA request syntax." You may think this answers the question, I do not. This is proof by unsubstantiated assertion. The issues that concern me are use cases of the form: 1) A DNS administrator wishes to create an equivalence between two DNS names such that all resources that are associated with one will apply to the other. e.g. alias www.example.com to example.com www.example.com CNAME example.com _443._tcp.example.com TLSA .... Problem: No means is specified that will allow a client to discover the TLSA record. Attempting to resolve for _443._tcp.www.example.com results in 'not found'. So the administrator is required to specify: www.example.com CNAME example.com _443._tcp.www.example.com TLSA .... _443._tcp.example.com TLSA .... This is bad because it means that we now have two points where the TLSA record has to be maintained. The value of having an alias is lost. Possible solution: One way to solve this is to note that any client is going to have to also look up the A record for the service. Thus if the A record lookup returns an alias, the client is required to retry the lookup for the canonical name. A typical lookup is thus going to be: Phase 1: Query1: www.example.com ? A Query2: _443._tcp.www.example.com ? TLSA Both queries fail but we get a CNAME as an additional record (and likely the A record). So we perform a second phase: Query1: example.com ? A Query2: _443._tcp.example.com ? TLSA This appears to work with any form of aliasing. The rule that I think applies to prefixes is that they only work on a canonical name. So don't look for them till they are canonical. 2) Wildcards Wildcards are much harder to deal with because they began as a server feature, not as part of the protocol. There is no midpoint wildcard (x.*.y.z) A wildcard of the form *.example.com is going to play havoc with any prefixed record as it will resolve for any prefix. Conclusion: TLSA records SHOULD NOT be wildcarded. To create the effect of a wildcard TLSA record the approach that should be used is to apply the wildcard to an alias, for example: *.example.com CNAME wildcard.example.com _443._tcp.wildcard.example.com TLSA .... wildcard.example.com A 127.0.0.1 Attempting to resolve any domain in example.com (other than wildcard.example.com) will now result in a wildcarded CNAME being returned that provides a canonical name to which the prefix can be applied. These approaches are actually general and can be applied when any prefixed record is being used. -- Website: http://hallambaker.com/ --00504502984361628804a8448bb4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable At present the draft makes no mention of CNAME, the only mention of wildcar= ds is

"Wild Cards -- Covered in the TLSA request syntax. Redirection -- Covered in the TLSA request syntax."
=
You may think this answers the question, I do not. This is p= roof by unsubstantiated assertion.


The issues that concern me are use cases of the form:

<= div>1) A DNS administrator wishes to create an equivalence between two DNS = names such that all resources that are associated with one will apply to th= e other.


=

www.example.co= m =A0 =A0 =A0 =A0 =A0 =A0 =A0 CNAME exam= ple.com
_443._tcp.example.com         TLSA  ....


Problem: No means is specified tha= t will allow a client to discover the TLSA record.

Attempting to resolve for=A0_443._tcp.www.example.com results in = 'not found'. So the administrator is required to specify:

www.example.com =A0 =A0 =A0 =A0 =A0 =A0 =A0 CNAME example.com
_443._tc=
p.www.example.com     TLSA  ....
_443._tcp.example.com         TLSA  ....=

This is bad because it means that we now have two= points where the TLSA record has to be maintained. The value of having an = alias is lost.


Possible solution:

One way to solve this is to note that any client is goi= ng to have to also look up the A record for the service. Thus if the A reco= rd lookup returns an alias, the client is required to retry the lookup for = the canonical name.

A typical lookup is thus going to be:

Phase 1:

Query1: =A0=A0www.example.com ? A
Query2: =A0_= 443._tcp.www.example.com ? TLSA<= /span>

Both queries fail but we get a = CNAME as an additional record (and likely the A record). So we perform a se= cond phase:

Query1: = =A0=A0example.com ? A
Query2: =A0_443._tcp.example.com ? TLSA

This appears to work with any form of aliasing. The rule that I think appli= es to prefixes is that they only work on a canonical name. So don't loo= k for them till they are canonical.


2) Wildcards

Wildcards are much harder to dea= l with because they began as a server feature, not as part of the protocol.= There is no midpoint wildcard (x.*.y.z)

A wildcar= d of the form *.example.com is going to = play havoc with any prefixed record as it will resolve for any prefix.

Conclusion: TLSA records SHOULD NOT be wildcarded.


To create the effect of a wildcard TLSA= record the approach that should be used is to apply the wildcard to an ali= as, for example:

*.example.com =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 CNAME wildcard.example.com
_443._tcp.wildcard.example.com      TLSA  ....
=
wildcard.example.com           =
     A 127.0.0.1
=
Attempting to resolve any = domain in example.com (other than wildcard.example.com) will now result= in a wildcarded CNAME being returned that provides a canonical name to whi= ch the prefix can be applied.


These approaches are actually general an= d can be applied when any prefixed record is being used.

-- <= br>Website: http://hallambaker.com/=

--00504502984361628804a8448bb4-- From jakob@kirei.se Sun Jul 17 11:35:51 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 763D421F8569 for ; Sun, 17 Jul 2011 11:35:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.617 X-Spam-Level: X-Spam-Status: No, score=0.617 tagged_above=-999 required=5 tests=[AWL=-0.966, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_SE=0.35, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9tqM1qETv2oT for ; Sun, 17 Jul 2011 11:35:50 -0700 (PDT) Received: from spg.kirei.se (spg.kirei.se [IPv6:2001:67c:394:15::9]) by ietfa.amsl.com (Postfix) with ESMTP id D103021F8568 for ; Sun, 17 Jul 2011 11:35:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kirei.se; s=spg20100524; h=received:references:in-reply-to:mime-version:content-transfer-encoding: content-type:message-id:cc:x-mailer:from:subject:date:to; bh=QRTqj7pjcVhGRurLi+HITTIDq7bTabVHUcTXs3Wivk0=; b=xqf788mroLwaUrx4EwmwCwI5/8dkJ4tJ0exw//Vy+EJVhdLD04iHV6lxFn9b7nTvLL+Ku7UJf/abv PiNH3XuZ9WViYphmQtLR3pjG1/jVPDxd6fRcFRD8HraO5m6otNkHL615dEyndt+g/RXge5gHXE32CP 4A7Rh2NwhmOlKG/4= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg-relay.kirei.se (Halon Mail Gateway) with ESMTPS; Sun, 17 Jul 2011 20:35:46 +0200 (CEST) References: In-Reply-To: Mime-Version: 1.0 (iPad Mail 8J3) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-1--239417781 Message-Id: <16351912-18B3-45D5-8C0E-B01D434B0F02@kirei.se> X-Mailer: iPad Mail (8J3) From: Jakob Schlyter Date: Sun, 17 Jul 2011 20:35:41 +0200 To: Phillip Hallam-Baker Cc: "dane@ietf.org" Subject: Re: [dane] Fixing DANE to resolve properly with DNS X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jul 2011 18:35:51 -0000 --Apple-Mail-1--239417781 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii 17 jul 2011 kl. 16:17 skrev Phillip Hallam-Baker : > 1) A DNS administrator wishes to create an equivalence between two DNS nam= es such that all resources that are associated with one will apply to the ot= her. >=20 > e.g. alias www.example.com to example.com >=20 >=20 > www.example.com CNAME example.com > _443._tcp.example.com TLSA .... Why not add a CNAME for the prefixed name? E.g.,=20 _443._tcp.example.com. CNAME _443._tcp.example.com. > 2) Wildcards >=20 > Wildcards are much harder to deal with because they began as a server feat= ure, not as part of the protocol. There is no midpoint wildcard (x.*.y.z) >=20 > A wildcard of the form *.example.com is going to play havoc with any prefi= xed record as it will resolve for any prefix. >=20 > Conclusion: TLSA records SHOULD NOT be wildcarded. I'm not too sure this is a real problem, given that people already played ha= voc by using wildcards in the first place. A lot of other services are alrea= dy broken when wildcards are used.=20 > To create the effect of a wildcard TLSA record the approach that should be= used is to apply the wildcard to an alias, for example: >=20 > *.example.com CNAME wildcard.example.com > _443._tcp.wildcard.example.com TLSA .... > wildcard.example.com A 127.0.0.1 >=20 > Attempting to resolve any domain in example.com (other than wildcard.examp= le.com) will now result in a wildcarded CNAME being returned that provides a= canonical name to which the prefix can be applied. Sure, although that would work only if the TLSA client can detect the addres= s was the result of a CNAME.=20 Jakob --Apple-Mail-1--239417781 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
17 jul 2011 kl. 16:17 skrev Phillip Hal= lam-Baker <hallam@gmail.com>:<= br>
1) A DNS adm= inistrator wishes to create an equivalence between two DNS names such that a= ll resources that are associated with one will apply to the other.



www.example.com             &nb= sp; CNAME exam= ple.com
_443._tcp.example.com         TLSA  ....

Why not add a CNAME for the prefi= xed name? E.g., 
_443._tcp.example.com. CNAME _443._tcp.example.com.=


2) Wildcards

= Wildcards are much harder to deal with because they began as a server featur= e, not as part of the protocol. There is no midpoint wildcard (x.*.y.z)

A wildcard of the form *.example.com is going to play havoc w= ith any prefixed record as it will resolve for any prefix.

Conclusion: TLSA records SHOULD NOT be wildcarded.
=

I'm not too sure this is a real prob= lem, given that people already played havoc by using wildcards in the first p= lace. A lot of other services are already broken when wildcards are used.&nb= sp;

To cre= ate the effect of a wildcard TLSA record the approach that should be used is= to apply the wildcard to an alias, for example:

*.example.com               &nb= sp;       CNAME wildcard.example.com
=
Attempting to resolve any domain in example.com (other than w= ildcard.example.com) will now result in a wildcarded CNAME being ret= urned that provides a canonical name to which the prefix can be applied.

Sure, although that would work only if t= he TLSA client can detect the address was the result of a CNAME. 
=

  Jakob

= --Apple-Mail-1--239417781-- From hallam@gmail.com Sun Jul 17 15:30:32 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C0CF21F87C2 for ; Sun, 17 Jul 2011 15:30:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.056 X-Spam-Level: X-Spam-Status: No, score=-3.056 tagged_above=-999 required=5 tests=[AWL=-0.342, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mgcESlHb8pkQ for ; Sun, 17 Jul 2011 15:30:31 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5884521F87BC for ; Sun, 17 Jul 2011 15:30:31 -0700 (PDT) Received: by yxp4 with SMTP id 4so1319852yxp.31 for ; Sun, 17 Jul 2011 15:30:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0O0FNyQV1Gmjpmy2Hui1iyDxEfLKxeZxQpMAlUciQoY=; b=WqLbzlCLysEeeT3xiV8dVIptxphUD52t21Yjaz2nuXrULoKwAOimCVoGWuNGVhwfNe IhsV2XHjzp6OeGl18lQwU+45fPE2in/K+p35J4/8m3DCxTlIlfeHGCEsDUCHRWgCsRw9 vsvxRmt3YAUsoXsa+l6+md+XyyrEvy4P/lstg= MIME-Version: 1.0 Received: by 10.100.75.12 with SMTP id x12mr4914574ana.27.1310941830531; Sun, 17 Jul 2011 15:30:30 -0700 (PDT) Received: by 10.100.134.9 with HTTP; Sun, 17 Jul 2011 15:30:30 -0700 (PDT) In-Reply-To: <16351912-18B3-45D5-8C0E-B01D434B0F02@kirei.se> References: <16351912-18B3-45D5-8C0E-B01D434B0F02@kirei.se> Date: Sun, 17 Jul 2011 18:30:30 -0400 Message-ID: From: Phillip Hallam-Baker To: Jakob Schlyter Content-Type: multipart/alternative; boundary=001636b2af5321490604a84b6e4a Cc: "dane@ietf.org" Subject: Re: [dane] Fixing DANE to resolve properly with DNS X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jul 2011 22:30:32 -0000 --001636b2af5321490604a84b6e4a Content-Type: text/plain; charset=ISO-8859-1 On Sun, Jul 17, 2011 at 2:35 PM, Jakob Schlyter wrote: > 17 jul 2011 kl. 16:17 skrev Phillip Hallam-Baker : > > 1) A DNS administrator wishes to create an equivalence between two DNS > names such that all resources that are associated with one will apply to the > other. > > e.g. alias www.example.com to > example.com > > > www.example.com CNAME > example.com > > _443._ tcp.example.com TLSA .... > > > Why not add a CNAME for the prefixed name? E.g., > _443._tcp.example.com. CNAME _443._tcp.example.com. > That defeats the purpose of CNAME, if you are going to do that you might as well just copy all the entries from one node to the other. Maintaining the CNAME links is going to be pretty much as hard as copying the destination. The problem is harder when you have outsourcing. If I CNAME www.hallambaker.com to my blogger blog, I want that to map to anything Google then do from then on without having to do any more config. In fact I would have to change my DNS hosting to do any more config. Support for CNAME means supporting the use cases CNAME is designed to meet, not merely proposing a mechanism that works technically but looses the point of CNAME entirely. > 2) Wildcards > > Wildcards are much harder to deal with because they began as a server > feature, not as part of the protocol. There is no midpoint wildcard > (x.*.y.z) > > A wildcard of the form *. example.com is going to play > havoc with any prefixed record as it will resolve for any prefix. > > Conclusion: TLSA records SHOULD NOT be wildcarded. > > > I'm not too sure this is a real problem, given that people already played > havoc by using wildcards in the first place. A lot of other services are > already broken when wildcards are used. > I think you need to be a bit more specific to make that argument. Wildcards work just fine for HTTP. If you are proposing a spec to work with HTTP you probably want to make it work with wildcards. I am proposing a mechanism here that makes it work properly. My personal criteria for whether I support the draft in IETF last call is whether it actually works with DNS or not. If the spec does not actually work with aliases or wildcards then I am not going to be able to build on it myself so I won't be able to recommend it for any status higher than experimental. Again, I am proposing a fix here, not just raising a problem. -- Website: http://hallambaker.com/ --001636b2af5321490604a84b6e4a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Sun, Jul 17, 2011 at 2:35 PM, Jakob S= chlyter <jakob@kirei= .se> wrote:
17 jul 2011 kl. 16:17 skrev Phillip Hallam-Ba= ker <hallam@gmail.= com>:

1) A DNS administrator wishes to create an equivalence= between two DNS names such that all resources that are associated with one= will apply to the other.



www.example.com =A0 =A0 =A0 = =A0 =A0 =A0 =A0 CNAME = example.com 
_443._tcp.ex=
ample.com         TLSA  ....

Why not add a CNAME for= the prefixed name? E.g.,=A0
_443._tcp.example.com. CNAME _443._tcp.example.com.

That defeats the purpose of CNAME, i= f you are going to do that you might as well just copy all the entries from= one node to the other. Maintaining the CNAME links is going to be pretty m= uch as hard as copying the destination.

The problem is harder when you have outsourcing. If I C= NAME www.hallambaker.com to my b= logger blog, I want that to map to anything Google then do from then on wit= hout having to do any more config. In fact I would have to change my DNS ho= sting to do any more config.

Support for CNAME means supporting the use cases CNAME = is designed to meet, not merely proposing a mechanism that works technicall= y but looses the point of CNAME entirely.
=A0
<= div>
2) Wildcards

Wildca= rds are much harder to deal with because they began as a server feature, no= t as part of the protocol. There is no midpoint wildcard (x.*.y.z)

A wildcard of the form *.exa= mple.com is going to play havoc with any prefixed record as it will res= olve for any prefix.

Conclusion: TLSA records SHOULD NOT be wildcarded.

I'm not too sure this is= a real problem, given that people already played havoc by using wildcards = in the first place. A lot of other services are already broken when wildcar= ds are used.=A0

I think you need to be a bit more sp= ecific to make that argument.

Wildcards work just = fine for HTTP. If you are proposing a spec to work with HTTP you probably w= ant to make it work with wildcards.

=A0I am proposing a mechanism here that makes it work p= roperly.


My personal criteria for w= hether I support the draft in IETF last call is whether it actually works w= ith DNS or not.

If the spec does not actually work with aliases or wild= cards then I am not going to be able to build on it myself so I won't b= e able to recommend it for any status higher than experimental.

Again, I am proposing a fix here, not just raising a problem= .

--
Website: http://hallambaker.com/

--001636b2af5321490604a84b6e4a-- From paul.hoffman@vpnc.org Sun Jul 17 15:50:18 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D868121F87C9 for ; Sun, 17 Jul 2011 15:50:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.65 X-Spam-Level: X-Spam-Status: No, score=-102.65 tagged_above=-999 required=5 tests=[AWL=-0.051, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gjllluIeydZJ for ; Sun, 17 Jul 2011 15:50:18 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id C237921F87BC for ; Sun, 17 Jul 2011 15:50:17 -0700 (PDT) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p6HMnxvK033665 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sun, 17 Jul 2011 15:50:00 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Paul Hoffman In-Reply-To: Date: Sun, 17 Jul 2011 15:50:11 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: DANE WG X-Mailer: Apple Mail (2.1084) Subject: Re: [dane] Fixing DANE to resolve properly with DNS X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jul 2011 22:50:19 -0000 On Jul 17, 2011, at 7:17 AM, Phillip Hallam-Baker wrote: > At present the draft makes no mention of CNAME, the only mention of = wildcards is >=20 > "Wild Cards -- Covered in the TLSA request syntax. > Redirection -- Covered in the TLSA request syntax." >=20 > You may think this answers the question, I do not. This is proof by = unsubstantiated assertion. Actually, we didn't think it answered the question; we just got lazy. We = should add more about this in the next draft, definitely. > The issues that concern me are use cases of the form: >=20 > 1) A DNS administrator wishes to create an equivalence between two DNS = names such that all resources that are associated with one will apply to = the other. >=20 > e.g. alias www.example.com to example.com >=20 >=20 > www.example.com CNAME example.com > _443._tcp.example.com TLSA .... >=20 >=20 > Problem: No means is specified that will allow a client to discover = the TLSA record. >=20 > Attempting to resolve for _443._tcp.www.example.com results in 'not = found'. So the administrator is required to specify: >=20 > www.example.com CNAME example.com > _443._tcp.www.example.com TLSA .... > _443._tcp.example.com TLSA .... >=20 > This is bad because it means that we now have two points where the = TLSA record has to be maintained. The value of having an alias is lost. It does mean that there are two points where the TLSA record has to be = maintained, and that is a security feature. In addition to your example, = consider: www.example.com CNAME www.notexample.notcom _443._tcp.www.example.com TLSA ... If the zone administrator for www.example.com can specify what the = certificates should be validated for www.notexample.notcom, that is a = serious security flaw. > Possible solution: >=20 > One way to solve this is to note that any client is going to have to = also look up the A record for the service. Thus if the A record lookup = returns an alias, the client is required to retry the lookup for the = canonical name. >=20 > A typical lookup is thus going to be: >=20 > Phase 1: >=20 > Query1: www.example.com ? A > Query2: _443._tcp.www.example.com ? TLSA >=20 > Both queries fail but we get a CNAME as an additional record (and = likely the A record). So we perform a second phase: >=20 > Query1: example.com ? A > Query2: _443._tcp.example.com ? TLSA >=20 > This appears to work with any form of aliasing. The rule that I think = applies to prefixes is that they only work on a canonical name. So don't = look for them till they are canonical. The first part is definitely correct: the prefixes only apply to the = actual name of the host. I don't see the reason for the second part, = however. Why not look up the prefixed name? If you get NXDOMAIN and an = alias for the unprefixed name, you have lost nothing. > 2) Wildcards >=20 > Wildcards are much harder to deal with because they began as a server = feature, not as part of the protocol. There is no midpoint wildcard = (x.*.y.z) >=20 > A wildcard of the form *.example.com is going to play havoc with any = prefixed record as it will resolve for any prefix. >=20 > Conclusion: TLSA records SHOULD NOT be wildcarded. Please be more specific. Do you mean "the host name for which there is a = prefixed TLSA record SHOULD NOT also be wildcarded" or "the host name = that contains a prefix and that has a TLSA record SHOULD NOT be = wildcarded"? > To create the effect of a wildcard TLSA record the approach that = should be used is to apply the wildcard to an alias, for example: >=20 > *.example.com CNAME wildcard.example.com > _443._tcp.wildcard.example.com TLSA .... > wildcard.example.com A 127.0.0.1 >=20 > Attempting to resolve any domain in example.com (other than = wildcard.example.com) will now result in a wildcarded CNAME being = returned that provides a canonical name to which the prefix can be = applied. >=20 >=20 > These approaches are actually general and can be applied when any = prefixed record is being used. Have they been dealt with in other IETF protocols that use prefixes? It = would be great if we can reuse words from those RFCs. --Paul Hoffman From i.grok@comcast.net Sun Jul 17 15:53:13 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C8A721F8877 for ; Sun, 17 Jul 2011 15:53:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.415 X-Spam-Level: X-Spam-Status: No, score=-102.415 tagged_above=-999 required=5 tests=[AWL=0.184, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yeyfG2G7yRhm for ; Sun, 17 Jul 2011 15:53:12 -0700 (PDT) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [76.96.62.16]) by ietfa.amsl.com (Postfix) with ESMTP id AFF6821F8876 for ; Sun, 17 Jul 2011 15:53:09 -0700 (PDT) Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta01.westchester.pa.mail.comcast.net with comcast id 9AtA1h0020QuhwU51AtAQ9; Sun, 17 Jul 2011 22:53:10 +0000 Received: from odin.ulthar.us ([68.33.77.0]) by omta02.westchester.pa.mail.comcast.net with comcast id 9At91h00D00PQ6U3NAt9dj; Sun, 17 Jul 2011 22:53:10 +0000 Received: from odin.ulthar.us (localhost [127.0.0.1]) by odin.ulthar.us (8.14.4/8.14.3) with ESMTP id p6HMr6cS002212 for ; Sun, 17 Jul 2011 18:53:06 -0400 Received: (from draco@localhost) by odin.ulthar.us (8.14.4/8.14.4/Submit) id p6HMr6Mv002210 for dane@ietf.org; Sun, 17 Jul 2011 18:53:06 -0400 Date: Sun, 17 Jul 2011 18:53:06 -0400 From: Scott Schmit To: dane@ietf.org Message-ID: <20110717225306.GA2009@odin.ulthar.us> Mail-Followup-To: dane@ietf.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Fixing DANE to resolve properly with DNS X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jul 2011 22:53:13 -0000 On Sun, Jul 17, 2011 at 10:17:36AM -0400, Phillip Hallam-Baker wrote: > One way to solve this is to note that any client is going to have to also > look up the A record for the service. Thus if the A record lookup returns an > alias, the client is required to retry the lookup for the canonical name. > > > To create the effect of a wildcard TLSA record the approach that should be > used is to apply the wildcard to an alias, for example: > > > Attempting to resolve any domain in example.com (other than > wildcard.example.com) will now result in a wildcarded CNAME being returned > that provides a canonical name to which the prefix can be applied. > > These approaches are actually general and can be applied when any prefixed > record is being used. I agree with this approach -- this is how I saw it working too. -- Scott Schmit From hallam@gmail.com Sun Jul 17 17:33:39 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 953D021F886A for ; Sun, 17 Jul 2011 17:33:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.489 X-Spam-Level: X-Spam-Status: No, score=-3.489 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0D04TCjJGTIU for ; Sun, 17 Jul 2011 17:33:38 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7B80D21F8834 for ; Sun, 17 Jul 2011 17:33:38 -0700 (PDT) Received: by gyd5 with SMTP id 5so1266225gyd.31 for ; Sun, 17 Jul 2011 17:33:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=uMi6eijdkGTLJ+5Ze7RhqHgm+BjYr3Q2mEtAwEHtjQw=; b=YKRimjgg3/+yOcANU1QYCBMB4K3Wr8C9iVba9n59kbUOnXWNZU9lLKgg+bgJLGbZoQ bYPLFhvccG/Dr6sdKAkMXwC2QKIPKDnpmXDG0a4fbsANwLbC8K6zC2TH1wjZ9mLnSAcN 173vvvtHHrFGioZetJwRTfy2ppYaT+WoJCyK0= MIME-Version: 1.0 Received: by 10.100.75.12 with SMTP id x12mr4948821ana.27.1310949217119; Sun, 17 Jul 2011 17:33:37 -0700 (PDT) Received: by 10.100.134.9 with HTTP; Sun, 17 Jul 2011 17:33:37 -0700 (PDT) In-Reply-To: References: Date: Sun, 17 Jul 2011 20:33:37 -0400 Message-ID: From: Phillip Hallam-Baker To: Paul Hoffman Content-Type: multipart/alternative; boundary=001636b2af5367aec404a84d267a Cc: DANE WG Subject: Re: [dane] Fixing DANE to resolve properly with DNS X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 00:33:39 -0000 --001636b2af5367aec404a84d267a Content-Type: text/plain; charset=ISO-8859-1 On Sun, Jul 17, 2011 at 6:50 PM, Paul Hoffman wrote: > On Jul 17, 2011, at 7:17 AM, Phillip Hallam-Baker wrote: > > > A typical lookup is thus going to be: > > > > Phase 1: > > > > Query1: www.example.com ? A > > Query2: _443._tcp.www.example.com ? TLSA > > > > Both queries fail but we get a CNAME as an additional record (and likely > the A record). So we perform a second phase: > > > > Query1: example.com ? A > > Query2: _443._tcp.example.com ? TLSA > > > > This appears to work with any form of aliasing. The rule that I think > applies to prefixes is that they only work on a canonical name. So don't > look for them till they are canonical. > > The first part is definitely correct: the prefixes only apply to the actual > name of the host. I don't see the reason for the second part, however. Why > not look up the prefixed name? If you get NXDOMAIN and an alias for the > unprefixed name, you have lost nothing. > Looking up the prefixed name is not the problem, having to specify it for each alias is the problem. Better statement would be 'don't stop looking for them till you have a canonical name'. > > 2) Wildcards > > > > Wildcards are much harder to deal with because they began as a server > feature, not as part of the protocol. There is no midpoint wildcard > (x.*.y.z) > > > > A wildcard of the form *.example.com is going to play havoc with any > prefixed record as it will resolve for any prefix. > > > > Conclusion: TLSA records SHOULD NOT be wildcarded. > > Please be more specific. Do you mean "the host name for which there is a > prefixed TLSA record SHOULD NOT also be wildcarded" or "the host name that > contains a prefix and that has a TLSA record SHOULD NOT be wildcarded"? I mean that in general no TLSA record should ever be wildcarded, nor should any SRV, URI, ESRV, or any other record that takes a prefix. The only case where wildcarding a TSLA record is going to make sense is if the statement you want to make is for all TCP ports at a DNS name. The more general wildcard would be for all services running a specific protocol: _443._tcp.*.example.com To get that effect you need to introduce a layer of indirection and that is why fixing the CNAME semantics is vital. You can create a CNAME for *. example.com and that can point to a location that has the TLSA record. > > These approaches are actually general and can be applied when any > prefixed record is being used. > > Have they been dealt with in other IETF protocols that use prefixes? It > would be great if we can reuse words from those RFCs. > No, it has generally been held that this is an insoluble protocol problem. Retry on the canonical name is the simplest approach for DANE. For SRV and URI the objective is to support Web Services and the approach described in ESRV is more appropriate. That also has a two phase discovery approach but with two different RR types. The first phase uses the GSRV record which is never prefixed, the second looks for the ESRV record which is salways prefixed and always bound to a canonical name. The reason fixing SRV and URI does not help much on their own is that they are examples of advanced discovery services rather than an exhaustive enumeration of all possible advanced discovery services. The choice of discovery mechanism should be made by the site, not the Web Service protocol designer. -- Website: http://hallambaker.com/ --001636b2af5367aec404a84d267a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Sun, Jul 17, 2011 at 6:50 PM, Paul Ho= ffman <paul.h= offman@vpnc.org> wrote:
On Jul 17, 2011, at 7:17 AM, Phillip Hallam-Baker wrote:<= br>
=A0
> A typical lookup is thus going to be:
>
> Phase 1:
>
> Query1: =A0 www.e= xample.com ? A
> Query2: =A0_443._tcp.www.example.com ? TLSA
>
> Both queries fail but we get a CNAME as an additional record (and like= ly the A record). So we perform a second phase:
>
> Query1: =A0 example.c= om ? A
> Query2: =A0_443._= tcp.example.com ? TLSA
>
> This appears to work with any form of aliasing. The rule that I think = applies to prefixes is that they only work on a canonical name. So don'= t look for them till they are canonical.

The first part is definitely correct: the prefixes only apply to the = actual name of the host. I don't see the reason for the second part, ho= wever. Why not look up the prefixed name? If you get NXDOMAIN and an alias = for the unprefixed name, you have lost nothing.

Looking up the prefixed name is not the pr= oblem, having to specify it for each alias is the problem.

Better statement would be 'don't stop looking for them til= l you have a canonical name'.

=A0
> 2) Wildcards
>
> Wildcards are much harder to deal with because they began as a server = feature, not as part of the protocol. There is no midpoint wildcard (x.*.y.= z)
>
> A wildcard of the form *.example.com is going to play havoc with any prefixed record as it w= ill resolve for any prefix.
>
> Conclusion: TLSA records SHOULD NOT be wildcarded.

Please be more specific. Do you mean "the host name for which th= ere is a prefixed TLSA record SHOULD NOT also be wildcarded" or "= the host name that contains a prefix and that has a TLSA record SHOULD NOT = be wildcarded"?

I mean that in general no TLSA record should ever be wi= ldcarded, nor should any SRV, URI, ESRV, or any other record that takes a p= refix.

The only case where wildcarding a TSLA reco= rd is going to make sense is if the statement you want to make is for all T= CP ports at a DNS name.=A0


The more general wildcard would be for a= ll services running a specific protocol: _443._tcp.*.example.com

To get that effect you ne= ed to introduce a layer of indirection and that is why fixing the CNAME sem= antics is vital. You can create a CNAME for *.example.com and that can point to =A0a location that has the TLSA rec= ord.



> These approaches are actually general and can be applied when any pref= ixed record is being used.

Have they been dealt with in other IETF protocols that use prefixes? = It would be great if we can reuse words from those RFCs.

No, it has generally been held that this is an insoluble = protocol problem.


Retry on the canonical name is the simpl= est approach for DANE. For SRV and URI the objective is to support Web Serv= ices and the approach described in ESRV is more appropriate.=A0

That also has a two phase discovery approach but with two di= fferent RR types. The first phase uses the GSRV record which is never prefi= xed, the second looks for the ESRV record which is salways prefixed and alw= ays bound to a canonical name.
=A0
The reason fixing SRV and URI does not help much o= n their own is that they are examples of advanced discovery services rather= than an exhaustive enumeration of all possible advanced discovery services= . The choice of discovery mechanism should be made by the site, not the Web= Service protocol designer.

--
Website: http://h= allambaker.com/

--001636b2af5367aec404a84d267a-- From paul.hoffman@vpnc.org Sun Jul 17 18:00:07 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5E5821F86DE for ; Sun, 17 Jul 2011 18:00:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.649 X-Spam-Level: X-Spam-Status: No, score=-102.649 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k8a-nl5aPhIM for ; Sun, 17 Jul 2011 18:00:07 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 0AED221F8553 for ; Sun, 17 Jul 2011 18:00:06 -0700 (PDT) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p6I0xrSi037375 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sun, 17 Jul 2011 17:59:54 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Paul Hoffman In-Reply-To: Date: Sun, 17 Jul 2011 18:00:05 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4E3B800F-8A14-4027-BA98-E86B6785C1D3@vpnc.org> References: To: DANE WG X-Mailer: Apple Mail (2.1084) Subject: Re: [dane] Fixing DANE to resolve properly with DNS X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 01:00:08 -0000 On Jul 17, 2011, at 5:33 PM, Phillip Hallam-Baker wrote: > Better statement would be 'don't stop looking for them till you have a = canonical name'. That seems like good advice. We can add that. > > 2) Wildcards > > > > Wildcards are much harder to deal with because they began as a = server feature, not as part of the protocol. There is no midpoint = wildcard (x.*.y.z) > > > > A wildcard of the form *.example.com is going to play havoc with any = prefixed record as it will resolve for any prefix. > > > > Conclusion: TLSA records SHOULD NOT be wildcarded. >=20 > Please be more specific. Do you mean "the host name for which there is = a prefixed TLSA record SHOULD NOT also be wildcarded" or "the host name = that contains a prefix and that has a TLSA record SHOULD NOT be = wildcarded"? >=20 > I mean that in general no TLSA record should ever be wildcarded, nor = should any SRV, URI, ESRV, or any other record that takes a prefix. This seems like advice ("think carefully before wildcarding a TLSA = record") rather than a mandated (SHOULD/MUST) requirement. We can add = that. > The only case where wildcarding a TSLA record is going to make sense = is if the statement you want to make is for all TCP ports at a DNS name.=20= And that seems like a good reason to wildcard at the first prefix. > The more general wildcard would be for all services running a specific = protocol: _443._tcp.*.example.com >=20 > To get that effect you need to introduce a layer of indirection and = that is why fixing the CNAME semantics is vital. You can create a CNAME = for *.example.com and that can point to a location that has the TLSA = record. Sounds right. > > These approaches are actually general and can be applied when any = prefixed record is being used. >=20 > Have they been dealt with in other IETF protocols that use prefixes? = It would be great if we can reuse words from those RFCs. >=20 > No, it has generally been held that this is an insoluble protocol = problem. Good enough. --Paul Hoffman From i.grok@comcast.net Sun Jul 17 18:38:18 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB66E21F88E5 for ; Sun, 17 Jul 2011 18:38:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.507 X-Spam-Level: X-Spam-Status: No, score=-102.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fcw+q6Azibu4 for ; Sun, 17 Jul 2011 18:38:18 -0700 (PDT) Received: from qmta04.emeryville.ca.mail.comcast.net (qmta04.emeryville.ca.mail.comcast.net [76.96.30.40]) by ietfa.amsl.com (Postfix) with ESMTP id 5DB9621F88A6 for ; Sun, 17 Jul 2011 18:38:18 -0700 (PDT) Received: from omta17.emeryville.ca.mail.comcast.net ([76.96.30.73]) by qmta04.emeryville.ca.mail.comcast.net with comcast id 9C1i1h0061afHeLA4DeFNY; Mon, 18 Jul 2011 01:38:15 +0000 Received: from odin.ulthar.us ([68.33.77.0]) by omta17.emeryville.ca.mail.comcast.net with comcast id 9Df91h01A00PQ6U8dDfAiG; Mon, 18 Jul 2011 01:39:11 +0000 Received: from odin.ulthar.us (localhost [127.0.0.1]) by odin.ulthar.us (8.14.4/8.14.3) with ESMTP id p6I1cDII002511 for ; Sun, 17 Jul 2011 21:38:14 -0400 Received: (from draco@localhost) by odin.ulthar.us (8.14.4/8.14.4/Submit) id p6I1cDII002509 for dane@ietf.org; Sun, 17 Jul 2011 21:38:13 -0400 Date: Sun, 17 Jul 2011 21:38:13 -0400 From: Scott Schmit To: dane@ietf.org Message-ID: <20110718013813.GA2236@odin.ulthar.us> Mail-Followup-To: dane@ietf.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Fixing DANE to resolve properly with DNS X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 01:38:19 -0000 On Sun, Jul 17, 2011 at 03:50:11PM -0700, Paul Hoffman wrote: > On Jul 17, 2011, at 7:17 AM, Phillip Hallam-Baker wrote: > > 1) A DNS administrator wishes to create an equivalence between two > > DNS names such that all resources that are associated with one will > > apply to the other. > > > > e.g. alias www.example.com to example.com > > > > > > www.example.com CNAME example.com > > _443._tcp.example.com TLSA .... > > > > > > Problem: No means is specified that will allow a client to discover > > the TLSA record. > > > > Attempting to resolve for _443._tcp.www.example.com results in 'not > > found'. So the administrator is required to specify: > > > > www.example.com CNAME example.com > > _443._tcp.www.example.com TLSA .... > > _443._tcp.example.com TLSA .... > > > > This is bad because it means that we now have two points where the > > TLSA record has to be maintained. The value of having an alias is > > lost. > > It does mean that there are two points where the TLSA record has to be > maintained, and that is a security feature. In addition to your > example, consider: > > www.example.com CNAME www.notexample.notcom > _443._tcp.www.example.com TLSA ... > > If the zone administrator for www.example.com can specify what the > certificates should be validated for www.notexample.notcom, that is a > serious security flaw. This could be a security tradeoff made by the owner of example.com. If the TLSA record is present at www.example.com, then it can be enforced on www.notexample.notcom. If it's not present, the TLSA record at www.notexample.notcom is used instead. If I own both example.com and notexample.notcom, I'm obviously not going to worry about nefarious acts by myself. That said, this opens a new question: if I have a chain of CNAMEs, how many TLSA record sets am I required to look at to decide if the certificate I get is the right one? For each name in the chain? Just the first one? Just the last one? The first and the last? If we have to check all of them, then I worry about how complicated the check is going to be. An earlier email about the use case draft mentioned that it should allow for expressing multiple constraints at once (AND) as opposed to multiple independent constraints (OR) like we have now in the dane draft. When we combine that with the rollover requirement, and the need to check each name in a CNAME chain, you end up needing to check the AND of the simultaneous constraints (mechanism not yet explained in the current draft), the OR of sets of constraints (for rollover), and the AND of each constraint set in the CNAME chain. I'm not sure how well-tested that code path will be in most clients. It seems like the best way to do it that gets what everybody wants is to check the first name in the chain that has TLSA records and ignore any after that. -- Scott Schmit From hallam@gmail.com Sun Jul 17 18:53:38 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26F2721F87E2 for ; Sun, 17 Jul 2011 18:53:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.492 X-Spam-Level: X-Spam-Status: No, score=-3.492 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pn2mANq9Poua for ; Sun, 17 Jul 2011 18:53:37 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 524CF21F8772 for ; Sun, 17 Jul 2011 18:53:37 -0700 (PDT) Received: by ywp31 with SMTP id 31so1282328ywp.31 for ; Sun, 17 Jul 2011 18:53:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=apEe9cASLkjGPKvsWClAwt1ovt8dJGvbBFXO1Q2xXjc=; b=VLCp2qVds2ULTk/bJ6K8cD8QnoePLU0hamIz3FRPYHd2De/ZxKt+JJHeNwAuamzdhp aDIEWEpRCzTI3w9Usk8/mclrZQdZljFI5e512HXZrgSAWTzrUzn9n1s8J5GFR/BUVHrd V7hHMUZjV/lGdzA9vEQlqt7nhI5GrO5x6hfDA= MIME-Version: 1.0 Received: by 10.101.174.28 with SMTP id b28mr4962097anp.71.1310954015449; Sun, 17 Jul 2011 18:53:35 -0700 (PDT) Received: by 10.100.134.9 with HTTP; Sun, 17 Jul 2011 18:53:35 -0700 (PDT) In-Reply-To: <20110718013813.GA2236@odin.ulthar.us> References: <20110718013813.GA2236@odin.ulthar.us> Date: Sun, 17 Jul 2011 21:53:35 -0400 Message-ID: From: Phillip Hallam-Baker To: dane@ietf.org Content-Type: multipart/alternative; boundary=001636c5c22c68633a04a84e442e Subject: Re: [dane] Fixing DANE to resolve properly with DNS X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 01:53:38 -0000 --001636c5c22c68633a04a84e442e Content-Type: text/plain; charset=ISO-8859-1 On Sun, Jul 17, 2011 at 9:38 PM, Scott Schmit wrote: > www.example.com CNAME www.notexample.notcom > > _443._tcp.www.example.com TLSA ... > > > > If the zone administrator for www.example.com can specify what the > > certificates should be validated for www.notexample.notcom, that is a > > serious security flaw. > I don't see the problem here. The alias is from www.example.comto www.notexample.notcom Anyone can point any domain anywhere they please, but they cant affect the interpretation of the target when someone types that in. At the moment anyone can point a CNAME at paypal.com. Does that really matter? There might be a security issue somewhere there. HTTP world is complex and there are a lot of really bad security assumptions built into some of the scripting stuff. But I doubt there is anything here going to be unique to DANE. > > That said, this opens a new question: if I have a chain of CNAMEs, how > many TLSA record sets am I required to look at to decide if the > certificate I get is the right one? For each name in the chain? Just the > first one? Just the last one? The first and the last? > How many CNAMEs are you going to go to to find the A record? Its going to be the same number. Either you eventually get to a canonical or you give up. -- Website: http://hallambaker.com/ --001636c5c22c68633a04a84e442e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Sun, Jul 17, 2011 at 9:38 PM, Scott S= chmit <i.grok@co= mcast.net> wrote:

> www.example.com CNAME www.notexample.notcom
> _443._tcp.www= .example.com TLSA ...
>
> If the zone administrator for www.example.com can specify what the
> certificates should be validated for www.notexample.notcom, that is a<= br> > serious security flaw.

I don't see the problem here. The alias is from www.example.com to=A0www.notexample.notcom

Anyone can point any domain anywhere they please, but they cant = affect the interpretation of the target when someone types that in.


At the moment anyone can point a CNAME at = paypal.com. Does that really matter?=A0

There might be a security issue= somewhere there. HTTP world is complex and there are a lot of really bad s= ecurity assumptions built into some of the scripting stuff. But I doubt the= re is anything here going to be unique to DANE.

That said, this opens a new question: if I have a chain of CNAMEs, how
many TLSA record sets am I required to look at to decide if the
certificate I get is the right one? For each name in the chain? Just the first one? Just the last one? The first and the last?
=
How many CNAMEs are you going to go to to find the A record?=

Its going to be the same number. Either you event= ually get to a canonical or you give up.=A0


--
Website: http://hallambaker.com/

--001636c5c22c68633a04a84e442e-- From paul.hoffman@vpnc.org Sun Jul 17 20:24:03 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD3AE21F8AF2 for ; Sun, 17 Jul 2011 20:24:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.648 X-Spam-Level: X-Spam-Status: No, score=-102.648 tagged_above=-999 required=5 tests=[AWL=-0.049, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YTmRW45En1j0 for ; Sun, 17 Jul 2011 20:24:03 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id E7AA921F8AF0 for ; Sun, 17 Jul 2011 20:24:02 -0700 (PDT) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p6I3Nn8a041649 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sun, 17 Jul 2011 20:23:49 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Paul Hoffman In-Reply-To: Date: Sun, 17 Jul 2011 20:24:00 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <601CBC7C-5122-4CCF-9811-440E96DCC4F7@vpnc.org> References: <20110718013813.GA2236@odin.ulthar.us> To: DANE WG X-Mailer: Apple Mail (2.1084) Subject: Re: [dane] Fixing DANE to resolve properly with DNS X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 03:24:03 -0000 On Jul 17, 2011, at 6:53 PM, Phillip Hallam-Baker wrote: >=20 >=20 > On Sun, Jul 17, 2011 at 9:38 PM, Scott Schmit = wrote: >=20 > > www.example.com CNAME www.notexample.notcom > > _443._tcp.www.example.com TLSA ... > > > > If the zone administrator for www.example.com can specify what the > > certificates should be validated for www.notexample.notcom, that is = a > > serious security flaw. >=20 > I don't see the problem here. The alias is from www.example.com to = www.notexample.notcom >=20 > Anyone can point any domain anywhere they please, but they cant affect = the interpretation of the target when someone types that in. >=20 >=20 > At the moment anyone can point a CNAME at paypal.com. Does that really = matter?=20 Earlier on this thread, you argued that the owner www.example.com should = be able to make an alias to example.com that would have the person = resolving think that the TLSA record for www.example.com is also the one = for example.com. "This is bad because it means that we now have two = points where the TLSA record has to be maintained. The value of having = an alias is lost." Do you believe that the owner www.example.com should = be able to make an alias to www.notexample.notcom that would have the = person resolving think that the TLSA record for www.example.com is also = the one for www.notexample.notcom? The next time the person goes to = www.notexample.notcom, assuming that the aliased TLSA record's TTL has = not expired, they won't try to get the TLSA record, and will instead use = the one that came from www.example.com. --Paul Hoffman From hallam@gmail.com Sun Jul 17 20:48:51 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED99521F8AE1 for ; Sun, 17 Jul 2011 20:48:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.495 X-Spam-Level: X-Spam-Status: No, score=-3.495 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zvStvOCS2R11 for ; Sun, 17 Jul 2011 20:48:51 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id E8CF621F8AF0 for ; Sun, 17 Jul 2011 20:48:50 -0700 (PDT) Received: by gyd5 with SMTP id 5so1304473gyd.31 for ; Sun, 17 Jul 2011 20:48:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JV+eXuTvhVyKCQktx348TWLZYla6sJ9vA985N/vSsgw=; b=n5dkgpnkOnLQbeg9wY0bVDuIWyN7oJI7ExhXRBRq8Tps2w3RLHJ2fj3xxUZzruRzUO btPxaooXNmQfBW36v3q8RO8uqIjXTuTEuykNG0LBOMs5GitVt69MSvaqYBOHEcl0x2wJ uU16Tdf2G08qt4oVznPA1e0mN99K4SUb0plDk= MIME-Version: 1.0 Received: by 10.101.43.3 with SMTP id v3mr4947085anj.137.1310960929347; Sun, 17 Jul 2011 20:48:49 -0700 (PDT) Received: by 10.100.134.9 with HTTP; Sun, 17 Jul 2011 20:48:49 -0700 (PDT) In-Reply-To: <601CBC7C-5122-4CCF-9811-440E96DCC4F7@vpnc.org> References: <20110718013813.GA2236@odin.ulthar.us> <601CBC7C-5122-4CCF-9811-440E96DCC4F7@vpnc.org> Date: Sun, 17 Jul 2011 23:48:49 -0400 Message-ID: From: Phillip Hallam-Baker To: Paul Hoffman Content-Type: multipart/alternative; boundary=001636ed72268218c304a84fe068 Cc: DANE WG Subject: Re: [dane] Fixing DANE to resolve properly with DNS X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 03:48:52 -0000 --001636ed72268218c304a84fe068 Content-Type: text/plain; charset=ISO-8859-1 On Sun, Jul 17, 2011 at 11:24 PM, Paul Hoffman wrote: > On Jul 17, 2011, at 6:53 PM, Phillip Hallam-Baker wrote: > > > > > > > On Sun, Jul 17, 2011 at 9:38 PM, Scott Schmit > wrote: > > > > > www.example.com CNAME www.notexample.notcom > > > _443._tcp.www.example.com TLSA ... > > > > > > If the zone administrator for www.example.com can specify what the > > > certificates should be validated for www.notexample.notcom, that is a > > > serious security flaw. > > > > I don't see the problem here. The alias is from www.example.com to > www.notexample.notcom > > > > Anyone can point any domain anywhere they please, but they cant affect > the interpretation of the target when someone types that in. > > > > > > At the moment anyone can point a CNAME at paypal.com. Does that really > matter? > > Earlier on this thread, you argued that the owner www.example.com should > be able to make an alias to example.com that would have the person > resolving think that the TLSA record for www.example.com is also the one > for example.com. "This is bad because it means that we now have two points > where the TLSA record has to be maintained. The value of having an alias is > lost." Do you believe that the owner www.example.com should be able to > make an alias to www.notexample.notcom that would have the person resolving > think that the TLSA record for www.example.com is also the one for > www.notexample.notcom? The next time the person goes to > www.notexample.notcom, assuming that the aliased TLSA record's TTL has not > expired, they won't try to get the TLSA record, and will instead use the one > that came from www.example.com. > > Absolutely not. The pointers go in one direction. www.example.com CNAME www.notexample.notcom Data that is bound to www.example.com is valid for that domain and no other. Any client that made use of that data for www.notexample.notcom in any other context than that of following an alias from www.example.com is wrong. Data that is bound to www.notexample.notcom applies to www.example.comthough. That is the point of the CNAME. So probably a good idea to have a comment to the effect that caches have to store the data in sensible form here. It is certainly wrong and stupid to do it the other way, but people have repeatedly done such things in DNS code in the past. One corner case that comes up is what to do if there is data in both places, which should take precedence? -- Website: http://hallambaker.com/ --001636ed72268218c304a84fe068 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Sun, Jul 17, 2011 at 11:24 PM, Paul H= offman <paul.= hoffman@vpnc.org> wrote:
On Jul 17, 2011, at 6:53 PM, Phillip Hallam-Baker wrote:<= br>
>
>
> On Sun, Jul 17, 2011 at 9:38 PM, Scott Schmit <i.grok@comcast.net> wrote:
>
> > www.example.= com CNAME www.notexample.notcom
> > _443._tc= p.www.example.com TLSA ...
> >
> > If the zone administrator for www.example.com can specify what the
> > certificates should be validated for www.notexample.notcom, that = is a
> > serious security flaw.
>
> I don't see the problem here. The alias is from www.example.com to www.notexample.no= tcom
>
> Anyone can point any domain anywhere they please, but they cant affect= the interpretation of the target when someone types that in.
>
>
> At the moment anyone can point a CNAME at paypal.com. Does that really matter?

Earlier on this thread, you argued that the owner www.example.com should be able to mak= e an alias to example.com<= /a> that would have the person resolving think that the TLSA record for www.example.com is al= so the one for example.com= . "This is bad because it means that we now have two points where = the TLSA record has to be maintained. The value of having an alias is lost.= " Do you believe that the owner www.example.com should be able to make an alias to www.n= otexample.notcom that would have the person resolving think that the TLSA r= ecord for www.example.= com is also the one for www.notexample.notcom? The next time the person= goes to www.notexample.notcom, assuming that the aliased TLSA record's= TTL has not expired, they won't try to get the TLSA record, and will i= nstead use the one that came from www.example.com.

=

Absolutely not.

The pointers g= o in one direction.

www.example.com CNAME=A0www.notexample.notcom


Data that is bou= nd to www.example.com is valid for t= hat domain and no other. Any client that made use of that data for=A0www.no= texample.notcom in any other context than that of following an alias from <= a href=3D"http://www.example.com">www.example.com is wrong.

Data that is bound to=A0www.notexample.notcom applies t= o=A0www.example.com though. That is = the point of the CNAME.=A0


So proba= bly a good idea to have a comment to the effect that caches have to store t= he data in sensible form here. It is certainly wrong and stupid to do it th= e other way, but people have repeatedly done such things in DNS code in the= past.

One corner case that comes up is what to do if there is= data in both places, which should take precedence?

= =A0
--
Website: http://hallambake= r.com/

--001636ed72268218c304a84fe068-- From i.grok@comcast.net Mon Jul 18 05:23:05 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4E0E21F8B84 for ; Mon, 18 Jul 2011 05:23:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.538 X-Spam-Level: X-Spam-Status: No, score=-102.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SFjqDFfah-4I for ; Mon, 18 Jul 2011 05:23:05 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by ietfa.amsl.com (Postfix) with ESMTP id 4209721F8B46 for ; Mon, 18 Jul 2011 05:23:05 -0700 (PDT) Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by qmta03.westchester.pa.mail.comcast.net with comcast id 9QNv1h0030EZKEL53QP5Y3; Mon, 18 Jul 2011 12:23:05 +0000 Received: from odin.ulthar.us ([68.33.77.0]) by omta01.westchester.pa.mail.comcast.net with comcast id 9QP41h00F00PQ6U3MQP4Lz; Mon, 18 Jul 2011 12:23:04 +0000 Received: from odin.ulthar.us (localhost [127.0.0.1]) by odin.ulthar.us (8.14.4/8.14.3) with ESMTP id p6ICN1ZI004460 for ; Mon, 18 Jul 2011 08:23:01 -0400 Received: (from draco@localhost) by odin.ulthar.us (8.14.4/8.14.4/Submit) id p6ICN04V004458 for dane@ietf.org; Mon, 18 Jul 2011 08:23:00 -0400 Date: Mon, 18 Jul 2011 08:23:00 -0400 From: Scott Schmit To: dane@ietf.org Message-ID: <20110718122300.GB2236@odin.ulthar.us> Mail-Followup-To: dane@ietf.org References: <20110718013813.GA2236@odin.ulthar.us> <601CBC7C-5122-4CCF-9811-440E96DCC4F7@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Fixing DANE to resolve properly with DNS X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 12:23:05 -0000 On Sun, Jul 17, 2011 at 11:48:49PM -0400, Phillip Hallam-Baker wrote: > One corner case that comes up is what to do if there is data in both > places, which should take precedence? If you reread my email (the one you replied to), you'll see that I already brought up this point and proposed a solution. -- Scott Schmit From ajs@anvilwalrusden.com Mon Jul 18 05:27:14 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 083E921F873D for ; Mon, 18 Jul 2011 05:27:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Vjat56x5p0U for ; Mon, 18 Jul 2011 05:27:13 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 36C4D21F8B37 for ; Mon, 18 Jul 2011 05:27:06 -0700 (PDT) Received: from shinkuro.com (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id BCBA11ECB41C for ; Mon, 18 Jul 2011 12:27:04 +0000 (UTC) Date: Mon, 18 Jul 2011 08:27:03 -0400 From: Andrew Sullivan To: dane@ietf.org Message-ID: <20110718122703.GE40026@shinkuro.com> References: <20110718013813.GA2236@odin.ulthar.us> <601CBC7C-5122-4CCF-9811-440E96DCC4F7@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Fixing DANE to resolve properly with DNS X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 12:27:14 -0000 On Sun, Jul 17, 2011 at 11:48:49PM -0400, Phillip Hallam-Baker wrote: > Absolutely not. > > The pointers go in one direction. I'll note that there have been suggestions in the past (but no I-D as far as I've seen) to put an ALIAS record on the target side, as a kind of assurance that the target of the xNAME knows that it is such a target. Would there be any value in pursuing that line of thinking? A -- Andrew Sullivan ajs@anvilwalrusden.com From hallam@gmail.com Mon Jul 18 06:42:06 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17D7D21F8686 for ; Mon, 18 Jul 2011 06:42:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.499 X-Spam-Level: X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WxI9rp7G3x74 for ; Mon, 18 Jul 2011 06:42:01 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9ABA221F85F1 for ; Mon, 18 Jul 2011 06:42:01 -0700 (PDT) Received: by yxp4 with SMTP id 4so1544629yxp.31 for ; Mon, 18 Jul 2011 06:42:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=kfMM866j1reXI0RYUlaHWzgNTS1BxG0DVkk/EC2xMY4=; b=HEDelM3Jbe2K5UsOhEtEGAnmfWPrZlwg/TlESrmT+QdvRomeNCa38HniSHwwrpE2hJ 0D/idqEaZXydPLxBN7XBFn3yWS/QZkvob+Detebiuvxl4cwBWAv3419DUd9Wn6kktOSh ZCI2K6HHaX9oI+OEgfnrFVdj0L979f/PZ2tDM= MIME-Version: 1.0 Received: by 10.100.75.12 with SMTP id x12mr5432757ana.27.1310996520843; Mon, 18 Jul 2011 06:42:00 -0700 (PDT) Received: by 10.100.134.9 with HTTP; Mon, 18 Jul 2011 06:42:00 -0700 (PDT) In-Reply-To: <20110718122300.GB2236@odin.ulthar.us> References: <20110718013813.GA2236@odin.ulthar.us> <601CBC7C-5122-4CCF-9811-440E96DCC4F7@vpnc.org> <20110718122300.GB2236@odin.ulthar.us> Date: Mon, 18 Jul 2011 09:42:00 -0400 Message-ID: From: Phillip Hallam-Baker To: dane@ietf.org Content-Type: multipart/alternative; boundary=001636b2af53ed39ab04a85829e5 Subject: Re: [dane] Fixing DANE to resolve properly with DNS X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 13:42:06 -0000 --001636b2af53ed39ab04a85829e5 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jul 18, 2011 at 8:23 AM, Scott Schmit wrote: > On Sun, Jul 17, 2011 at 11:48:49PM -0400, Phillip Hallam-Baker wrote: > > One corner case that comes up is what to do if there is data in both > > places, which should take precedence? > > If you reread my email (the one you replied to), you'll see that I > already brought up this point and proposed a solution. > I was trying to capture it for the writeup. It is easy enough to solve but everyone needs to solve in the same way or there will be ambiguity. -- Website: http://hallambaker.com/ --001636b2af53ed39ab04a85829e5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Mon, Jul 18, 2011 at 8:23 AM, Scott S= chmit <i.grok@co= mcast.net> wrote:
On Sun, Jul 17, 2011 at 11:48:49PM -0400, Phillip Hallam-= Baker wrote:
> One corner case that comes up is what to do if there is data in both > places, which should take precedence?

If you reread my email (the one you replied to), you'll see that = I
already brought up this point and proposed a solution.

I was trying to capture it for the writeup. It is easy enou= gh to solve but everyone needs to solve in the same way or there will be am= biguity.
=A0
--
Website: htt= p://hallambaker.com/

--001636b2af53ed39ab04a85829e5-- From hallam@gmail.com Mon Jul 18 06:46:18 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C114221F85E3 for ; Mon, 18 Jul 2011 06:46:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.501 X-Spam-Level: X-Spam-Status: No, score=-3.501 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z+nSS1K8Tkq5 for ; Mon, 18 Jul 2011 06:46:14 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 51CAB21F85F1 for ; Mon, 18 Jul 2011 06:46:14 -0700 (PDT) Received: by yxp4 with SMTP id 4so1547280yxp.31 for ; Mon, 18 Jul 2011 06:46:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=EctT259fRAmTNkONNLwXqvSesMpqIStK5+ETMW4wT7A=; b=P0DNvv2zIoZ2faRGaLgDEH4H5b9ZRREOoyl8ruo2FOHn5bd0D+BeWGAJZKcn56zFRg cTnLNGcw5GWiKFKixVDvv83fYZLne1J1YgCy5nrS0tWdlAGotlgPNVl4TbUuaon979JZ S7URPPWk7+ZR9dSpRz15oYoV956v4HKdRiR78= MIME-Version: 1.0 Received: by 10.101.43.3 with SMTP id v3mr5367065anj.137.1310996773821; Mon, 18 Jul 2011 06:46:13 -0700 (PDT) Received: by 10.100.134.9 with HTTP; Mon, 18 Jul 2011 06:46:13 -0700 (PDT) In-Reply-To: <20110718122703.GE40026@shinkuro.com> References: <20110718013813.GA2236@odin.ulthar.us> <601CBC7C-5122-4CCF-9811-440E96DCC4F7@vpnc.org> <20110718122703.GE40026@shinkuro.com> Date: Mon, 18 Jul 2011 09:46:13 -0400 Message-ID: From: Phillip Hallam-Baker To: Andrew Sullivan Content-Type: multipart/alternative; boundary=001636ed7226015d0e04a8583934 Cc: dane@ietf.org Subject: Re: [dane] Fixing DANE to resolve properly with DNS X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 13:46:18 -0000 --001636ed7226015d0e04a8583934 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jul 18, 2011 at 8:27 AM, Andrew Sullivan wrote: > On Sun, Jul 17, 2011 at 11:48:49PM -0400, Phillip Hallam-Baker wrote: > > Absolutely not. > > > > The pointers go in one direction. > > I'll note that there have been suggestions in the past (but no I-D as > far as I've seen) to put an ALIAS record on the target side, as a kind > of assurance that the target of the xNAME knows that it is such a > target. Would there be any value in pursuing that line of thinking? > I tend to think it is a much lower priority than getting security policy fixed in general. In fact I think that is going to be a pre-condition as any use of this scheme is going to be optional and thus face the downgrade attack issue. One problem any scheme of that type is going to face is the fan-in problem. There could be a million CNAMEs pointing to the same name. So any reverse alias scheme has to use prefixes as well... -- Website: http://hallambaker.com/ --001636ed7226015d0e04a8583934 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Mon, Jul 18, 2011 at 8:27 AM, Andrew = Sullivan <aj= s@anvilwalrusden.com> wrote:
On Sun, Jul 17, 2011 at 11:48:49PM -0400, Phillip Hallam-= Baker wrote:
> Absolutely not.
>
> The pointers go in one direction.

I'll note that there have been suggestions in the past (but no I-= D as
far as I've seen) to put an ALIAS record on the target side, as a kind<= br> of assurance that the target of the xNAME knows that it is such a
target. =A0Would there be any value in pursuing that line of thinking?
<= /blockquote>

I tend to think it is a much lower priority= than getting security policy fixed in general. In fact I think that is goi= ng to be a pre-condition as any use of this scheme is going to be optional = and thus face the downgrade attack issue.

One problem any scheme of that type is going to face is= the fan-in problem. There could be a million CNAMEs pointing to the same n= ame. So any reverse alias scheme has to use prefixes as well...



=A0
--
Website:= http://hallambaker.com/

--001636ed7226015d0e04a8583934-- From ondrej.sury@nic.cz Mon Jul 18 09:37:09 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3287921F8876 for ; Mon, 18 Jul 2011 09:37:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.093 X-Spam-Level: X-Spam-Status: No, score=-0.093 tagged_above=-999 required=5 tests=[AWL=-0.993, BAYES_50=0.001, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dBK3-E1Pn-0K for ; Mon, 18 Jul 2011 09:37:04 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 0DAAE21F85AE for ; Mon, 18 Jul 2011 09:37:04 -0700 (PDT) Received: from kimac.office.nic.cz (unknown [IPv6:2001:1488:ac14:1400:5a55:caff:fe25:fa18]) by mail.nic.cz (Postfix) with ESMTPSA id 1E1832A2957 for ; Mon, 18 Jul 2011 18:37:03 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1311007023; bh=xpa6oi5cPyUOTa/zxiA5KqR8jeI3oGI0x4xDnhSaBTI=; h=Message-ID:Date:From:MIME-Version:To:Subject:Content-Type: Content-Transfer-Encoding; b=BIBIY2/sKE1neGow2VCDsvMR3H3TU8PferqTTXoN0f04P/iZiT97b8axLXju9SNRa 2RNQCNyj8DhcA8jTw1+tU6RwvPhGCH4cak7f8P7A4A3zzKjGoOLxOaEkVCnjhBKw6h ktDYo4mHknPHtb/exRfLKVEdJpqCRhHtWXSrxTq0= Message-ID: <4E24612E.4060708@nic.cz> Date: Mon, 18 Jul 2011 18:37:02 +0200 From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= Organization: CZ.NIC, z.s.p.o. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: dane@ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Subject: [dane] Canceling the Quebec session X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 16:37:09 -0000 Hi, unless anybody objects and come with the topic, I am going to cancel the session in 24 hours, since nobody came with anything yet. Apart from serialization which we don't believe is our topic and will be covered elsewhere. O. -- Ondřej Surý vedoucí výzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- From hallam@gmail.com Mon Jul 18 10:15:29 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07B6121F85F2 for ; Mon, 18 Jul 2011 10:15:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.244 X-Spam-Level: X-Spam-Status: No, score=-2.244 tagged_above=-999 required=5 tests=[AWL=-1.212, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U-g5OXoPYGn2 for ; Mon, 18 Jul 2011 10:15:23 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6E70D21F8585 for ; Mon, 18 Jul 2011 10:15:23 -0700 (PDT) Received: by ywp31 with SMTP id 31so1616305ywp.31 for ; Mon, 18 Jul 2011 10:15:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=isph426+MmtJBYQOV60bRI1pVn/YIpniVvOPkYp/B0Y=; b=WvJ94HobGEtyYXrlYEwIYhcCFq7Wd3vLXBS3TADS+U3jtRTtqg/iBuzmCMdmxAxKF+ yHSwJgGvxq6ry4NRqz85M9l651c/pKnb5HQAqHaYJb/k/r4eFTbwgtgrhG3QRKk5z/zr 3MqtNc9TsXnY9HKtBDh3vpCsxUAyssmhG3DMI= MIME-Version: 1.0 Received: by 10.100.75.12 with SMTP id x12mr5671802ana.27.1311009322522; Mon, 18 Jul 2011 10:15:22 -0700 (PDT) Received: by 10.100.134.9 with HTTP; Mon, 18 Jul 2011 10:15:22 -0700 (PDT) In-Reply-To: <4E24612E.4060708@nic.cz> References: <4E24612E.4060708@nic.cz> Date: Mon, 18 Jul 2011 13:15:22 -0400 Message-ID: From: Phillip Hallam-Baker To: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= Content-Type: multipart/alternative; boundary=001636b2af53f756cc04a85b2410 Cc: dane@ietf.org Subject: Re: [dane] Canceling the Quebec session X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 17:15:29 -0000 --001636b2af53f756cc04a85b2410 Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable As I said before, we should use the session to get the DNS resolution completely nailed down. That is going to be the last chance we have to discuss DNS dependencies wit= h DNS people in person. If they agree with what the WG comes up with then tha= t is fine. If not there is likely going to be a lot of confusion and wheel spinning on the list. The other issue that I think requires in person discussion is what to do next. Should the WG get the RR draft for key distribution published and the= n close or do people want to do something further. If so what is that and wha= t would be the scope. On Mon, Jul 18, 2011 at 12:37 PM, Ond=F8ej Sur=FD wrot= e: > Hi, > > unless anybody objects and come with the topic, I am going to cancel the > session in 24 hours, since nobody came with anything yet. Apart from > serialization which we don't believe is our topic and will be covered > elsewhere. > > O. > -- > Ond=F8ej Sur=FD > vedouc=ED v=FDzkumu/Head of R&D department > ------------------------------**------------- > CZ.NIC, z.s.p.o. -- Laborato=F8e CZ.NIC > Americka 23, 120 00 Praha 2, Czech Republic > mailto:ondrej.sury@nic.cz http://nic.cz/ > tel:+420.222745110 fax:+420.222745112 > ------------------------------**------------- > ______________________________**_________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/**listinfo/dane > --=20 Website: http://hallambaker.com/ --001636b2af53f756cc04a85b2410 Content-Type: text/html; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable As I said before, we should use the session to get the DNS resolution compl= etely nailed down.

That is going to be the last chance w= e have to discuss DNS dependencies with DNS people in person. If they agree= with what the WG comes up with then that is fine. If not there is likely g= oing to be a lot of confusion and wheel spinning on the list.


The other issue that I think requires in= person discussion is what to do next. Should the WG get the RR draft for k= ey distribution published and then close or do people want to do something = further. If so what is that and what would be the scope.



On Mon, Jul 18, 2011= at 12:37 PM, Ond=F8ej Sur=FD <ondrej.sury@nic.cz> wrote:
Hi,

unless anybody objects and come with the topic, I am going to cancel the se= ssion in 24 hours, since nobody came with anything yet. =A0Apart from seria= lization which we don't believe is our topic and will be covered elsewh= ere.

O.
--
=A0Ond=F8ej Sur=FD
=A0vedouc=ED v=FDzkumu/Head of R&D department
=A0-------------------------------------------
=A0CZ.NIC, z.s.p.o. =A0 =A0-- =A0 =A0Laborato=F8e CZ.NIC
=A0Americka 23, 120 00 Praha 2, Czech Republic
=A0mailto:ondrej.su= ry@nic.cz =A0 =A0http://ni= c.cz/
=A0tel:+420.222745110 =A0 =A0 =A0 fax:+420.222745112
=A0-------------------------------------------
_______________________________________________
dane mailing list
dane@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/dane



--
Website: http://hallambaker.com/

--001636b2af53f756cc04a85b2410-- From paul@xelerance.com Mon Jul 18 10:34:44 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9A8C21F8B15 for ; Mon, 18 Jul 2011 10:34:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.335 X-Spam-Level: X-Spam-Status: No, score=-6.335 tagged_above=-999 required=5 tests=[AWL=-0.036, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kleapZHeUloa for ; Mon, 18 Jul 2011 10:34:44 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by ietfa.amsl.com (Postfix) with ESMTP id DA9E421F8AD9 for ; Mon, 18 Jul 2011 10:34:43 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 4F7AFBF4A; Mon, 18 Jul 2011 13:35:12 -0400 (EDT) Date: Mon, 18 Jul 2011 13:35:12 -0400 (EDT) From: Paul Wouters To: =?ISO-8859-2?Q?Ond=F8ej_Sur=FD?= In-Reply-To: <4E24612E.4060708@nic.cz> Message-ID: References: <4E24612E.4060708@nic.cz> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT Cc: dane@ietf.org Subject: Re: [dane] Canceling the Quebec session X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 17:34:44 -0000 On Mon, 18 Jul 2011, Ondřej Surý wrote: > unless anybody objects and come with the topic, I am going to cancel the > session in 24 hours, since nobody came with anything yet. Apart from > serialization which we don't believe is our topic and will be covered > elsewhere. Don't we have 13/19 open issues? http://trac.tools.ietf.org/wg/dane/trac/query?status=new&status=assigned&status=reopened&component=protocol Paul From jakob@kirei.se Mon Jul 18 11:24:16 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 516A521F8B5E for ; Mon, 18 Jul 2011 11:24:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.368 X-Spam-Level: X-Spam-Status: No, score=0.368 tagged_above=-999 required=5 tests=[AWL=-0.331, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fvJ-04Z06+iE for ; Mon, 18 Jul 2011 11:24:12 -0700 (PDT) Received: from spg.kirei.se (spg.kirei.se [IPv6:2001:67c:394:15::9]) by ietfa.amsl.com (Postfix) with ESMTP id 752CB21F8579 for ; Mon, 18 Jul 2011 11:24:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kirei.se; s=spg20100524; h=received:references:in-reply-to:mime-version:content-transfer-encoding: content-type:message-id:cc:x-mailer:from:subject:date:to; bh=RXNp5s0cjk69/z4e3akCGdzUKGZe/BIMg3oLpozapfs=; b=UESMC+6rY7KndyGI9j2bA2/dXiAPbwrjxY37Y7JK8To7AkKiilaBkGZm/cg5dhDJD4c9nWabTDYn0 hY5wRLhbjpgaa1RJz+yVOyW08Z9hrImFLPdO4rros91nQMy/kDUpEJTeYAqi8U1oxj/RwY4+dgYcQD 3iEWeyf7+s+eo2F8= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg-relay.kirei.se (Halon Mail Gateway) with ESMTPS; Mon, 18 Jul 2011 20:24:05 +0200 (CEST) References: In-Reply-To: Mime-Version: 1.0 (iPad Mail 8J3) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-3--153712348 Message-Id: <189933DE-6A77-45AD-8CDD-A9F7D486A890@kirei.se> X-Mailer: iPad Mail (8J3) From: Jakob Schlyter Date: Mon, 18 Jul 2011 20:24:06 +0200 To: Paul Hoffman Cc: DANE WG Subject: Re: [dane] Fixing DANE to resolve properly with DNS X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 18:24:16 -0000 --Apple-Mail-3--153712348 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii 18 jul 2011 kl. 00:50 skrev Paul Hoffman : > It does mean that there are two points where the TLSA record has to be mai= ntained, and that is a security feature. In addition to your example, consid= er: >=20 > www.example.com CNAME www.notexample.notcom > _443._tcp.www.example.com TLSA ... I'd prefer if the CNAME is used for the address only and a separate CNAME fo= r the certificate association. This way, the domain name holder can choose i= f he wants to delegate both addressing (A/AAAA) and TLSA, or just one of the= m. Jakob --Apple-Mail-3--153712348 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
18 jul 2011 kl. 00:50 skrev Paul Hoffma= n <paul.hoffman@vpnc.org>= :

It does mean that there are t= wo points where the TLSA record has to be maintained, and that is a security= feature. In addition to your example, consider:

= www.example.com CNAME www.notexample.notcom
_443._t= cp.www.example.com TLSA ...

I'd p= refer if the CNAME is used for the address only and a separate CNAME for the= certificate association.  This way, the domain name holder can choose i= f he wants to delegate both addressing (A/AAAA) and TLSA, or just one of the= m.

  Jakob

= --Apple-Mail-3--153712348-- From ietf@augustcellars.com Mon Jul 18 11:38:17 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6095D21F8AF2 for ; Mon, 18 Jul 2011 11:38:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eZQWoLacysUB for ; Mon, 18 Jul 2011 11:38:16 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id BBA2921F8AED for ; Mon, 18 Jul 2011 11:38:16 -0700 (PDT) Received: from TITUS (176.120.168.69.static.onlinenw.com [69.168.120.176]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTP id A1F256A426; Mon, 18 Jul 2011 11:38:15 -0700 (PDT) From: "Jim Schaad" To: "Paul Hoffman" , Date: Mon, 18 Jul 2011 11:37:17 -0700 Message-ID: <008401cc4579$b91f7e30$2b5e7a90$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Acw9mHN1ofsKu1eLQvusWULERIdOXQ== Content-Language: en-us Cc: dane@ietf.org Subject: [dane] Review of draft-ietf-dane-protocol-08.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 18:38:17 -0000 I have done a careful read of the document and here are my comments: 1. IMO, you need to have another item added to section 2.1.1 - I believe that the use of type 3 is insufficient for dealing with an intermediate CA. Consider the following case: TA1->CA_TA1->EE and TA2->CA_TA2->EE In both of these cases the public key for CA_TA1 and CA_TA2 are the same, however it is not clear that the extensions that are included in these two certificates are going to be the same. Thus information might be lost or changed in how the certificate EE is trusted. 2. The text in para 4 of section 4.4 should probably also say that if the certificate type is not understood by the TLS client then the association is marked as unusable. 3. The text in para 6 of section 4.4 is very out of date. It does not discuss any certificate type except end-entity and states that if an end-entity certificate is not found (i.e. you cannot do a trust anchor only DANE record) then the handshake aborts 4. In section 5 - 3.2 Certificate constraints - see above point about why I don't think a public key actually implements a certificate constraint - it just implements a public key constraint. As such it does not enforce any extensions in the certificate. 5. In section 5 - I have missed all of the text that discusses the Combination point. I think that the message a while ago about the need for a potentially new certificate type is going to be required to deal with combinations. As such I do not believe that the current draft has any useful discussion on combinations. 6. In section 6 - I believe that the roll-over text needs to include two different phases. The first is covered - that is that the TTL will cause the old record to disappear. However you need to have sufficient text to state what happens if there are two end-entity certificates present at the same time as this is also part of the roll over text. There are some interesting cases that might also be hard to document and implement and thus need to be discussed. What is happens if one is trying to roll over from a TLSA record of type 1 to a TLSA record of type 2. While both are present, only one of the records needs to be satisfied. 7. In section 6 - There is a missing discussion for delegated service that needs to be include - Specifically it is not clear to me that the semantics for item #3 in the delegated service section are implementable. (Separate message follows) 8. Formatting error in 2.1.3 s/ASN.1Cert object/ASN.1 Cert Object/ 9. In section 2.2, I can understand the default representation of the certificate for association being a hexadecimal character string, however I would prefer not having a MUST here as I believe that it might make sense for people to represent this in other ways - i.e. information that represents a certificate might be more useful in more advanced versions. 10. Section 4.1 - The text assumes that all future reference types are going to be hashes. I do not believe that this will necessarily be true. For example I can see people defining a PGP certificate reference type. I think the last two sentences can be combined together when a more general statement that the certificate referenced must be dereferenced and match. I don't know of any new reference types that might be included. I believe that in association with this we should change the reference type 0 from Full Certificate to Value. If I include a cert type of 3 and a ref type of 0 then calling the public key a full certificate does not really make any sense. 11. Section 4.2 - As with the usage document, if the "Certification Authority Certificate" is only for trust anchors - I would much rather see the title of the section reflect that point. It is not currently allowed for an intermediate certification authority and thus the title is misleading. I personally have no problems with a certificate being both an EE certificate and a trust anchor as that is what is happening. 12. Section 4.4 - You say that type is a "trust anchor for that domain name" I think that this is a bit squirrely for language as it allows for a possible ambiguity with DNSSEC vs TLS. I would preferce that that it is a "trust anchor for certificate chains for services in this domain name". 13. Section 4.4 - Missing paragraph? " If a certificate association contains a certificate type field that is not understood by the TLS client, that certificate association MUST be marked as unusable." Apologies - I tried to get this out earlier, but I have been on the road for much of the last three weeks. Jim From hallam@gmail.com Mon Jul 18 12:43:35 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8310821F859E for ; Mon, 18 Jul 2011 12:43:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.504 X-Spam-Level: X-Spam-Status: No, score=-3.504 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zf-TGtOx2YYR for ; Mon, 18 Jul 2011 12:43:31 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id DB84521F8575 for ; Mon, 18 Jul 2011 12:43:30 -0700 (PDT) Received: by ywp31 with SMTP id 31so1693780ywp.31 for ; Mon, 18 Jul 2011 12:43:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=YHgeuHbDezkh4+ulYMXZVXX2gYXCbbmGTQsBx6T2FfM=; b=XkY3cgCagD0NfHfnDBA5/OH1xM66O8c38hRdxAcslOZFvB9DgCuU5E69S/WItvoelK jXlT1b1XBFet07YOBfm/kAuNgLkRbB3n/cyM6ACpUHS0nIuIHK+7EvDlWvvW/thTVVGs 5rBxP9cwIh4HqoLTa1RWgayRf8pH5Lv+Cb+b8= MIME-Version: 1.0 Received: by 10.101.192.13 with SMTP id u13mr5827587anp.49.1311018209808; Mon, 18 Jul 2011 12:43:29 -0700 (PDT) Received: by 10.100.134.9 with HTTP; Mon, 18 Jul 2011 12:43:29 -0700 (PDT) In-Reply-To: <189933DE-6A77-45AD-8CDD-A9F7D486A890@kirei.se> References: <189933DE-6A77-45AD-8CDD-A9F7D486A890@kirei.se> Date: Mon, 18 Jul 2011 15:43:29 -0400 Message-ID: From: Phillip Hallam-Baker To: Jakob Schlyter Content-Type: multipart/alternative; boundary=001636c5c157b092ce04a85d36a0 Cc: Paul Hoffman , DANE WG Subject: Re: [dane] Fixing DANE to resolve properly with DNS X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 19:43:35 -0000 --001636c5c157b092ce04a85d36a0 Content-Type: text/plain; charset=ISO-8859-1 How can you make that work with wildcards? On Mon, Jul 18, 2011 at 2:24 PM, Jakob Schlyter wrote: > 18 jul 2011 kl. 00:50 skrev Paul Hoffman : > > It does mean that there are two points where the TLSA record has to be > maintained, and that is a security feature. In addition to your example, > consider: > > www.example.com CNAME > www.notexample.notcom > _443._tcp.www.example.com TLSA ... > > > I'd prefer if the CNAME is used for the address only and a separate CNAME > for the certificate association. This way, the domain name holder can > choose if he wants to delegate both addressing (A/AAAA) and TLSA, or just > one of them. > > Jakob > > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > > -- Website: http://hallambaker.com/ --001636c5c157b092ce04a85d36a0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable How can you make that work with wildcards?

On Mon, Jul 18, 2011 at 2:24 PM, Jakob Schlyter <jakob@kirei.se> wrote:
18 jul 2011 kl. 00:50 skrev Paul Hoffman <= paul.hoffman@vpn= c.org>:

It does mean that there are two points where the TLSA record has to be m= aintained, and that is a security feature. In addition to your example, con= sider:

www.example.com CNAME www.notexample.notc= om
_443._tcp.ww= w.example.com TLSA ...

I'd prefer if the CNAME is used for the address only and a separate CN= AME for the certificate association. =A0This way, the domain name holder ca= n choose if he wants to delegate both addressing (A/AAAA) and TLSA, or just= one of them.

=A0=A0Jakob


_______________________________________________
dane mailing list
dane@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/dane




--
Website: http://hallambaker.com/

--001636c5c157b092ce04a85d36a0-- From ilari.liusvaara@elisanet.fi Mon Jul 18 12:56:13 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ECBB21F84E8 for ; Mon, 18 Jul 2011 12:56:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Defh5AQkHQi for ; Mon, 18 Jul 2011 12:56:12 -0700 (PDT) Received: from emh06.mail.saunalahti.fi (emh06.mail.saunalahti.fi [62.142.5.116]) by ietfa.amsl.com (Postfix) with ESMTP id 0BA2421F87C3 for ; Mon, 18 Jul 2011 12:56:00 -0700 (PDT) Received: from saunalahti-vams (vs3-11.mail.saunalahti.fi [62.142.5.95]) by emh06-2.mail.saunalahti.fi (Postfix) with SMTP id 074D7C7EAE; Mon, 18 Jul 2011 22:55:58 +0300 (EEST) Received: from emh04.mail.saunalahti.fi ([62.142.5.110]) by vs3-11.mail.saunalahti.fi ([62.142.5.95]) with SMTP (gateway) id A0368A01EAD; Mon, 18 Jul 2011 22:55:58 +0300 Received: from LK-Perkele-VI (a88-112-55-20.elisa-laajakaista.fi [88.112.55.20]) by emh04.mail.saunalahti.fi (Postfix) with ESMTP id BB4EF41BE2; Mon, 18 Jul 2011 22:55:52 +0300 (EEST) Date: Mon, 18 Jul 2011 22:57:11 +0300 From: Ilari Liusvaara To: Jim Schaad Message-ID: <20110718195711.GA32357@LK-Perkele-VI.localdomain> References: <008401cc4579$b91f7e30$2b5e7a90$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <008401cc4579$b91f7e30$2b5e7a90$@augustcellars.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: Ilari Liusvaara X-Antivirus: VAMS Cc: Paul Hoffman , dane@ietf.org Subject: Re: [dane] Review of draft-ietf-dane-protocol-08.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 19:56:13 -0000 On Mon, Jul 18, 2011 at 11:37:17AM -0700, Jim Schaad wrote: > I have done a careful read of the document and here are my comments: > > 2. The text in para 4 of section 4.4 should probably also say that if the > certificate type is not understood by the TLS client then the association is > marked as unusable. -1. Such associations must be considered usable but not matching or you will get a downgrade attack possibility. > 3. The text in para 6 of section 4.4 is very out of date. It does not > discuss any certificate type except end-entity and states that if an > end-entity certificate is not found (i.e. you cannot do a trust anchor only > DANE record) then the handshake aborts I think TLS requres an end-entity certificate (unless selected Ciphersuite does not use certificates at all). > 4. In section 5 - 3.2 Certificate constraints - see above point about why I > don't think a public key actually implements a certificate constraint - it > just implements a public key constraint. As such it does not enforce any > extensions in the certificate. Such extensions can be handled in untrusted manner. I.e. only process restrictions. > 9. In section 2.2, I can understand the default representation of the > certificate for association being a hexadecimal character string, however I > would prefer not having a MUST here as I believe that it might make sense > for people to represent this in other ways - i.e. information that > represents a certificate might be more useful in more advanced versions. Well, that's DNS RR represntation anyway, not any sort of wire format. Also, the hex format is pretty easy with hashes (shasum / sha256sum output). > 10. Section 4.1 - The text assumes that all future reference types are going > to be hashes. I do not believe that this will necessarily be true. For > example I can see people defining a PGP certificate reference type. I think > the last two sentences can be combined together when a more general > statement that the certificate referenced must be dereferenced and match. I > don't know of any new reference types that might be included. I believe > that in association with this we should change the reference type 0 from > Full Certificate to Value. If I include a cert type of 3 and a ref type > of 0 then calling the public key a full certificate does not really make any > sense. The idea is that certificate type sets constraints on what it can match and tells how to format the data. Then reference type tells what hash function (if any) this data is to be run through. This decouples the certificate type and reference type. Also, this type of cartesian factorizability makes implementation easier. Thus to add PGP type, add certificate type 4 that can match PGP certificates and specify how to format them. > 11. Section 4.2 - As with the usage document, if the "Certification > Authority Certificate" is only for trust anchors - I would much rather see > the title of the section reflect that point. It is not currently allowed > for an intermediate certification authority and thus the title is > misleading. I personally have no problems with a certificate being both an > EE certificate and a trust anchor as that is what is happening. Actually, according to text it is any higher certificate with EE specifically excluded (use type 1 to match EEs). I think this is the intention for type 2. > 12. Section 4.4 - You say that type is a "trust anchor for that domain > name" I think that this is a bit squirrely for language as it allows for a > possible ambiguity with DNSSEC vs TLS. I would preferce that that it is a > "trust anchor for certificate chains for services in this domain name". Or actually, isn't it just one port in that domain name? > 13. Section 4.4 - Missing paragraph? " If a certificate association > contains a certificate type field that is not understood by the TLS client, > that certificate association MUST be marked as unusable." See point 2 above for reasons I consider this to be very bad idea. -Ilari From rbarnes@bbn.com Mon Jul 18 13:21:13 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60C9621F859E for ; Mon, 18 Jul 2011 13:21:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NH63i7rL7rzN for ; Mon, 18 Jul 2011 13:21:12 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 764E221F858A for ; Mon, 18 Jul 2011 13:21:12 -0700 (PDT) Received: from ros-dhcp192-1-51-85.bbn.com ([192.1.51.85]:59561) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QiuJJ-000K36-Si; Mon, 18 Jul 2011 16:21:01 -0400 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <20110718195711.GA32357@LK-Perkele-VI.localdomain> Date: Mon, 18 Jul 2011 16:20:53 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <1E3D06D4-8068-41AA-AC51-408E5768E952@bbn.com> References: <008401cc4579$b91f7e30$2b5e7a90$@augustcellars.com> <20110718195711.GA32357@LK-Perkele-VI.localdomain> To: Ilari Liusvaara X-Mailer: Apple Mail (2.1082) Cc: Paul Hoffman , dane@ietf.org Subject: Re: [dane] Review of draft-ietf-dane-protocol-08.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 20:21:13 -0000 >> 3. The text in para 6 of section 4.4 is very out of date. It does = not >> discuss any certificate type except end-entity and states that if an >> end-entity certificate is not found (i.e. you cannot do a trust = anchor only >> DANE record) then the handshake aborts >=20 > I think TLS requres an end-entity certificate (unless selected = Ciphersuite > does not use certificates at all). RFC 5246 implies that this is the case, but does not normatively require = it. See: --Richard= From ietf@augustcellars.com Mon Jul 18 14:06:06 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B76D21F8785 for ; Mon, 18 Jul 2011 14:06:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dJ8S3otha2DB for ; Mon, 18 Jul 2011 14:06:05 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3BDAE21F8782 for ; Mon, 18 Jul 2011 14:06:05 -0700 (PDT) Received: from TITUS (173-8-216-38-Oregon.hfc.comcastbusiness.net [173.8.216.38]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTP id 4EF326A439; Mon, 18 Jul 2011 14:06:04 -0700 (PDT) From: "Jim Schaad" To: "'Ilari Liusvaara'" References: <008401cc4579$b91f7e30$2b5e7a90$@augustcellars.com> <20110718195711.GA32357@LK-Perkele-VI.localdomain> In-Reply-To: <20110718195711.GA32357@LK-Perkele-VI.localdomain> Date: Mon, 18 Jul 2011 14:05:05 -0700 Message-ID: <00a101cc458e$5f480610$1dd81230$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJOFWqSNY3v5v+I3x66poTmatTjUgGJLujLk+Kh41A= Content-Language: en-us Cc: 'Paul Hoffman' , dane@ietf.org Subject: Re: [dane] Review of draft-ietf-dane-protocol-08.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 21:06:06 -0000 Comments mixed in > -----Original Message----- > From: Ilari Liusvaara [mailto:ilari.liusvaara@elisanet.fi] > Sent: Monday, July 18, 2011 12:57 PM > To: Jim Schaad > Cc: Paul Hoffman; jakob@kirei.se; dane@ietf.org > Subject: Re: [dane] Review of draft-ietf-dane-protocol-08.txt >=20 > On Mon, Jul 18, 2011 at 11:37:17AM -0700, Jim Schaad wrote: > > I have done a careful read of the document and here are my comments: > > > > 2. The text in para 4 of section 4.4 should probably also say that = if > > the certificate type is not understood by the TLS client then the > > association is marked as unusable. >=20 > -1. Such associations must be considered usable but not matching or = you will > get a downgrade attack possibility. If that is the case then I would also say that the same text should be = used for the references section. I.e. if there is a reference that you = do not understand then the association should not be marked as unusable = and continue for the same reason as above. Either both can be ignored = or neither can be ignored. >=20 > > 3. The text in para 6 of section 4.4 is very out of date. It does > > not discuss any certificate type except end-entity and states that = if > > an end-entity certificate is not found (i.e. you cannot do a trust > > anchor only DANE record) then the handshake aborts >=20 > I think TLS requres an end-entity certificate (unless selected = Ciphersuite does > not use certificates at all). My text was a bit too brief I guess. The text in the paragraph states = that if an association is not found for the end-entity certificate then = the handshake stops. However there is no reason in principle that an = association could not be made for either the trust anchor or one of the = intermediary CA certificates and no association exist for the EE = certificate. This is not to state that TLS does not have an EE = certificate. >=20 > > 4. In section 5 - 3.2 Certificate constraints - see above point = about > > why I don't think a public key actually implements a certificate > > constraint - it just implements a public key constraint. As such it > > does not enforce any extensions in the certificate. >=20 > Such extensions can be handled in untrusted manner. I.e. only process > restrictions. At least one of us has misunderstood the other. If I have the case of=20 TA1->CA1->EE =20 And the certificate CA1(signed by TA1) has a critical extension in it = that needs to be checked by the TLS client. Alice puts in a TLSA restriction that the public key of CA1 must appear = in the chain. TA2->CA2->EE The certificate CA2(signed by TA2) has the same public key as CA1, but = does not contain the critical extension that Alice wants to see = enforced. There is nothing in the current system to say that only the = cert for CA1 but not the cert for CA2 can be used to validate the = certificate EE when doing chain validation. Both certificates satisfy = the public key constraint but do not have the same properties for doing = path validation in PKIX. >=20 > > 9. In section 2.2, I can understand the default representation of = the > > certificate for association being a hexadecimal character string, > > however I would prefer not having a MUST here as I believe that it > > might make sense for people to represent this in other ways - i.e. > > information that represents a certificate might be more useful in = more > advanced versions. >=20 > Well, that's DNS RR represntation anyway, not any sort of wire format. >=20 > Also, the hex format is pretty easy with hashes (shasum / sha256sum > output). I understand that this is not a wire format. But I think that the MUST = is too strong. Do you disagree? >=20 > > 10. Section 4.1 - The text assumes that all future reference types = are > > going to be hashes. I do not believe that this will necessarily be > > true. For example I can see people defining a PGP certificate > > reference type. I think the last two sentences can be combined > > together when a more general statement that the certificate = referenced > > must be dereferenced and match. I don't know of any new reference > > types that might be included. I believe that in association with = this we > should change the reference type 0 from > > Full Certificate to Value. If I include a cert type of 3 and a = ref type > > of 0 then calling the public key a full certificate does not really > > make any sense. >=20 > The idea is that certificate type sets constraints on what it can = match and tells > how to format the data. Then reference type tells what hash function = (if any) > this data is to be run through. >=20 > This decouples the certificate type and reference type. Also, this = type of > cartesian factorizability makes implementation easier. >=20 > Thus to add PGP type, add certificate type 4 that can match PGP = certificates > and specify how to format them. I think that I changed thoughts half way through and messed up. A new = reference type might be "indirect" which would contain a DNS name to = look for the TLSA certificate data . Partly in this text I am mixing up = reference type and certificate type. Thought #1 The text assumes that all future reference types are going to be hashes. = I do not believe that this will necessarily be true. For example, I = can see people defining an "indirect" reference type where the contents = is a DNS node to look in to get the actual certificate value. =20 Thought #2 I think that using Full certificate for reference type 0 is incorrect = and should be Value. If I include a cert type of 3 and a ref type of 0 = then calling the public key a full certificate does not really make any = sense. >=20 > > 11. Section 4.2 - As with the usage document, if the "Certification > > Authority Certificate" is only for trust anchors - I would much = rather > > see the title of the section reflect that point. It is not = currently > > allowed for an intermediate certification authority and thus the = title > > is misleading. I personally have no problems with a certificate = being > > both an EE certificate and a trust anchor as that is what is = happening. >=20 > Actually, according to text it is any higher certificate with EE = specifically > excluded (use type 1 to match EEs). I think this is the intention for = type 2. If you read the text is says "The certificate association is valid if = the first certificate in the certificate bundle can be validly chained to the trust anchor from the TLSA data." Which means that it is only for trust anchors. Type 2 is in section 4.3 = and thus would not be covered by this section (and the title on the = section) >=20 > > 12. Section 4.4 - You say that type is a "trust anchor for that > > domain name" I think that this is a bit squirrely for language as = it > > allows for a possible ambiguity with DNSSEC vs TLS. I would = preferce > > that that it is a "trust anchor for certificate chains for services = in this domain > name". >=20 > Or actually, isn't it just one port in that domain name? That would depend on the domain name in question. If it was example.com = then no it is the entire domain (with possible exceptions). If it is = _443._tcp.example.com then it would be for a specific port and protocol. >=20 > > 13. Section 4.4 - Missing paragraph? " If a certificate association > > contains a certificate type field that is not understood by the TLS > > client, that certificate association MUST be marked as unusable." >=20 > See point 2 above for reasons I consider this to be very bad idea. This is what I get for writing a message over the course of 2 weeks. = This is a duplicate item and can be ignored. Jim >=20 > -Ilari From jimsch@nwlink.com Mon Jul 18 11:55:52 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD82821F8591 for ; Mon, 18 Jul 2011 11:55:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HW2PlJoM8d0e for ; Mon, 18 Jul 2011 11:55:48 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id EAB7421F8B89 for ; Mon, 18 Jul 2011 11:55:47 -0700 (PDT) Received: from TITUS (176.120.168.69.static.onlinenw.com [69.168.120.176]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp2.pacifier.net (Postfix) with ESMTP id 3D0686A437; Mon, 18 Jul 2011 11:55:47 -0700 (PDT) From: "Jim Schaad" To: "Paul Hoffman" , Date: Mon, 18 Jul 2011 11:54:49 -0700 Message-ID: <008501cc457c$2be79400$83b6bc00$@nwlink.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AcxFedTdCD0ie4NASPGwgIl6w0ihPQ== Content-Language: en-us X-Mailman-Approved-At: Mon, 18 Jul 2011 14:13:25 -0700 Cc: dane@ietf.org Subject: [dane] Delegated Services Problems X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 18:55:52 -0000 I have been going through the delegated services cases (3.4 in use-cases) and I have decided that I don't understand enough to think that they are correct. 1. Alice maintains DNSSEC control of the tree and delegates a service to Oscar. This case is straight forward from Alice's point of view. Alice maintains all DNS records and the coordination needed if either the addresses or the certificate chain changes is well understood. 2. Alice delegates a sub-domain to Oscar and Oscar becomes the DNSSEC authority for the sub-tree. This case is also straight forward, the use case document is missing the fact that if the DNS keys for Oscar change then Alice needs to be notified of this. 3. Alice just does a CName reference to Oscar for the service and Oscar is the full authority. Again this case is straight forward and requires zero coordination between Alice and Oscar at all. 4. Alice keeps the DNS records but delegates the address records to Oscar. With my limited understanding I can think of a couple of ways that this could be implemented. 4a. Alice delegates www.alice.com to Oscar and Oscar delegates _443._tcp._www.alice.com back to Alice. In this case things work as expected, but Alice does not have any insurance that Oscar is doing the delegation back except by doing a routine name resolution and seeing where things go. 4b. Alice uses a CName to Oscar and Oscar delegates back to Alice. In this case alice.com contains a CName to alice.oscar.com and Oscar delegates _443._tcp._alice.oscar.com back to Alice. Note that one would not be able to CName to Oscar.com as this would mess up both Oscar and anyone else that Oscar is giving services to. 4c. Alice uses a CName to get the A/AAAA record for the service, but the TLSA records are kept in Alice's DNS tree. This changes the way that I have always thought that the DNS lookups will occur for DANE and thus needs both consideration and documentation if it is to be used. NOTE: This is the only method that can be used by Alice if she really wants to keep full control of the certificates/keys and trust anchors used by Oscar. Look up for Addresses: www.alice.com - returns nothing alice.com - returns CName to Oscar.com Oscar.com - returns AAAA record for server. Look up for TLSA records: _443._tcp.www.alice.com - returns nothing _443._tcp.alice.com - if returns TLSA records - then use them Else Use the CName record from alice.com _443._tcp.oscar.com - returns TLSA records. I am sure that the above sequence of what things to look up is both incomplete and wrong, but it will give me enough rope to show the sequence of events that I want to see happen. The address look ups proceed as currently defined. However for the TLSA look ups a new sequence of events is done. 1. Start by using the ORIGINAL address you were looking for and make the TLSA modifications for it. 2. Resolve for a TLSA record - if found then stop 3. Resolve for a CName record - if found then change to the search address to the TSLA modifications on the new CName record go to step 2 4. Move to parent in tree - if "too high" stop 5. Go to step 2 Jim From paul@xelerance.com Mon Jul 18 14:19:02 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5009A21F871E for ; Mon, 18 Jul 2011 14:19:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.482 X-Spam-Level: X-Spam-Status: No, score=-6.482 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EQdCfwTy06Sv for ; Mon, 18 Jul 2011 14:19:01 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by ietfa.amsl.com (Postfix) with ESMTP id B423721F86AE for ; Mon, 18 Jul 2011 14:19:01 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 4809D570FB; Mon, 18 Jul 2011 17:19:31 -0400 (EDT) Date: Mon, 18 Jul 2011 17:19:31 -0400 (EDT) From: Paul Wouters To: Ilari Liusvaara In-Reply-To: <20110718195711.GA32357@LK-Perkele-VI.localdomain> Message-ID: References: <008401cc4579$b91f7e30$2b5e7a90$@augustcellars.com> <20110718195711.GA32357@LK-Perkele-VI.localdomain> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Paul Hoffman , dane@ietf.org Subject: Re: [dane] Review of draft-ietf-dane-protocol-08.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 21:19:02 -0000 On Mon, 18 Jul 2011, Ilari Liusvaara wrote: >> 3. The text in para 6 of section 4.4 is very out of date. It does not >> discuss any certificate type except end-entity and states that if an >> end-entity certificate is not found (i.e. you cannot do a trust anchor only >> DANE record) then the handshake aborts > > I think TLS requres an end-entity certificate (unless selected Ciphersuite > does not use certificates at all). Hopefully not much longer: http://tools.ietf.org/html/draft-wouters-tls-oob-pubkey-00 > The idea is that certificate type sets constraints on what it can match and > tells how to format the data. Then reference type tells what hash function > (if any) this data is to be run through. > > This decouples the certificate type and reference type. Also, this type > of cartesian factorizability makes implementation easier. > > Thus to add PGP type, add certificate type 4 that can match PGP certificates > and specify how to format them. The naming of "certificate" in the entire document could be made more uhm opaque to allow for different types, but it might make reading the document much harder. Paul From mrex@sap.com Mon Jul 18 15:04:55 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2673D21F893E for ; Mon, 18 Jul 2011 15:04:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.895 X-Spam-Level: X-Spam-Status: No, score=-9.895 tagged_above=-999 required=5 tests=[AWL=0.354, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S33-iR3kfbJr for ; Mon, 18 Jul 2011 15:04:54 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 0110E21F86DE for ; Mon, 18 Jul 2011 15:04:53 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p6IM4pAC003953 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 19 Jul 2011 00:04:51 +0200 (MEST) From: Martin Rex Message-Id: <201107182204.p6IM4pds016022@fs4113.wdf.sap.corp> To: hallam@gmail.com (Phillip Hallam-Baker) Date: Tue, 19 Jul 2011 00:04:51 +0200 (MEST) In-Reply-To: from "Phillip Hallam-Baker" at Jul 17, 11 09:53:35 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: dane@ietf.org Subject: Re: [dane] Fixing DANE to resolve properly with DNS X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 22:04:55 -0000 Phillip Hallam-Baker wrote: > > I don't see the problem here. The alias is from www.example.com to > www.notexample.notcom > > Anyone can point any domain anywhere they please, but they cant affect the > interpretation of the target when someone types that in. > > At the moment anyone can point a CNAME at paypal.com. Does that really > matter? No, it doesn't matter. CNAMEs are completely irrelevant _and_ invisible to server endpoint identification in TLS. They slow down the gethostbyname() call to obtain an IP-Address but are otherwise invisible to the app. All of the occurrences of CNAME in http://tools.ietf.org/html/rfc6125 read CNAME canonicalization is not done. -Martin From i.grok@comcast.net Mon Jul 18 16:43:07 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53DD021F89A7 for ; Mon, 18 Jul 2011 16:43:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.553 X-Spam-Level: X-Spam-Status: No, score=-102.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z2St5ZbACz9h for ; Mon, 18 Jul 2011 16:43:06 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by ietfa.amsl.com (Postfix) with ESMTP id 5021321F8794 for ; Mon, 18 Jul 2011 16:43:06 -0700 (PDT) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta03.westchester.pa.mail.comcast.net with comcast id 9bi91h0021vXlb853bj6jS; Mon, 18 Jul 2011 23:43:06 +0000 Received: from odin.ulthar.us ([68.33.77.0]) by omta17.westchester.pa.mail.comcast.net with comcast id 9bj51h01300PQ6U3dbj5xe; Mon, 18 Jul 2011 23:43:06 +0000 Received: from odin.ulthar.us (localhost [127.0.0.1]) by odin.ulthar.us (8.14.4/8.14.3) with ESMTP id p6INh3WH005754 for ; Mon, 18 Jul 2011 19:43:03 -0400 Received: (from draco@localhost) by odin.ulthar.us (8.14.4/8.14.4/Submit) id p6INh3NT005753 for dane@ietf.org; Mon, 18 Jul 2011 19:43:03 -0400 Date: Mon, 18 Jul 2011 19:43:03 -0400 From: Scott Schmit To: dane@ietf.org Message-ID: <20110718234303.GA4512@odin.ulthar.us> Mail-Followup-To: dane@ietf.org References: <4E24612E.4060708@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Canceling the Quebec session X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 23:43:07 -0000 On Mon, Jul 18, 2011 at 01:15:22PM -0400, Phillip Hallam-Baker wrote: > The other issue that I think requires in person discussion is what to do > next. Should the WG get the RR draft for key distribution published and then > close or do people want to do something further. If so what is that and what > would be the scope. The next item in our charter is IPsec. -- Scott Schmit From mrex@sap.com Mon Jul 18 17:57:09 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F85121F8788 for ; Mon, 18 Jul 2011 17:57:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.902 X-Spam-Level: X-Spam-Status: No, score=-9.902 tagged_above=-999 required=5 tests=[AWL=0.347, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JmfJxuGYTfFm for ; Mon, 18 Jul 2011 17:57:08 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 5B92521F873A for ; Mon, 18 Jul 2011 17:57:08 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p6J0uwxo023273 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 19 Jul 2011 02:56:58 +0200 (MEST) From: Martin Rex Message-Id: <201107190056.p6J0uvkp001385@fs4113.wdf.sap.corp> To: rbarnes@bbn.com (Richard L. Barnes) Date: Tue, 19 Jul 2011 02:56:57 +0200 (MEST) In-Reply-To: <1E3D06D4-8068-41AA-AC51-408E5768E952@bbn.com> from "Richard L. Barnes" at Jul 18, 11 04:20:53 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: paul.hoffman@vpnc.org, dane@ietf.org Subject: Re: [dane] Review of draft-ietf-dane-protocol-08.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 00:57:09 -0000 Richard L. Barnes wrote: > > >> 3. The text in para 6 of section 4.4 is very out of date. It does not > >> discuss any certificate type except end-entity and states that if an > >> end-entity certificate is not found (i.e. you cannot do a trust anchor > >> only DANE record) then the handshake aborts > > > > I think TLS requres an end-entity certificate (unless selected > > Ciphersuite does not use certificates at all). > > RFC 5246 implies that this is the case, but does not normatively require it. > See: I do not see any such implication, and in fact, using self-signed certs as well as servers using "allowed to act as a CA" cert work fine with every TLS implementation that I've seen, once you configure the trust. Btw. shipping a TLS implementation with _ZERO_ trust anchors preconfigured is perfectly reasonable. In that case, configuring trust for a server with a self-signed cert could be easier that configuring trust for a server with a cert signed by a commercial CA. -Martin From fanf2@hermes.cam.ac.uk Tue Jul 19 11:06:35 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 248F821F84E0 for ; Tue, 19 Jul 2011 11:06:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sj-4vKzm9ng6 for ; Tue, 19 Jul 2011 11:06:31 -0700 (PDT) Received: from ppsw-51.csi.cam.ac.uk (ppsw-51.csi.cam.ac.uk [131.111.8.151]) by ietfa.amsl.com (Postfix) with ESMTP id 17C8C21F84E3 for ; Tue, 19 Jul 2011 11:06:30 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:54059) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:fanf2) id 1QjEge-0002xA-WH (Exim 4.72) (return-path ); Tue, 19 Jul 2011 19:06:28 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1QjEgd-00048u-WA (Exim 4.67) (return-path ); Tue, 19 Jul 2011 19:06:28 +0100 Date: Tue, 19 Jul 2011 19:06:27 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Phillip Hallam-Baker In-Reply-To: Message-ID: References: <16351912-18B3-45D5-8C0E-B01D434B0F02@kirei.se> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: "dane@ietf.org" Subject: Re: [dane] Fixing DANE to resolve properly with DNS X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 18:06:35 -0000 Phillip Hallam-Baker wrote: > > Why not add a CNAME for the prefixed name? E.g., > > _443._tcp.example.com. CNAME _443._tcp.example.com. > > That defeats the purpose of CNAME, if you are going to do that you might as > well just copy all the entries from one node to the other. Maintaining the > CNAME links is going to be pretty much as hard as copying the destination. No. The CNAME links are exactly parallel, of the form original CNAME target _443._tcp.original CNAME _443._tcp.target The CNAME target will be much less volatile and subject to operational change than the contents of the A, AAAA, and TLSA records. Outsourcing makes no difference. There are other protocols that have this non-problem, e.g. DKIM. Tony. -- f.anthony.n.finch http://dotat.at/ Lundy, Fastnet: Northwest becoming cyclonic then north, 4 or 5, occasionally 6. Slight or moderate. Rain or showers. Moderate or good. From fanf2@hermes.cam.ac.uk Tue Jul 19 11:13:25 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C4E421F856F for ; Tue, 19 Jul 2011 11:13:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0HmnztfcCsq2 for ; Tue, 19 Jul 2011 11:13:21 -0700 (PDT) Received: from ppsw-50.csi.cam.ac.uk (ppsw-50.csi.cam.ac.uk [131.111.8.150]) by ietfa.amsl.com (Postfix) with ESMTP id 27B1721F8564 for ; Tue, 19 Jul 2011 11:13:21 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:59811) by ppsw-50.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1QjEnH-0000cQ-qI (Exim 4.72) (return-path ); Tue, 19 Jul 2011 19:13:19 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1QjEnH-0004y4-6K (Exim 4.67) (return-path ); Tue, 19 Jul 2011 19:13:19 +0100 Date: Tue, 19 Jul 2011 19:13:19 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Phillip Hallam-Baker In-Reply-To: Message-ID: References: <20110718013813.GA2236@odin.ulthar.us> <601CBC7C-5122-4CCF-9811-440E96DCC4F7@vpnc.org> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: Paul Hoffman , DANE WG Subject: Re: [dane] Fixing DANE to resolve properly with DNS X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 18:13:25 -0000 Phillip Hallam-Baker wrote: > > So probably a good idea to have a comment to the effect that caches have to > store the data in sensible form here. That kind of recommendation is for dnsop and is off-topic for this wg. Tony. -- f.anthony.n.finch http://dotat.at/ Biscay: Northwest, backing west or southwest for a time, 5 to 7. Moderate or rough. Showers then rain. Good, becoming moderate or poor. From fanf2@hermes.cam.ac.uk Tue Jul 19 11:15:06 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8025921F8564 for ; Tue, 19 Jul 2011 11:15:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D0n6lH48ZmJ9 for ; Tue, 19 Jul 2011 11:15:06 -0700 (PDT) Received: from ppsw-41.csi.cam.ac.uk (ppsw-41.csi.cam.ac.uk [131.111.8.141]) by ietfa.amsl.com (Postfix) with ESMTP id EF80721F853E for ; Tue, 19 Jul 2011 11:15:05 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:41552) by ppsw-41.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:fanf2) id 1QjEoy-0003uW-R8 (Exim 4.72) (return-path ); Tue, 19 Jul 2011 19:15:04 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1QjEoy-0005HR-11 (Exim 4.67) (return-path ); Tue, 19 Jul 2011 19:15:04 +0100 Date: Tue, 19 Jul 2011 19:15:04 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Phillip Hallam-Baker In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: dane@ietf.org Subject: Re: [dane] Fixing DANE to resolve properly with DNS X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 18:15:06 -0000 Phillip Hallam-Baker wrote: > > One way to solve this is to note that any client is going to have to also > look up the A record for the service. Thus if the A record lookup returns an > alias, the client is required to retry the lookup for the canonical name. That would require a DANE client to use custom resolution code instead of just using a generic lookup function. Tony. -- f.anthony.n.finch http://dotat.at/ Shannon: Cyclonic becoming northerly 4 or 5, increasing 6 or 7 for a time in far southwest. Moderate or rough. Rain then showers. Moderate or poor, becoming good. From hallam@gmail.com Tue Jul 19 11:29:32 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6B555E8004 for ; Tue, 19 Jul 2011 11:29:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.505 X-Spam-Level: X-Spam-Status: No, score=-3.505 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hHq-C45j64Xq for ; Tue, 19 Jul 2011 11:29:29 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 342C122801A for ; Tue, 19 Jul 2011 11:29:28 -0700 (PDT) Received: by gyd5 with SMTP id 5so2163848gyd.31 for ; Tue, 19 Jul 2011 11:29:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fjpIAUjwNbwNO5ochWYnJiWWSe7oeMbg93AZIzazTus=; b=qmyQ4KMzZAjRknHkot5oQTONhFWUw4RIrbQe5utjhXrvZjxRN2GjvB7en2BRbQyQWI PIRuwhYggguirWCEgbkXocSJzCB5+vmf8We/BNsKWKMSHydg5RmOT10TxnxvM8yBLUtC YvUJ8OxpEyVpujGb/fM7gruRHkynI9LB42AiY= MIME-Version: 1.0 Received: by 10.100.74.38 with SMTP id w38mr6905332ana.5.1311100167647; Tue, 19 Jul 2011 11:29:27 -0700 (PDT) Received: by 10.100.134.9 with HTTP; Tue, 19 Jul 2011 11:29:27 -0700 (PDT) In-Reply-To: References: <20110718013813.GA2236@odin.ulthar.us> <601CBC7C-5122-4CCF-9811-440E96DCC4F7@vpnc.org> Date: Tue, 19 Jul 2011 14:29:27 -0400 Message-ID: From: Phillip Hallam-Baker To: Tony Finch Content-Type: multipart/alternative; boundary=001636b2b302c1f0dc04a8704bfb Cc: Paul Hoffman , DANE WG Subject: Re: [dane] Fixing DANE to resolve properly with DNS X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 18:29:33 -0000 --001636b2b302c1f0dc04a8704bfb Content-Type: text/plain; charset=ISO-8859-1 No, in this case the cache being referred to was an in-application cache. The Security Considerations have to cover the whole protocol. Even it DNSops also has to address it, the protocol docs have to alert them to the dependency. On Tue, Jul 19, 2011 at 2:13 PM, Tony Finch wrote: > Phillip Hallam-Baker wrote: > > > > So probably a good idea to have a comment to the effect that caches have > to > > store the data in sensible form here. > > That kind of recommendation is for dnsop and is off-topic for this wg. > > Tony. > -- > f.anthony.n.finch http://dotat.at/ > Biscay: Northwest, backing west or southwest for a time, 5 to 7. Moderate > or > rough. Showers then rain. Good, becoming moderate or poor. > -- Website: http://hallambaker.com/ --001636b2b302c1f0dc04a8704bfb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable No, in this case the cache being referred to was an in-application cache.
The Security Considerations have to cover the whole proto= col. Even it DNSops also has to address it, the protocol docs have to alert= them to the dependency.


On Tue, Jul 19, 2011 at 2:13 PM, To= ny Finch <dot@dotat.at= > wrote:
Phillip Hallam-Baker <hallam@gmail.com> wrote:
>
> So probably a good idea to have a comment to t= he effect that caches have to
> store the data in sensible form here.

That kind of recommendation is for dnsop and is off-topic for this wg= .

Tony.
--
f.anthony.n.finch =A0<dot@dotat.at&g= t; =A0http://dotat.at/
Biscay: Northwest, backing west or southwest for a time, 5 to 7. Mode= rate or
rough. Showers then rain. Good, becoming moderate or poor.



--
Website: http://hallambaker.com/

--001636b2b302c1f0dc04a8704bfb-- From hallam@gmail.com Tue Jul 19 11:31:04 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B76095E800A for ; Tue, 19 Jul 2011 11:31:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.507 X-Spam-Level: X-Spam-Status: No, score=-3.507 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7fau1Cg-QNLn for ; Tue, 19 Jul 2011 11:31:00 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 333E55E8009 for ; Tue, 19 Jul 2011 11:31:00 -0700 (PDT) Received: by ywp31 with SMTP id 31so2172850ywp.31 for ; Tue, 19 Jul 2011 11:30:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8DsqwjDCbl6AA4660qBPLj6p08upeIBx/N1kiTPSOjI=; b=r6lJQNz3tFQk+gLUE6VvXZZtc/HZMOZmVPPgePKvbche/8rrAh8CkUhh+XOcxDC5hG uDGWM6QqKC2rfNHk+1iqIZNLDTnlISCkjYH7FAKCBg/76fwOOM8Fo14PBLKpoxvggtF8 MFdpKpRaLCHgmtv8hb4q4S0pFc3ADcyHS3Qew= MIME-Version: 1.0 Received: by 10.101.175.36 with SMTP id c36mr6950442anp.93.1311100259654; Tue, 19 Jul 2011 11:30:59 -0700 (PDT) Received: by 10.100.134.9 with HTTP; Tue, 19 Jul 2011 11:30:59 -0700 (PDT) In-Reply-To: References: Date: Tue, 19 Jul 2011 14:30:59 -0400 Message-ID: From: Phillip Hallam-Baker To: Tony Finch Content-Type: multipart/alternative; boundary=001636c5be693ddc4a04a870517d Cc: dane@ietf.org Subject: Re: [dane] Fixing DANE to resolve properly with DNS X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 18:31:04 -0000 --001636c5be693ddc4a04a870517d Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jul 19, 2011 at 2:15 PM, Tony Finch wrote: > Phillip Hallam-Baker wrote: > > > > One way to solve this is to note that any client is going to have to also > > look up the A record for the service. Thus if the A record lookup returns > an > > alias, the client is required to retry the lookup for the canonical name. > > That would require a DANE client to use custom resolution code instead of > just using a generic lookup function. Not a problem, DANE libraries are going to have to have DNSSEC processing anyway. -- Website: http://hallambaker.com/ --001636c5be693ddc4a04a870517d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Jul 19, 2011 at 2:15 PM, Tony Fi= nch <dot@dotat.at&= gt; wrote:
Phillip Hallam-Baker <hallam@gmail.com> wrote:
>
> One way to solve this is to note that any clie= nt is going to have to also
> look up the A record for the service. Thus if the A record lookup retu= rns an
> alias, the client is required to retry the lookup for the canonical na= me.

That would require a DANE client to use custom resolution code instea= d of
just using a generic lookup function.

Not a= problem, DANE libraries are going to have to have DNSSEC processing anyway= .=A0




--
Website: http://hallambaker.com/
--001636c5be693ddc4a04a870517d-- From paul@xelerance.com Tue Jul 19 11:49:40 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A868621F8512 for ; Tue, 19 Jul 2011 11:49:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.496 X-Spam-Level: X-Spam-Status: No, score=-6.496 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id du5R3Os9OZer for ; Tue, 19 Jul 2011 11:49:39 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by ietfa.amsl.com (Postfix) with ESMTP id 9481221F850E for ; Tue, 19 Jul 2011 11:49:39 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 9EF89BF51; Tue, 19 Jul 2011 14:50:10 -0400 (EDT) Date: Tue, 19 Jul 2011 14:50:10 -0400 (EDT) From: Paul Wouters To: Phillip Hallam-Baker In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8BIT Cc: dane@ietf.org Subject: Re: [dane] Fixing DANE to resolve properly with DNS X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 18:49:40 -0000 On Tue, 19 Jul 2011, Phillip Hallam-Baker wrote: > Not a problem, DANE libraries are going to have to have DNSSEC processing anyway.  Or look for the AD bit on the localhost dnssec resolver. Paul From nweaver@icsi.berkeley.edu Tue Jul 19 11:51:48 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA14411E807A for ; Tue, 19 Jul 2011 11:51:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J308SX3ChX46 for ; Tue, 19 Jul 2011 11:51:43 -0700 (PDT) Received: from taffy.ICSI.Berkeley.EDU (taffy.ICSI.Berkeley.EDU [192.150.187.26]) by ietfa.amsl.com (Postfix) with ESMTP id 993A3228016 for ; Tue, 19 Jul 2011 11:51:43 -0700 (PDT) Received: from albook.hsd1.ca.comcast.net (c-76-102-105-174.hsd1.ca.comcast.net [76.102.105.174]) (Authenticated sender: nweaver) by taffy.ICSI.Berkeley.EDU (Postfix) with ESMTP id E9BB736A382; Tue, 19 Jul 2011 11:51:39 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Nicholas Weaver In-Reply-To: Date: Tue, 19 Jul 2011 11:51:39 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Paul Wouters X-Mailer: Apple Mail (2.1084) Cc: dane@ietf.org Subject: Re: [dane] Fixing DANE to resolve properly with DNS X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 18:51:48 -0000 On Jul 19, 2011, at 11:50 AM, Paul Wouters wrote: > On Tue, 19 Jul 2011, Phillip Hallam-Baker wrote: >=20 >> Not a problem, DANE libraries are going to have to have DNSSEC = processing anyway.=20 >=20 > Or look for the AD bit on the localhost dnssec resolver. >=20 > Paul The system APIs currently don't support this, so why not bake the = resolver library into the app if you have to change the API anyway, = because the AD bit is a fiction unless you know exactly what is doing = the validating. From Jeff.Hodges@KingsMountain.com Tue Jul 19 12:02:59 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 740745E8009 for ; Tue, 19 Jul 2011 12:02:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.267 X-Spam-Level: X-Spam-Status: No, score=-102.267 tagged_above=-999 required=5 tests=[AWL=-0.002, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F8Zwqrjo+6ia for ; Tue, 19 Jul 2011 12:02:55 -0700 (PDT) Received: from oproxy7-pub.bluehost.com (oproxy7-pub.bluehost.com [67.222.55.9]) by ietfa.amsl.com (Postfix) with SMTP id 887E85E8004 for ; Tue, 19 Jul 2011 12:02:39 -0700 (PDT) Received: (qmail 24863 invoked by uid 0); 19 Jul 2011 19:02:36 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy7.bluehost.com with SMTP; 19 Jul 2011 19:02:36 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kingsmountain.com; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=HdNRlSPBLWMgduVXQM5FNJOpwqkZpI0xfytMJ7TDh2q3W04eWVxv6XZf7MVTcLyt2cu1adMDyJAcHfxLIVwc+ivIhsuXfm+XmDmziP6WRTBsn+PywOmfvatAcacGxJMn; Received: from outbound4.ebay.com ([216.113.168.128] helo=[10.244.137.251]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1QjFYx-0001Xf-O5 for dane@ietf.org; Tue, 19 Jul 2011 13:02:35 -0600 Message-ID: <4E25D4CB.2040108@KingsMountain.com> Date: Tue, 19 Jul 2011 12:02:35 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11 MIME-Version: 1.0 To: IETF DANE WG list Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com} Subject: Re: [dane] Canceling the Quebec session X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 19:02:59 -0000 Given PHB's & Paul Wouters' points (i count 14 open tickets out of 24 total), and Jim Schaad's review of draft-ietf-dane-protocol-08, it'd seem there's stuff to talk about f2f next week, yes? =JeffH From jakob@kirei.se Tue Jul 19 12:12:50 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 979FC21F855B for ; Tue, 19 Jul 2011 12:12:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.275 X-Spam-Level: X-Spam-Status: No, score=-0.275 tagged_above=-999 required=5 tests=[AWL=0.423, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_SE=0.35, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KkvxCY+dHg10 for ; Tue, 19 Jul 2011 12:12:46 -0700 (PDT) Received: from spg.kirei.se (spg.kirei.se [IPv6:2001:67c:394:15::9]) by ietfa.amsl.com (Postfix) with ESMTP id 9DBDE21F84B6 for ; Tue, 19 Jul 2011 12:12:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kirei.se; s=spg20100524; h=received:subject:mime-version:content-type:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to:x-mailer; bh=Z1IRNrRk8IVPRp79MjB6MConx34/CoHSeiWdHhCtmFk=; b=iccv3yFmmFCVDnQoEOEiIVo6u028h2xPpbc6whbb+Ssvfsfp7TAUFzQyhLxuqyXzFFI9spwvvhN9L g2K/keaK3n32CJlp2bdRDyudj9BCanHsdPEACNZ+yJgVPBCM9ua3ffYTOTU3wqjpeWZpN9Oqx8yDJ3 t7BW4j86E3tKQ9Co= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg-relay.kirei.se (Halon Mail Gateway) with ESMTPS; Tue, 19 Jul 2011 21:12:39 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Jakob Schlyter In-Reply-To: Date: Tue, 19 Jul 2011 21:12:37 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <892C2AF4-8BC9-41DB-A2B9-A37C08FBC1D9@kirei.se> References: <189933DE-6A77-45AD-8CDD-A9F7D486A890@kirei.se> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1084) Cc: Paul Hoffman , DANE WG Subject: Re: [dane] Fixing DANE to resolve properly with DNS X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 19:12:50 -0000 On 18 jul 2011, at 21.43, Phillip Hallam-Baker wrote: > How can you make that work with wildcards? Your suggestion to look up the prefixed names based on the canonical = hostname would indeed work. However, if we would implement that, I do = believe that the TLSA RR of the original hostname should take = precedence. jakob From warren@kumari.net Tue Jul 19 12:12:57 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BE5021F8565 for ; Tue, 19 Jul 2011 12:12:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yf+pADmRoM4O for ; Tue, 19 Jul 2011 12:12:56 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 860ED21F855B for ; Tue, 19 Jul 2011 12:12:56 -0700 (PDT) Received: from [192.168.1.5] (unknown [216.226.38.2]) by vimes.kumari.net (Postfix) with ESMTPSA id 28BBF1B41540; Tue, 19 Jul 2011 15:12:56 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warren Kumari In-Reply-To: <4E25D4CB.2040108@KingsMountain.com> Date: Tue, 19 Jul 2011 15:13:20 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E25D4CB.2040108@KingsMountain.com> To: =JeffH X-Mailer: Apple Mail (2.1084) Cc: IETF DANE WG list Subject: Re: [dane] Canceling the Quebec session X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 19:12:57 -0000 On Jul 19, 2011, at 3:02 PM, =3DJeffH wrote: > Given PHB's & Paul Wouters' points (i count 14 open tickets out of 24 = total), and Jim Schaad's review of draft-ietf-dane-protocol-08, it'd = seem there's stuff to talk about f2f next week, yes? Yes. We will be meeting. We have an almost full agenda and will post it = shortly (want to confirm that we have the titles correct and confirming = that one of the speakers is still willing). W >=20 > =3DJeffH > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane >=20 From hallam@gmail.com Tue Jul 19 13:20:38 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 689EE21F8B13 for ; Tue, 19 Jul 2011 13:20:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.509 X-Spam-Level: X-Spam-Status: No, score=-3.509 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XCjohyHENQvB for ; Tue, 19 Jul 2011 13:20:34 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id E01D121F8B10 for ; Tue, 19 Jul 2011 13:20:33 -0700 (PDT) Received: by gxk19 with SMTP id 19so2203789gxk.31 for ; Tue, 19 Jul 2011 13:20:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8r6YZOWp01yG8R8/WYNH/66zepxJ3uY/AvVSPIUbaxs=; b=VIpbkJfzcgVvapDo+YUrGkS3QdQ7GRSu9kNFN/StddvC5V/GtbySqx2mgFaeyGwe1j 4JZWTl5vCXdor6DR1cQBBME2IQDfiDi+HsmT4sRPeLQznK/Xxazf3Irq01ux8deJAjUs wudmXJRwMnRAHpLX8k736p4ahVfnSxQQgxcNQ= MIME-Version: 1.0 Received: by 10.101.174.28 with SMTP id b28mr7004914anp.71.1311106833147; Tue, 19 Jul 2011 13:20:33 -0700 (PDT) Received: by 10.100.134.9 with HTTP; Tue, 19 Jul 2011 13:20:33 -0700 (PDT) In-Reply-To: References: Date: Tue, 19 Jul 2011 16:20:33 -0400 Message-ID: From: Phillip Hallam-Baker To: Paul Wouters Content-Type: multipart/alternative; boundary=001636c5c22c0d659a04a871d989 Cc: dane@ietf.org Subject: Re: [dane] Fixing DANE to resolve properly with DNS X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 20:20:38 -0000 --001636c5c22c0d659a04a871d989 Content-Type: text/plain; charset=ISO-8859-1 If they can see the AD bit they can see the CNAMEs. On Tue, Jul 19, 2011 at 2:50 PM, Paul Wouters wrote: > On Tue, 19 Jul 2011, Phillip Hallam-Baker wrote: > > Not a problem, DANE libraries are going to have to have DNSSEC processing >> anyway. >> > > Or look for the AD bit on the localhost dnssec resolver. > > Paul > -- Website: http://hallambaker.com/ --001636c5c22c0d659a04a871d989 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable If they can see the AD bit they can see the CNAMEs.


=
On Tue, Jul 19, 2011 at 2:50 PM, Paul Wouters <paul@xelerance.co= m> wrote:
On Tue, 19 Jul 2011, Phil= lip Hallam-Baker wrote:

Not a problem, DANE libraries are going to have to have DNSSEC processing a= nyway.=A0

Or look for the AD bit on the localhost dnssec resolver.

Paul



--
Website: http://hallambaker.com/

--001636c5c22c0d659a04a871d989-- From hallam@gmail.com Tue Jul 19 13:24:31 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C5D421F8B15 for ; Tue, 19 Jul 2011 13:24:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.511 X-Spam-Level: X-Spam-Status: No, score=-3.511 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8yCdB9-kXb9F for ; Tue, 19 Jul 2011 13:24:30 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id 644BB21F8B13 for ; Tue, 19 Jul 2011 13:24:30 -0700 (PDT) Received: by yie30 with SMTP id 30so2227735yie.31 for ; Tue, 19 Jul 2011 13:24:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=EYGvpaq5G7j3JBFevYleKpihjv2xekLz5QY+DEam+bg=; b=vajx40xtlWkbiIgyB/2MQnnK2hmdJ/AdyW6xljZ3EGjsmscEWu2K1bXBFh6RcY4+km WjZLUly8jLf8ow46c6V79M9Ng7nKBEWGe+mmmqQvBu217L3QGNH0vJ7CTI5WYtgwQvPD npNbzfqb+9nM20+59IDhxBJR0bEh6UsrqsGZ8= MIME-Version: 1.0 Received: by 10.100.75.12 with SMTP id x12mr7023541ana.27.1311107069982; Tue, 19 Jul 2011 13:24:29 -0700 (PDT) Received: by 10.100.134.9 with HTTP; Tue, 19 Jul 2011 13:24:29 -0700 (PDT) In-Reply-To: <892C2AF4-8BC9-41DB-A2B9-A37C08FBC1D9@kirei.se> References: <189933DE-6A77-45AD-8CDD-A9F7D486A890@kirei.se> <892C2AF4-8BC9-41DB-A2B9-A37C08FBC1D9@kirei.se> Date: Tue, 19 Jul 2011 16:24:29 -0400 Message-ID: From: Phillip Hallam-Baker To: Jakob Schlyter Content-Type: multipart/alternative; boundary=001636b2af532b39a904a871e713 Cc: Paul Hoffman , DANE WG Subject: Re: [dane] Fixing DANE to resolve properly with DNS X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 20:24:31 -0000 --001636b2af532b39a904a871e713 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jul 19, 2011 at 3:12 PM, Jakob Schlyter wrote: > On 18 jul 2011, at 21.43, Phillip Hallam-Baker wrote: > > > How can you make that work with wildcards? > > Your suggestion to look up the prefixed names based on the canonical > hostname would indeed work. However, if we would implement that, I do > believe that the TLSA RR of the original hostname should take precedence. I don't much care what the precedence is, just as long as there is one specified and it is found to be reasonable in the light of implementation experience. We also need to decide on the circumstances in which the name shown to the user (if any) is going to be the source and the circumstances in which it is the destination. -- Website: http://hallambaker.com/ --001636b2af532b39a904a871e713 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Jul 19, 2011 at 3:12 PM, Jakob S= chlyter <jakob@kirei= .se> wrote:
On 18 jul 2011, at 21.43, Phillip Hallam-Baker wrote:

> How can you make that work with wildcards?

Your suggestion to look up the prefixed names based on the canonical = hostname would indeed work. However, if we would implement that, I do belie= ve that the TLSA RR of the original hostname should take precedence.

I don't much care what the precedence is, just as l= ong as there is one specified and it is found to be reasonable in the light= of implementation experience.

We also need to dec= ide on the circumstances in which the name shown to the user (if any) is go= ing to be the source and the circumstances in which it is the destination.<= /div>
=A0

--
Website: http://hallambaker.com/

--001636b2af532b39a904a871e713-- From ajs@anvilwalrusden.com Tue Jul 19 13:40:45 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FED421F8922 for ; Tue, 19 Jul 2011 13:40:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pfZuzInfSrSD for ; Tue, 19 Jul 2011 13:40:44 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 8CC6121F891F for ; Tue, 19 Jul 2011 13:40:44 -0700 (PDT) Received: from shinkuro.com (spliair.spotnik.ADSL.akn.ca [66.135.98.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 1B5BF1ECB41C for ; Tue, 19 Jul 2011 20:40:43 +0000 (UTC) Date: Tue, 19 Jul 2011 16:40:57 -0400 From: Andrew Sullivan To: dane@ietf.org Message-ID: <20110719204056.GC48176@shinkuro.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Fixing DANE to resolve properly with DNS X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 20:40:45 -0000 On Tue, Jul 19, 2011 at 02:50:10PM -0400, Paul Wouters wrote: > > Or look for the AD bit on the localhost dnssec resolver. I will point out that the last time the AD bit came up in any DNSEXT meeting, someone (Rob Austein?) got up at the mic and said something along the lines of, "We have to get the message across that the AD bit is for debugging." I'm aware that a large vendor based in Redmond thinks otherwise. -- Andrew Sullivan ajs@anvilwalrusden.com From warren@kumari.net Tue Jul 19 14:19:40 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37C9421F8B0F for ; Tue, 19 Jul 2011 14:19:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qrQcAg6QJZhr for ; Tue, 19 Jul 2011 14:19:39 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id AFB0F21F8B08 for ; Tue, 19 Jul 2011 14:19:39 -0700 (PDT) Received: from [192.168.1.5] (unknown [216.226.38.2]) by vimes.kumari.net (Postfix) with ESMTPSA id D29C51B40533 for ; Tue, 19 Jul 2011 17:19:38 -0400 (EDT) From: Warren Kumari Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 19 Jul 2011 17:20:02 -0400 Message-Id: <3F562A05-276C-4E5D-A807-0DA8873A40C8@kumari.net> To: IETF DANE WG list Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [dane] Closing issues that are no longer relevant... X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 21:19:40 -0000 Hello. Apologies all, I have not been very diligent in closing issues as they = are discussed / become non-relevant.=20 I'm going through the issue tracker and think that many of them can be = closed -- unless I hear strong objections by the end of week I'm = planning marking the following as closed: Issue /#6: Downgrade -- Addressed by discussions on DNSSEC stripping, = and in Section 4.4. Issue #15: What data should be hashed -- Addressed in Protocol doc / = discussions. Issue #22: Provide the security of the strongest digest supported by = both sides -- Discussions on list (decided that this should be left to = the relying party) Issue #2: Relying parties policies -- Addressed by discussions / changes = in the Protocol doc. Issue #7: Error Handling : What to do when you receive an invalid record = -- Addressed in Protocol doc ((e.g Section 4.4))=20 W= From ietf@augustcellars.com Tue Jul 19 14:43:43 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E297822800F for ; Tue, 19 Jul 2011 14:43:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TrZjgdi8zqes for ; Tue, 19 Jul 2011 14:43:43 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id 78D69228006 for ; Tue, 19 Jul 2011 14:43:43 -0700 (PDT) Received: from TITUS (176.120.168.69.static.onlinenw.com [69.168.120.176]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTP id E54B76A40F; Tue, 19 Jul 2011 14:43:42 -0700 (PDT) From: "Jim Schaad" To: "'Warren Kumari'" , "'IETF DANE WG list'" References: <3F562A05-276C-4E5D-A807-0DA8873A40C8@kumari.net> In-Reply-To: <3F562A05-276C-4E5D-A807-0DA8873A40C8@kumari.net> Date: Tue, 19 Jul 2011 14:42:42 -0700 Message-ID: <001a01cc465c$cb779890$6266c9b0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQDs2xGmLfV1Q/zFfRlg1O8NPsvbM5azAwkg Content-Language: en-us Subject: Re: [dane] Closing issues that are no longer relevant... X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 21:43:44 -0000 > -----Original Message----- > From: dane-bounces@ietf.org [mailto:dane-bounces@ietf.org] On Behalf Of > Warren Kumari > Sent: Tuesday, July 19, 2011 2:20 PM > To: IETF DANE WG list > Subject: [dane] Closing issues that are no longer relevant... > > Hello. > > Apologies all, I have not been very diligent in closing issues as they are > discussed / become non-relevant. > > I'm going through the issue tracker and think that many of them can be > closed -- unless I hear strong objections by the end of week I'm planning > marking the following as closed: > > > Issue /#6: Downgrade -- Addressed by discussions on DNSSEC stripping, and > in Section 4.4. > > Issue #15: What data should be hashed -- Addressed in Protocol doc / > discussions. > > Issue #22: Provide the security of the strongest digest supported by both > sides -- Discussions on list (decided that this should be left to the relying > party) > > Issue #2: Relying parties policies -- Addressed by discussions / changes in the > Protocol doc. > > Issue #7: Error Handling : What to do when you receive an invalid record -- > Addressed in Protocol doc ((e.g Section 4.4)) This is not fully addressed in the spec at present. Specifically what to do with unknown certificate types is not documented. Also I am not sure what the correct behavior should be for mal-formatted items. I.e. if bytes are missing or added to the current records. If you use an ASN.1 parser on the certificate and compare it, rather than byte comparing it then trailing bad bytes might be ignored. Jim > > > W > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From paul@xelerance.com Tue Jul 19 14:55:43 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BB8D21F8565 for ; Tue, 19 Jul 2011 14:55:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.502 X-Spam-Level: X-Spam-Status: No, score=-6.502 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HiJI79-qQR8k for ; Tue, 19 Jul 2011 14:55:42 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by ietfa.amsl.com (Postfix) with ESMTP id A315A21F8562 for ; Tue, 19 Jul 2011 14:55:42 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 8F05E570FB; Tue, 19 Jul 2011 17:56:10 -0400 (EDT) Date: Tue, 19 Jul 2011 17:56:09 -0400 (EDT) From: Paul Wouters To: Andrew Sullivan In-Reply-To: <20110719204056.GC48176@shinkuro.com> Message-ID: References: <20110719204056.GC48176@shinkuro.com> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dane@ietf.org Subject: Re: [dane] Fixing DANE to resolve properly with DNS X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 21:55:43 -0000 On Tue, 19 Jul 2011, Andrew Sullivan wrote: > I will point out that the last time the AD bit came up in any DNSEXT > meeting, someone (Rob Austein?) got up at the mic and said something > along the lines of, "We have to get the message across that the AD bit > is for debugging." I'm aware that a large vendor based in Redmond > thinks otherwise. That is the same as saying "all apps have to link to a dnssec capable resolver" Which means, unless they somehow magically share a cache, every app will be generating queries to validate the entire path to the root. Everytime they start. That seems sub-optimal to me. Paul From nweaver@icsi.berkeley.edu Tue Jul 19 14:57:30 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D59821F85DA for ; Tue, 19 Jul 2011 14:57:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9w4mBg3khPmD for ; Tue, 19 Jul 2011 14:57:30 -0700 (PDT) Received: from taffy.ICSI.Berkeley.EDU (taffy.ICSI.Berkeley.EDU [192.150.187.26]) by ietfa.amsl.com (Postfix) with ESMTP id 2B6B221F8572 for ; Tue, 19 Jul 2011 14:57:30 -0700 (PDT) Received: from albook.hsd1.ca.comcast.net (c-76-102-105-174.hsd1.ca.comcast.net [76.102.105.174]) (Authenticated sender: nweaver) by taffy.ICSI.Berkeley.EDU (Postfix) with ESMTP id E66C036A38B; Tue, 19 Jul 2011 14:57:29 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Nicholas Weaver In-Reply-To: Date: Tue, 19 Jul 2011 14:57:29 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110719204056.GC48176@shinkuro.com> To: Paul Wouters X-Mailer: Apple Mail (2.1084) Cc: dane@ietf.org Subject: Re: [dane] Fixing DANE to resolve properly with DNS X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 21:57:30 -0000 On Jul 19, 2011, at 2:56 PM, Paul Wouters wrote: > On Tue, 19 Jul 2011, Andrew Sullivan wrote: >=20 >> I will point out that the last time the AD bit came up in any DNSEXT >> meeting, someone (Rob Austein?) got up at the mic and said something >> along the lines of, "We have to get the message across that the AD = bit >> is for debugging." I'm aware that a large vendor based in Redmond >> thinks otherwise. >=20 > That is the same as saying "all apps have to link to a dnssec capable > resolver" >=20 > Which means, unless they somehow magically share a cache, every app = will > be generating queries to validate the entire path to the root. = Everytime > they start. >=20 > That seems sub-optimal to me. And those get trapped by either the local system resolver cache or the = ISP's cache... >=20 > Paul >=20 >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From hallam@gmail.com Tue Jul 19 15:08:57 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6387221F8505 for ; Tue, 19 Jul 2011 15:08:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.512 X-Spam-Level: X-Spam-Status: No, score=-3.512 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R-3oUhYRo3lh for ; Tue, 19 Jul 2011 15:08:53 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id DF3E321F84AE for ; Tue, 19 Jul 2011 15:08:52 -0700 (PDT) Received: by yxp4 with SMTP id 4so2363978yxp.31 for ; Tue, 19 Jul 2011 15:08:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=roj7pXNJNpdbbxjiHHf7GGCAKfjmYKPFKS8TwAuwiSw=; b=qPAb5IjEjVslkqDe7pev8rN4kT9nHjrxfSww3ih6TUJP6pLK0WOaf5AfCI/NnytB/m VA3QL/+2j/H3QNVwcYdL0ZU9kszJ3nhP+GOQ2osFJrwdU0PpsB1lweJcboEYlucVWoDT YyqhZmP9KmTX1+fDcI2pYAiq5QbVrVHwyL0ZE= MIME-Version: 1.0 Received: by 10.101.175.36 with SMTP id c36mr7155350anp.93.1311113332323; Tue, 19 Jul 2011 15:08:52 -0700 (PDT) Received: by 10.100.134.9 with HTTP; Tue, 19 Jul 2011 15:08:52 -0700 (PDT) In-Reply-To: <20110719204056.GC48176@shinkuro.com> References: <20110719204056.GC48176@shinkuro.com> Date: Tue, 19 Jul 2011 18:08:52 -0400 Message-ID: From: Phillip Hallam-Baker To: Andrew Sullivan Content-Type: multipart/alternative; boundary=001636c5be696ef7a504a8735cff Cc: dane@ietf.org Subject: Re: [dane] Fixing DANE to resolve properly with DNS X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 22:08:57 -0000 --001636c5be696ef7a504a8735cff Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jul 19, 2011 at 4:40 PM, Andrew Sullivan wrote: > On Tue, Jul 19, 2011 at 02:50:10PM -0400, Paul Wouters wrote: > > > > Or look for the AD bit on the localhost dnssec resolver. > > I will point out that the last time the AD bit came up in any DNSEXT > meeting, someone (Rob Austein?) got up at the mic and said something > along the lines of, "We have to get the message across that the AD bit > is for debugging." I'm aware that a large vendor based in Redmond > thinks otherwise. To the extent that said vendor has a consistent opinion on the matter I think you will find that it is coming from a group of people that includes at least one person who hasTuring award for his contributions to computer security theory. Now you can disagree with their conclusion but I don't think you can assume that it is based on ignorance. -- Website: http://hallambaker.com/ --001636c5be696ef7a504a8735cff Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Jul 19, 2011 at 4:40 PM, Andrew = Sullivan <aj= s@anvilwalrusden.com> wrote:
On Tue, Jul 19, 2011 at 02:50:10PM -0400, Paul Wouters wr= ote:
>
> Or look for the AD bit on the localhost dnssec resolver.

I will point out that the last time the AD bit came up in any DNSEXT<= br> meeting, someone (Rob Austein?) got up at the mic and said something
along the lines of, "We have to get the message across that the AD bit=
is for debugging." =A0I'm aware that a large vendor based in Redmo= nd
thinks otherwise.

To the extent that said v= endor has a consistent opinion on the matter I think you will find that it = is coming from a group of people that includes at least one person who hasT= uring award for his contributions to computer security theory.

Now you can disagree with their conclusion but I don= 9;t think you can assume that it is based on ignorance.
--001636c5be696ef7a504a8735cff-- From warren@kumari.net Tue Jul 19 15:14:12 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55F7D5E8011 for ; Tue, 19 Jul 2011 15:14:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XeJX87IlaAGt for ; Tue, 19 Jul 2011 15:14:12 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id E8B905E8008 for ; Tue, 19 Jul 2011 15:14:11 -0700 (PDT) Received: from [192.168.1.5] (unknown [216.226.38.2]) by vimes.kumari.net (Postfix) with ESMTPSA id 6F48C1B411A1; Tue, 19 Jul 2011 18:14:11 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Warren Kumari In-Reply-To: Date: Tue, 19 Jul 2011 18:14:35 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <50B98096-E152-4FA5-B638-95085A9303EA@kumari.net> References: <4E25D4CB.2040108@KingsMountain.com> To: Warren Kumari X-Mailer: Apple Mail (2.1084) Cc: IETF DANE WG list Subject: Re: [dane] Canceling the Quebec session X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 22:14:12 -0000 On Jul 19, 2011, at 3:13 PM, Warren Kumari wrote: >=20 > On Jul 19, 2011, at 3:02 PM, =3DJeffH wrote: >=20 >> Given PHB's & Paul Wouters' points (i count 14 open tickets out of 24 = total), and Jim Schaad's review of draft-ietf-dane-protocol-08, it'd = seem there's stuff to talk about f2f next week, yes? >=20 > Yes. >=20 > We will be meeting. We have an almost full agenda and will post it = shortly (want to confirm that we have the titles correct and confirming = that one of the speakers is still willing). And I've just published the draft agenda=85 W >=20 > W >=20 >>=20 >> =3DJeffH >> _______________________________________________ >> dane mailing list >> dane@ietf.org >> https://www.ietf.org/mailman/listinfo/dane >>=20 >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane >=20 From gnu@toad.com Tue Jul 19 17:06:43 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11DE021F8915 for ; Tue, 19 Jul 2011 17:06:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.097 X-Spam-Level: X-Spam-Status: No, score=0.097 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_NJABL_RELAY=2.696] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bp+rIx0AVhp8 for ; Tue, 19 Jul 2011 17:06:42 -0700 (PDT) Received: from new.toad.com (new.toad.com [209.237.225.253]) by ietfa.amsl.com (Postfix) with ESMTP id 7514E21F86BB for ; Tue, 19 Jul 2011 17:06:27 -0700 (PDT) Received: from new.toad.com (localhost.localdomain [127.0.0.1]) by new.toad.com (8.12.9/8.12.9) with ESMTP id p6K06LDn000304; Tue, 19 Jul 2011 17:06:21 -0700 Message-Id: <201107200006.p6K06LDn000304@new.toad.com> To: Phillip Hallam-Baker In-reply-to: References: <20110719204056.GC48176@shinkuro.com> Comments: In-reply-to Phillip Hallam-Baker message dated "Tue, 19 Jul 2011 18:08:52 -0400." Date: Tue, 19 Jul 2011 17:06:21 -0700 From: John Gilmore Cc: dane@ietf.org Subject: Re: [dane] Fixing DANE to resolve properly with DNS X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 00:06:43 -0000 > Or look for the AD bit on the localhost dnssec resolver. If Microsoft wants to ship insecure software, nobody can stop them; indeed nobody has been able to stop them for decades. That doesn't mean that the DANE group should be designing insecure protocols that can be subverted by toggling a single bit in an unsecured packet. And could we tone down the indirect "we won't really tell you who said this, but you can assume it comes from a giant corporation in a large northwestern state who has a cubicle next to a guy who got a Turing award" type of argument? If you have an argument, please state it directly. John From matt@mattmccutchen.net Tue Jul 19 17:15:48 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D58C121F8AE1 for ; Tue, 19 Jul 2011 17:15:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0oe4rDcka8EJ for ; Tue, 19 Jul 2011 17:15:44 -0700 (PDT) Received: from homiemail-a4.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id B8C3321F8ADC for ; Tue, 19 Jul 2011 17:15:44 -0700 (PDT) Received: from homiemail-a4.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a4.g.dreamhost.com (Postfix) with ESMTP id 6C24F51C069; Tue, 19 Jul 2011 17:15:44 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=vauZAKc6b3D7V94lgyI/Ki2X00YCzu6Zxy1LJy7Iuj+ tUpEeYgS9s3agTBLM3h95w5fUHJO2p8tS49Xz2SYCo5MeewI75MMLYbsIwJ1PpWD SsGUyc48Dc9XUcRxAXskY6PTswURlfYVcp7rdFlGx7nIoIbpBDuhV/MhT8ocXJBU = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=4ubuZpzfrqnjgclmHPkCuPh0U+Q=; b=oW9icdCdeo H4imXJnelcsVgKvXy1q1bzez+LS8Diwx6dafTvbt2WYnX8rkcERKttK1sPa2srH5 ipuUogYNOfUm5gFy50B0kC4J5NQbRMTqbxc/C8dTzVk3BC/Ib/27NB3S8qot/tXx FUoalQ/vau07/jd9uE4tfmf0MbVnAz3fE= Received: from [192.168.1.39] (pool-74-96-129-171.washdc.east.verizon.net [74.96.129.171]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a4.g.dreamhost.com (Postfix) with ESMTPSA id CE5F551C062; Tue, 19 Jul 2011 17:15:43 -0700 (PDT) From: Matt McCutchen To: John Gilmore In-Reply-To: <201107200006.p6K06LDn000304@new.toad.com> References: <20110719204056.GC48176@shinkuro.com> <201107200006.p6K06LDn000304@new.toad.com> Content-Type: text/plain; charset="UTF-8" Date: Tue, 19 Jul 2011 20:15:42 -0400 Message-ID: <1311120942.3300.40.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 Content-Transfer-Encoding: 7bit Cc: dane@ietf.org Subject: Re: [dane] Fixing DANE to resolve properly with DNS X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 00:15:48 -0000 On Tue, 2011-07-19 at 17:06 -0700, John Gilmore wrote: > > Or look for the AD bit on the localhost dnssec resolver. > > [...] That doesn't > mean that the DANE group should be designing insecure protocols that > can be subverted by toggling a single bit Specious argument. Think of S_IWOTH on /etc/passwd. > in an unsecured packet. Privileged ports on localhost are not subject to interception. I think deployers can make an appropriate decision as to whether they want to accept the claims of a localhost resolver. -- Matt From paul@xelerance.com Tue Jul 19 18:35:37 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEDE521F8553 for ; Tue, 19 Jul 2011 18:35:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.507 X-Spam-Level: X-Spam-Status: No, score=-6.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9737CA588Qu4 for ; Tue, 19 Jul 2011 18:35:37 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by ietfa.amsl.com (Postfix) with ESMTP id 6548221F854F for ; Tue, 19 Jul 2011 18:35:37 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 325CA570FB; Tue, 19 Jul 2011 21:36:09 -0400 (EDT) Date: Tue, 19 Jul 2011 21:36:08 -0400 (EDT) From: Paul Wouters To: Nicholas Weaver In-Reply-To: Message-ID: References: <20110719204056.GC48176@shinkuro.com> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dane@ietf.org Subject: Re: [dane] Fixing DANE to resolve properly with DNS X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 01:35:38 -0000 On Tue, 19 Jul 2011, Nicholas Weaver wrote: >> That is the same as saying "all apps have to link to a dnssec capable >> resolver" >> >> Which means, unless they somehow magically share a cache, every app will >> be generating queries to validate the entire path to the root. Everytime >> they start. >> >> That seems sub-optimal to me. > > And those get trapped by either the local system resolver cache or the ISP's cache... And if the system resolver is dnssec aware, why not trust the AD bit to localhost? An ISP cache is nice, but if it means 5 roundtrips over 3G, it still sucks to do that for every app on my phone. Paul From ogud@ogud.com Thu Jul 21 08:24:14 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1C4421F8A55 for ; Thu, 21 Jul 2011 08:24:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.53 X-Spam-Level: X-Spam-Status: No, score=-106.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QPwnFLBJNIEp for ; Thu, 21 Jul 2011 08:24:13 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id 4B97221F8A7B for ; Thu, 21 Jul 2011 08:24:13 -0700 (PDT) Received: from [IPv6:::1] (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p6LFO9c7025770 for ; Thu, 21 Jul 2011 11:24:09 -0400 (EDT) (envelope-from ogud@ogud.com) Message-ID: <4E284494.8000708@ogud.com> Date: Thu, 21 Jul 2011 11:24:04 -0400 From: Olafur Gudmundsson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: dane@ietf.org References: <20110719204056.GC48176@shinkuro.com> In-Reply-To: <20110719204056.GC48176@shinkuro.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Subject: Re: [dane] Fixing DANE to resolve properly with DNS X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2011 15:24:14 -0000 On 19/07/2011 4:40 PM, Andrew Sullivan wrote: > On Tue, Jul 19, 2011 at 02:50:10PM -0400, Paul Wouters wrote: >> >> Or look for the AD bit on the localhost dnssec resolver. > > I will point out that the last time the AD bit came up in any DNSEXT > meeting, someone (Rob Austein?) got up at the mic and said something > along the lines of, "We have to get the message across that the AD bit > is for debugging." I'm aware that a large vendor based in Redmond > thinks otherwise. > Strictly speaking what he said was "unprotected AD bit is for debugging only". Microsoft uses TSIG to protect the contents of the answer between their clients and servers. for historical background see RF3655 The most important paragraph is in section 3: A resolver MUST NOT blindly trust the AD bit unless it communicates with a recursive nameserver over a secure transport mechanism or using a message authentication such as TSIG [RFC2845] or SIG(0) [RFC2931] and is explicitly configured to trust this recursive name server. The secure transport mechanism covers 127.0.0.1 and IPSEC, ssh-tunnel .... (shameless plug) RFC3655 Section 4 is quite enlightening in the DANE context. Olafur From internet-drafts@ietf.org Mon Jul 25 12:59:19 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18C5021F8B97; Mon, 25 Jul 2011 12:59:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sJUbcW8IOdGa; Mon, 25 Jul 2011 12:59:18 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4D0E21F8B91; Mon, 25 Jul 2011 12:59:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.56 Message-ID: <20110725195918.23032.51904.idtracker@ietfa.amsl.com> Date: Mon, 25 Jul 2011 12:59:18 -0700 Cc: dane@ietf.org Subject: [dane] I-D Action: draft-ietf-dane-protocol-09.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 19:59:19 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the DNS-based Authentication of Named Ent= ities Working Group of the IETF. Title : Using Secure DNS to Associate Certificates with Domain N= ames For TLS Author(s) : Paul Hoffman Jakob Schlyter Filename : draft-ietf-dane-protocol-09.txt Pages : 16 Date : 2011-07-25 TLS and DTLS use PKIX certificates for authenticating the server. Users want their applications to verify that the certificate provided by the TLS server is in fact associated with the domain name they expect. TLSA provides bindings of keys to domains that are asserted not by external entities, but by the entities that operate the DNS. This document describes how to use secure DNS to associate the TLS server's certificate with the intended domain name. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dane-protocol-09.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-dane-protocol-09.txt From paul.hoffman@vpnc.org Mon Jul 25 13:05:26 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5974B21F8A4D for ; Mon, 25 Jul 2011 13:05:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aGs6SxUh7aXB for ; Mon, 25 Jul 2011 13:05:26 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 98F0321F8A4B for ; Mon, 25 Jul 2011 13:05:25 -0700 (PDT) Received: from dhcp-25eb.meeting.ietf.org ([130.129.37.235]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p6PK58v7060154 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 25 Jul 2011 13:05:09 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 25 Jul 2011 16:05:22 -0400 Message-Id: <922AB5D0-34A0-4D5A-9789-9A763B89919C@vpnc.org> To: DANE WG Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [dane] draft-ietf-dane-protocol-09.txt for CNAME and wildcards X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 20:05:26 -0000 Greetings again. Jakob and I have updated the draft to better described = the interaction of TLSA with CNAME and wildcards (see Appendix A). We = apologize for punting on this in the previous draft. Comments on the = additions are welcome. --Paul Hoffman From ekr@rtfm.com Tue Jul 26 04:03:45 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF30C21F8C42 for ; Tue, 26 Jul 2011 04:03:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JbFz2HnjATFG for ; Tue, 26 Jul 2011 04:03:45 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0F52021F8B27 for ; Tue, 26 Jul 2011 04:03:38 -0700 (PDT) Received: by wyj26 with SMTP id 26so88121wyj.31 for ; Tue, 26 Jul 2011 04:03:38 -0700 (PDT) Received: by 10.227.196.208 with SMTP id eh16mr4874941wbb.37.1311678218122; Tue, 26 Jul 2011 04:03:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.227.145.209 with HTTP; Tue, 26 Jul 2011 04:03:18 -0700 (PDT) In-Reply-To: <1E3D06D4-8068-41AA-AC51-408E5768E952@bbn.com> References: <008401cc4579$b91f7e30$2b5e7a90$@augustcellars.com> <20110718195711.GA32357@LK-Perkele-VI.localdomain> <1E3D06D4-8068-41AA-AC51-408E5768E952@bbn.com> From: Eric Rescorla Date: Tue, 26 Jul 2011 07:03:18 -0400 Message-ID: To: "Richard L. Barnes" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Paul Hoffman , dane@ietf.org Subject: Re: [dane] Review of draft-ietf-dane-protocol-08.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 11:03:45 -0000 I'm not sure why you say it doesn't normatively require it. The text is: When this message will be sent: The server MUST send a Certificate message whenever the agreed- upon key exchange method uses certificates for authentication (this includes all key exchange methods defined in this document except DH_anon). This message will always immediately follow the ServerHello message. Meaning of this message: This message conveys the server's certificate chain to the client. The certificate MUST be appropriate for the negotiated cipher suite's key exchange algorithm and any negotiated extensions. I don't see any scope for omitting it because of stuff that happens outside= of TLS. -Ekr On Mon, Jul 18, 2011 at 4:20 PM, Richard L. Barnes wrote: >>> 3. =A0The text in para 6 of section 4.4 is very out of date. =A0It does= not >>> discuss any certificate type except end-entity and states that if an >>> end-entity certificate is not found (i.e. you cannot do a trust anchor = only >>> DANE record) then the handshake aborts >> >> I think TLS requres an end-entity certificate (unless selected Ciphersui= te >> does not use certificates at all). > > RFC 5246 implies that this is the case, but does not normatively require = it. =A0See: > > > --Richard > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > From ekr@rtfm.com Tue Jul 26 04:04:58 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0B6621F8C44 for ; Tue, 26 Jul 2011 04:04:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nmQ5MFTWo2uE for ; Tue, 26 Jul 2011 04:04:58 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2419021F8C40 for ; Tue, 26 Jul 2011 04:04:57 -0700 (PDT) Received: by wwe5 with SMTP id 5so231403wwe.13 for ; Tue, 26 Jul 2011 04:04:57 -0700 (PDT) Received: by 10.227.196.208 with SMTP id eh16mr4876268wbb.37.1311678297106; Tue, 26 Jul 2011 04:04:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.227.145.209 with HTTP; Tue, 26 Jul 2011 04:04:37 -0700 (PDT) In-Reply-To: References: <008401cc4579$b91f7e30$2b5e7a90$@augustcellars.com> <20110718195711.GA32357@LK-Perkele-VI.localdomain> <1E3D06D4-8068-41AA-AC51-408E5768E952@bbn.com> From: Eric Rescorla Date: Tue, 26 Jul 2011 07:04:37 -0400 Message-ID: To: "Richard L. Barnes" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Paul Hoffman , dane@ietf.org Subject: Re: [dane] Review of draft-ietf-dane-protocol-08.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 11:04:59 -0000 Perhaps your point is that it doesn't require a cert that is formally a PKIX EE cert. I agree, TLS is quite vague on this point. What it requires is that there be a cert corresponding to the public key the server intends to use. -Ekr On Tue, Jul 26, 2011 at 7:03 AM, Eric Rescorla wrote: > I'm not sure why you say it doesn't normatively require it. The text is: > > =A0 When this message will be sent: > > =A0 =A0 =A0The server MUST send a Certificate message whenever the agreed= - > =A0 =A0 =A0upon key exchange method uses certificates for authentication > =A0 =A0 =A0(this includes all key exchange methods defined in this docume= nt > =A0 =A0 =A0except DH_anon). =A0This message will always immediately follo= w the > =A0 =A0 =A0ServerHello message. > > =A0 Meaning of this message: > > =A0 =A0 =A0This message conveys the server's certificate chain to the cli= ent. > > =A0 =A0 =A0The certificate MUST be appropriate for the negotiated cipher > =A0 =A0 =A0suite's key exchange algorithm and any negotiated extensions. > > I don't see any scope for omitting it because of stuff that happens outsi= de of > TLS. > > -Ekr > > > > On Mon, Jul 18, 2011 at 4:20 PM, Richard L. Barnes wrot= e: >>>> 3. =A0The text in para 6 of section 4.4 is very out of date. =A0It doe= s not >>>> discuss any certificate type except end-entity and states that if an >>>> end-entity certificate is not found (i.e. you cannot do a trust anchor= only >>>> DANE record) then the handshake aborts >>> >>> I think TLS requres an end-entity certificate (unless selected Ciphersu= ite >>> does not use certificates at all). >> >> RFC 5246 implies that this is the case, but does not normatively require= it. =A0See: >> >> >> --Richard >> _______________________________________________ >> dane mailing list >> dane@ietf.org >> https://www.ietf.org/mailman/listinfo/dane >> > From rbarnes@bbn.com Tue Jul 26 10:37:34 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 445E511E80EC for ; Tue, 26 Jul 2011 10:37:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.593 X-Spam-Level: X-Spam-Status: No, score=-106.593 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rRT+dbZZy-R3 for ; Tue, 26 Jul 2011 10:37:33 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 9C34B11E8073 for ; Tue, 26 Jul 2011 10:37:30 -0700 (PDT) Received: from [128.89.253.130] (port=62049 helo=[130.129.16.219]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QllZF-0003PU-VJ for dane@ietf.org; Tue, 26 Jul 2011 13:37:18 -0400 From: "Richard L. Barnes" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 26 Jul 2011 13:36:47 -0400 Message-Id: <11CDFEC7-1CDC-4FA1-AF89-3CFAED07D6EB@bbn.com> To: DANE WG Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [dane] Comments on draft-ietf-dane-protocol-09 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 17:37:34 -0000 Dear DANE, On the way up to Quebec, I gave the current DANE protocol spec a pretty = thorough read. My comments are below. --Richard 1.3.=20 Exclusion part should be removed. Probably want to link to PKIX/TLS/DNS terminology, as in draft-ietf-dane-use-cases. 4.=20 I would expect this section to be stronger, clearly defining the logic = that the client follow to determine the validity of the assertion. = Probably need more 2119 language to clearly specify behavior. 4.1., 4.2. In 4.1 and 4.2, the distinction is made between type ref type 0 and = nonzero. It would be more extensible to specify individually by ref type = -- or else just make it a hash type field. 4.1.=20 I'm concerned that only doing byte wise comparison could lead to = malformed certs being accepted. Suggest requiring that cert be well = formed, or at least noting that it must meet the requirements of TLS for = certs, e.g. KeyCertSign bit being set. 4.2. The use of the term "Trust Anchor" here is sloppy. What you really want = to say here is that a CA certificate matching the TLSA record MUST be in = the certification path. =20 4.3 I thought we had agreed not to do bare public keys? They are not in the = use cases doc. 4.4.=20 This section should be either a summary of previous sections, or the = only normative part. It might be useful to provide some pseudocode for the client = validation process. 4.4.=20 The discussion of SAN here seems to intrude on the application layer. = Maybe we want to say that TLSA can only be used when the expected = service identifier is a domain name? And even that should be said in = the context of RFC 6125. 5.=20 I disagree that this document addresses the cert lock and CA lock use = cases. Both of those entail normal PKIX validation, which both certTypes = in this document disable. Of course, the RP can always make the = decision, but it would be good to enable the domain owner to make a = recommendation -- suggest adding a flag for this.= From paul@xelerance.com Tue Jul 26 14:16:11 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68F4621F86AD for ; Tue, 26 Jul 2011 14:16:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.516 X-Spam-Level: X-Spam-Status: No, score=-6.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C-Dx6dMUxqKz for ; Tue, 26 Jul 2011 14:16:11 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by ietfa.amsl.com (Postfix) with ESMTP id C787B21F86AB for ; Tue, 26 Jul 2011 14:16:10 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 19BEEBE69; Tue, 26 Jul 2011 17:17:04 -0400 (EDT) Date: Tue, 26 Jul 2011 17:17:03 -0400 (EDT) From: Paul Wouters To: Eric Rescorla In-Reply-To: Message-ID: References: <008401cc4579$b91f7e30$2b5e7a90$@augustcellars.com> <20110718195711.GA32357@LK-Perkele-VI.localdomain> <1E3D06D4-8068-41AA-AC51-408E5768E952@bbn.com> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Paul Hoffman , dane@ietf.org Subject: Re: [dane] Review of draft-ietf-dane-protocol-08.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 21:16:11 -0000 On Tue, 26 Jul 2011, Eric Rescorla wrote: > Perhaps your point is that it doesn't require a cert that is formally > a PKIX EE cert. > > I agree, TLS is quite vague on this point. What it requires is that > there be a cert corresponding to the public key the server intends to use. And hopefully we can update that to be "the subjectPublicKeyInfo, optionally wrapped into a cert, that the server intends to use" :P Paul From paul@xelerance.com Tue Jul 26 15:10:15 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E73C321F877F for ; Tue, 26 Jul 2011 15:10:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.52 X-Spam-Level: X-Spam-Status: No, score=-6.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nuq4WiBDpvK4 for ; Tue, 26 Jul 2011 15:10:15 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by ietfa.amsl.com (Postfix) with ESMTP id 645DB21F8757 for ; Tue, 26 Jul 2011 15:09:46 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 54027BE69; Tue, 26 Jul 2011 18:10:30 -0400 (EDT) Date: Tue, 26 Jul 2011 18:10:30 -0400 (EDT) From: Paul Wouters To: "Richard L. Barnes" In-Reply-To: <11CDFEC7-1CDC-4FA1-AF89-3CFAED07D6EB@bbn.com> Message-ID: References: <11CDFEC7-1CDC-4FA1-AF89-3CFAED07D6EB@bbn.com> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: DANE WG Subject: Re: [dane] Comments on draft-ietf-dane-protocol-09 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 22:10:16 -0000 On Tue, 26 Jul 2011, Richard L. Barnes wrote: > 4. > I would expect this section to be stronger, clearly defining the logic that the client follow to determine the validity of the assertion. Probably need more 2119 language to clearly specify behavior. Perhaps move up section 4.4 to here would satisfy your concern? > 4.1., 4.2. > In 4.1 and 4.2, the distinction is made between type ref type 0 and nonzero. It would be more extensible to specify individually by ref type -- or else just make it a hash type field. I agree that the reference type could be called a hash type field. But then Section 4.2 should not be using it to change behaviour on the certificate bundle. I think if any behaviour of the certificate types needs further directions, it should be a new certificate type, and not a side effect of the reference type. Actually, I would probably rename "Certificate type" to "Reference type" and rename "reference type" to "hash type". This also more cleanly allows non-certificate type extensions. > 4.1. > I'm concerned that only doing byte wise comparison could lead to malformed certs being accepted. Suggest requiring that cert be well formed, or at least noting that it must meet the requirements of TLS for certs, e.g. KeyCertSign bit being set. You could say "the first valid certificate offered by the TLS server", but then you have to qualify "valid", especially that it might NOT mean [PKIX] validation. Arguably, if the TLS connection did not get a "proper" certificate to validate, there is no point in looking up or comparing the DNS record. How about: Once a validly formed certificate type 1 (a certificate that identifies an end entity) is received from the TLS server, it is matched [...] > 4.2. > The use of the term "Trust Anchor" here is sloppy. What you really want to say here is that a CA certificate matching the TLSA record MUST be in the certification path. The entire paragraph is very hard to read. It seems to list 3 use cases: 1) The TLSA record specifies the CA that signed the EE cert received in the certificate bundle from the TLS server 2) The TLSA record specifies a CA that should treated as Trust Anchor for the certificate bundle received from the TLS Server. 3) The TLSA record specifies a CA that should treated as Trust Anchor for any existing locally configured Trust Anchors, which should themselves lead to a validation path to the EE cert. The last option actually scares me. I could use it to determine which locally configured trust anchors your have. It could also be misused by putting (or forcing others to put) a very large encompassing CA cert in there. Think of a nation state mandating such a certificate.... The third case also mixes up local client policy. I don't think a TLSA record should tell a client exactly when to use its preconfigured trust anchors - the TLS client probably knows better (or has very specific instructions) on when to use its locally configured trust anchors and for what. I suggest removing case 3) and leave that to "local policy". Then writing up the first two cases become somewhat easier. > 4.3 > I thought we had agreed not to do bare public keys? They are not in the use cases doc. Technically, this is not doing bare public keys, but identification of a certificate based on a public key. Yes, it could also be used if/when we have a TLS extension that allows us to suppress sending a [PKIX] container with filler to be ignored. I don't think we need to make it harder for such future possible extension (disclaimer: I wrote a draft for such a TLS extension) > 5. > I disagree that this document addresses the cert lock and CA lock use cases. > Both of those entail normal PKIX validation, which both certTypes in this document disable. How does 4.1 not satisfy the "cert lock" use case? Is your concern that it not specificly states that the TLSA record should be override local client policy of preconfigured trust anchors? I think some people would object to such language. Similarly for 4.2 for the CA lock case. Perhaps we could state more clearly that a matching trust path based on the TLSA record is required to confirm the EE/CA certificate obtained from the TLS server before proceeding with any local client policy. Would that satisfy your "lock in" concerns? This could be explained in Section 4.1 > Of course, the RP can always make the decision, but it would be good to enable the domain owner to make a recommendation -- suggest adding a flag for this. I don't see how a flag would address anything. The TLSA record itself is already a claim by the domain owner on what they believe is a valid TLS public key/cert. A flag for "yes really" wouldn't add much to that. Paul From matt@mattmccutchen.net Tue Jul 26 21:50:51 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5854021F874A for ; Tue, 26 Jul 2011 21:50:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id viWcBNOLDzxF for ; Tue, 26 Jul 2011 21:50:50 -0700 (PDT) Received: from homiemail-a10.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id B635521F873D for ; Tue, 26 Jul 2011 21:50:50 -0700 (PDT) Received: from homiemail-a10.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a10.g.dreamhost.com (Postfix) with ESMTP id 2E89B280076; Tue, 26 Jul 2011 21:50:50 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=u9PRYqQkrs178RrhYyy4FbRCZCfFixqaBxFJJTtsZH5 VvuGg9zj1OWaGYKxhbPgOixi5imHnNuWEBy5kj9pQ7MfsjP5HPjuwQL0pDFwFxaY MzfOWxLqrHMsaQbZU9TGxZ/S0tI2qiuedXafzabC9+9us3NwvBkAdgNFdBFuk7bg = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=1R87JIx6WyMhoY0OgZoT82VLzQA=; b=oInLdHHmAX LKR3X4SSh6KjbNDC5NhTOkw85MLFF+y/UF302xH82jQeCFBm0FKs/rofBUgbBMjx mvRYVo4WIesnIB+Fr7LlIWsUbkxmJdbtVARdeQMwP6ef/m0BsQReQl4274ZSGWGd 8oz5JpISs5NOmHUEsQ3DMlGyHkqhl3RRs= Received: from [192.168.1.39] (pool-74-96-44-194.washdc.east.verizon.net [74.96.44.194]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a10.g.dreamhost.com (Postfix) with ESMTPSA id B0264280075; Tue, 26 Jul 2011 21:50:48 -0700 (PDT) From: Matt McCutchen To: Paul Wouters In-Reply-To: References: <11CDFEC7-1CDC-4FA1-AF89-3CFAED07D6EB@bbn.com> Content-Type: text/plain; charset="UTF-8" Date: Wed, 27 Jul 2011 00:50:47 -0400 Message-ID: <1311742247.7071.98.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 Content-Transfer-Encoding: 7bit Cc: DANE WG Subject: [dane] Purely restrictive statements X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 04:50:51 -0000 On Tue, 2011-07-26 at 18:10 -0400, Paul Wouters wrote: > > Of course, the RP can always make the decision, but it would be good to enable the domain owner to make a recommendation -- suggest adding a flag for this. > > I don't see how a flag would address anything. The TLSA record itself is already > a claim by the domain owner on what they believe is a valid TLS public key/cert. No, the domain owner may wish to make a purely restrictive statement. This is most important when an alternative CA (with cross certificates) can serve as a useful constraint but the domain owner does not want to be exposed to arbitrary certificates from it. Another possible use is to require a given intermediate or server certificate without waiving PKIX revocation checks. -- Matt From matt@mattmccutchen.net Tue Jul 26 21:54:57 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74B6821F8A7B for ; Tue, 26 Jul 2011 21:54:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EqKIIyxwSXC4 for ; Tue, 26 Jul 2011 21:54:56 -0700 (PDT) Received: from homiemail-a7.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id CECD821F8A7E for ; Tue, 26 Jul 2011 21:54:56 -0700 (PDT) Received: from homiemail-a7.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a7.g.dreamhost.com (Postfix) with ESMTP id 0E7BC25C064; Tue, 26 Jul 2011 21:54:56 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=ry0di7KGBPohKvqsqqzy+LYY5+q2CJ4puc7jITBpSJd GS4X7nNly6hc23UpJSN6y8r2Z4VFrcJkJuyD0aQmava9EMCvY3cf5itJZjssF6Wd Ry3H334muio6SR5Vky1kYJtI/h+mC5wG2vx60wG/lp73GC2Qrz1aDi+2r7YXOVL0 = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=4vY0gMG2h1QGVYpmmKhQQWSkRx4=; b=qMK7EOvC65 v57xTSbr5VcgQ09zRUPKX//LU0h36yOkQtI/aN1fvIT+VA+9yDOSW6axRwobGR0/ u2jHs6ctRPYXnA/HBL4ttcBkFT+jL+zxs5nQWBsfl6DzHBqGPdd/9wCEnA5pYOv4 QY8RRUrjY/oo6xGRSSb3A7nUJBak54lPw= Received: from [192.168.1.39] (pool-74-96-44-194.washdc.east.verizon.net [74.96.44.194]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a7.g.dreamhost.com (Postfix) with ESMTPSA id 987B425C062; Tue, 26 Jul 2011 21:54:55 -0700 (PDT) From: Matt McCutchen To: Jim Schaad In-Reply-To: <00a101cc458e$5f480610$1dd81230$@augustcellars.com> References: <008401cc4579$b91f7e30$2b5e7a90$@augustcellars.com> <20110718195711.GA32357@LK-Perkele-VI.localdomain> <00a101cc458e$5f480610$1dd81230$@augustcellars.com> Content-Type: text/plain; charset="UTF-8" Date: Wed, 27 Jul 2011 00:54:54 -0400 Message-ID: <1311742494.7071.101.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 Content-Transfer-Encoding: 7bit Cc: dane@ietf.org Subject: Re: [dane] Review of draft-ietf-dane-protocol-08.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 04:54:57 -0000 On Mon, 2011-07-18 at 14:05 -0700, Jim Schaad wrote: > > > 12. Section 4.4 - You say that type is a "trust anchor for that > > > domain name" I think that this is a bit squirrely for language as it > > > allows for a possible ambiguity with DNSSEC vs TLS. I would preferce > > > that that it is a "trust anchor for certificate chains for services in this domain > > name". > > > > Or actually, isn't it just one port in that domain name? > > That would depend on the domain name in question. If it was > example.com then no it is the entire domain (with possible > exceptions). If it is _443._tcp.example.com then it would be for a > specific port and protocol. The current draft does not provide for lookup of TLSA records at any owner name other than _port._transport.host . -- Matt From matt@mattmccutchen.net Tue Jul 26 23:03:18 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6494A11E8078 for ; Tue, 26 Jul 2011 23:03:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4eyPeNSR4o+c for ; Tue, 26 Jul 2011 23:03:17 -0700 (PDT) Received: from homiemail-a2.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id EAE4911E8072 for ; Tue, 26 Jul 2011 23:03:17 -0700 (PDT) Received: from homiemail-a2.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a2.g.dreamhost.com (Postfix) with ESMTP id 91D93280069; Tue, 26 Jul 2011 23:03:17 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=saHoFkV8OTX1A1CGRUjvekYu5AcExV2gH6IZFPkj49N +nP5ZVf35Vv+0488arjdclM4kTyttO0M0O4r1yomAjeNPmOiLujAWoLacxx6xlvJ fdpIy6LqQR4bGQSwZ7SJM/V0tiBBk0/7njh8TW2lALaHrkyG3nBYXqCATcL47wkI = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=vmtrjkBxweLnPMmtPxxTpmzpvJ8=; b=S7iCz1ys5d 6M1hVxl4LuQ2UtQP0uDKmwuXm99gf+OwAM3pRmDEjvDHzBpUTdsxlorroWns6qk+ LTTxeaeG39S/+/mQoauBoVxxnffjCn9vHhsBxRpoHlbwW0Zeor612VRlKVjSYJQd CLu6HBrBHoayjnXOJ7ORTawbp7zqBlvU8= Received: from [192.168.1.39] (pool-74-96-44-194.washdc.east.verizon.net [74.96.44.194]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a2.g.dreamhost.com (Postfix) with ESMTPSA id 266E2280061; Tue, 26 Jul 2011 23:03:17 -0700 (PDT) From: Matt McCutchen To: Warren Kumari In-Reply-To: <3F562A05-276C-4E5D-A807-0DA8873A40C8@kumari.net> References: <3F562A05-276C-4E5D-A807-0DA8873A40C8@kumari.net> Content-Type: text/plain; charset="UTF-8" Date: Wed, 27 Jul 2011 02:03:15 -0400 Message-ID: <1311746595.7071.122.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 Content-Transfer-Encoding: 7bit Cc: IETF DANE WG list Subject: Re: [dane] Closing issues that are no longer relevant... X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 06:03:18 -0000 On Tue, 2011-07-19 at 17:20 -0400, Warren Kumari wrote: > I'm going through the issue tracker and think that many of them can be > closed -- unless I hear strong objections by the end of week I'm > planning marking the following as closed: I am just coming back to this now, and I think the following issues have not in fact been addressed. I will comment on the individual issues: > Issue /#6: Downgrade -- Addressed by discussions on DNSSEC stripping, > and in Section 4.4. > Issue #22: Provide the security of the strongest digest supported by > both sides -- Discussions on list (decided that this should be left to > the relying party) > Issue #2: Relying parties policies -- Addressed by discussions / > changes in the Protocol doc. I don't fault you for aggressively closing issues and putting the onus on others to reopen them, but you could perhaps have given more thought to the resolutions; your proposed closure of the three below would probably have been better described as "wontfix". :) Also, IMO, a link should be mandatory to cite "discussions". In this kind of high-stakes standardization process, you can expect that at least one person will want to check your sources. -- Matt From matt@mattmccutchen.net Tue Jul 26 23:20:00 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68BE85E801D for ; Tue, 26 Jul 2011 23:20:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2A3k4lX1P8Lr for ; Tue, 26 Jul 2011 23:19:59 -0700 (PDT) Received: from homiemail-a37.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id C58515E8017 for ; Tue, 26 Jul 2011 23:19:59 -0700 (PDT) Received: from homiemail-a37.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a37.g.dreamhost.com (Postfix) with ESMTP id 8A1EA20806B for ; Tue, 26 Jul 2011 23:19:59 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=sKhADRQfOKzEEtTWXqmBfKCSqjKyA+D05GhdFSII3JM /BjmcfLPEnAFIuFZHwWlNmo/xIeX4tY12UJBxwd33wYwLD1T1hpQHb43NeFe0Gbl isujCxXZGbZp9ab1wfXK8oCfvSR8UGW8mOzGwuEBJB3AGVY+kBGscp2mgETeK3ik = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=0H4Fm3HLSsa8b1h6WCkggV1VQt4=; b=p4ZINcjF/W WiTpFjLxefq+Wd86uyYiKqKJBGTj8SbQRi0OuM0XDYlBI8Pz0T84ObgbVq62Sy0w uItrtyltRceBl783ZDwB7fdlOlImIxppEpNfoYcGA39UlNIHRJGIaoyaX7qq6rgA cE6M6IRW+J0SG89s30n91IOgWpirq5QLA= Received: from [192.168.1.39] (pool-74-96-44-194.washdc.east.verizon.net [74.96.44.194]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a37.g.dreamhost.com (Postfix) with ESMTPSA id CB986208063 for ; Tue, 26 Jul 2011 23:19:58 -0700 (PDT) From: Matt McCutchen To: DANE WG In-Reply-To: <1311742247.7071.98.camel@localhost> References: <11CDFEC7-1CDC-4FA1-AF89-3CFAED07D6EB@bbn.com> <1311742247.7071.98.camel@localhost> Content-Type: text/plain; charset="UTF-8" Date: Wed, 27 Jul 2011 02:19:56 -0400 Message-ID: <1311747597.7071.123.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 Content-Transfer-Encoding: 7bit Subject: Re: [dane] Purely restrictive statements X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 06:20:00 -0000 On Wed, 2011-07-27 at 00:50 -0400, Matt McCutchen wrote: > On Tue, 2011-07-26 at 18:10 -0400, Paul Wouters wrote: > > > Of course, the RP can always make the decision, but it would be good to enable the domain owner to make a recommendation -- suggest adding a flag for this. > > > > I don't see how a flag would address anything. The TLSA record itself is already > > a claim by the domain owner on what they believe is a valid TLS public key/cert. > > No, the domain owner may wish to make a purely restrictive statement. > This is most important when an alternative CA (with cross certificates) > can serve as a useful constraint but the domain owner does not want to > be exposed to arbitrary certificates from it. Another possible use is > to require a given intermediate or server certificate without waiving > PKIX revocation checks. -> https://trac.tools.ietf.org/wg/dane/trac/ticket/25 -- Matt From matt@mattmccutchen.net Tue Jul 26 23:22:31 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C8AE21F8696 for ; Tue, 26 Jul 2011 23:22:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fGZGWguNIMsL for ; Tue, 26 Jul 2011 23:22:30 -0700 (PDT) Received: from homiemail-a5.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id 830D821F8686 for ; Tue, 26 Jul 2011 23:22:30 -0700 (PDT) Received: from homiemail-a5.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a5.g.dreamhost.com (Postfix) with ESMTP id 570CF70406E; Tue, 26 Jul 2011 23:22:30 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=TNfBpXRCQnrIsYS4expkHqF0OU3dByHrPQAhazpOn+m WgpR5ZZvSzeIFP0tOaDjdCka+l3APobKdRZ2gzEDzChTtkJQlYomIFZZckQ5Nrnf BJyxenrtPd+QhX9Z0EV41fMot1yfd983YrUpJb4xvammDLInhwChsg78o/FfGTow = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=nvqo6Fpq0QpjqiGAAAik2WgZrYQ=; b=bSqa146mAW mJ04c9B9wPKZng4F9Hm0kac/jElbURvSuGfWvCu5cfcB4h3tbw+Yuf2xQUMJTSmo nJRN4besg5fXpr+K47P03obnF83AfhYzxramZe27S4WYXKP+5VkoFVY7acG0sZvl ufTIQyS5t2AqYydpOulvrRUPn8Q8M79OA= Received: from [192.168.1.39] (pool-74-96-44-194.washdc.east.verizon.net [74.96.44.194]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a5.g.dreamhost.com (Postfix) with ESMTPSA id E05AB70406A; Tue, 26 Jul 2011 23:22:29 -0700 (PDT) From: Matt McCutchen To: Jim Schaad In-Reply-To: <008401cc4579$b91f7e30$2b5e7a90$@augustcellars.com> References: <008401cc4579$b91f7e30$2b5e7a90$@augustcellars.com> Content-Type: text/plain; charset="UTF-8" Date: Wed, 27 Jul 2011 02:22:28 -0400 Message-ID: <1311747748.7071.125.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 Content-Transfer-Encoding: 7bit Cc: dane@ietf.org Subject: Re: [dane] Review of draft-ietf-dane-protocol-08.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 06:22:31 -0000 On Mon, 2011-07-18 at 11:37 -0700, Jim Schaad wrote: > 5. In section 5 - I have missed all of the text that discusses the > Combination point. I think that the message a while ago about the need for > a potentially new certificate type is going to be required to deal with > combinations. As such I do not believe that the current draft has any > useful discussion on combinations. If you meant this: https://www.ietf.org/mail-archive/web/dane/current/msg02637.html then see: https://trac.tools.ietf.org/wg/dane/trac/ticket/27 -- Matt From matt@mattmccutchen.net Tue Jul 26 23:36:34 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67F2511E8074 for ; Tue, 26 Jul 2011 23:36:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TJun0T4+mFnV for ; Tue, 26 Jul 2011 23:36:33 -0700 (PDT) Received: from homiemail-a3.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id C1D2C11E8072 for ; Tue, 26 Jul 2011 23:36:33 -0700 (PDT) Received: from homiemail-a3.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a3.g.dreamhost.com (Postfix) with ESMTP id 6C44A284078; Tue, 26 Jul 2011 23:36:33 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=WKy5v5VnGKutZjjKbllKT5IkSLEhDIBWbx+ndKjOhqr 1YLG5+G886kXs7ySCFDerQnLvtqG8u8kwXoDyXIfAhtiT4jKUX18f2FmCfjRtNeW sozVPQl2pIk1PP0WMrG0uOHZOsWaDFUWEhltwA27S8srfaTxGUqY/QlJHqN/Lx/E = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=vIYUAYHebO4i0KkREsXE80HTCTY=; b=kSy0FgtxGs bgJW/CfCiHnO0fjnVFEPUSregJPm1RcD+24IlXvIkCXd9MBksDeIcuM26nEcaFvY DRnlRYGpSIQwNt4/QrqiLaCXOqLUvb3LBv8+rpXZCJd3ImMx67QjFnlKFJ/pJi7w opsiukgjC4OICUxDRYcE13JG03H7eMHIU= Received: from [192.168.1.39] (pool-74-96-44-194.washdc.east.verizon.net [74.96.44.194]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a3.g.dreamhost.com (Postfix) with ESMTPSA id D7484284071; Tue, 26 Jul 2011 23:36:32 -0700 (PDT) From: Matt McCutchen To: Tony Finch In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Date: Wed, 27 Jul 2011 02:36:30 -0400 Message-ID: <1311748591.7071.130.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 Content-Transfer-Encoding: 7bit Cc: dane@ietf.org Subject: Re: [dane] Fixing DANE to resolve properly with DNS X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 06:36:34 -0000 On Tue, 2011-07-19 at 19:15 +0100, Tony Finch wrote: > Phillip Hallam-Baker wrote: > > > > One way to solve this is to note that any client is going to have to also > > look up the A record for the service. Thus if the A record lookup returns an > > alias, the client is required to retry the lookup for the canonical name. > > That would require a DANE client to use custom resolution code instead of > just using a generic lookup function. Indeed. We have a choice of requiring the client to peek under the covers of the DNS or introducing a new DANE-specific signaling mechanism on top of DNS. I would tend to prefer the former, but new arguments may come to light. libunbound has ub_result::canonname; I don't know about popular non-validating stub resolvers. -- Matt From matt@mattmccutchen.net Tue Jul 26 23:42:15 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA33E11E8074 for ; Tue, 26 Jul 2011 23:42:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qE68MH8yvL82 for ; Tue, 26 Jul 2011 23:42:15 -0700 (PDT) Received: from homiemail-a10.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id 253F811E8072 for ; Tue, 26 Jul 2011 23:42:15 -0700 (PDT) Received: from homiemail-a10.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a10.g.dreamhost.com (Postfix) with ESMTP id F173728006C; Tue, 26 Jul 2011 23:42:14 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=Dy3W6OVZ1ikeYPyRfCbLJ9AbRNVgfU2XooZDl8qVUAH 88QQDCZp9Y1BLr+oI2dGENZm++Q0JkSwQYE1mUxRmGBAVLQpnxKAyuSnQmeHuOZv dFXQuRLG9RrMWF33Dw3AVqeAwOtGyGttUDI6FZqp7DUQmNVuK79bP7l7sx+Pesb0 = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=uP10SboerITKGfpeBfahNiU3Xtg=; b=ej0NWNFdgf zhx4N2O2nWgE2G5fRFnapCLA0yUB+yeY4cfnPokgJsbmYdq8cAsEykjL9o3I50L8 kgf4x7DHQcpIuyTdNlS3wB6A3bsiIi6NEKeNWzC7IbxNaLGqXPpkq68t8sboMv9q ZJik8v52UjUuTS3lBTRGWuvX7a1v7rEoE= Received: from [192.168.1.39] (pool-74-96-44-194.washdc.east.verizon.net [74.96.44.194]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a10.g.dreamhost.com (Postfix) with ESMTPSA id 8887E280065; Tue, 26 Jul 2011 23:42:14 -0700 (PDT) From: Matt McCutchen To: Paul Hoffman In-Reply-To: <922AB5D0-34A0-4D5A-9789-9A763B89919C@vpnc.org> References: <922AB5D0-34A0-4D5A-9789-9A763B89919C@vpnc.org> Content-Type: text/plain; charset="UTF-8" Date: Wed, 27 Jul 2011 02:42:12 -0400 Message-ID: <1311748932.7071.135.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 Content-Transfer-Encoding: 7bit Cc: DANE WG Subject: Re: [dane] draft-ietf-dane-protocol-09.txt for CNAME and wildcards X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 06:42:15 -0000 On Mon, 2011-07-25 at 16:05 -0400, Paul Hoffman wrote: > Greetings again. Jakob and I have updated the draft to better > described the interaction of TLSA with CNAME and wildcards (see > Appendix A). We apologize for punting on this in the previous draft. > Comments on the additions are welcome. All you have done is describe what is currently possible by redirecting or wildcarding TLSA RRsets based on the semantics of DNS. The request was to modify DANE to work with current deployments that use redirection and wildcarding of hosts. See https://trac.tools.ietf.org/wg/dane/trac/ticket/24 for a pretty comprehensive statement of the problem. -- Matt From ietf@augustcellars.com Wed Jul 27 06:04:17 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0376121F8B29 for ; Wed, 27 Jul 2011 06:04:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.134 X-Spam-Level: X-Spam-Status: No, score=-3.134 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E04OzoYJKAUb for ; Wed, 27 Jul 2011 06:04:16 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id 8C34121F8B27 for ; Wed, 27 Jul 2011 06:04:16 -0700 (PDT) Received: from TITUS (dhcp-10a6.meeting.ietf.org [130.129.16.166]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id DC9D738F07; Wed, 27 Jul 2011 06:04:15 -0700 (PDT) From: "Jim Schaad" To: "'Matt McCutchen'" References: <008401cc4579$b91f7e30$2b5e7a90$@augustcellars.com> <20110718195711.GA32357@LK-Perkele-VI.localdomain> <00a101cc458e$5f480610$1dd81230$@augustcellars.com> <1311742494.7071.101.camel@localhost> In-Reply-To: <1311742494.7071.101.camel@localhost> Date: Wed, 27 Jul 2011 09:03:15 -0400 Message-ID: <00a201cc4c5d$8d5b4460$a811cd20$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJOFWqSNY3v5v+I3x66poTmatTjUgGJLujLAgHPIp0BLPmKtJPWz9bw Content-Language: en-us Cc: dane@ietf.org Subject: Re: [dane] Review of draft-ietf-dane-protocol-08.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 13:04:17 -0000 > -----Original Message----- > From: Matt McCutchen [mailto:matt@mattmccutchen.net] > Sent: Wednesday, July 27, 2011 12:55 AM > To: Jim Schaad > Cc: dane@ietf.org > Subject: Re: [dane] Review of draft-ietf-dane-protocol-08.txt >=20 > On Mon, 2011-07-18 at 14:05 -0700, Jim Schaad wrote: > > > > 12. Section 4.4 - You say that type is a "trust anchor for that > > > > domain name" I think that this is a bit squirrely for language = as > > > > it allows for a possible ambiguity with DNSSEC vs TLS. I would > > > > preferce that that it is a "trust anchor for certificate chains > > > > for services in this domain > > > name". > > > > > > Or actually, isn't it just one port in that domain name? > > > > That would depend on the domain name in question. If it was > > example.com then no it is the entire domain (with possible > > exceptions). If it is _443._tcp.example.com then it would be for a > > specific port and protocol. >=20 > The current draft does not provide for lookup of TLSA records at any = owner > name other than _port._transport.host . But you could find the records at any of the DNS names starting at that = point and striping off the left most token until you actually find the = TLSA records. However I don't believe that this changes my statement = that I am not happy with the language in question. Jim >=20 > -- > Matt From matt@mattmccutchen.net Wed Jul 27 10:34:26 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8FE121F86C3 for ; Wed, 27 Jul 2011 10:34:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jSQSJcZsbwcX for ; Wed, 27 Jul 2011 10:34:25 -0700 (PDT) Received: from homiemail-a4.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id CE5B811E80DF for ; Wed, 27 Jul 2011 10:34:25 -0700 (PDT) Received: from homiemail-a4.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a4.g.dreamhost.com (Postfix) with ESMTP id 8AE9251C07B; Wed, 27 Jul 2011 10:34:25 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=bJEm8vjW5AJmvRuWcDu5tiZbqmU3PABZUw1d3Wf6nZ3 XWfCttkm4WACHAuy0G0wG4OqGpMe2QbWBbUue0sPHS7bRvUf+GxvzZAFrqaQ3d+V rFqJQpuCw8h0+V0y4XXm5uJVhwMFQsqL/jt1qYW46h0ltIWcR5Hx4Kcnv/4Jpo10 = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=Ao/gUvZnxi+Zpxh1vx962sqfahk=; b=Q6n8An2ZWq rL+h9WseUzWRjCTZTAZZspKwXGuMEwMsI7tGJ9u+NvMGE5eaTyOCd59CIhwtgM17 8NTBVykSLzGNv/uONB/AQiyIZzSewa6EiPKB2GoOL0W4Spb6pjhb/K9QyUcCuhOH TGtW1lRa28S12AvA3FwGufXD7dEBF4aN0= Received: from [10.5.0.146] (unknown [192.80.55.242]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a4.g.dreamhost.com (Postfix) with ESMTPSA id 261D651C074; Wed, 27 Jul 2011 10:34:24 -0700 (PDT) From: Matt McCutchen To: Jim Schaad In-Reply-To: <00a201cc4c5d$8d5b4460$a811cd20$@augustcellars.com> References: <008401cc4579$b91f7e30$2b5e7a90$@augustcellars.com> <20110718195711.GA32357@LK-Perkele-VI.localdomain> <00a101cc458e$5f480610$1dd81230$@augustcellars.com> <1311742494.7071.101.camel@localhost> <00a201cc4c5d$8d5b4460$a811cd20$@augustcellars.com> Content-Type: text/plain; charset="UTF-8" Date: Wed, 27 Jul 2011 13:34:23 -0400 Message-ID: <1311788063.2084.15.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 Content-Transfer-Encoding: 7bit Cc: dane@ietf.org Subject: Re: [dane] Review of draft-ietf-dane-protocol-08.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 17:34:27 -0000 On Wed, 2011-07-27 at 09:03 -0400, Jim Schaad wrote: > > On Mon, 2011-07-18 at 14:05 -0700, Jim Schaad wrote: > > > > > 12. Section 4.4 - You say that type is a "trust anchor for that > > > > > domain name" I think that this is a bit squirrely for language as > > > > > it allows for a possible ambiguity with DNSSEC vs TLS. I would > > > > > preferce that that it is a "trust anchor for certificate chains > > > > > for services in this domain > > > > name". > > > > > > > > Or actually, isn't it just one port in that domain name? > > > > > > That would depend on the domain name in question. If it was > > > example.com then no it is the entire domain (with possible > > > exceptions). If it is _443._tcp.example.com then it would be for a > > > specific port and protocol. > > > > The current draft does not provide for lookup of TLSA records at any owner > > name other than _port._transport.host . > > But you could find the records at any of the DNS names starting at > that point and striping off the left most token until you actually > find the TLSA records. The draft does not provide for any such behavior, except inasmuch as it happens automatically via DNS wildcard expansion. And I do not see a need to state the effect of DNS wildcard expansion specifically rather than just let it generate individual virtual RRsets that apply to all possible transports and ports at the host. > However I don't believe that this changes my statement that I am not > happy with the language in question. Agreed. -- Matt From paul@xelerance.com Wed Jul 27 11:36:05 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A0B821F8B22 for ; Wed, 27 Jul 2011 11:36:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.523 X-Spam-Level: X-Spam-Status: No, score=-6.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LWaK1vb2heHK for ; Wed, 27 Jul 2011 11:36:04 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by ietfa.amsl.com (Postfix) with ESMTP id 8926E21F8B09 for ; Wed, 27 Jul 2011 11:36:04 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 0B1A857124; Wed, 27 Jul 2011 14:37:00 -0400 (EDT) Date: Wed, 27 Jul 2011 14:36:59 -0400 (EDT) From: Paul Wouters To: Matt McCutchen In-Reply-To: <1311747597.7071.123.camel@localhost> Message-ID: References: <11CDFEC7-1CDC-4FA1-AF89-3CFAED07D6EB@bbn.com> <1311742247.7071.98.camel@localhost> <1311747597.7071.123.camel@localhost> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: DANE WG Subject: Re: [dane] Purely restrictive statements X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 18:36:05 -0000 On Wed, 27 Jul 2011, Matt McCutchen wrote: >>> I don't see how a flag would address anything. The TLSA record itself is already >>> a claim by the domain owner on what they believe is a valid TLS public key/cert. >> >> No, the domain owner may wish to make a purely restrictive statement. >> This is most important when an alternative CA (with cross certificates) >> can serve as a useful constraint but the domain owner does not want to >> be exposed to arbitrary certificates from it. Another possible use is >> to require a given intermediate or server certificate without waiving >> PKIX revocation checks. > > -> https://trac.tools.ietf.org/wg/dane/trac/ticket/25 Isn't this already covered? If they want it restrictive, they put in the EE cert. If they want it restrictive & traditional, they put in the CA cert that's in the CA bundle received from the TLS server. If they want it traditional, they don't put in a TLSA record at all. the "additive" case is really a case of local policy and not for the TLS server to dictate. Paul From internet-drafts@ietf.org Thu Jul 28 06:40:42 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBB6021F87C7; Thu, 28 Jul 2011 06:40:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.574 X-Spam-Level: X-Spam-Status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DcJCee7-Etdy; Thu, 28 Jul 2011 06:40:42 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73F1B21F87C3; Thu, 28 Jul 2011 06:40:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.56 Message-ID: <20110728134042.12658.39629.idtracker@ietfa.amsl.com> Date: Thu, 28 Jul 2011 06:40:42 -0700 Cc: dane@ietf.org Subject: [dane] I-D Action: draft-ietf-dane-use-cases-05.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 13:40:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the DNS-based Authentication of Named Ent= ities Working Group of the IETF. Title : Use Cases and Requirements for DNS-based Authentication = of Named Entities (DANE) Author(s) : Richard Barnes Filename : draft-ietf-dane-use-cases-05.txt Pages : 12 Date : 2011-07-28 Many current applications use the certificate-based authentication features in TLS to allow clients to verify that a connected server properly represents a desired domain name. Typically, this authentication has been based on PKIX certificate chains rooted in well-known CAs, but additional information can be provided via the DNS itself. This document describes a set of use cases in which the DNS and DNSSEC could be used to make assertions that support the TLS authentication process. The main focus of this document is TLS server authentication, but it also covers TLS client authentication for applications where TLS clients are identified by domain names. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dane-use-cases-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-dane-use-cases-05.txt From rbarnes@bbn.com Thu Jul 28 12:35:26 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CD7E5E8030 for ; Thu, 28 Jul 2011 12:35:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.594 X-Spam-Level: X-Spam-Status: No, score=-106.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f-3kyZRvt4XH for ; Thu, 28 Jul 2011 12:35:25 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id C95E05E802E for ; Thu, 28 Jul 2011 12:35:25 -0700 (PDT) Received: from [128.89.253.184] (port=56098 helo=dhcp-10db.meeting.ietf.org) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QmWMf-000ONm-Em for dane@ietf.org; Thu, 28 Jul 2011 15:35:25 -0400 From: "Richard L. Barnes" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 28 Jul 2011 15:35:24 -0400 Message-Id: <2703F451-ABDB-4160-8ABC-87A906ED1479@bbn.com> To: DANE WG Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [dane] Jabber? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 19:35:26 -0000 I have a DANE chair question. Either of you on jabber? From rbarnes@bbn.com Thu Jul 28 12:35:56 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6148D5E8031 for ; Thu, 28 Jul 2011 12:35:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.594 X-Spam-Level: X-Spam-Status: No, score=-106.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ZwDjbp-aaOR for ; Thu, 28 Jul 2011 12:35:56 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 06CAE5E8030 for ; Thu, 28 Jul 2011 12:35:56 -0700 (PDT) Received: from [128.89.253.184] (port=56098 helo=dhcp-10db.meeting.ietf.org) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QmWN9-000ONm-CB for dane@ietf.org; Thu, 28 Jul 2011 15:35:55 -0400 From: Richard L. Barnes Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 28 Jul 2011 15:35:55 -0400 References: <2703F451-ABDB-4160-8ABC-87A906ED1479@bbn.com> To: DANE WG Message-Id: <8BA8B5C6-E62D-4690-8CEB-DA682AAC36E3@bbn.com> Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [dane] Fwd: Jabber? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 19:35:56 -0000 Sorry, meant to send only to the chairs. Please ignore. --Richard Begin forwarded message: > From: "Richard L. Barnes" > Date: July 28, 2011 3:35:24 PM EDT > To: DANE WG > Subject: Jabber? > > I have a DANE chair question. Either of you on jabber? From rbarnes@bbn.com Fri Jul 29 11:10:39 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89D5921F86A8 for ; Fri, 29 Jul 2011 11:10:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.595 X-Spam-Level: X-Spam-Status: No, score=-106.595 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DZMVoC9vG4cF for ; Fri, 29 Jul 2011 11:10:38 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 70C6E21F8640 for ; Fri, 29 Jul 2011 11:10:38 -0700 (PDT) Received: from [128.89.253.33] (port=62583 helo=dhcp-10db.meeting.ietf.org) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QmrW9-000IbN-Hu for dane@ietf.org; Fri, 29 Jul 2011 14:10:37 -0400 From: "Richard L. Barnes" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 29 Jul 2011 14:10:37 -0400 Message-Id: To: DANE WG Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [dane] Comments on -proto, Appendix 1 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2011 18:10:39 -0000 Overall, I think this text is really good. The one thing I would like = to see is a little more discussion of the operational meaning of the = three example cases. For example: 1. Both the service and TLSA records are delegated to the CNAME target, = allowing the operator of the target to choose the service delivery point = and the certificate constraints/assertions. 2. Only the service record is delegated to the CNAME target. The origin = domain holder retains control of TLSA records, enabling him to place = constraints on the certificates used by the target operator. The target = operator also provides TLSA information that may be used by the target = itself (directly) or by other origin domains delegated to the target = domain. 3. Only the service record is delegated to the CNAME target. The origin = domain holder retains control of TLSA records, enabling him to place = constraints on the certificates used by the target operator.= From hallam@gmail.com Sat Jul 30 21:30:33 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1471821F86EC for ; Sat, 30 Jul 2011 21:30:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.466 X-Spam-Level: X-Spam-Status: No, score=-3.466 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id slzhax3bfjRu for ; Sat, 30 Jul 2011 21:30:32 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 47AB521F86EA for ; Sat, 30 Jul 2011 21:30:29 -0700 (PDT) Received: by gwb20 with SMTP id 20so3818069gwb.31 for ; Sat, 30 Jul 2011 21:30:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=qLFrR5/1zKm3vH8GUOyB1ryQb2j2MEq8cpvhTHG8114=; b=u2dal6T4vTRCpcPYJ4BHr0KxYhjtVBItBQIsNb3Pla2pfVjprR+mMfciWDCbc0EH8F jDEv41ZgiqMJ0pMWuTMHSue3DscyO+do3L3Fmjn3dE3oR3lfK3DdyrsyhF9p5co1+hAn EN+mNYgGBBvYi8gpmjWmRHhNo7L3uxT0I/v8w= MIME-Version: 1.0 Received: by 10.101.178.21 with SMTP id f21mr2324951anp.138.1312086631252; Sat, 30 Jul 2011 21:30:31 -0700 (PDT) Received: by 10.100.34.3 with HTTP; Sat, 30 Jul 2011 21:30:31 -0700 (PDT) Date: Sun, 31 Jul 2011 00:30:31 -0400 Message-ID: From: Phillip Hallam-Baker To: dane@ietf.org Content-Type: multipart/alternative; boundary=005045017caa9202ab04a955f9fb Subject: [dane] CNAMES and Wildcards X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jul 2011 04:30:33 -0000 --005045017caa9202ab04a955f9fb Content-Type: text/plain; charset=ISO-8859-1 Following the discussion in the WG meeting, my position is this: * DANE can go forward to WGLC without the wildcard and alias issues being fully addressed but it should not become a standards track RFC until they are fully addressed. There are two routes forward:' 1) Fix the problems in the DANE WG using the approach proposed. 2) Propose the fix to DNSEXT and wait for it to be progressed there. I do not see any reason to make progress in DANE dependent on DNSEXT. DANE is fully competent to make proposals with respect to the handling of the TLSA record in my view. Clearly a proposal to adopt this approach as a general approach to other prefixed RRs is something that DNSEXT should consider, but that is not relevant to DANE. Since DANE requires the client to be able to process DNSSEC RR chains, the ability to acquire and process CNAME records is already present in the spec. -- Website: http://hallambaker.com/ --005045017caa9202ab04a955f9fb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Following the discussion in the WG meeting, my position is this:

* DANE can go forward to WGLC without the wildcard and alias issue= s being fully addressed but it should not become a standards track RFC unti= l they are fully addressed.

There are two routes forward:'

=
1) Fix the problems in the DANE WG using the approach proposed.
<= div>2) Propose the fix to DNSEXT and wait for it to be progressed there.

I do not see any reason to make progress in DANE depend= ent on DNSEXT. DANE is fully competent to make proposals with respect to th= e handling of the TLSA record in my view. Clearly a proposal to adopt this = approach as a general approach to other prefixed RRs is something that DNSE= XT should consider, but that is =A0not relevant to DANE.


Since DANE requires the client to be abl= e to process DNSSEC RR chains, the ability to acquire and process CNAME rec= ords is already present in the spec.

--005045017caa9202ab04a955f9fb-- From paul.hoffman@vpnc.org Sun Jul 31 07:51:08 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2247921F8753 for ; Sun, 31 Jul 2011 07:51:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.621 X-Spam-Level: X-Spam-Status: No, score=-102.621 tagged_above=-999 required=5 tests=[AWL=-0.022, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b2PrDCfKouyw for ; Sun, 31 Jul 2011 07:51:07 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 59C6321F8749 for ; Sun, 31 Jul 2011 07:51:07 -0700 (PDT) Received: from [10.20.30.104] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p6VEonMI085947 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 31 Jul 2011 07:50:50 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Sun, 31 Jul 2011 07:51:06 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4B7B160E-B835-44E3-A5A8-8DC50E3498FD@vpnc.org> References: To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1084) Cc: dane@ietf.org Subject: Re: [dane] CNAMES and Wildcards X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jul 2011 14:51:08 -0000 On Jul 30, 2011, at 9:30 PM, Phillip Hallam-Baker wrote: > Following the discussion in the WG meeting, my position is this: >=20 > * DANE can go forward to WGLC without the wildcard and alias issues = being fully addressed but it should not become a standards track RFC = until they are fully addressed. Can you be more specific about what you mean by "fully addressed"? Jakob = and I did a pass at that in the current document, showing how DANE works = with CNAMEs, DNAMEs, and wildcards, but are quite open to the WG telling = us to change it or add more. (We have queued some minor changes for the = next draft for typos in the appendix.) > There are two routes forward:' >=20 > 1) Fix the problems in the DANE WG using the approach proposed. > 2) Propose the fix to DNSEXT and wait for it to be progressed there. >=20 > I do not see any reason to make progress in DANE dependent on DNSEXT. = DANE is fully competent to make proposals with respect to the handling = of the TLSA record in my view. Clearly a proposal to adopt this approach = as a general approach to other prefixed RRs is something that DNSEXT = should consider, but that is not relevant to DANE. This disagrees with what you say above about "should not become a = standards track RFC". There are many standards-track RFCs that deal with = CNAMEs and wildcards just like DANE does, except without the additional = explanation we have added. > Since DANE requires the client to be able to process DNSSEC RR chains, = the ability to acquire and process CNAME records is already present in = the spec. Quite right. --Paul Hoffman From hallam@gmail.com Sun Jul 31 08:23:29 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD01621F86BF for ; Sun, 31 Jul 2011 08:23:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.517 X-Spam-Level: X-Spam-Status: No, score=-3.517 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i5l3LezY+eXX for ; Sun, 31 Jul 2011 08:23:29 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id C82CD21F86C7 for ; Sun, 31 Jul 2011 08:23:28 -0700 (PDT) Received: by gxk19 with SMTP id 19so3758421gxk.31 for ; Sun, 31 Jul 2011 08:23:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=da4o4+hbZUfXbxXsSePpn0bCpNg6dSY1/N1eaat8pHY=; b=DkZYp5S8Qkb96IpX7annUhzQ4HAHOmPJpoSJpKek0xdJ5KDI4cwnPlcjAqAlGI+E15 ihRSAPy1XzxDPKnygRa3yISFA9tNP3f2lE5uA+m6SZTFVZ3bCX9bp2E1oxgecUndFS3M 8QHCkn+xuKTbELfHZngCxFBWgY4LOas/zAV78= MIME-Version: 1.0 Received: by 10.101.164.25 with SMTP id r25mr2479482ano.94.1312125811417; Sun, 31 Jul 2011 08:23:31 -0700 (PDT) Received: by 10.100.34.3 with HTTP; Sun, 31 Jul 2011 08:23:31 -0700 (PDT) In-Reply-To: <4B7B160E-B835-44E3-A5A8-8DC50E3498FD@vpnc.org> References: <4B7B160E-B835-44E3-A5A8-8DC50E3498FD@vpnc.org> Date: Sun, 31 Jul 2011 11:23:31 -0400 Message-ID: From: Phillip Hallam-Baker To: Paul Hoffman Content-Type: multipart/alternative; boundary=0016e6d26d72e3e0e604a95f1836 Cc: dane@ietf.org Subject: Re: [dane] CNAMES and Wildcards X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jul 2011 15:23:29 -0000 --0016e6d26d72e3e0e604a95f1836 Content-Type: text/plain; charset=ISO-8859-1 On Sun, Jul 31, 2011 at 10:51 AM, Paul Hoffman wrote: > On Jul 30, 2011, at 9:30 PM, Phillip Hallam-Baker wrote: > > > Following the discussion in the WG meeting, my position is this: > > > > * DANE can go forward to WGLC without the wildcard and alias issues being > fully addressed but it should not become a standards track RFC until they > are fully addressed. > > Can you be more specific about what you mean by "fully addressed"? Jakob > and I did a pass at that in the current document, showing how DANE works > with CNAMEs, DNAMEs, and wildcards, but are quite open to the WG telling us > to change it or add more. (We have queued some minor changes for the next > draft for typos in the appendix.) By fully addressed I mean that there is a defined algorithm for resolving DANE DNS RRs that is compatible with administrative use cases for use of Wildcare and alias (CNAME, DNAME) records. The current appendix suggests options but does not mandate a particular behavior. Thus DNS administrators deploying DANE cannot rely on these records actually working. > > There are two routes forward:' > > > > 1) Fix the problems in the DANE WG using the approach proposed. > > 2) Propose the fix to DNSEXT and wait for it to be progressed there. > > > > I do not see any reason to make progress in DANE dependent on DNSEXT. > DANE is fully competent to make proposals with respect to the handling of > the TLSA record in my view. Clearly a proposal to adopt this approach as a > general approach to other prefixed RRs is something that DNSEXT should > consider, but that is not relevant to DANE. > > This disagrees with what you say above about "should not become a standards > track RFC". There are many standards-track RFCs that deal with CNAMEs and > wildcards just like DANE does, except without the additional explanation we > have added. That is not relevant for the following reasons: 1) It is the deployment experience from use of those prefix records that motivated the work to define this mechanism. 2) At the time there was no proposed solution that would enable correct handling of the RRs. 3) The only prior proposal that involved restrictive trust statements in the DNS is the DKIM policy mechanism. -- Website: http://hallambaker.com/ --0016e6d26d72e3e0e604a95f1836 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Sun, Jul 31, 2011 at 10:51 AM, Paul H= offman <paul.= hoffman@vpnc.org> wrote:
On Jul 30, 2011, at 9:30 PM, Phillip Hallam-Baker wrote:<= br>
> Following the discussion in the WG meeting, my position is this:
>
> * DANE can go forward to WGLC without the wildcard and alias issues be= ing fully addressed but it should not become a standards track RFC until th= ey are fully addressed.

Can you be more specific about what you mean by "fully addressed= "? Jakob and I did a pass at that in the current document, showing how= DANE works with CNAMEs, DNAMEs, and wildcards, but are quite open to the W= G telling us to change it or add more. (We have queued some minor changes f= or the next draft for typos in the appendix.)

By fully addressed I mean that there is a defined algor= ithm for resolving DANE DNS RRs that is compatible with administrative use = cases for use of Wildcare and alias (CNAME, DNAME) records.

The current appendix suggests options but does not mandate a par= ticular behavior. Thus DNS administrators deploying DANE cannot rely on the= se records actually working.


=A0
> There are two routes forward:'
>
> 1) Fix the problems in the DANE WG using the approach proposed.
> 2) Propose the fix to DNSEXT and wait for it to be progressed there. >
> I do not see any reason to make progress in DANE dependent on DNSEXT. = DANE is fully competent to make proposals with respect to the handling of t= he TLSA record in my view. Clearly a proposal to adopt this approach as a g= eneral approach to other prefixed RRs is something that DNSEXT should consi= der, but that is =A0not relevant to DANE.

This disagrees with what you say above about "should not become = a standards track RFC". There are many standards-track RFCs that deal = with CNAMEs and wildcards just like DANE does, except without the additiona= l explanation we have added.

That is not relevant for the following reasons:

1) It is the deployment experience from use of those pref= ix records that motivated the work to define this mechanism.=A0

2) At the time there was no proposed solution that would ena= ble correct handling of the RRs.

3) The only prior= proposal that involved restrictive trust statements in the DNS is the DKIM= policy mechanism.=A0
=A0
--
Website: htt= p://hallambaker.com/

--0016e6d26d72e3e0e604a95f1836-- From paul.hoffman@vpnc.org Sun Jul 31 08:44:13 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A11EC21F86C4 for ; Sun, 31 Jul 2011 08:44:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.621 X-Spam-Level: X-Spam-Status: No, score=-102.621 tagged_above=-999 required=5 tests=[AWL=-0.022, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id axwx43RRGChV for ; Sun, 31 Jul 2011 08:44:13 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id F2CC521F86CA for ; Sun, 31 Jul 2011 08:44:12 -0700 (PDT) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p6VFhtii087584 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 31 Jul 2011 08:43:56 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Sun, 31 Jul 2011 08:44:13 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0E22E3A1-5D7B-42F0-AADC-96935CFD4BD2@vpnc.org> References: <4B7B160E-B835-44E3-A5A8-8DC50E3498FD@vpnc.org> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1084) Cc: dane@ietf.org Subject: Re: [dane] CNAMES and Wildcards X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jul 2011 15:44:13 -0000 On Jul 31, 2011, at 8:23 AM, Phillip Hallam-Baker wrote: > By fully addressed I mean that there is a defined algorithm for = resolving DANE DNS RRs that is compatible with administrative use cases = for use of Wildcare and alias (CNAME, DNAME) records. OK, then can you say specifically what you mean by "compatible with = administrative use cases"? That phrase is not used in the WG's use cases = document that has gone through the WG and IETF Last Calls. > The current appendix suggests options but does not mandate a = particular behavior. Can you say why it should mandate particular behavior that is different = than for, say, DKIM or SRV which also rely on name prefixing?=20 > Thus DNS administrators deploying DANE cannot rely on these records = actually working. Why not? They work fine for the rest of the DNS: why makes TLSA special = here? If TLSA is actually different than normal RRtypes, we should say that in = a prominent place in the protocol document. Proposed wording is welcome. --Paul Hoffman From hallam@gmail.com Sun Jul 31 10:51:40 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7DB721F886C for ; Sun, 31 Jul 2011 10:51:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pji3pUeflQXz for ; Sun, 31 Jul 2011 10:51:40 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6FB8321F8513 for ; Sun, 31 Jul 2011 10:51:40 -0700 (PDT) Received: by iye7 with SMTP id 7so7147278iye.31 for ; Sun, 31 Jul 2011 10:51:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=uYkEyq3yFfXYxC4B6/pTjhFF2nQsMq+5kZCApv5SKsA=; b=gBiyfNF1myRicQB/cqDxc8Q4DCFmLVqEEzthRmLdd0N3QKnbrg+zzoopiBqrejyB2W h92u/MqBeMa/ynwW012/eWB1g0LgnLzlkN9nkFd7Q2rvoIEESzcvGOK8bte9q6jwiWSR iew6ZS/jLjKMGmI4ku1Gpwn5yz0JfxSIzCMg8= Received: by 10.42.145.200 with SMTP id g8mr2438139icv.4.1312134704337; Sun, 31 Jul 2011 10:51:44 -0700 (PDT) Received: from [10.73.166.84] (mobile-166-137-137-169.mycingular.net [166.137.137.169]) by mx.google.com with ESMTPS id hq1sm5618207icc.14.2011.07.31.10.51.43 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 31 Jul 2011 10:51:43 -0700 (PDT) References: <4B7B160E-B835-44E3-A5A8-8DC50E3498FD@vpnc.org> <0E22E3A1-5D7B-42F0-AADC-96935CFD4BD2@vpnc.org> In-Reply-To: <0E22E3A1-5D7B-42F0-AADC-96935CFD4BD2@vpnc.org> Mime-Version: 1.0 (iPhone Mail 8C148) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (8C148) From: Phillip Hallam-Baker Date: Sun, 31 Jul 2011 13:51:38 -0400 To: Paul Hoffman Cc: "dane@ietf.org" Subject: Re: [dane] CNAMES and Wildcards X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jul 2011 17:51:41 -0000 Sent from my iPhone On 31 Jul 2011, at 11:44, Paul Hoffman wrote: > On Jul 31, 2011, at 8:23 AM, Phillip Hallam-Baker wrote: >> By fully addressed I mean that there is a defined algorithm for resolving= DANE DNS RRs that is compatible with administrative use cases for use of Wi= ldcare and alias (CNAME, DNAME) records. >=20 > OK, then can you say specifically what you mean by "compatible with admini= strative use cases"? That phrase is not used in the WG's use cases document t= hat has gone through the WG and IETF Last Calls. There are many problems with the way this WG has proceeded. I raised the con= cern then, I stated the degree of my concern. I have not retracted. I do not agree that consensus has been demonstrated on any point whatsoever.= This appears tome to be a new interpretation of the use cases document. Thus= I am re-raising those concerns with respect to use cases which must not pro= ceed either. I will be raising these in IETF last call. >> The current appendix suggests options but does not mandate a particular b= ehavior. >=20 > Can you say why it should mandate particular behavior that is different th= an for, say, DKIM or SRV which also rely on name prefixing?=20 Fixing legacy is difficult. Thus it is entirely consistent to say that no mo= re legacy should be created with a known set of problems. >> Thus DNS administrators deploying DANE cannot rely on these records actua= lly working. >=20 > Why not? They work fine for the rest of the DNS: why makes TLSA special he= re? They do not work. The premise is wrong and so is the conclusion. > If TLSA is actually different than normal RRtypes, we should say that in a= prominent place in the protocol document. Proposed wording is welcome Is it? Is it really? Seems to me that when you say that it is a way to try to close off discussio= n rather than a genuine request for text. Each time I have offered text I ha= ve been told that the issue has already been decided.=20 From ajs@crankycanuck.ca Sun Jul 31 09:12:10 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4719E21F8841 for ; Sun, 31 Jul 2011 09:12:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.444 X-Spam-Level: X-Spam-Status: No, score=-1.444 tagged_above=-999 required=5 tests=[AWL=-1.155, BAYES_00=-2.599, SARE_URGBIZ=0.725, URG_BIZ=1.585] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aqvuz6PjouRn for ; Sun, 31 Jul 2011 09:12:09 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id CF62221F8661 for ; Sun, 31 Jul 2011 09:12:09 -0700 (PDT) Received: from shinkuro.com (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 4F8B51ECB41C for ; Sun, 31 Jul 2011 16:12:13 +0000 (UTC) Date: Sun, 31 Jul 2011 12:12:11 -0400 From: Andrew Sullivan To: dane@ietf.org Message-ID: <20110731161210.GH9434@shinkuro.com> References: <4B7B160E-B835-44E3-A5A8-8DC50E3498FD@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Sun, 31 Jul 2011 11:18:58 -0700 Subject: Re: [dane] CNAMES and Wildcards X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jul 2011 16:12:10 -0000 Dear colleagues, I am sorry I was unable to make the DANE meeting on Friday either in person or remotely. I was called away on urgent family business. Nevertheless, I have read the document. I have yet to read a complete and coherent critique of the current text in the document. In particular, On Sun, Jul 31, 2011 at 11:23:31AM -0400, Phillip Hallam-Baker wrote: > > By fully addressed I mean that there is a defined algorithm for resolving > DANE DNS RRs that is compatible with administrative use cases for use of > Wildcare and alias (CNAME, DNAME) records. > > The current appendix suggests options but does not mandate a particular > behavior. Thus DNS administrators deploying DANE cannot rely on these > records actually working. that requirement is completely bogus. DNS zone operators have and have always had a wide degree of operational freedom with their zones. The above seems to suggest that DANE might try to require one and only one way to use DNAME and CNAME records (not to mention wildcards) in a zone in the presence of RRTYPEs that are the result of DANE work. But we don't get to make those rules. All we can do is say, "Here's what you need to take into consideration." It's the operator's zone. S/he will do as s/he pleases. All we can do is suggest tactics to maximize interoperation. For instance, my personal advice with respect to wildcards and the proposals I've seen so far on this mailing list (including those that have been rejected) is, "Don't do that." I don't believe anyone will get wildcards and any such security mechanism right, and I think it is borrowing trouble to try to use them. But I'm not the Internet Cops, and I don't want to be either. A -- Andrew Sullivan ajs@crankycanuck.ca From hallam@gmail.com Sun Jul 31 11:54:17 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3656B21F8922 for ; Sun, 31 Jul 2011 11:54:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.363 X-Spam-Level: X-Spam-Status: No, score=-2.363 tagged_above=-999 required=5 tests=[AWL=-1.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_URGBIZ=0.725, URG_BIZ=1.585] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5vMBAC6-JZ7K for ; Sun, 31 Jul 2011 11:54:16 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5EAE321F8906 for ; Sun, 31 Jul 2011 11:54:16 -0700 (PDT) Received: by gyd5 with SMTP id 5so3790821gyd.31 for ; Sun, 31 Jul 2011 11:54:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=URNTYGReL6NrFwGXCfEV6sq7XFvtTgxikM/XWe+nPOg=; b=EoLoCmHGPZ/UgowyUP1X3HnJQrd/S8phKAG2BZGpB+Aa3Z0MJMu/daSgUC/xlkFPCB DOqajOL5fT4e8yCBwanWuakPyAjjM2JV0kIWSrUXv1FlA+rGjZ+YnpZD75nlywHBvljN A7+Gfuxx6Yo4nNKOhuIXmouqbmzwnkuwAmgdQ= MIME-Version: 1.0 Received: by 10.101.189.1 with SMTP id r1mr879091anp.6.1312138460042; Sun, 31 Jul 2011 11:54:20 -0700 (PDT) Received: by 10.100.34.3 with HTTP; Sun, 31 Jul 2011 11:54:20 -0700 (PDT) In-Reply-To: <20110731161210.GH9434@shinkuro.com> References: <4B7B160E-B835-44E3-A5A8-8DC50E3498FD@vpnc.org> <20110731161210.GH9434@shinkuro.com> Date: Sun, 31 Jul 2011 14:54:20 -0400 Message-ID: From: Phillip Hallam-Baker To: Andrew Sullivan Content-Type: multipart/alternative; boundary=001636c5bbf3ce97c004a9620ad3 Cc: dane@ietf.org Subject: Re: [dane] CNAMES and Wildcards X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jul 2011 18:54:17 -0000 --001636c5bbf3ce97c004a9620ad3 Content-Type: text/plain; charset=ISO-8859-1 On Sun, Jul 31, 2011 at 12:12 PM, Andrew Sullivan wrote: > Dear colleagues, > > I am sorry I was unable to make the DANE meeting on Friday either in > person or remotely. I was called away on urgent family business. > Nevertheless, I have read the document. I have yet to read a complete > and coherent critique of the current text in the document. In particular, > > On Sun, Jul 31, 2011 at 11:23:31AM -0400, Phillip Hallam-Baker wrote: > > > > By fully addressed I mean that there is a defined algorithm for resolving > > DANE DNS RRs that is compatible with administrative use cases for use of > > Wildcare and alias (CNAME, DNAME) records. > > > > The current appendix suggests options but does not mandate a particular > > behavior. Thus DNS administrators deploying DANE cannot rely on these > > records actually working. > > that requirement is completely bogus. DNS zone operators have and > have always had a wide degree of operational freedom with their zones. > They can stuff records in zones. But they can't predict what effect the records will have unless the resolution semantics are defined. And if they can't predict the effect of a configuration they can't use it. > The above seems to suggest that DANE might try to require one and only > one way to use DNAME and CNAME records (not to mention wildcards) in a > zone in the presence of RRTYPEs that are the result of DANE work. But > we don't get to make those rules. All we can do is say, "Here's what > you need to take into consideration." It's the operator's zone. S/he > will do as s/he pleases. All we can do is suggest tactics to maximize > interoperation. > What is at issue here is a requirement for client application developers. The operator can't make an informed decision if different client take different approaches. That is why it is a standards issue. -- Website: http://hallambaker.com/ --001636c5bbf3ce97c004a9620ad3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Sun, Jul 31, 2011 at 12:12 PM, Andrew= Sullivan <ajs@= crankycanuck.ca> wrote:
Dear colleagues,

I am sorry I was unable to make the DANE meeting on Friday either in
person or remotely. =A0I was called away on urgent family business.
Nevertheless, I have read the document. =A0I have yet to read a complete and coherent critique of the current text in the document. =A0In particular= ,

On Sun, Jul 31, 2011 at 11:23:31AM -0400, Phillip Hallam-Baker wrote:
>
> By fully addressed I mean that there is a defined algorithm for resolv= ing
> DANE DNS RRs that is compatible with administrative use cases for use = of
> Wildcare and alias (CNAME, DNAME) records.
>
> The current appendix suggests options but does not mandate a particula= r
> behavior. Thus DNS administrators deploying DANE cannot rely on these<= br> > records actually working.

that requirement is completely bogus. =A0DNS zone operators have and<= br> have always had a wide degree of operational freedom with their zones.
<= /blockquote>

They can stuff records in zones.
=
But they can't predict what effect the records will have= unless the resolution semantics are defined. And if they can't predict= the effect of a configuration they can't use it.

=A0
The above seems to suggest that DANE might try to require one and only
one way to use DNAME and CNAME records (not to mention wildcards) in a
zone in the presence of RRTYPEs that are the result of DANE work. =A0But we don't get to make those rules. =A0All we can do is say, "Here&#= 39;s what
you need to take into consideration." =A0It's the operator's z= one. =A0S/he
will do as s/he pleases. =A0All we can do is suggest tactics to maximize interoperation.

What is at issue here i= s a requirement for client application developers.

The operator can't make an informed decision if different client take = different approaches.

That is why it is a standards issue.

--
Website: http://hallamba= ker.com/

--001636c5bbf3ce97c004a9620ad3-- From paul.hoffman@vpnc.org Sun Jul 31 12:11:56 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0508C21F8877 for ; Sun, 31 Jul 2011 12:11:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.62 X-Spam-Level: X-Spam-Status: No, score=-102.62 tagged_above=-999 required=5 tests=[AWL=-0.021, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bfiptd5vGBPu for ; Sun, 31 Jul 2011 12:11:53 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 1332E21F87BC for ; Sun, 31 Jul 2011 12:11:52 -0700 (PDT) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p6VJBcM1093543 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sun, 31 Jul 2011 12:11:38 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Paul Hoffman In-Reply-To: Date: Sun, 31 Jul 2011 12:11:55 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4B7B160E-B835-44E3-A5A8-8DC50E3498FD@vpnc.org> <0E22E3A1-5D7B-42F0-AADC-96935CFD4BD2@vpnc.org> To: DANE WG X-Mailer: Apple Mail (2.1084) Subject: Re: [dane] CNAMES and Wildcards X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jul 2011 19:11:56 -0000 On Jul 31, 2011, at 10:51 AM, Phillip Hallam-Baker wrote: >> If TLSA is actually different than normal RRtypes, we should say that = in a prominent place in the protocol document. Proposed wording is = welcome >=20 > Is it? Is it really? Yes and yes. > Seems to me that when you say that it is a way to try to close off = discussion rather than a genuine request for text. Each time I have = offered text I have been told that the issue has already been decided.=20= Proposing text after there is WG consensus is, indeed, = counterproductive. There is no WG consensus on this issue which you have = just brought up, albeit unclearly. The WG can better find consensus if = you propose the actual text you want in the protocol document for this = topic. --Paul Hoffman From ajs@anvilwalrusden.com Sun Jul 31 13:26:04 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CEB921F87E2 for ; Sun, 31 Jul 2011 13:26:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lXjsoCyyCJ-y for ; Sun, 31 Jul 2011 13:26:04 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 0F6FE21F8733 for ; Sun, 31 Jul 2011 13:26:03 -0700 (PDT) Received: from shinkuro.com (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 04CD01ECB41C for ; Sun, 31 Jul 2011 20:26:07 +0000 (UTC) Date: Sun, 31 Jul 2011 16:26:01 -0400 From: Andrew Sullivan To: dane@ietf.org Message-ID: <20110731202601.GJ9434@shinkuro.com> References: <4B7B160E-B835-44E3-A5A8-8DC50E3498FD@vpnc.org> <20110731161210.GH9434@shinkuro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] CNAMES and Wildcards X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jul 2011 20:26:04 -0000 On Sun, Jul 31, 2011 at 02:54:20PM -0400, Phillip Hallam-Baker wrote: > What is at issue here is a requirement for client application developers. > > The operator can't make an informed decision if different client take > different approaches. > > That is why it is a standards issue. Then it seems to me you need to send text. I haven't seen such text, and in fact I still don't understand even remotely why you think the current text is wrong. -- Andrew Sullivan ajs@anvilwalrusden.com From hallam@gmail.com Sun Jul 31 16:34:04 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB7C221F86BE for ; Sun, 31 Jul 2011 16:34:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.5 X-Spam-Level: X-Spam-Status: No, score=-3.5 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U6X0hb0Tc4k2 for ; Sun, 31 Jul 2011 16:34:04 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id 11BAA21F86BD for ; Sun, 31 Jul 2011 16:34:04 -0700 (PDT) Received: by yie30 with SMTP id 30so3844663yie.31 for ; Sun, 31 Jul 2011 16:34:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gBC1OQNVVE6n8zb86sdswCzwy6ps9fEpxOU+6pKpt3I=; b=gFDDB4rprKjy/GPXcSu5UBHaMPBBraWV9CKCKUQq/xjU474YfrV5Y9oJC+MXAxGkPy hK9u6SWL1QkXzhQSCp8w838UbA0+7fsZgYqIBsrKxQW8j38IM/i/7mWVpOCc8t8RLWZp 0e0wRCcfGKCn97Bhof1n17tLWxSt3ERC29/c4= MIME-Version: 1.0 Received: by 10.101.164.25 with SMTP id r25mr2662734ano.94.1312155248475; Sun, 31 Jul 2011 16:34:08 -0700 (PDT) Received: by 10.100.34.3 with HTTP; Sun, 31 Jul 2011 16:34:08 -0700 (PDT) In-Reply-To: <20110731202601.GJ9434@shinkuro.com> References: <4B7B160E-B835-44E3-A5A8-8DC50E3498FD@vpnc.org> <20110731161210.GH9434@shinkuro.com> <20110731202601.GJ9434@shinkuro.com> Date: Sun, 31 Jul 2011 19:34:08 -0400 Message-ID: From: Phillip Hallam-Baker To: Andrew Sullivan Content-Type: multipart/alternative; boundary=0016e6d26d7279bf0304a965f3e2 Cc: dane@ietf.org Subject: Re: [dane] CNAMES and Wildcards X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jul 2011 23:34:04 -0000 --0016e6d26d7279bf0304a965f3e2 Content-Type: text/plain; charset=ISO-8859-1 On Sun, Jul 31, 2011 at 4:26 PM, Andrew Sullivan wrote: > On Sun, Jul 31, 2011 at 02:54:20PM -0400, Phillip Hallam-Baker wrote: > > > What is at issue here is a requirement for client application developers. > > > > The operator can't make an informed decision if different client take > > different approaches. > > > > That is why it is a standards issue. > > Then it seems to me you need to send text. I haven't seen such text, > and in fact I still don't understand even remotely why you think the > current text is wrong. Sending text would be appropriate if the issue was a disagreement over the precise wording. In this case we do not appear to have agreement on the principle so asking for wording seems premature. The issue with the current wording is that it is a set of options in an appendix. I want to see there be precisely one correct approach to resolving TLSA records and that it be in the main body of the text. -- Website: http://hallambaker.com/ --0016e6d26d7279bf0304a965f3e2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Sun, Jul 31, 2011 at 4:26 PM, Andrew = Sullivan <aj= s@anvilwalrusden.com> wrote:
On Sun, Jul 31, 2011 at 02:54:20PM -0400, Phillip Hallam-= Baker wrote:

> What is at issue here is a requirement for client application develope= rs.
>
> The operator can't make an informed decision if different client t= ake
> different approaches.
>
> That is why it is a standards issue.

Then it seems to me you need to send text. =A0I haven't seen such= text,
and in fact I still don't understand even remotely why you think the current text is wrong.

Sending text would b= e appropriate if the issue was a disagreement over the precise wording. In = this case we do not appear to have agreement on the principle so asking for= wording seems premature.

The issue with the current wording is that it is a set = of options in an appendix.=A0

I want to see there = be precisely one correct approach to resolving TLSA records and that it be = in the main body of the text.
=A0

--
Website: http://hallambaker.com/

--0016e6d26d7279bf0304a965f3e2-- From paul.hoffman@vpnc.org Sun Jul 31 16:55:57 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D952621F851A for ; Sun, 31 Jul 2011 16:55:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.62 X-Spam-Level: X-Spam-Status: No, score=-102.62 tagged_above=-999 required=5 tests=[AWL=-0.021, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mZE6X4OHEs-z for ; Sun, 31 Jul 2011 16:55:57 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 39B9921F8514 for ; Sun, 31 Jul 2011 16:55:57 -0700 (PDT) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p6VNtgq8000208 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sun, 31 Jul 2011 16:55:43 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Paul Hoffman In-Reply-To: Date: Sun, 31 Jul 2011 16:56:00 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <131D123D-837A-4FA9-A58A-BA1602F14707@vpnc.org> References: <4B7B160E-B835-44E3-A5A8-8DC50E3498FD@vpnc.org> <20110731161210.GH9434@shinkuro.com> <20110731202601.GJ9434@shinkuro.com> To: DANE WG X-Mailer: Apple Mail (2.1084) Subject: Re: [dane] CNAMES and Wildcards X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jul 2011 23:55:58 -0000 On Jul 31, 2011, at 4:34 PM, Phillip Hallam-Baker wrote: > Sending text would be appropriate if the issue was a disagreement over = the precise wording. In this case we do not appear to have agreement on = the principle so asking for wording seems premature. Asking for wording is *never* premature. This WG has gotten into long = discussions over issues, only later to discover that the proposer had a = different idea than what was discussed. That's a waste of time. > The issue with the current wording is that it is a set of options in = an appendix.=20 >=20 > I want to see there be precisely one correct approach to resolving = TLSA records and that it be in the main body of the text. Proposed wording for the main body of the text: TLSA records are retrieved in exactly the same manner as all other = DNS records are today. --Paul Hoffman From ajs@anvilwalrusden.com Sun Jul 31 18:45:03 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2520921F85F2 for ; Sun, 31 Jul 2011 18:45:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ejEqdirAlvaA for ; Sun, 31 Jul 2011 18:45:02 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 2DB0621F85CE for ; Sun, 31 Jul 2011 18:45:02 -0700 (PDT) Received: from shinkuro.com (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 20E9B1ECB41C; Mon, 1 Aug 2011 01:45:06 +0000 (UTC) Date: Sun, 31 Jul 2011 21:44:59 -0400 From: Andrew Sullivan To: Phillip Hallam-Baker Message-ID: <20110801014459.GD20015@shinkuro.com> References: <4B7B160E-B835-44E3-A5A8-8DC50E3498FD@vpnc.org> <20110731161210.GH9434@shinkuro.com> <20110731202601.GJ9434@shinkuro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: dane@ietf.org Subject: Re: [dane] CNAMES and Wildcards X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 01:45:03 -0000 On Sun, Jul 31, 2011 at 07:34:08PM -0400, Phillip Hallam-Baker wrote: > Sending text would be appropriate if the issue was a disagreement over the > precise wording. In this case we do not appear to have agreement on the > principle so asking for wording seems premature. Well, then, perhaps you can explain to me what it is that is wrong about "TLSA is another RRTYPE like all other RRTYPES, and it resolves in exactly the same way." That's what the document says now, and you keep waving your hand saying that it's wrong. How? I'm a simpleton. Explain to me what the problem is, ideally by walking through an example. Do I think there are giant pits underneath this RRTYPE if you use it carelessly with wildcards and *NAME? Sure. But that was part of what we took on when we undertook this work. What's special? A -- Andrew Sullivan ajs@anvilwalrusden.com