From matt@mattmccutchen.net Sat Oct 1 11:51: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 C4BC421F84FC for ; Sat, 1 Oct 2011 11:51:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.634 X-Spam-Level: X-Spam-Status: No, score=-2.634 tagged_above=-999 required=5 tests=[AWL=-0.035, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Smn6hUj1HPWC for ; Sat, 1 Oct 2011 11:51:47 -0700 (PDT) Received: from homiemail-a38.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id 09B2421F9094 for ; Sat, 1 Oct 2011 11:51:47 -0700 (PDT) Received: from homiemail-a38.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a38.g.dreamhost.com (Postfix) with ESMTP id 40F5410AFAA; Sat, 1 Oct 2011 11:54:44 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:date:in-reply-to:references:content-type :content-transfer-encoding:message-id:mime-version; q=dns; s= mattmccutchen.net; b=eEjAKaasFAIYmbQxt/NdR4cErhhoDokeAQpFjS8siqy vCQeEqAgIs+fD6JoxgUyLUl83pAzgcXhfhMycPGAj3HiTWoNZA4m8AhMUywbA/Rs 0d3FjuKjb7shc9TbYqG53OUV8PKAHl6cymGKvsOl++pBKpLq2ScdWi1a9TfH+OP8 = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:date:in-reply-to:references:content-type :content-transfer-encoding:message-id:mime-version; s= mattmccutchen.net; bh=m9bznA4YSDpEbM2azSoF7Ko8YZ8=; b=l/NKC3ouQw EVWWi9tf6UCxYCLu1wmqG37lqcRRUV6UsXeVwnO2g161HzYF8luoK/ZVgabcjGc9 DofX4UfOTVCfyALWBBAEB/+ALbddflais2Bsx/Wgh6iihowt1uWcih8lkDic636N f7d6pMS0oe/deM51mETsHOufCKkIs7Iw4= Received: from [IPv6:::1] (c-98-248-34-40.hsd1.ca.comcast.net [98.248.34.40]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a38.g.dreamhost.com (Postfix) with ESMTPSA id 14D5C10AFA1; Sat, 1 Oct 2011 11:54:44 -0700 (PDT) From: Matt McCutchen To: "Richard L. Barnes" Date: Sat, 01 Oct 2011 11:54:43 -0700 In-Reply-To: References: <061.a8eeecd5d3e79d55021946fbc77943e1@trac.tools.ietf.org> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3 Content-Transfer-Encoding: 7bit Message-ID: <1317495284.2102.11.camel@localhost> Mime-Version: 1.0 Cc: dane Subject: Re: [dane] #37: Additive assertion of server certificate 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: Sat, 01 Oct 2011 18:51:47 -0000 On Tue, 2011-09-27 at 23:39 -0400, Richard L. Barnes wrote: > This is a non-issue. Using the cert as a TA means that you accept any > chain starting with that cert. Since a server cert itself is a chain > starting with that cert (of length 1), if you put a server cert in a > type 2 record, it Just Works. It occurs to me that exactly the same argument can be made to eliminate usage 1: if we delete the word "CA" from the definition of usage 0, then you can just publish the server cert and it will chain through itself, as required. The only difference between usages 0/1 and 2 is the additivity of the assertion, so I cannot see the motivation for having separate usages for non-additive assertions of CA and EE certs and declining to similarly subdivide the additive assertions. We should have both of usages 1 and 3 or neither (of course, I would prefer both). The status quo is just a windfall for the public CAs, since folks like me will have to get a publicly recognized server cert to be able to do an assertion of the server cert via usage 1. -- Matt From ondrej.sury@nic.cz Mon Oct 3 08:26: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 8F30621F8B8B for ; Mon, 3 Oct 2011 08:26:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.522 X-Spam-Level: X-Spam-Status: No, score=-0.522 tagged_above=-999 required=5 tests=[AWL=-0.681, BAYES_20=-0.74, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zQcPzkY04TT1 for ; Mon, 3 Oct 2011 08:26:44 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 698FD21F8B83 for ; Mon, 3 Oct 2011 08:26:44 -0700 (PDT) Received: from [IPv6:2001:1488:ac14:1400:e911:8bbf:5341:bc2d] (unknown [IPv6:2001:1488:ac14:1400:e911:8bbf:5341:bc2d]) by mail.nic.cz (Postfix) with ESMTPSA id 54CD52A0DF1; Mon, 3 Oct 2011 17:29:46 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1317655786; bh=OZJ2u5zrsU8dHkv+MmOn7m+TaRaV6S6Sl3vhGTTEI3c=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=SnRTKKm7K4pheI//nxx84NF6kvH+EG25FVLPoxzKj/lryt7E6ya6ZF+G/bWq8dBdW jY5FUEoaDi+kNztb5WWqirx9C/SFYYHxkrm9B1pAHnUky3J1nbp1pBA4hg3o86fNT+ 14k8Oqhy++KaeQMkZtEfXEPXDyJB/KiQhb1ya7rc= Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <881C47F4-FDE0-43DC-BF7E-D85729D057AE@kumari.net> Date: Mon, 3 Oct 2011 17:29:46 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6BE1DA4F-2684-4923-A0E1-833BEE0F3295@nic.cz> References: <1E08D85E-3E17-4E30-BF21-6C37E8CE3052@kumari.net> <000401cc7423$bf343990$3d9cacb0$@augustcellars.com> <881C47F4-FDE0-43DC-BF7E-D85729D057AE@kumari.net> To: Warren Kumari X-Mailer: Apple Mail (2.1244.3) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: DANE WG Subject: Re: [dane] Opening issues #25, #26, #27 as a group (last call) 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, 03 Oct 2011 15:26:48 -0000 Hi, On 21. 9. 2011, at 18:07, Warren Kumari wrote: > It appears to the chairs that issues #25, #26, #27 are all variations = on a theme and are all predicated on DANE doing [ conjunctive / = disjunctive / grouping / sets ] -- see issue #32, Matt's proposed schema = ( https://www.ietf.org/mail-archive/web/dane/current/msg02637.html ), = etc. >=20 > We believe that this was viewed by the WG as cool and sexy, but adding = too much additional complexity to the protocol (see the thread around: = http://www.ietf.org/mail-archive/web/dane/current/msg03351.html ). >=20 > Unless we hear that the WG would like to reconsider this, we are = planning on calling these issues closed. Since we haven't heard from the WG to reconsider and we have heard more = voices to keep it simple and close the issues, we are going to close = these three issues now. O. -- 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 ------------------------------------------- From zack.weinberg@gmail.com Mon Oct 3 13:03: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 6E8D521F8E74 for ; Mon, 3 Oct 2011 13:03:30 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TZbv8hjYFXDm for ; Mon, 3 Oct 2011 13:03:29 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id A98D821F8E73 for ; Mon, 3 Oct 2011 13:03:29 -0700 (PDT) Received: by qadb12 with SMTP id b12so2510109qad.31 for ; Mon, 03 Oct 2011 13:06:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=Pok0j/wz0HlYYYp5EbJOCDc/wR3ifmw3686BZHJRfI8=; b=Gmg0UJqsqacTcveRWF6q7w10FgzbuwJD/DslVvsCKIgI8wie8ei8jrSxwyf5AOEO6E T/kk7CriDmqe6MdMdENw6BUQ6EhE2pv4mwP2DxoYx1R1DNaFcpbwA2oK2LOixuUj3LPP h6Qpk3w0vG2JF+nqeZqMwVJmkELph879ndZgk= Received: by 10.68.57.3 with SMTP id e3mr3612259pbq.86.1317672392111; Mon, 03 Oct 2011 13:06:32 -0700 (PDT) Received: from dhcp-135.danastreet.live555.com (dhcp-135.danastreet.live555.com. [64.6.174.135]) by mx.google.com with ESMTPS id e7sm29150825pbq.1.2011.10.03.13.06.31 (version=SSLv3 cipher=OTHER); Mon, 03 Oct 2011 13:06:31 -0700 (PDT) Sender: Zack Weinberg Message-ID: <4E8A15C6.3000408@sv.cmu.edu> Date: Mon, 03 Oct 2011 13:06:30 -0700 From: Zack Weinberg User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: IETF DANE WG list References: <201109272223.p8RMNPpA026467@fs4113.wdf.sap.corp> <4E856FB8.9000301@sidn.nl> <1317451765.2130.94.camel@localhost> In-Reply-To: <1317451765.2130.94.camel@localhost> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dane] Fwd: #36: Only requiring DNSSEC where it is needed 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, 03 Oct 2011 20:03:30 -0000 On 2011-09-30 11:49 PM, Matt McCutchen wrote: >> A DANE client that ignores DNSSEC validation under any circumstances >> -- note that in this scenario, it doesn't get any TLSA records back at >> all! -- will not defend against this attack; but a client that treats >> DNSSEC "bogus" or "stripped" states as a hard failure, regardless of >> TLSA contents, will defend. > > To simplify matters a bit, note that RFC 4033 "bogus" includes what you > are calling "stripped". Thanks for the correction. I think I was trying to remember the RFC 4033 distinction between "insecure" (parent zone signed, child zone attestably unsigned) and "indeterminate" (no trust anchor at all). At some point clients will have to start treating "indeterminate" as a hard fail to prevent a network MITM from downgrading them by completely stripping DNSSEC, but I think that's out of scope for DANE; it belongs in a 'how to consume DNSSEC properly' document. >>> Again, I believe the new proposal adds one step: "if you received a type 2 >>> response, make sure it was covered with DNSSEC". That's the same >>> number of steps as "if you received any response, make sure it was >>> covered with DNSSEC". >> >> I hope I have demonstrated that this is inadequate. > > You and Paul are arguing past each other. Paul is assuming a validating > resolver that doesn't even give you a response unless it is "secure" or > "verified insecure"; in that case, you're already protected from > tampering with signed TLSA records. Ah, but no! The attacker needs to be a little more sophisticated in this case, but it's still doable. They leave DNSSEC intact for the A record, block the TLSA response entirely, and intercept traffic to the legitimate server by messing with the *routing*. A client that falls back to legacy PKIX behavior under these conditions loses the protection of a cert-type 0/1 restriction. Basically, the only time it is safe for a DANE client to downgrade to legacy PKIX behavior on a signed zone is if it *actually receives* a valid NSEC(n) response for the TLSA record query. The details of "doesn't even give you a response" matter here, of course - maybe this can be made secure with a resolver library that behaves as you describe, if its error codes are sufficiently detailed. But it still requires the application to consider DNSSEC state ahead of processing any TLSA records that are received. And therefore it is *operationally* simpler to process DNSSEC state once and for all before even looking at the TLSA records. I want to repeat that my concern here is strictly implementational. I agree that > If you get verified-insecure > records of usage 0 or 1, you do not gain or lose any *security* by > processing them (emphasis mine) but I think that "MUST ignore all verified-insecure TLSA records, regardless of their contents" is sufficiently more likely to be *implemented correctly* that it is worthwhile, even though it sacrifices a use case on the server end (deploying DANE restrictions without being ready to do DNSSEC yet). zw From zack.weinberg@gmail.com Mon Oct 3 13:08: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 B4FA421F8DFC for ; Mon, 3 Oct 2011 13:08:09 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wjRvIiYP17gg for ; Mon, 3 Oct 2011 13:08:09 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id A2B7821F8DF9 for ; Mon, 3 Oct 2011 13:08:03 -0700 (PDT) Received: by vcbfo11 with SMTP id fo11so4820944vcb.31 for ; Mon, 03 Oct 2011 13:11:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=YIUUYvankrnGTFAlCnefG22pxzq9bkv+eEc/ESemg88=; b=lExkbczHNTDZ86Tvd9yI+ruuAwplcOyG/xYCeXy26srOI5NvhpI/k9Sa7JefoWKWGs 1JSpmgpeD5PLX48cQCDQ8lJ11cavM92ZBV4p/RFfO1jxq4OR2+3OetYJMFVHYrTakD6D tio3iOcXGxz4RP9Hx3GWPdhZ/Fq69ICb8uwQw= Received: by 10.68.19.100 with SMTP id d4mr3777327pbe.28.1317672666183; Mon, 03 Oct 2011 13:11:06 -0700 (PDT) Received: from dhcp-135.danastreet.live555.com (dhcp-135.danastreet.live555.com. [64.6.174.135]) by mx.google.com with ESMTPS id h5sm56869155pbq.11.2011.10.03.13.11.01 (version=SSLv3 cipher=OTHER); Mon, 03 Oct 2011 13:11:02 -0700 (PDT) Sender: Zack Weinberg Message-ID: <4E8A16D5.70309@sv.cmu.edu> Date: Mon, 03 Oct 2011 13:11:01 -0700 From: Zack Weinberg User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: IETF DANE WG list References: <061.add9f922b5dfb2db7544981f78552e7e@trac.tools.ietf.org> <076.bdd0467de056ddca69582bc0104dce57@trac.tools.ietf.org> <1317264820.2975.58.camel@localhost> <1317360012.2130.8.camel@localhost> <1317446870.2130.49.camel@localhost> In-Reply-To: <1317446870.2130.49.camel@localhost> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dane] #33: Publish enough information for the client to achieve the security of its favorite digest 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, 03 Oct 2011 20:08:09 -0000 On 2011-09-30 10:27 PM, Matt McCutchen wrote: > On Fri, 2011-09-30 at 11:03 -0700, Zack Weinberg wrote: >> To put all digests of one cert in one RR, you would >> need to define a parseable format for the data portion. > > Yes, it could be something trivial like: > > (cert usage, selector, (algorithm ID, 16-bit length, value)*) I agree that parsing this would not be that much of a headache. >> As far as I >> know there is no other RR that needs this treatment, so we'd be making >> up something new and adding code to all clients. If we keep it to one >> digest per RR, we get the same functionality for free. > > What functionality are you envisioning reusing? The functionality of segmenting DNS reply *packets* into RRs. > I'm not convinced that solution 1 does in fact require more code. I'd > imagine the code to parse the RDATA into individual digest values would > be comparable in size to the code to collate RRs by group ID for > solution 3. The rest is two levels of iteration, either way. This is also a valid point. And since the consensus seems to be against *either* 1 or 3 right now, it's notable that only option 1 can be deployed later without defining a new RRtype (we'd have to define a new "sequence-of" reference type, but that's easier than a whole new RR). I wonder if the WG would be willing to consider reserving a byte in the RR against the possibility that group IDs, disjunctions, or something else yet-unforeseen will become necessary in the future. zw From ajs@anvilwalrusden.com Mon Oct 3 13:13: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 C7A2121F8D13 for ; Mon, 3 Oct 2011 13:13:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qS4Ya6weTT0e for ; Mon, 3 Oct 2011 13:13:10 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 51FF021F8CD9 for ; Mon, 3 Oct 2011 13:13:05 -0700 (PDT) Received: from shinkuro.com (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id C881C1ECB41C for ; Mon, 3 Oct 2011 20:16:01 +0000 (UTC) Date: Mon, 3 Oct 2011 16:16:05 -0400 From: Andrew Sullivan To: dane@ietf.org Message-ID: <20111003201605.GN53886@shinkuro.com> References: <4E856FB8.9000301@sidn.nl> <1317451765.2130.94.camel@localhost> <4E8A15C6.3000408@sv.cmu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E8A15C6.3000408@sv.cmu.edu> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Fwd: #36: Only requiring DNSSEC where it is needed 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, 03 Oct 2011 20:13:10 -0000 On Mon, Oct 03, 2011 at 01:06:30PM -0700, Zack Weinberg wrote: > At some point clients will have to start treating "indeterminate" as > a hard fail to prevent a network MITM from downgrading them by > completely stripping DNSSEC No, they won't. If you have a trust anchor and you get back an answer that you can't validate, you fail the validation. That means that if you have a trust anchor for the root and the root's answer doesn't validate, you fail starting there. Once you have the first validated answer, you can follow the chain so long as there are no islands. You only have to worry about the indeterminate case when you encounter an island for which you don't have a trust anchor -- in which case you couldn't validate anyway. If any of the answers from your valid trust anchor are tampered with, you will be able to tell, and you can fail at that point. Many people worry about this "stripping" problem, but it isn't possible. A -- Andrew Sullivan ajs@anvilwalrusden.com From zack.weinberg@gmail.com Mon Oct 3 13:19: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 E968521F8D1C for ; Mon, 3 Oct 2011 13:19:04 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wwKot9VEeD-y for ; Mon, 3 Oct 2011 13:19:04 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id 3B78021F8CF8 for ; Mon, 3 Oct 2011 13:19:04 -0700 (PDT) Received: by qyk33 with SMTP id 33so3580974qyk.10 for ; Mon, 03 Oct 2011 13:22:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=vm2ITrH1hcORTIH7efKeekvRj/G1HVlC2zIosZlNXFY=; b=RXv2Mu4TK8HsfB4SCGkxEYf3nXc0eLBXj5gW+p3lD7p8UwE5+XPiRJelqbXI7OqGIs n4HOV0o/IItb0XNf96OILE83rwkO8nn/CFoMm0j1HJCWIJ/9uG25s/7Ya/925tNef+6l ICIuWTZ7s8h6jXCGeO8f21UW6o5PIE5gUYWDE= Received: by 10.68.34.138 with SMTP id z10mr3649179pbi.105.1317673326675; Mon, 03 Oct 2011 13:22:06 -0700 (PDT) Received: from dhcp-135.danastreet.live555.com (dhcp-135.danastreet.live555.com. [64.6.174.135]) by mx.google.com with ESMTPS id z1sm56988287pbl.5.2011.10.03.13.22.06 (version=SSLv3 cipher=OTHER); Mon, 03 Oct 2011 13:22:06 -0700 (PDT) Sender: Zack Weinberg Message-ID: <4E8A196C.5060602@sv.cmu.edu> Date: Mon, 03 Oct 2011 13:22:04 -0700 From: Zack Weinberg User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: dane@ietf.org References: <4E856FB8.9000301@sidn.nl> <1317451765.2130.94.camel@localhost> <4E8A15C6.3000408@sv.cmu.edu> <20111003201605.GN53886@shinkuro.com> In-Reply-To: <20111003201605.GN53886@shinkuro.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dane] Fwd: #36: Only requiring DNSSEC where it is needed 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, 03 Oct 2011 20:19:05 -0000 On 2011-10-03 1:16 PM, Andrew Sullivan wrote: > On Mon, Oct 03, 2011 at 01:06:30PM -0700, Zack Weinberg wrote: > >> At some point clients will have to start treating "indeterminate" as >> a hard fail to prevent a network MITM from downgrading them by >> completely stripping DNSSEC > > No, they won't. If you have a trust anchor and you get back an answer > that you can't validate, you fail the validation. That means that if > you have a trust anchor for the root and the root's answer doesn't > validate, you fail starting there. It is precisely this that may not be operationally feasible at present. A client with a configured trust anchor for the root zone may still be in a circumstance where it can't get DNSSEC information for any zone, for a reason that does not imply a security problem (e.g. an obsolete recursive resolver that's dropping DNSSEC data on the floor). > You only have to worry about the indeterminate case when you encounter an > island for which you don't have a trust anchor -- in which case you > couldn't validate anyway. Given that the root has now been signed, I'm not sure whether this case can occur anymore - please clarify. zw From ajs@anvilwalrusden.com Mon Oct 3 13:29: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 9ADCC21F8E47 for ; Mon, 3 Oct 2011 13:29:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qFwpgk-svvCt for ; Mon, 3 Oct 2011 13:29:11 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 1F21B21F8E46 for ; Mon, 3 Oct 2011 13:29:10 -0700 (PDT) Received: from shinkuro.com (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id DAD3E1ECB41C for ; Mon, 3 Oct 2011 20:32:07 +0000 (UTC) Date: Mon, 3 Oct 2011 16:32:11 -0400 From: Andrew Sullivan To: dane@ietf.org Message-ID: <20111003203211.GP53886@shinkuro.com> References: <4E856FB8.9000301@sidn.nl> <1317451765.2130.94.camel@localhost> <4E8A15C6.3000408@sv.cmu.edu> <20111003201605.GN53886@shinkuro.com> <4E8A196C.5060602@sv.cmu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E8A196C.5060602@sv.cmu.edu> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Fwd: #36: Only requiring DNSSEC where it is needed 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, 03 Oct 2011 20:29:11 -0000 On Mon, Oct 03, 2011 at 01:22:04PM -0700, Zack Weinberg wrote: > It is precisely this that may not be operationally feasible at > present. A client with a configured trust anchor for the root zone > may still be in a circumstance where it can't get DNSSEC information > for any zone, for a reason that does not imply a security problem > (e.g. an obsolete recursive resolver that's dropping DNSSEC data on > the floor). If it's "dropping DNSSEC data on the floor", the DNS response will fail validation and be bogus. If, however, it responds with the DO bit not set, you have a different situation. That does seem to be a case where you could have an attacker on network; you would have to decide whether you'd accept a response without DO. > Given that the root has now been signed, I'm not sure whether this > case can occur anymore - please clarify. Sure it can. If you don't send your DNSKEY or DS data to your parent, then the trust chain doesn't go across the zone cut and you're an island. The DNS is a distributed database. Everyone needs to do their part, or the chains break. A -- Andrew Sullivan ajs@anvilwalrusden.com From marka@isc.org Mon Oct 3 18:02: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 4106021F8DF9 for ; Mon, 3 Oct 2011 18:02:22 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZPNjhyNqIqoi for ; Mon, 3 Oct 2011 18:02:06 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id D9E1A21F8BF0 for ; Mon, 3 Oct 2011 18:02:05 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id 4AF0A5F98A2; Tue, 4 Oct 2011 01:03:50 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id F2947216C33; Tue, 4 Oct 2011 01:03:47 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 64C0014911E0; Tue, 4 Oct 2011 11:58:33 +1100 (EST) To: Zack Weinberg From: Mark Andrews References: <4E856FB8.9000301@sidn.nl> <1317451765.2130.94.camel@localhost> <4E8A15C6.3000408@sv.cmu.edu> <20111003201605.GN53886@shinkuro.com> <4E8A196C.5060602@sv.cmu.edu> In-reply-to: Your message of "Mon, 03 Oct 2011 13:22:04 PDT." <4E8A196C.5060602@sv.cmu.edu> Date: Tue, 04 Oct 2011 11:58:33 +1100 Message-Id: <20111004005833.64C0014911E0@drugs.dv.isc.org> Cc: dane@ietf.org Subject: Re: [dane] Fwd: #36: Only requiring DNSSEC where it is needed 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, 04 Oct 2011 01:02:22 -0000 In message <4E8A196C.5060602@sv.cmu.edu>, Zack Weinberg writes: > On 2011-10-03 1:16 PM, Andrew Sullivan wrote: > > On Mon, Oct 03, 2011 at 01:06:30PM -0700, Zack Weinberg wrote: > > > >> At some point clients will have to start treating "indeterminate" as > >> a hard fail to prevent a network MITM from downgrading them by > >> completely stripping DNSSEC > > > > No, they won't. If you have a trust anchor and you get back an answer > > that you can't validate, you fail the validation. That means that if > > you have a trust anchor for the root and the root's answer doesn't > > validate, you fail starting there. > > It is precisely this that may not be operationally feasible at present. > A client with a configured trust anchor for the root zone may still be > in a circumstance where it can't get DNSSEC information for any zone, > for a reason that does not imply a security problem (e.g. an obsolete > recursive resolver that's dropping DNSSEC data on the floor). Then pick a different recursive server / complain to the operator of the recursive server. EDNS is 12 years old (1999). DO is 10 years old (2001). DNSSEC bis is 6 years old (2005). There really is no excuse to not pass DNSSEC records along in 2011. They don't have to validate, though it helps if they do. > > You only have to worry about the indeterminate case when you encounter an > > island for which you don't have a trust anchor -- in which case you > > couldn't validate anyway. > > Given that the root has now been signed, I'm not sure whether this case > can occur anymore - please clarify. > > zw > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From zack.weinberg@gmail.com Mon Oct 3 19:35: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 E0B5C21F8E9B for ; Mon, 3 Oct 2011 19:35:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.033 X-Spam-Level: X-Spam-Status: No, score=-3.033 tagged_above=-999 required=5 tests=[AWL=-0.056, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i1baFWLHwA35 for ; Mon, 3 Oct 2011 19:35:06 -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 49E4A21F8E9A for ; Mon, 3 Oct 2011 19:35:06 -0700 (PDT) Received: by gyd12 with SMTP id 12so38465gyd.31 for ; Mon, 03 Oct 2011 19:38:10 -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:content-type :content-transfer-encoding; bh=IE7XYUSg/c9Mfg77ElGqB8D+neoPRgSxoLFGGCYChsE=; b=keJQImnRAcxuT/CGiauJ4TWz54UM38ACev6a17nutvt5MwUsOTvGv8+ifNGzLlfS1F xlQSlinHjQrPrnfBG5G4iJ/u7KnYInp7AFXfxfSi6GrvzyfxMoYF2+uJV7tNWb6EJ8zQ qhC90kVReONkpPy4c7rh1aZP2koAcTa9Fbq/Y= MIME-Version: 1.0 Received: by 10.68.33.101 with SMTP id q5mr5620515pbi.121.1317695889559; Mon, 03 Oct 2011 19:38:09 -0700 (PDT) Sender: zack.weinberg@gmail.com Received: by 10.68.59.105 with HTTP; Mon, 3 Oct 2011 19:38:09 -0700 (PDT) In-Reply-To: <20111004005833.64C0014911E0@drugs.dv.isc.org> References: <4E856FB8.9000301@sidn.nl> <1317451765.2130.94.camel@localhost> <4E8A15C6.3000408@sv.cmu.edu> <20111003201605.GN53886@shinkuro.com> <4E8A196C.5060602@sv.cmu.edu> <20111004005833.64C0014911E0@drugs.dv.isc.org> Date: Mon, 3 Oct 2011 19:38:09 -0700 X-Google-Sender-Auth: 0MgPsvZc-ngCCA55hKh4TtRMzBQ Message-ID: From: Zack Weinberg To: IETF DANE WG list Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [dane] Fwd: #36: Only requiring DNSSEC where it is needed 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, 04 Oct 2011 02:35:07 -0000 On Mon, Oct 3, 2011 at 5:58 PM, Mark Andrews wrote: > In message <4E8A196C.5060602@sv.cmu.edu>, Zack Weinberg writes: >> =C2=A0 A client with a configured trust anchor for the root zone may sti= ll be >> in a circumstance where it can't get DNSSEC information for any zone, >> for a reason that does not imply a security problem (e.g. an obsolete >> recursive resolver that's dropping DNSSEC data on the floor). > > Then pick a different recursive server / complain to the operator > of the recursive server. =C2=A0EDNS is 12 years old (1999). =C2=A0DO is 1= 0 > years old (2001). =C2=A0DNSSEC bis is 6 years old (2005). There really > is no excuse to not pass DNSSEC records along in 2011. =C2=A0They don't > have to validate, though it helps if they do. The root was only signed last year (2010) and even now very few network clients actually look for and validate DNSSEC records -- so as much as I would *like* to agree with your position, I suspect it'll be another several years before it's realistic. zw From marka@isc.org Mon Oct 3 20:25: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 D52F321F8E68 for ; Mon, 3 Oct 2011 20:25:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.299 X-Spam-Level: X-Spam-Status: No, score=-0.299 tagged_above=-999 required=5 tests=[AWL=2.300, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WDR0UQX1QmCb for ; Mon, 3 Oct 2011 20:25:52 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 460AB21F8E62 for ; Mon, 3 Oct 2011 20:25:52 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id 515D45F98E6; Tue, 4 Oct 2011 03:28:42 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6233:4bff:fe01:7585]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 1572C216C36; Tue, 4 Oct 2011 03:28:40 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id A21501492790; Tue, 4 Oct 2011 14:28:36 +1100 (EST) To: Zack Weinberg From: Mark Andrews References: <4E856FB8.9000301@sidn.nl> <1317451765.2130.94.camel@localhost> <4E8A15C6.3000408@sv.cmu.edu> <20111003201605.GN53886@shinkuro.com> <4E8A196C.5060602@sv.cmu.edu> <20111004005833.64C0014911E0@drugs.dv.isc.org> In-reply-to: Your message of "Mon, 03 Oct 2011 19:38:09 PDT." Date: Tue, 04 Oct 2011 14:28:36 +1100 Message-Id: <20111004032836.A21501492790@drugs.dv.isc.org> Cc: IETF DANE WG list Subject: Re: [dane] Fwd: #36: Only requiring DNSSEC where it is needed 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, 04 Oct 2011 03:25:54 -0000 In message , Zack Weinberg writes: > On Mon, Oct 3, 2011 at 5:58 PM, Mark Andrews wrote: > > In message <4E8A196C.5060602@sv.cmu.edu>, Zack Weinberg writes: > >>   A client with a configured trust anchor for the root zone may still > be > >> in a circumstance where it can't get DNSSEC information for any zone, > >> for a reason that does not imply a security problem (e.g. an obsolete > >> recursive resolver that's dropping DNSSEC data on the floor). > > > > Then pick a different recursive server / complain to the operator > > of the recursive server.  EDNS is 12 years old (1999).  DO is 10 > > years old (2001).  DNSSEC bis is 6 years old (2005). There really > > is no excuse to not pass DNSSEC records along in 2011.  They don't > > have to validate, though it helps if they do. > > The root was only signed last year (2010) and even now very few > network clients actually look for and validate DNSSEC records -- so as > much as I would *like* to agree with your position, I suspect it'll be > another several years before it's realistic. While signing the root was a significant milestone it really as nothing to do with whether DNSSEC records will be passed on recursive servers. You need to look at when DNSSEC aware recursive servers shipped as they can pass on the records with or without trust anchors being configured. For BIND you need to look at BIND 9.3.0 (DNSSECbis Jan 2005) and BIND 9.6.0 (NSEC3 support Dec 2008). As far as BIND is concerned all supported versions support NSEC3 and DNSSECbis. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From zack.weinberg@gmail.com Mon Oct 3 21:03: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 6843D21F8E62 for ; Mon, 3 Oct 2011 21:03:20 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iYD7qE9go0nD for ; Mon, 3 Oct 2011 21:03:20 -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 DD7C921F8E11 for ; Mon, 3 Oct 2011 21:03:19 -0700 (PDT) Received: by iaby26 with SMTP id y26so133184iab.31 for ; Mon, 03 Oct 2011 21:06:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=G7e3XbiOmH7Z+m40ma9ElgVplgSmXY0NqQgwFtfso8c=; b=YO+mhXnP+QGtbzdi35JglSWW0RpEV4NExwlBXzr75rtJU4DX+lWvnCgr5Xd84CL2AA oPlnvFcKI3n0gPvxF9S3m3troRQfOMeGZcXI5rkZCLReMmhde3/7MxtFoxL7F4v0pKSH N20sVwtkh0mNM4JeMk8hhKQ15KGczEjGA8qeU= Received: by 10.42.108.8 with SMTP id f8mr1090957icp.169.1317701183759; Mon, 03 Oct 2011 21:06:23 -0700 (PDT) Received: from ardsley.local (99-113-32-219.lightspeed.sntcca.sbcglobal.net. [99.113.32.219]) by mx.google.com with ESMTPS id eh34sm31879709ibb.5.2011.10.03.21.06.22 (version=SSLv3 cipher=OTHER); Mon, 03 Oct 2011 21:06:22 -0700 (PDT) Sender: Zack Weinberg Message-ID: <4E8A863D.7030209@sv.cmu.edu> Date: Mon, 03 Oct 2011 21:06:21 -0700 From: Zack Weinberg User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: IETF DANE WG list References: <4E856FB8.9000301@sidn.nl> <1317451765.2130.94.camel@localhost> <4E8A15C6.3000408@sv.cmu.edu> <20111003201605.GN53886@shinkuro.com> <4E8A196C.5060602@sv.cmu.edu> <20111004005833.64C0014911E0@drugs.dv.isc.org> <20111004032836.A21501492790@drugs.dv.isc.org> In-Reply-To: <20111004032836.A21501492790@drugs.dv.isc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dane] Fwd: #36: Only requiring DNSSEC where it is needed 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, 04 Oct 2011 04:03:20 -0000 On 2011-10-03 8:28 PM, Mark Andrews wrote: > While signing the root was a significant milestone it really as > nothing to do with whether DNSSEC records will be passed on recursive > servers. You need to look at when DNSSEC aware recursive servers > shipped as they can pass on the records with or without trust anchors > being configured. > > For BIND you need to look at BIND 9.3.0 (DNSSECbis Jan 2005) and > BIND 9.6.0 (NSEC3 support Dec 2008). As far as BIND is concerned > all supported versions support NSEC3 and DNSSECbis. Until people start consuming DNSSEC data at the edge, nobody in the middle has any serious incentive to make sure it works; so I think your estimate of the state of the *installed base* of *everything that has to pass DNS traffic along* is over-optimistic. Nicholas Weaver had actual numbers which, as I recall, said it would be possible to start doing that consuming now, but *not* to treat DNSSEC outages as evidence of malicious tampering. zw From marka@isc.org Mon Oct 3 21:46: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 4D28821F8F4E for ; Mon, 3 Oct 2011 21:46:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.732 X-Spam-Level: X-Spam-Status: No, score=-1.732 tagged_above=-999 required=5 tests=[AWL=0.867, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zmg+31yzJXqK for ; Mon, 3 Oct 2011 21:46:12 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id ABF5421F8F4D for ; Mon, 3 Oct 2011 21:46:12 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id 126115F98EF; Tue, 4 Oct 2011 04:48:56 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6233:4bff:fe01:7585]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 4E1ED216C33; Tue, 4 Oct 2011 04:48:54 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id C04B81492CA3; Tue, 4 Oct 2011 15:48:51 +1100 (EST) To: Zack Weinberg From: Mark Andrews References: <4E856FB8.9000301@sidn.nl> <1317451765.2130.94.camel@localhost> <4E8A15C6.3000408@sv.cmu.edu> <20111003201605.GN53886@shinkuro.com> <4E8A196C.5060602@sv.cmu.edu> <20111004005833.64C0014911E0@drugs.dv.isc.org> <20111004032836.A21501492790@drugs.dv.isc.org> <4E8A863D.7030209@sv.cmu.edu> In-reply-to: Your message of "Mon, 03 Oct 2011 21:06:21 PDT." <4E8A863D.7030209@sv.cmu.edu> Date: Tue, 04 Oct 2011 15:48:51 +1100 Message-Id: <20111004044851.C04B81492CA3@drugs.dv.isc.org> Cc: IETF DANE WG list Subject: Re: [dane] Fwd: #36: Only requiring DNSSEC where it is needed 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, 04 Oct 2011 04:46:13 -0000 In message <4E8A863D.7030209@sv.cmu.edu>, Zack Weinberg writes: > On 2011-10-03 8:28 PM, Mark Andrews wrote: > > While signing the root was a significant milestone it really as > > nothing to do with whether DNSSEC records will be passed on recursive > > servers. You need to look at when DNSSEC aware recursive servers > > shipped as they can pass on the records with or without trust anchors > > being configured. > > > > For BIND you need to look at BIND 9.3.0 (DNSSECbis Jan 2005) and > > BIND 9.6.0 (NSEC3 support Dec 2008). As far as BIND is concerned > > all supported versions support NSEC3 and DNSSECbis. > > Until people start consuming DNSSEC data at the edge, nobody in the > middle has any serious incentive to make sure it works; so I think > your estimate of the state of the *installed base* of *everything that > has to pass DNS traffic along* is over-optimistic. In most cases there are only two middle boxes to worry about. The ISP's resolver and the CPE device. The resolver, if it is DNSSEC aware, is already dealing with any upstream issues. That leaves CPE devices which should be field updatable in most cases. > Nicholas Weaver had actual numbers which, as I recall, said it would be > possible to start doing that consuming now, but *not* to treat DNSSEC > outages as evidence of malicious tampering. > > zw > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From matt@mattmccutchen.net Mon Oct 3 21:50: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 BEE9A21F8F16 for ; Mon, 3 Oct 2011 21:50:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.483 X-Spam-Level: X-Spam-Status: No, score=-2.483 tagged_above=-999 required=5 tests=[AWL=-0.184, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y+lug57yqdfy for ; Mon, 3 Oct 2011 21:50:05 -0700 (PDT) Received: from homiemail-a60.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id 90EA421F8F15 for ; Mon, 3 Oct 2011 21:50:05 -0700 (PDT) Received: from homiemail-a60.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a60.g.dreamhost.com (Postfix) with ESMTP id AD4563BC065; Mon, 3 Oct 2011 21:53:09 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:date:in-reply-to:references:content-type:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=WYGb/hLjnqFtC9w79G/rQX9+469lwLSBzAYJQq8y81W viMX9nySeTjs7M5NWCdkGfyQbYYCq/e+/yZWMaXZhNTXMyNUoaMzFMyEOIgjUHB7 LbYACxL9QTHbiQuXrgTST/Ygst2sRKlPZTVrKbbWZlTYdWhYp6kXIrcKwKXjPILw = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:date:in-reply-to:references:content-type :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=RH8SjQwslFgcRS2YgZZYiZwVkoU=; b=Tu7Hj2plIF F/zs+vMzWjLyqQyNSWJzoNW37bu/0zf/LO6XpbbEv4G1E8qlf4bXQMm9K1CqpMsy a5sytbUcDb5SaTDMSjJ808BIKYJpZnfcT3mM5s7uq8GSYfVDxKw0haAXdGLLvHU8 EomA8We8Ux3iCTmOm1PRGt8dnOIQvFIgs= Received: from [IPv6:::1] (c-98-248-34-40.hsd1.ca.comcast.net [98.248.34.40]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a60.g.dreamhost.com (Postfix) with ESMTPSA id 7F29A3BC062; Mon, 3 Oct 2011 21:53:09 -0700 (PDT) From: Matt McCutchen To: =?UTF-8?Q?Ond=C5=99ej_Sur=C3=BD?= Date: Mon, 03 Oct 2011 21:53:08 -0700 In-Reply-To: <6BE1DA4F-2684-4923-A0E1-833BEE0F3295@nic.cz> References: <1E08D85E-3E17-4E30-BF21-6C37E8CE3052@kumari.net> <000401cc7423$bf343990$3d9cacb0$@augustcellars.com> <881C47F4-FDE0-43DC-BF7E-D85729D057AE@kumari.net> <6BE1DA4F-2684-4923-A0E1-833BEE0F3295@nic.cz> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3 Message-ID: <1317703989.3944.8.camel@localhost> Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Cc: DANE WG Subject: Re: [dane] Opening issues #25, #26, #27 as a group (last call) 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, 04 Oct 2011 04:50:06 -0000 On Mon, 2011-10-03 at 17:29 +0200, Ond=C5=99ej Sur=C3=BD wrote: > On 21. 9. 2011, at 18:07, Warren Kumari wrote: >=20 > > It appears to the chairs that issues #25, #26, #27 are all variations= on a theme and are all predicated on DANE doing [ conjunctive / disjunc= tive / grouping / sets ] -- see issue #32, Matt's proposed schema ( https= ://www.ietf.org/mail-archive/web/dane/current/msg02637.html ), etc. > >=20 > > We believe that this was viewed by the WG as cool and sexy, but addin= g too much additional complexity to the protocol (see the thread around: = http://www.ietf.org/mail-archive/web/dane/current/msg03351.html ). > >=20 > > Unless we hear that the WG would like to reconsider this, we are plan= ning on calling these issues closed. >=20 >=20 > Since we haven't heard from the WG to reconsider and we have heard more= voices to keep it simple and close the issues, we are going to close the= se three issues now. Are you sure that those voices applied to all three issues? Warren originally framed the discussion under the misconception that the three issues together duplicated #32, but only #27 is a duplicate of #32 (https://www.ietf.org/mail-archive/web/dane/current/msg03439.html). I do not object to closing #27. As for the other issues, we have Phill's +1 to address #25, and #26 is a policy question that hardly affects the complexity of the protocol. --=20 Matt From matt@mattmccutchen.net Mon Oct 3 22:39: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 727D421F8BA8 for ; Mon, 3 Oct 2011 22:39:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.628 X-Spam-Level: X-Spam-Status: No, score=-2.628 tagged_above=-999 required=5 tests=[AWL=-0.029, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CPXm52OyuWYU for ; Mon, 3 Oct 2011 22:39:40 -0700 (PDT) Received: from homiemail-a7.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id B16B121F8B94 for ; Mon, 3 Oct 2011 22:39:40 -0700 (PDT) Received: from homiemail-a7.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a7.g.dreamhost.com (Postfix) with ESMTP id EF2DF25C063; Mon, 3 Oct 2011 22:42: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=L14ZtAZYhnyJ+pCpco5Wt0tVEIBgfhGzAltXiwNUEOb HQh6I3yvurVwGTdayjVXZLKxqk68wYf6dZeLliLRwUFLSuG6IQG45Wcx71VqwAiS bQEKdBFK1yTaj/kAFnEG5uq7lwUp11oA6i6w3wxkfwRyz/tc7Ue3tQ/XFUYluA3c = 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=rkHBzisld+U8M77bLUX102OUNQ8=; b=kmXMZvUw5d QzU5Msa6cITKROa5iJy/HISpGwt7TMlTkjMXYzftS+cF5TS7/YBJcHTR37hqu0n7 JvmhNrs5RMdGJM7kPy5K/YeYb6nolpYJygwcg3Wo5uGzAONmMvSwazMGb6xHgsdz sXR5fmPUPUmMuhT5oJgN4DOhVayvSlTr0= Received: from [IPv6:::1] (c-98-248-34-40.hsd1.ca.comcast.net [98.248.34.40]) (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 C6A0925C062; Mon, 3 Oct 2011 22:42:44 -0700 (PDT) From: Matt McCutchen To: Zack Weinberg In-Reply-To: <4E8A15C6.3000408@sv.cmu.edu> References: <201109272223.p8RMNPpA026467@fs4113.wdf.sap.corp> <4E856FB8.9000301@sidn.nl> <1317451765.2130.94.camel@localhost> <4E8A15C6.3000408@sv.cmu.edu> Content-Type: text/plain; charset="UTF-8" Date: Mon, 03 Oct 2011 22:42:37 -0700 Message-ID: <1317706957.3944.34.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 3.0.3 Content-Transfer-Encoding: 7bit Cc: IETF DANE WG list Subject: Re: [dane] Fwd: #36: Only requiring DNSSEC where it is needed 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, 04 Oct 2011 05:39:41 -0000 On Mon, 2011-10-03 at 13:06 -0700, Zack Weinberg wrote: > On 2011-09-30 11:49 PM, Matt McCutchen wrote: > > You and Paul are arguing past each other. Paul is assuming a validating > > resolver that doesn't even give you a response unless it is "secure" or > > "verified insecure"; in that case, you're already protected from > > tampering with signed TLSA records. > > Ah, but no! The attacker needs to be a little more sophisticated in this > case, but it's still doable. They leave DNSSEC intact for the A record, > block the TLSA response entirely, [...] > Basically, the only time it is safe for a DANE client to downgrade to > legacy PKIX behavior on a signed zone is if it *actually receives* a > valid NSEC(n) response for the TLSA record query. Yes, yes, I meant to say that the server authentication code fails closed unless it gets a response from the resolver, which in turn does not return a response unless it is "secure" or "verified insecure". Clearly, if one wants the security of DNSSEC, one has to... fully enforce DNSSEC. These distinctions are all beside the point of the thread. > The details of "doesn't even give you a response" matter here, of course > - maybe this can be made secure with a resolver library that behaves as > you describe, if its error codes are sufficiently detailed. But it > still requires the application to consider DNSSEC state ahead of > processing any TLSA records that are received. No, if the resolver library exposes "failed to get a secure or verified insecure response" as an error code in the same right as "network is unreachable", since the outcome needs to be "fail closed" either way (a momentary network blip should not compromise the security any more than MITM tampering), the code would likely just check for an error and not specifically for DNSSEC state. > And therefore it is > *operationally* simpler to process DNSSEC state once and for all before > even looking at the TLSA records. As above, it depends on the library, though you are probably right for many clients. > I want to repeat that my concern here is strictly implementational. I > agree that > > > If you get verified-insecure > > records of usage 0 or 1, you do not gain or lose any *security* by > > processing them > > (emphasis mine) but I think that "MUST ignore all verified-insecure TLSA > records, regardless of their contents" is sufficiently more likely to be > *implemented correctly* that it is worthwhile, even though it sacrifices > a use case on the server end (deploying DANE restrictions without being > ready to do DNSSEC yet). This is just speculation against speculation. I am personally -0.5 to putting a MUST that is not in fact a requirement of the security model. -- Matt From matt@mattmccutchen.net Mon Oct 3 22:52: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 54F1821F8D57 for ; Mon, 3 Oct 2011 22:52:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.627 X-Spam-Level: X-Spam-Status: No, score=-2.627 tagged_above=-999 required=5 tests=[AWL=-0.028, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xDBsFnJfbLue for ; Mon, 3 Oct 2011 22:52:42 -0700 (PDT) Received: from homiemail-a37.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id D8AAF21F8D4C for ; Mon, 3 Oct 2011 22:52:42 -0700 (PDT) Received: from homiemail-a37.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a37.g.dreamhost.com (Postfix) with ESMTP id BBC1B20806D; Mon, 3 Oct 2011 22:55:45 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:date:in-reply-to:references:content-type :content-transfer-encoding:message-id:mime-version; q=dns; s= mattmccutchen.net; b=lQVS/n5hcJVSMUupz5TuzLaQj31v7aPY5Q1zyhC9+Vo VJWhpZDmM7d3yIH9penfy8psPhXbI9FIoGN6Fe3PIBnND3HcEkezGsT9NTYnstfX 0iBdNPAYEMj0sQBLVwSupHH+byuqKM7ISAOCdbPVg/BM7BlQGdCZybeVrt+0Aotw = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:date:in-reply-to:references:content-type :content-transfer-encoding:message-id:mime-version; s= mattmccutchen.net; bh=REgxIeakkEPoFgmEToHn9Vl0vHc=; b=BZCNcCqcPj uXPVycsXvWsM8Wui7r6dy+fsCO0kdFhJHfYDNXDH84Ca6jVpk/Su9lc+3LFDoCzW gyAQz9zoK+VBXwZct6UDUmVouHGeq0ySkXa2xUHtjxkzFMM9ATkfov/EWllpYdjo Tm1+FFnHlW5f/sCPdbK+KOxZ3+zGMeKpE= Received: from [IPv6:::1] (c-98-248-34-40.hsd1.ca.comcast.net [98.248.34.40]) (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 7F55F20806B; Mon, 3 Oct 2011 22:55:45 -0700 (PDT) From: Matt McCutchen To: Zack Weinberg Date: Mon, 03 Oct 2011 22:55:44 -0700 In-Reply-To: <4E8A15C6.3000408@sv.cmu.edu> References: <201109272223.p8RMNPpA026467@fs4113.wdf.sap.corp> <4E856FB8.9000301@sidn.nl> <1317451765.2130.94.camel@localhost> <4E8A15C6.3000408@sv.cmu.edu> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3 Content-Transfer-Encoding: 7bit Message-ID: <1317707745.3944.45.camel@localhost> Mime-Version: 1.0 Cc: IETF DANE WG list Subject: Re: [dane] Fwd: #36: Only requiring DNSSEC where it is needed 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, 04 Oct 2011 05:52:43 -0000 On Mon, 2011-10-03 at 13:06 -0700, Zack Weinberg wrote: > On 2011-09-30 11:49 PM, Matt McCutchen wrote: > >> A DANE client that ignores DNSSEC validation under any circumstances > >> -- note that in this scenario, it doesn't get any TLSA records back at > >> all! -- will not defend against this attack; but a client that treats > >> DNSSEC "bogus" or "stripped" states as a hard failure, regardless of > >> TLSA contents, will defend. > > > > To simplify matters a bit, note that RFC 4033 "bogus" includes what you > > are calling "stripped". > > Thanks for the correction. I think I was trying to remember the RFC > 4033 distinction between "insecure" (parent zone signed, child zone > attestably unsigned) and "indeterminate" (no trust anchor at all). At > some point clients will have to start treating "indeterminate" as a hard > fail to prevent a network MITM from downgrading them by completely > stripping DNSSEC, I think Andrew tried to clarify this, but I will try again: The occurrence of the "indeterminate" state is purely a function of your configuration. If you have a trust anchor for "." and the MITM completely strips DNSSEC, that is bogus, /not/ indeterminate. The above is the DNSSEC model. One can conceive of various bodges to work on existing networks, but since most of them would completely give away the security in a theoretical sense, I don't find it very useful to discuss the security of DANE in the presence of such bodges. It's more sensible to build DANE cleanly on the DNSSEC model and simply let the bodger beware. -- Matt From ahu@xs.powerdns.com Mon Oct 3 23:24: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 50AF621F8D61 for ; Mon, 3 Oct 2011 23:24:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.227 X-Spam-Level: X-Spam-Status: No, score=-2.227 tagged_above=-999 required=5 tests=[AWL=0.373, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J6BFEcdK3u2D for ; Mon, 3 Oct 2011 23:24:36 -0700 (PDT) Received: from xs.powerdns.com (xs.powerdns.com [IPv6:2001:888:2000:1d::2]) by ietfa.amsl.com (Postfix) with ESMTP id A73E921F8D5C for ; Mon, 3 Oct 2011 23:24:36 -0700 (PDT) Received: from ahu by xs.powerdns.com with local (Exim 4.71) (envelope-from ) id 1RAyTZ-0005Cc-BO; Tue, 04 Oct 2011 08:27:37 +0200 Date: Tue, 4 Oct 2011 08:27:37 +0200 From: bert hubert To: Zack Weinberg Message-ID: <20111004062737.GA23425@xs.powerdns.com> References: <060.8aca11012e6c9583642ba071c54be972@trac.tools.ietf.org> <075.e771c9a4f93afa495f330ae9d1ebfa5a@trac.tools.ietf.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: dane@ietf.org Subject: [dane] how about not talking about DNSSEC Re: #36: Only requiring DNSSEC where it is needed 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, 04 Oct 2011 06:24:37 -0000 On Thu, Sep 29, 2011 at 09:56:11AM -0700, Zack Weinberg wrote: > >  A related issue is whether clients MUST (1) attempt a DNSSEC query, (2) > >  fail the handshake unless the query completes with "secure" or "verified > >  insecure" state, and (3) if a "secure" nonempty TLSA RRset is returned, > >  process it as described in the spec.  This requirement goes hand in hand > >  with the current statement that clients MUST fail the handshake if the > >  server cert does not match any TLSA RR; one is not meaningful without the > >  other.  So I think we should make both or neither of these behaviors > >  conformance requirements (c.f. ticket:26). > > Agree entirely (and I vote for "both"). Might want some wiggle room > in the wording to allow for Adam's DANE-stapling scheme instead of > client doing its own DNSSEC processing. Hi everybody, DANE is great stuff, and it specifies how you could trust certificates. The DANE material is in turn protected by DNSSEC, so you could trust the DANE material. I see zero reason to burden the DANE standard with details how how DNSSEC SHOULD or MUST be used. This can only hurt us in the long run, say, if DNSSEC standard or practice changes. Especially the latter. Any hopes that implementors might not do the right thing unless they "MUST" do now weigh up to the downsides mentioned above. So how about we say as little as possible on DNSSEC? Bert From lutz@iks-jena.de Mon Oct 3 23:40: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 076A521F8D17 for ; Mon, 3 Oct 2011 23:40:21 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oVgbKAKucS1g for ; Mon, 3 Oct 2011 23:40:20 -0700 (PDT) Received: from annwfn.iks-jena.de (annwfn-eth.iks-jena.de [IPv6:2001:4bd8:0:104:20a:e4ff:fe80:3138]) by ietfa.amsl.com (Postfix) with ESMTP id 2ED6921F8D70 for ; Mon, 3 Oct 2011 23:40:19 -0700 (PDT) X-SMTP-Sender: IPv6:2001:4bd8:0:666:248:54ff:fe12:ee3f Received: from belenus.iks-jena.de (belenus.iks-jena.de [IPv6:2001:4bd8:0:666:248:54ff:fe12:ee3f]) by annwfn.iks-jena.de (8.14.3/8.14.1) with ESMTP id p946hI23004326; Tue, 4 Oct 2011 08:43:21 +0200 X-MSA-Host: belenus.iks-jena.de Received: (from lutz@localhost) by belenus.iks-jena.de (8.14.3/8.14.1/Submit) id p946hGPn002374; Tue, 4 Oct 2011 08:43:16 +0200 Date: Tue, 4 Oct 2011 08:43:16 +0200 From: Lutz Donnerhacke To: dane@ietf.org Message-ID: <20111004064316.GB2275@belenus.iks-jena.de> References: <060.8aca11012e6c9583642ba071c54be972@trac.tools.ietf.org> <075.e771c9a4f93afa495f330ae9d1ebfa5a@trac.tools.ietf.org> <20111004062737.GA23425@xs.powerdns.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111004062737.GA23425@xs.powerdns.com> X-message-flag: Please send plain text messages only. Thank you. User-Agent: Mutt/1.5.17 (2007-11-01) Cc: dane@ietf.org Subject: Re: [dane] how about not talking about DNSSEC Re: #36: Only requiring DNSSEC where it is needed 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, 04 Oct 2011 06:40:21 -0000 On Tue, Oct 04, 2011 at 08:27:37AM +0200, bert hubert wrote: > DANE is great stuff, and it specifies how you could trust certificates. > > The DANE material is in turn protected by DNSSEC, so you could trust the > DANE material. > > I see zero reason to burden the DANE standard with details how how DNSSEC > SHOULD or MUST be used. I agree. From hallam@gmail.com Tue Oct 4 05:45: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 55A0821F886A for ; Tue, 4 Oct 2011 05:45:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.49 X-Spam-Level: X-Spam-Status: No, score=-3.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ylFScPpkAAhH for ; Tue, 4 Oct 2011 05:45:40 -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 9B10F21F8801 for ; Tue, 4 Oct 2011 05:45:40 -0700 (PDT) Received: by ywm3 with SMTP id 3so537663ywm.31 for ; Tue, 04 Oct 2011 05:48:45 -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:content-transfer-encoding; bh=l7I/0D9DiGv36LnJT147IvxmtrZ5x7aeGIlSzhymjyg=; b=l0hUuFbQulpPtxEkNytfNabK3f8Wb3ON6Lr0wGgQD3LdL/8WGl31VU1lGP2yw3r6+T FXzKbvzHCWNqDN4/ldW43CgKUHynIC+lbSuO9dTjb+sAP3hGOElaGXtGhNAtAqaR4X6o 9Ry8Z34Ic3IOYR9n5gBKXOt1QErDZ0SVXePRQ= MIME-Version: 1.0 Received: by 10.101.27.34 with SMTP id e34mr925422anj.162.1317732525351; Tue, 04 Oct 2011 05:48:45 -0700 (PDT) Received: by 10.100.212.14 with HTTP; Tue, 4 Oct 2011 05:48:45 -0700 (PDT) In-Reply-To: <20111004062737.GA23425@xs.powerdns.com> References: <060.8aca11012e6c9583642ba071c54be972@trac.tools.ietf.org> <075.e771c9a4f93afa495f330ae9d1ebfa5a@trac.tools.ietf.org> <20111004062737.GA23425@xs.powerdns.com> Date: Tue, 4 Oct 2011 08:48:45 -0400 Message-ID: From: Phillip Hallam-Baker To: bert hubert Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dane@ietf.org Subject: Re: [dane] how about not talking about DNSSEC Re: #36: Only requiring DNSSEC where it is needed 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, 04 Oct 2011 12:45:41 -0000 On Tue, Oct 4, 2011 at 2:27 AM, bert hubert wro= te: > On Thu, Sep 29, 2011 at 09:56:11AM -0700, Zack Weinberg wrote: >> > =A0A related issue is whether clients MUST (1) attempt a DNSSEC query,= (2) >> > =A0fail the handshake unless the query completes with "secure" or "ver= ified >> > =A0insecure" state, and (3) if a "secure" nonempty TLSA RRset is retur= ned, >> > =A0process it as described in the spec. =A0This requirement goes hand = in hand >> > =A0with the current statement that clients MUST fail the handshake if = the >> > =A0server cert does not match any TLSA RR; one is not meaningful witho= ut the >> > =A0other. =A0So I think we should make both or neither of these behavi= ors >> > =A0conformance requirements (c.f. ticket:26). >> >> Agree entirely (and I vote for "both"). =A0Might want some wiggle room >> in the wording to allow for Adam's DANE-stapling scheme instead of >> client doing its own DNSSEC processing. > > Hi everybody, > > DANE is great stuff, and it specifies how you could trust certificates. > > The DANE material is in turn protected by DNSSEC, so you could trust the > DANE material. > > I see zero reason to burden the DANE standard with details how how DNSSEC > SHOULD or MUST be used. > > This can only hurt us in the long run, say, if DNSSEC standard or practic= e > changes. Especially the latter. > > Any hopes that implementors might not do the right thing unless they "MUS= T" > do now weigh up to the downsides mentioned above. > > So how about we say as little as possible on DNSSEC? I totally agree. I don't think DNSSEC out to the end point client is even desirable. It might be for a Web browser, it is certainly not desirable for embedded devices. Since only about 10% of the computers in my house are desktop or laptop devices and the proportion is dropping sharply, I don't see a good case to nail DANE to one DNS security approach. If any new protocol is going to get early adopters it is always in areas that are currently unserved or underserved. Web Services and embedded devices are the areas that will be relevant. --=20 Website: http://hallambaker.com/ From nweaver@icsi.berkeley.edu Tue Oct 4 05:53: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 AE28921F8C57 for ; Tue, 4 Oct 2011 05:53:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.519 X-Spam-Level: X-Spam-Status: No, score=-2.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y8-OwpXf2hp0 for ; Tue, 4 Oct 2011 05:53:51 -0700 (PDT) Received: from rock.ICSI.Berkeley.EDU (rock.ICSI.Berkeley.EDU [192.150.186.19]) by ietfa.amsl.com (Postfix) with ESMTP id 3705721F8C49 for ; Tue, 4 Oct 2011 05:53:51 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 80EB82C4026; Tue, 4 Oct 2011 05:56:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at ICSI.Berkeley.EDU Received: from rock.ICSI.Berkeley.EDU ([127.0.0.1]) by localhost (maihub.ICSI.Berkeley.EDU [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 6XeT-mMjJjIB; Tue, 4 Oct 2011 05:56:56 -0700 (PDT) Received: from [10.0.1.2] (c-76-103-166-40.hsd1.ca.comcast.net [76.103.166.40]) (Authenticated sender: nweaver) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 204B92C401E; Tue, 4 Oct 2011 05:56:56 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=iso-8859-1 From: Nicholas Weaver In-Reply-To: Date: Tue, 4 Oct 2011 05:57:08 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7B75D74E-F0E2-4E83-96CC-25B53E05F896@icsi.berkeley.edu> References: <060.8aca11012e6c9583642ba071c54be972@trac.tools.ietf.org> <075.e771c9a4f93afa495f330ae9d1ebfa5a@trac.tools.ietf.org> <20111004062737.GA23425@xs.powerdns.com> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1244.3) Cc: dane@ietf.org Subject: Re: [dane] how about not talking about DNSSEC Re: #36: Only requiring DNSSEC where it is needed 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, 04 Oct 2011 12:53:51 -0000 On Oct 4, 2011, at 5:48 AM, Phillip Hallam-Baker wrote: > I totally agree. >=20 > I don't think DNSSEC out to the end point client is even desirable. It > might be for a Web browser, it is certainly not desirable for embedded > devices. Since only about 10% of the computers in my house are desktop > or laptop devices and the proportion is dropping sharply, I don't see > a good case to nail DANE to one DNS security approach. I disagree, STRONGLY here. =20 The recursive resolver is a failure from a security standpoint: unless = the owner of the end system also owns the recursive resolver, the = resolver itself must not be trusted. Beyond OpenDNS tricks and NXDOMAIN wildcarding, we STILL have major = ISPs who are using the recursive resolver to man-in-the-middle intercept = Yahoo and Bing (and Google until Google puts a stop to it with Captchas = and/or legal threats). From hallam@gmail.com Tue Oct 4 05:55: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 53C6D21F8C57 for ; Tue, 4 Oct 2011 05:55:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.491 X-Spam-Level: X-Spam-Status: No, score=-3.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X8EpUHvwXJdF for ; Tue, 4 Oct 2011 05:55:47 -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 851C321F8C49 for ; Tue, 4 Oct 2011 05:55:47 -0700 (PDT) Received: by ggnk3 with SMTP id k3so230494ggn.31 for ; Tue, 04 Oct 2011 05:58: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:content-transfer-encoding; bh=G4gB9cAe16B7UBB93iKF6MGGuSgfjQcIwrTGolJB4EM=; b=blcNXlSTqdpfYRB/J4mCiwQk2g0DaA/91MM3gg48mn8VYazjvGiwft1uMrffWEgngs BjSA7/W7Qd8055ksXtzniSoD636ThvICZ9mzsOJUc7eISeWG9OCf+BOOn210rpQbWH7H cSMS/I4r/U+kMnvLHLUgOeNZfnKxJKC40NyQw= MIME-Version: 1.0 Received: by 10.100.82.6 with SMTP id f6mr966274anb.52.1317733132012; Tue, 04 Oct 2011 05:58:52 -0700 (PDT) Received: by 10.100.212.14 with HTTP; Tue, 4 Oct 2011 05:58:51 -0700 (PDT) In-Reply-To: <1317707745.3944.45.camel@localhost> References: <201109272223.p8RMNPpA026467@fs4113.wdf.sap.corp> <4E856FB8.9000301@sidn.nl> <1317451765.2130.94.camel@localhost> <4E8A15C6.3000408@sv.cmu.edu> <1317707745.3944.45.camel@localhost> Date: Tue, 4 Oct 2011 08:58:51 -0400 Message-ID: From: Phillip Hallam-Baker To: Matt McCutchen Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IETF DANE WG list Subject: Re: [dane] Fwd: #36: Only requiring DNSSEC where it is needed 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, 04 Oct 2011 12:55:48 -0000 DNSSEC deployment can and will be blocked by a government level adversary. Since that is what we are facing here it seems pointless to tie the spec to one platform we know the adversary can and will mount a denial attack on. Russia is not pushing GOST because they care about obscure crypto algorithms. They are pushing GOST because back in the 17th century the Tzar murdered the aristocracy and enslaved the peasants and the place has been an authoritarian sink-hole ever since. It is about control. That does not mean that DNSSEC is useless, it just means that the role of DNSSEC is going to be limited to authenticating exchange of information in the free world where use is permitted. But that is OK because we have other techniques, tools and protocols for crossing the digital curtain. Adam's proposal to put the chain in the cert is the way to do key distribution on the basis of the DNSSEC hierarchy. Well, modulo the fact that it works much better with legacy browsers if the token can be put into an OCSP token. On Tue, Oct 4, 2011 at 1:55 AM, Matt McCutchen wro= te: > On Mon, 2011-10-03 at 13:06 -0700, Zack Weinberg wrote: >> On 2011-09-30 11:49 PM, Matt McCutchen wrote: >> >> A DANE client that ignores DNSSEC validation under any circumstances >> >> -- note that in this scenario, it doesn't get any TLSA records back a= t >> >> all! -- will not defend against this attack; but a client that treats >> >> DNSSEC "bogus" or "stripped" states as a hard failure, regardless of >> >> TLSA contents, will defend. >> > >> > To simplify matters a bit, note that RFC 4033 "bogus" includes what yo= u >> > are calling "stripped". >> >> Thanks for the correction. =A0I think I was trying to remember the RFC >> 4033 distinction between "insecure" (parent zone signed, child zone >> attestably unsigned) and "indeterminate" (no trust anchor at all). =A0At >> some point clients will have to start treating "indeterminate" as a hard >> fail to prevent a network MITM from downgrading them by completely >> stripping DNSSEC, > > I think Andrew tried to clarify this, but I will try again: > > The occurrence of the "indeterminate" state is purely a function of your > configuration. =A0If you have a trust anchor for "." and the MITM > completely strips DNSSEC, that is bogus, /not/ indeterminate. > > The above is the DNSSEC model. =A0One can conceive of various bodges to > work on existing networks, but since most of them would completely give > away the security in a theoretical sense, I don't find it very useful to > discuss the security of DANE in the presence of such bodges. =A0It's more > sensible to build DANE cleanly on the DNSSEC model and simply let the > bodger beware. > > -- > Matt > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > --=20 Website: http://hallambaker.com/ From hallam@gmail.com Tue Oct 4 05:59: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 1C00221F8C8C for ; Tue, 4 Oct 2011 05:59:23 -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.107, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DDn1QrDwjarj for ; Tue, 4 Oct 2011 05:59:22 -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 4B41421F8C79 for ; Tue, 4 Oct 2011 05:59:22 -0700 (PDT) Received: by gyd12 with SMTP id 12so552824gyd.31 for ; Tue, 04 Oct 2011 06:02: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:content-transfer-encoding; bh=GIjmuvz4eMtlpZsuAAVk2599xYxLxX89bBGbbsEtwms=; b=LGDPjLg+E2+EsQ7qymvupuktyv4gnNGH1GLBJy+NDxLed/ptr7vqKTtNwId5t/pJDt sOptxXFVCLfGeEeR6oG4+/vUErSwZ5wncN75r5S32G7vE8Jc0pUemJ/nHsWgAxtLDVWk LjKuN2QFRKSzKKK2h+1X+GFr/Fmhkax1xkYtM= MIME-Version: 1.0 Received: by 10.101.154.22 with SMTP id g22mr950412ano.96.1317733347153; Tue, 04 Oct 2011 06:02:27 -0700 (PDT) Received: by 10.100.212.14 with HTTP; Tue, 4 Oct 2011 06:02:27 -0700 (PDT) In-Reply-To: <20111004044851.C04B81492CA3@drugs.dv.isc.org> References: <4E856FB8.9000301@sidn.nl> <1317451765.2130.94.camel@localhost> <4E8A15C6.3000408@sv.cmu.edu> <20111003201605.GN53886@shinkuro.com> <4E8A196C.5060602@sv.cmu.edu> <20111004005833.64C0014911E0@drugs.dv.isc.org> <20111004032836.A21501492790@drugs.dv.isc.org> <4E8A863D.7030209@sv.cmu.edu> <20111004044851.C04B81492CA3@drugs.dv.isc.org> Date: Tue, 4 Oct 2011 09:02:27 -0400 Message-ID: From: Phillip Hallam-Baker To: Mark Andrews Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IETF DANE WG list Subject: Re: [dane] Fwd: #36: Only requiring DNSSEC where it is needed 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, 04 Oct 2011 12:59:23 -0000 If an enterprise is using DNSSEC to secure its internal network, the root of trust for the devices in that network SHOULD and MUST flow from a key that is controlled by the enterprise and not by ICANN. That is a very basic principle of security that is understood by pretty much anyone who is likely to be a DNSSEC early adopter. nsa.gov is not going to chain from the ICANN root. In fact the intra-governmental squabbling in the US federal govt, was so great that we could not even get them all to agree on one root for the federal govt. Hence the invention of the bridge CA. On Tue, Oct 4, 2011 at 12:48 AM, Mark Andrews wrote: > > In message <4E8A863D.7030209@sv.cmu.edu>, Zack Weinberg writes: >> On 2011-10-03 8:28 PM, Mark Andrews wrote: >> > While signing the root was a significant milestone it really as > > no= thing to do with whether DNSSEC records will be passed on recursive >> > servers. =A0You need to look at when DNSSEC aware recursive servers >> > shipped as they can pass on the records with or without trust anchors >> > being configured. >> > >> > For BIND you need to look at BIND 9.3.0 (DNSSECbis Jan 2005) and >> > BIND 9.6.0 (NSEC3 support Dec 2008). =A0As far as BIND is concerned >> > all supported versions support NSEC3 and DNSSECbis. >> >> Until people start consuming DNSSEC data at the edge, nobody in the >> middle has any serious incentive to make sure it works; so I think >> your estimate of the state of the *installed base* of *everything that >> has to pass DNS traffic along* is over-optimistic. > > In most cases there are only two middle boxes to worry about. =A0The > ISP's resolver and the CPE device. =A0The resolver, if it is DNSSEC > aware, is already dealing with any upstream issues. =A0That leaves > CPE devices which should be field updatable in most cases. > >> Nicholas Weaver had actual numbers which, as I recall, said it would be >> possible to start doing that consuming now, but *not* to treat DNSSEC >> outages as evidence of malicious tampering. >> >> zw >> _______________________________________________ >> dane mailing list >> dane@ietf.org >> https://www.ietf.org/mailman/listinfo/dane > -- > 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@is= c.org > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > --=20 Website: http://hallambaker.com/ From hallam@gmail.com Tue Oct 4 06:07: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 72B8921F8B9E for ; Tue, 4 Oct 2011 06:07:23 -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.107, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4huyIzuetQZr for ; Tue, 4 Oct 2011 06:07:22 -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 A5AFC21F8B36 for ; Tue, 4 Oct 2011 06:07:22 -0700 (PDT) Received: by ywm3 with SMTP id 3so561081ywm.31 for ; Tue, 04 Oct 2011 06:10: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:content-transfer-encoding; bh=QqwU6AiUCWWUSpJwhiS2Y2czwHzuDH9o9GsE3eF353o=; b=aaXHcOadCU6Aj8As7qUi3rWoGJNswoQ+dNLQJagrbv5427WEWQIOvCtVwb4R7eizOl BE8hTozqap66dMItn5tjmMt9xK5w2G+M0rAMppTda4Nnodr/0rwPy/sc/Z/8hX/292Ux lWTUP3pPFB0j+geX9E65SRCZwUykd0wIyKJA4= MIME-Version: 1.0 Received: by 10.101.27.34 with SMTP id e34mr948489anj.162.1317733827217; Tue, 04 Oct 2011 06:10:27 -0700 (PDT) Received: by 10.100.212.14 with HTTP; Tue, 4 Oct 2011 06:10:27 -0700 (PDT) In-Reply-To: <7B75D74E-F0E2-4E83-96CC-25B53E05F896@icsi.berkeley.edu> References: <060.8aca11012e6c9583642ba071c54be972@trac.tools.ietf.org> <075.e771c9a4f93afa495f330ae9d1ebfa5a@trac.tools.ietf.org> <20111004062737.GA23425@xs.powerdns.com> <7B75D74E-F0E2-4E83-96CC-25B53E05F896@icsi.berkeley.edu> Date: Tue, 4 Oct 2011 09:10:27 -0400 Message-ID: From: Phillip Hallam-Baker To: Nicholas Weaver Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dane@ietf.org Subject: Re: [dane] how about not talking about DNSSEC Re: #36: Only requiring DNSSEC where it is needed 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, 04 Oct 2011 13:07:23 -0000 On Tue, Oct 4, 2011 at 8:57 AM, Nicholas Weaver wrote: > > On Oct 4, 2011, at 5:48 AM, Phillip Hallam-Baker wrote: >> I totally agree. >> >> I don't think DNSSEC out to the end point client is even desirable. It >> might be for a Web browser, it is certainly not desirable for embedded >> devices. Since only about 10% of the computers in my house are desktop >> or laptop devices and the proportion is dropping sharply, I don't see >> a good case to nail DANE to one DNS security approach. > > I disagree, STRONGLY here. > > The recursive resolver is a failure from a security standpoint: unless th= e owner of the end system also owns the recursive resolver, the resolver it= self must not be trusted. The recursive resolver is always a trusted component in a network. Even with DNSSEC it has the power to DoS a site. NSEC3 allows the client to detect a DoS, but it can't find out where the site is without circumventing the resolver. The recursive resolver SHOULD be trustworthy. Now that does not mean 'running it yourself' since nobody I know is capable of doing that since humans do not come with ethernet ports and can't do RSA in their head. The recursive resolution needs to be done by a trustworthy server and the communication between the client and the server needs to be trustworthy. But given that I can barely get my netduinos to do RSA2048 once during startup, I really can't expect them to be verifying DNSSEC chains on every network transaction. Nor can I push out ICANN root updates to them in a feasible fashion. > Beyond OpenDNS tricks and NXDOMAIN wildcarding, =A0we STILL have major IS= Ps who are using the recursive resolver to man-in-the-middle intercept Yaho= o and Bing (and Google until Google puts a stop to it with Captchas and/or = legal threats). 'STILL'? I thought that sort of thing was increasing rather than decreasing. --=20 Website: http://hallambaker.com/ From paul@xelerance.com Tue Oct 4 06:28: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 CF1E921F8C04 for ; Tue, 4 Oct 2011 06:28:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.415 X-Spam-Level: X-Spam-Status: No, score=-4.415 tagged_above=-999 required=5 tests=[AWL=-1.816, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bdr7AdgWC4AV for ; Tue, 4 Oct 2011 06:28:04 -0700 (PDT) Received: from mx.xelerance.com (mx.xelerance.com [193.110.157.188]) by ietfa.amsl.com (Postfix) with ESMTP id 0857F21F8BF7 for ; Tue, 4 Oct 2011 06:28:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx.xelerance.com (Postfix) with ESMTP id E1A7099; Tue, 4 Oct 2011 09:30:59 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=xelerance.com; h= content-type:content-type:mime-version:user-agent:references :message-id:in-reply-to:subject:subject:from:from:date:date :received:received:received:received; s=smtp; t=1317735059; x= 1318339859; bh=cjeEHXd5yaMhwurnXc5jxxDZAjYZ22DYb3nNt3JR1qY=; b=h FL93L3uhdEi2yOr2gT1PnLDdt3x7nr0bo+xN3x/N/y9CePPmI+P7qaG13I4Tltun Foe2oJLjhAqsseD01BybTb0fMDRD5+GnzDz3nho+lf9Pyz9ksavlLtaaka85Z9t1 rwEyEJ0Xh29emJXi9ihcGeTMfghO2Orb+D5BIUpsfg= Received: from mx.xelerance.com ([127.0.0.1]) by localhost (mx.xelerance.com [127.0.0.1]) (amavisd-new, port 10026) with LMTP id WNLcohGET18r; Tue, 4 Oct 2011 09:30:59 -0400 (EDT) Received: from mail.xelerance.com (mail.xelerance.com [193.110.157.189]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.xelerance.com (Postfix) with ESMTPS id BE90A8E; Tue, 4 Oct 2011 09:30:57 -0400 (EDT) Received: by mail.xelerance.com (Postfix, from userid 1001) id C72D819E7; Tue, 4 Oct 2011 09:30:51 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.xelerance.com (Postfix) with ESMTP id C16D5F3E; Tue, 4 Oct 2011 09:30:51 -0400 (EDT) Date: Tue, 4 Oct 2011 09:30:51 -0400 (EDT) From: Paul Wouters To: Mark Andrews In-Reply-To: <20111004044851.C04B81492CA3@drugs.dv.isc.org> Message-ID: References: <4E856FB8.9000301@sidn.nl> <1317451765.2130.94.camel@localhost> <4E8A15C6.3000408@sv.cmu.edu> <20111003201605.GN53886@shinkuro.com> <4E8A196C.5060602@sv.cmu.edu> <20111004005833.64C0014911E0@drugs.dv.isc.org> <20111004032836.A21501492790@drugs.dv.isc.org> <4E8A863D.7030209@sv.cmu.edu> <20111004044851.C04B81492CA3@drugs.dv.isc.org> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: IETF DANE WG list Subject: Re: [dane] Fwd: #36: Only requiring DNSSEC where it is needed 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, 04 Oct 2011 13:28:04 -0000 On Tue, 4 Oct 2011, Mark Andrews wrote: >> Until people start consuming DNSSEC data at the edge, nobody in the >> middle has any serious incentive to make sure it works; so I think >> your estimate of the state of the *installed base* of *everything that >> has to pass DNS traffic along* is over-optimistic. > > In most cases there are only two middle boxes to worry about. The > ISP's resolver and the CPE device. The resolver, if it is DNSSEC > aware, is already dealing with any upstream issues. That leaves > CPE devices which should be field updatable in most cases. Those can be circumvented using a caching resolver directly. However, the ISP case and CPE case leave out the "mangling port 53" case. That could be a firewall near the CPE or ISP, and is actually a bigger issue. Then there is the brief DNS blackhole during signon Paul From paul@xelerance.com Tue Oct 4 06:34: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 A5FD421F8C0E for ; Tue, 4 Oct 2011 06:34:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.386 X-Spam-Level: X-Spam-Status: No, score=-4.386 tagged_above=-999 required=5 tests=[AWL=-1.787, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S0l4RRtchy0G for ; Tue, 4 Oct 2011 06:34:43 -0700 (PDT) Received: from mx.xelerance.com (mx.xelerance.com [193.110.157.188]) by ietfa.amsl.com (Postfix) with ESMTP id 2D43721F8C0C for ; Tue, 4 Oct 2011 06:34:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx.xelerance.com (Postfix) with ESMTP id 671C799; Tue, 4 Oct 2011 09:37:33 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=xelerance.com; h= content-type:content-type:mime-version:user-agent:references :message-id:in-reply-to:subject:subject:from:from:date:date :received:received:received:received; s=smtp; t=1317735452; x= 1318340252; bh=v4u7vrEomTLIB/Rva9gEZDnRZCA1oAZznZjRVy4mPWY=; b=U 2zxNPnzxqa2Ha4jQJ3ljSdlqfsTqCWHrGJaPdc7pCBqTCmSznpwZrKcCybz0cX/T gO9QlJGMflT88/35aNjX87gcAP604Ok/2a9nbngxHotP6JtbfQn6G/8N43/p82N5 tECywXwAhlU5ST/UvWA1DkPlRaA2gQW2MXuzMa1Kuk= Received: from mx.xelerance.com ([127.0.0.1]) by localhost (mx.xelerance.com [127.0.0.1]) (amavisd-new, port 10026) with LMTP id faWL+XXpxRgY; Tue, 4 Oct 2011 09:37:32 -0400 (EDT) Received: from mail.xelerance.com (mail.xelerance.com [193.110.157.189]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.xelerance.com (Postfix) with ESMTPS id B909C8E; Tue, 4 Oct 2011 09:37:32 -0400 (EDT) Received: by mail.xelerance.com (Postfix, from userid 1001) id AA3A219E7; Tue, 4 Oct 2011 09:37:26 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.xelerance.com (Postfix) with ESMTP id A8FDAF3E; Tue, 4 Oct 2011 09:37:26 -0400 (EDT) Date: Tue, 4 Oct 2011 09:37:26 -0400 (EDT) From: Paul Wouters To: Phillip Hallam-Baker In-Reply-To: Message-ID: References: <060.8aca11012e6c9583642ba071c54be972@trac.tools.ietf.org> <075.e771c9a4f93afa495f330ae9d1ebfa5a@trac.tools.ietf.org> <20111004062737.GA23425@xs.powerdns.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dane@ietf.org Subject: Re: [dane] how about not talking about DNSSEC Re: #36: Only requiring DNSSEC where it is needed 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, 04 Oct 2011 13:34:43 -0000 On Tue, 4 Oct 2011, Phillip Hallam-Baker wrote: > I don't think DNSSEC out to the end point client is even desirable. We disagree. Just like telnet is not desirable, DNS without DNSSEC is no longer desirable. > it is certainly not desirable for embedded devices. Just like firewalls (or a decent IP stack) was not desirable for SCADA devices? In fact, for embedded devices, people WANT DNSSEC (with raw public keys) because it is easier to validate then a 4KB cert blob when you don't even have a MMU. > If any new protocol is going to get early adopters it is always in > areas that are currently unserved or underserved. Web Services and > embedded devices are the areas that will be relevant. Agreed. Which makes the raw public keys with dane so important.... Paul From paul@xelerance.com Tue Oct 4 06:37: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 70AC521F8C20 for ; Tue, 4 Oct 2011 06:37:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.359 X-Spam-Level: X-Spam-Status: No, score=-4.359 tagged_above=-999 required=5 tests=[AWL=-1.760, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dKyhe19ZdZdN for ; Tue, 4 Oct 2011 06:37:22 -0700 (PDT) Received: from mx.xelerance.com (mx.xelerance.com [193.110.157.188]) by ietfa.amsl.com (Postfix) with ESMTP id 7E6C821F8C14 for ; Tue, 4 Oct 2011 06:37:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx.xelerance.com (Postfix) with ESMTP id 9633099; Tue, 4 Oct 2011 09:40:19 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=xelerance.com; h= content-type:content-type:mime-version:user-agent:references :message-id:in-reply-to:subject:subject:from:from:date:date :received:received:received:received; s=smtp; t=1317735618; x= 1318340418; bh=RVEmb8abg7DGWJWAQfLidViR9GwyC8xTO6W+i5hNAlU=; b=B 2RmMFiKv1ZkijcesiAZSz6tiwIqvEkUnv1YoMRBCb8HNRR1auXhd+hhxjw9giXEY YEE8o8lswwr6H2a54gsRtvX3uyeYtVAzAmZjJ9aVNfpP+Sj3PQ0II+9hAHfMsqS7 qZYfQrnV/rNoWUK+w+wibF6zJ2jbCV5iRot0xZiWzc= Received: from mx.xelerance.com ([127.0.0.1]) by localhost (mx.xelerance.com [127.0.0.1]) (amavisd-new, port 10026) with LMTP id 7Xgu71DJ9Fic; Tue, 4 Oct 2011 09:40:18 -0400 (EDT) Received: from mail.xelerance.com (mail.xelerance.com [193.110.157.189]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.xelerance.com (Postfix) with ESMTPS id B938E8E; Tue, 4 Oct 2011 09:40:18 -0400 (EDT) Received: by mail.xelerance.com (Postfix, from userid 1001) id A208119E7; Tue, 4 Oct 2011 09:40:12 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.xelerance.com (Postfix) with ESMTP id 9A6DCF3E; Tue, 4 Oct 2011 09:40:12 -0400 (EDT) Date: Tue, 4 Oct 2011 09:40:12 -0400 (EDT) From: Paul Wouters To: Phillip Hallam-Baker In-Reply-To: Message-ID: References: <201109272223.p8RMNPpA026467@fs4113.wdf.sap.corp> <4E856FB8.9000301@sidn.nl> <1317451765.2130.94.camel@localhost> <4E8A15C6.3000408@sv.cmu.edu> <1317707745.3944.45.camel@localhost> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: IETF DANE WG list Subject: Re: [dane] Fwd: #36: Only requiring DNSSEC where it is needed 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, 04 Oct 2011 13:37:23 -0000 On Tue, 4 Oct 2011, Phillip Hallam-Baker wrote: > Adam's proposal to put the chain in the cert is the way to do key > distribution on the basis of the DNSSEC hierarchy. Sadly, it required a leap of faith of having connected first without having been under attack, so while a "nice to have" it does not actually solve the security issue. Paul From paul@xelerance.com Tue Oct 4 06:45: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 8549C21F8B53 for ; Tue, 4 Oct 2011 06:45:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.332 X-Spam-Level: X-Spam-Status: No, score=-4.332 tagged_above=-999 required=5 tests=[AWL=-1.733, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I9bFHnELQl3T for ; Tue, 4 Oct 2011 06:45:06 -0700 (PDT) Received: from mx.xelerance.com (mx.xelerance.com [193.110.157.188]) by ietfa.amsl.com (Postfix) with ESMTP id CCD8521F8B4F for ; Tue, 4 Oct 2011 06:45:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx.xelerance.com (Postfix) with ESMTP id 18AB399; Tue, 4 Oct 2011 09:48:03 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=xelerance.com; h= content-type:content-type:mime-version:user-agent:references :message-id:in-reply-to:subject:subject:from:from:date:date :received:received:received:received; s=smtp; t=1317736082; x= 1318340882; bh=dd7cd8wgPocVhoi6J+FQipL5+/NkzI6n3qvq/R9fbNM=; b=d kifYU9fXpqULqXzq65SgvlLPtI4Wzo/bylOSUyAKikLXgNTe6uRZ24sqoS7bZoBf m+78LavcUIIkQunjz135O8WQdXSH+vx5vlhalOrQAWzU275xAMwLuq9nEqYpyKAW vVL5nkspWjqghZUfRmCyyA2jt9yZPYEbpWmNi2LRZI= Received: from mx.xelerance.com ([127.0.0.1]) by localhost (mx.xelerance.com [127.0.0.1]) (amavisd-new, port 10026) with LMTP id teGNCdA0PFhB; Tue, 4 Oct 2011 09:48:02 -0400 (EDT) Received: from mail.xelerance.com (mail.xelerance.com [193.110.157.189]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.xelerance.com (Postfix) with ESMTPS id 74B628E; Tue, 4 Oct 2011 09:48:02 -0400 (EDT) Received: by mail.xelerance.com (Postfix, from userid 1001) id 7E44019E7; Tue, 4 Oct 2011 09:47:56 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.xelerance.com (Postfix) with ESMTP id 7D138F3E; Tue, 4 Oct 2011 09:47:56 -0400 (EDT) Date: Tue, 4 Oct 2011 09:47:56 -0400 (EDT) From: Paul Wouters To: Phillip Hallam-Baker In-Reply-To: Message-ID: References: <060.8aca11012e6c9583642ba071c54be972@trac.tools.ietf.org> <075.e771c9a4f93afa495f330ae9d1ebfa5a@trac.tools.ietf.org> <20111004062737.GA23425@xs.powerdns.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dane@ietf.org Subject: Re: [dane] how about not talking about DNSSEC Re: #36: Only requiring DNSSEC where it is needed 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, 04 Oct 2011 13:45:06 -0000 On Tue, 4 Oct 2011, Paul Wouters wrote: > Just like firewalls (or a decent IP stack) was not desirable for SCADA > devices? In fact, for embedded devices, people WANT DNSSEC (with raw > public keys) because it is easier to validate then a 4KB cert blob when > you don't even have a MMU. As an example, the RIPE Atlas probes do not have the memory to fetch a TLS certificate blobs..... Paul From nweaver@ICSI.Berkeley.EDU Tue Oct 4 08:00: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 B3F3221F8C18 for ; Tue, 4 Oct 2011 08:00:19 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l+b5T7bsR6C8 for ; Tue, 4 Oct 2011 08:00:19 -0700 (PDT) Received: from rock.ICSI.Berkeley.EDU (rock.ICSI.Berkeley.EDU [192.150.186.19]) by ietfa.amsl.com (Postfix) with ESMTP id 100B521F8BCB for ; Tue, 4 Oct 2011 08:00:19 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 8DF7A2C4028; Tue, 4 Oct 2011 08:03:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at ICSI.Berkeley.EDU Received: from rock.ICSI.Berkeley.EDU ([127.0.0.1]) by localhost (maihub.ICSI.Berkeley.EDU [127.0.0.1]) (amavisd-new, port 10024) with LMTP id ZI++NbypUvpM; Tue, 4 Oct 2011 08:03:24 -0700 (PDT) Received: from gala.icir.org (gala [192.150.187.49]) (Authenticated sender: nweaver) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 1CA2E2C401E; Tue, 4 Oct 2011 08:03:24 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=iso-8859-1 From: Nicholas Weaver In-Reply-To: Date: Tue, 4 Oct 2011 08:03:24 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <2B08C85A-4422-464B-879E-DAE76F507272@ICSI.Berkeley.EDU> References: <060.8aca11012e6c9583642ba071c54be972@trac.tools.ietf.org> <075.e771c9a4f93afa495f330ae9d1ebfa5a@trac.tools.ietf.org> <20111004062737.GA23425@xs.powerdns.com> <7B75D74E-F0E2-4E83-96CC-25B53E05F896@icsi.berkeley.edu> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1244.3) Cc: dane@ietf.org Subject: Re: [dane] how about not talking about DNSSEC Re: #36: Only requiring DNSSEC where it is needed 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, 04 Oct 2011 15:00:19 -0000 On Oct 4, 2011, at 6:10 AM, Phillip Hallam-Baker wrote: > On Tue, Oct 4, 2011 at 8:57 AM, Nicholas Weaver > wrote: >>=20 >> On Oct 4, 2011, at 5:48 AM, Phillip Hallam-Baker wrote: >>> I totally agree. >>>=20 >>> I don't think DNSSEC out to the end point client is even desirable. = It >>> might be for a Web browser, it is certainly not desirable for = embedded >>> devices. Since only about 10% of the computers in my house are = desktop >>> or laptop devices and the proportion is dropping sharply, I don't = see >>> a good case to nail DANE to one DNS security approach. >>=20 >> I disagree, STRONGLY here. >>=20 >> The recursive resolver is a failure from a security standpoint: = unless the owner of the end system also owns the recursive resolver, the = resolver itself must not be trusted. >=20 > The recursive resolver is always a trusted component in a network. > Even with DNSSEC it has the power to DoS a site. NSEC3 allows the > client to detect a DoS, but it can't find out where the site is > without circumventing the resolver. Exactly: Circumvent the resolver whenever there is a DNSSEC failure. = Well, whenever there is any failure from it. EG, Xerocole happily says that their NXDOMAIN wildcarding solution works = with DNSSEC just fine. It simply returns a wildcard without any = signature information, trusting that the end-host will not validate it. The recursive resolver portion of the infrastructure made sense 20 years = ago. 20 years ago the code paths to do an on-the-endhost recursive = resolver counted for a lot more, and load and bandwidth mattered a lot = more. Today? Why not have every end host run its own resolver? > The recursive resolver SHOULD be trustworthy. But it IS NOT trustworthy. > Now that does not mean 'running it yourself' since nobody I know is > capable of doing that since humans do not come with ethernet ports and > can't do RSA in their head. It does mean "run by the same ownership". =20 > The recursive resolution needs to be done by a trustworthy server and > the communication between the client and the server needs to be > trustworthy. >=20 > But given that I can barely get my netduinos to do RSA2048 once during > startup, I really can't expect them to be verifying DNSSEC chains on > every network transaction. Nor can I push out ICANN root updates to > them in a feasible fashion. No, but in that case you could expect it to run its own direct fetch and = bypass the recursive resolver. =20 I would rather see end hosts NOT validating DNSSEC BUT bypassing the = recursive resolver, than relying on the recursive resolver to validate = DNSSEC. An adversary who can manipulate the received to end host's DNS reply = when it is bypassing the recursive resolver is already in an amazingly = powerful position, and for all but DANE-type applications where DNSSEC = is used to validate key material the adversary has effectively won even = without manipulating DNS information. >> Beyond OpenDNS tricks and NXDOMAIN wildcarding, we STILL have major = ISPs who are using the recursive resolver to man-in-the-middle intercept = Yahoo and Bing (and Google until Google puts a stop to it with Captchas = and/or legal threats). >=20 > 'STILL'? >=20 > I thought that sort of thing was increasing rather than decreasing. Given that most lawyers call this interception wiretapping (which has = criminal as well as civil penalties), most people who find out about it = STRONGLY object to it, AND the business model behind the interception = (change responses to redirect through affiliate networks) has been shown = non-viable as the affiliate networks themselves strongly object to this = when they find out, the continued interception is quite notable that it = is continuing at all. The only temporary increase was Earthlink, but they backed off within 2 = days of public disclosure, so it hasn't been increasing. From rbarnes@bbn.com Tue Oct 4 08:16: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 75F5421F8ADE for ; Tue, 4 Oct 2011 08:16:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.558 X-Spam-Level: X-Spam-Status: No, score=-106.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lJC7175s+lCB for ; Tue, 4 Oct 2011 08:16:55 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id CBF9921F8ABD for ; Tue, 4 Oct 2011 08:16:55 -0700 (PDT) Received: from [192.1.255.224] (port=54472 helo=col-dhcp-192-1-255-224.bbn.com) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1RB6mm-0003OC-IX; Tue, 04 Oct 2011 11:20:00 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: Date: Tue, 4 Oct 2011 11:19:55 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <060.8aca11012e6c9583642ba071c54be972@trac.tools.ietf.org> <075.e771c9a4f93afa495f330ae9d1ebfa5a@trac.tools.ietf.org> <20111004062737.GA23425@xs.powerdns.com> To: Paul Wouters X-Mailer: Apple Mail (2.1084) Cc: dane@ietf.org Subject: Re: [dane] how about not talking about DNSSEC Re: #36: Only requiring DNSSEC where it is needed 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, 04 Oct 2011 15:16:56 -0000 >> Just like firewalls (or a decent IP stack) was not desirable for = SCADA >> devices? In fact, for embedded devices, people WANT DNSSEC (with raw >> public keys) because it is easier to validate then a 4KB cert blob = when >> you don't even have a MMU. >=20 > As an example, the RIPE Atlas probes do not have the memory to fetch a = TLS > certificate blobs..... Bad example. ATLAS probes are based on the Lantronix XPort Pro = platform, which has this on its spec page: " SSLv3 and SSHv2 Client & Server, Selectable 128/256/512/1024 Bit = certificates " = = From warren@kumari.net Tue Oct 4 08:44: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 9471E21F8C53 for ; Tue, 4 Oct 2011 08:44:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.614 X-Spam-Level: X-Spam-Status: No, score=-104.614 tagged_above=-999 required=5 tests=[AWL=1.985, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k4btE95l2F7a for ; Tue, 4 Oct 2011 08:44:19 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id DD41321F8C47 for ; Tue, 4 Oct 2011 08:44:18 -0700 (PDT) Received: from dhcp-172-19-119-117.cbf.corp.google.com (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id A86BA1B40031; Tue, 4 Oct 2011 11:47:20 -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, 4 Oct 2011 11:47:19 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E856FB8.9000301@sidn.nl> <1317451765.2130.94.camel@localhost> <4E8A15C6.3000408@sv.cmu.edu> <20111003201605.GN53886@shinkuro.com> <4E8A196C.5060602@sv.cmu.edu> <20111004005833.64C0014911E0@drugs.dv.isc.org> <20111004032836.A21501492790@drugs.dv.isc.org> <4E8A863D.7030209@sv.cmu.edu> <20111004044851.C04B81492CA3@drugs.dv.isc.org> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1084) Cc: IETF DANE WG list Subject: Re: [dane] Fwd: #36: Only requiring DNSSEC where it is needed 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, 04 Oct 2011 15:44:19 -0000 On Oct 4, 2011, at 9:02 AM, Phillip Hallam-Baker wrote: > If an enterprise is using DNSSEC to secure its internal network, the > root of trust for the devices in that network SHOULD and MUST flow > from a key that is controlled by the enterprise and not by ICANN. That's a fairly strong (and broad) statement, for which I do not think I = see much evidence (although I don't know that many enterprises that are = signing / validating internal stuff) -- from other folk who have seen = enterprise deployments are you seeing enterprises use the IANA root or = their own?=20 I'm interested -- if DANE folk don't have much visibility here, maybe = I'll shuffle this off to the dnssec-deployment list (or DNSOP / EXT / = etc)... >=20 > That is a very basic principle of security that is understood by > pretty much anyone who is likely to be a DNSSEC early adopter. >=20 >=20 > nsa.gov is not going to chain from the ICANN root. >=20 > In fact the intra-governmental squabbling in the US federal govt, was > so great that we could not even get them all to agree on one root for > the federal govt. Hence the invention of the bridge CA. >=20 >=20 > On Tue, Oct 4, 2011 at 12:48 AM, Mark Andrews wrote: >>=20 >> In message <4E8A863D.7030209@sv.cmu.edu>, Zack Weinberg writes: >>> On 2011-10-03 8:28 PM, Mark Andrews wrote: >>>> While signing the root was a significant milestone it really as > > = nothing to do with whether DNSSEC records will be passed on recursive >>>> servers. You need to look at when DNSSEC aware recursive servers >>>> shipped as they can pass on the records with or without trust = anchors >>>> being configured. >>>>=20 >>>> For BIND you need to look at BIND 9.3.0 (DNSSECbis Jan 2005) and >>>> BIND 9.6.0 (NSEC3 support Dec 2008). As far as BIND is concerned >>>> all supported versions support NSEC3 and DNSSECbis. >>>=20 >>> Until people start consuming DNSSEC data at the edge, nobody in the >>> middle has any serious incentive to make sure it works; so I think >>> your estimate of the state of the *installed base* of *everything = that >>> has to pass DNS traffic along* is over-optimistic. >>=20 >> In most cases there are only two middle boxes to worry about. The >> ISP's resolver and the CPE device. The resolver, if it is DNSSEC >> aware, is already dealing with any upstream issues. That leaves >> CPE devices which should be field updatable in most cases. >>=20 >>> Nicholas Weaver had actual numbers which, as I recall, said it would = be >>> possible to start doing that consuming now, but *not* to treat = DNSSEC >>> outages as evidence of malicious tampering. >>>=20 >>> zw >>> _______________________________________________ >>> dane mailing list >>> dane@ietf.org >>> https://www.ietf.org/mailman/listinfo/dane >> -- >> Mark Andrews, ISC >> 1 Seymour St., Dundas Valley, NSW 2117, Australia >> PHONE: +61 2 9871 4742 INTERNET: marka@isc.org >> _______________________________________________ >> dane mailing list >> dane@ietf.org >> https://www.ietf.org/mailman/listinfo/dane >>=20 >=20 >=20 >=20 > --=20 > Website: http://hallambaker.com/ > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane >=20 From ajs@anvilwalrusden.com Tue Oct 4 09:08: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 8C79E21F8D63 for ; Tue, 4 Oct 2011 09:08:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L2LClFREvAIt for ; Tue, 4 Oct 2011 09:08:12 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 0481021F8BEC for ; Tue, 4 Oct 2011 09:08:12 -0700 (PDT) Received: from shinkuro.com (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id A3A9D1ECB41C for ; Tue, 4 Oct 2011 16:11:10 +0000 (UTC) Date: Tue, 4 Oct 2011 12:11:15 -0400 From: Andrew Sullivan To: dane@ietf.org Message-ID: <20111004161114.GF58709@shinkuro.com> References: <4E8A15C6.3000408@sv.cmu.edu> <20111003201605.GN53886@shinkuro.com> <4E8A196C.5060602@sv.cmu.edu> <20111004005833.64C0014911E0@drugs.dv.isc.org> <20111004032836.A21501492790@drugs.dv.isc.org> <4E8A863D.7030209@sv.cmu.edu> <20111004044851.C04B81492CA3@drugs.dv.isc.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] Fwd: #36: Only requiring DNSSEC where it is needed 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, 04 Oct 2011 16:08:12 -0000 On Tue, Oct 04, 2011 at 11:47:19AM -0400, Warren Kumari wrote: > That's a fairly strong (and broad) statement, for which I do not > think I see much evidence (although I don't know that many > enterprises that are signing / validating internal stuff) -- from > other folk who have seen enterprise deployments are you seeing > enterprises use the IANA root or their own? There was a lot of talk a couple years ago about TARs (Trust Anchor Repositories) and how they'd be managed. That all seemed to have dried up and blown away, and if people really wanted to use private keys to anchor some part of the namespace, I expect we'd be hearing a lot of discussion about how to manage such keys and so on. Nevertheless, there appears to be a consensus among implementers that "closest key wins" is a legitimate approach for managing the trust path, so that if you have a key for . and you have a key for example.com, you use the latter (and by option only the latter) for validating www.example.com. Given that these are shipping implementations, I presume there's demand. I find it hard to believe that, in the face of stone-age key management tools, the experience is going to be satisfying. But I guess some people want to do this. There's an additional issue here: if you seriously believe that the root key path is vulnerable, then presumably (1) you think there's a similar possible problem from the traditional X.509 infrastructure, and (2) you think that the root DNS is also a serious vulnerability. In environments I have actually experienced, these beliefs are the sort of things that people say a lot, but when faced with the terrific inconvenience of living with the consequences they don't actually do it. There are environments where the network people are capable enough and well-funded enough to implement this sort of thing, but I have pretty grave doubts that they're common. A -- Andrew Sullivan ajs@anvilwalrusden.com From paul@xelerance.com Tue Oct 4 09:19:54 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 9073C21F8CE3 for ; Tue, 4 Oct 2011 09:19:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.306 X-Spam-Level: X-Spam-Status: No, score=-4.306 tagged_above=-999 required=5 tests=[AWL=-1.707, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nV540sQxrvMj for ; Tue, 4 Oct 2011 09:19:53 -0700 (PDT) Received: from mx.xelerance.com (mx.xelerance.com [193.110.157.188]) by ietfa.amsl.com (Postfix) with ESMTP id 8089221F8C3E for ; Tue, 4 Oct 2011 09:19:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx.xelerance.com (Postfix) with ESMTP id 9B7AD9A; Tue, 4 Oct 2011 12:22:46 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=xelerance.com; h= content-type:content-type:mime-version:user-agent:references :message-id:in-reply-to:subject:subject:from:from:date:date :received:received:received:received; s=smtp; t=1317745365; x= 1318350165; bh=gLqgdgEDzAH11JtIewc8AJBgnz6W85yOSUxsbB3ASXE=; b=V MRkDI5iWRfyfqTTIM8dRtDegYiN+5A67BbGb3npdUa7Xx3QIXj89Y9f0K0LdifJy 1dAuqJsF1/BerT0txjbmPtTyJbX7numPBsxHQMN+6kBg9IacuNG387X/MOX1Lwpj yT0ozYeI4I/zjU1+Q2iAGl8Tes71bbTmz1wujGl8TQ= Received: from mx.xelerance.com ([127.0.0.1]) by localhost (mx.xelerance.com [127.0.0.1]) (amavisd-new, port 10026) with LMTP id mESdbe4kCK+v; Tue, 4 Oct 2011 12:22:45 -0400 (EDT) Received: from mail.xelerance.com (mail.xelerance.com [193.110.157.189]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.xelerance.com (Postfix) with ESMTPS id 8222499; Tue, 4 Oct 2011 12:22:43 -0400 (EDT) Received: by mail.xelerance.com (Postfix, from userid 1001) id B00AB19E7; Tue, 4 Oct 2011 12:22:37 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.xelerance.com (Postfix) with ESMTP id AEBB4F3E; Tue, 4 Oct 2011 12:22:37 -0400 (EDT) Date: Tue, 4 Oct 2011 12:22:37 -0400 (EDT) From: Paul Wouters To: "Richard L. Barnes" In-Reply-To: Message-ID: References: <060.8aca11012e6c9583642ba071c54be972@trac.tools.ietf.org> <075.e771c9a4f93afa495f330ae9d1ebfa5a@trac.tools.ietf.org> <20111004062737.GA23425@xs.powerdns.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dane@ietf.org Subject: Re: [dane] how about not talking about DNSSEC Re: #36: Only requiring DNSSEC where it is needed 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, 04 Oct 2011 16:19:54 -0000 On Tue, 4 Oct 2011, Richard L. Barnes wrote: >> As an example, the RIPE Atlas probes do not have the memory to fetch a TLS >> certificate blobs..... > > Bad example. ATLAS probes are based on the Lantronix XPort Pro platform, which has this on its spec page: > " > SSLv3 and SSHv2 Client & Server, Selectable 128/256/512/1024 Bit certificates > " > The developers found it to be impossible with their memory footprint, which is more then just running a single TLS client from busybox..... Or perhaps lantronix tested with self signed PKIX, and not with a real life giant blob of PKIX with a few intermediary CAs. The point is, embedded devices are severely constrained in memory and cpu. PKIX-TLS can be impossible as real-life examples (over vendor specs) have shown. Paul From paul@xelerance.com Tue Oct 4 09:23: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 0C11521F8DD6 for ; Tue, 4 Oct 2011 09:23:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.281 X-Spam-Level: X-Spam-Status: No, score=-4.281 tagged_above=-999 required=5 tests=[AWL=-1.682, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2K68iF1CR5BK for ; Tue, 4 Oct 2011 09:23:02 -0700 (PDT) Received: from mx.xelerance.com (mx.xelerance.com [193.110.157.188]) by ietfa.amsl.com (Postfix) with ESMTP id 362E521F8DD4 for ; Tue, 4 Oct 2011 09:23:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx.xelerance.com (Postfix) with ESMTP id 86CE599; Tue, 4 Oct 2011 12:25:59 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=xelerance.com; h= content-type:content-type:mime-version:user-agent:references :message-id:in-reply-to:subject:subject:from:from:date:date :received:received:received:received; s=smtp; t=1317745558; x= 1318350358; bh=Zn96XwshUZdyilAD1rpD+FV1lB4zGf9lFPnfZOxg25s=; b=Q A0//JZRDMDkLggFugIHcmmphq8a5cLkwiaLB6SJwVp5mxgOUp7J/ychIiBF5Rojg Iatz9vqPkud2EDpg7Icspcx1bXhldlhujK1MwsalLVpew0i5Gqq0+I5wNrDD/hgo HJYm6HlHMNSxbk4loeESfywrEuLQB/MStqt6EvUDjE= Received: from mx.xelerance.com ([127.0.0.1]) by localhost (mx.xelerance.com [127.0.0.1]) (amavisd-new, port 10026) with LMTP id 06U7OMsI1Zsu; Tue, 4 Oct 2011 12:25:58 -0400 (EDT) Received: from mail.xelerance.com (mail.xelerance.com [193.110.157.189]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.xelerance.com (Postfix) with ESMTPS id D44558E; Tue, 4 Oct 2011 12:25:58 -0400 (EDT) Received: by mail.xelerance.com (Postfix, from userid 1001) id C2C0E19E7; Tue, 4 Oct 2011 12:25:52 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.xelerance.com (Postfix) with ESMTP id C17A8F3E; Tue, 4 Oct 2011 12:25:52 -0400 (EDT) Date: Tue, 4 Oct 2011 12:25:52 -0400 (EDT) From: Paul Wouters To: Andrew Sullivan In-Reply-To: <20111004161114.GF58709@shinkuro.com> Message-ID: References: <4E8A15C6.3000408@sv.cmu.edu> <20111003201605.GN53886@shinkuro.com> <4E8A196C.5060602@sv.cmu.edu> <20111004005833.64C0014911E0@drugs.dv.isc.org> <20111004032836.A21501492790@drugs.dv.isc.org> <4E8A863D.7030209@sv.cmu.edu> <20111004044851.C04B81492CA3@drugs.dv.isc.org> <20111004161114.GF58709@shinkuro.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dane@ietf.org Subject: Re: [dane] Fwd: #36: Only requiring DNSSEC where it is needed 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, 04 Oct 2011 16:23:03 -0000 On Tue, 4 Oct 2011, Andrew Sullivan wrote: > Nevertheless, there appears to be a consensus among implementers that > "closest key wins" is a legitimate approach for managing the trust > path, so that if you have a key for . and you have a key for > example.com, you use the latter (and by option only the latter) for > validating www.example.com. Given that these are shipping > implementations, I presume there's demand. I find it hard to believe > that, in the face of stone-age key management tools, the experience is > going to be satisfying. But I guess some people want to do this. not so much "want" but "need". If you need to internet to resolve your internal names because of a missing DNSSEC chain element, you just broke all internal resolving when there is a WAN outage. Can't be good for job security :P Then there is the "internal only domains", that have no reference in external DNS, so you are forced to configure a key and forwarder anyway or else they will end up as "bogus". Paul From hallam@gmail.com Tue Oct 4 09:42: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 8C24B21F8A4E for ; Tue, 4 Oct 2011 09:42:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.416 X-Spam-Level: X-Spam-Status: No, score=-2.416 tagged_above=-999 required=5 tests=[AWL=-0.971, BAYES_00=-2.599, FRT_BELOW2=2.154, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SHHHXSCpIpsv for ; Tue, 4 Oct 2011 09:42:05 -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 DE7DF21F8801 for ; Tue, 4 Oct 2011 09:42:04 -0700 (PDT) Received: by gyd12 with SMTP id 12so820899gyd.31 for ; Tue, 04 Oct 2011 09:45: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:content-transfer-encoding; bh=lIeTBFe47VVY7CLGmACujU/SxB7cTk62YLmPlUWiyW4=; b=J1+Mt6r19qC2hPvRjkhUVjf1boPXX83IwcWnMn3U+qDDkjECIAcpIwPMiJO++oAMPY Ni+5fJhU/DdYKlXikS/T6d8WOlxWN/VFCFzvLSHWz2COrqxbVD3/7JZqHy85fqwh+ZO6 yGTRXlGidmQBRJSaCfW/6+t3y21D8LiJtukz8= MIME-Version: 1.0 Received: by 10.101.27.34 with SMTP id e34mr1180295anj.162.1317746710108; Tue, 04 Oct 2011 09:45:10 -0700 (PDT) Received: by 10.100.212.14 with HTTP; Tue, 4 Oct 2011 09:45:09 -0700 (PDT) In-Reply-To: References: <4E856FB8.9000301@sidn.nl> <1317451765.2130.94.camel@localhost> <4E8A15C6.3000408@sv.cmu.edu> <20111003201605.GN53886@shinkuro.com> <4E8A196C.5060602@sv.cmu.edu> <20111004005833.64C0014911E0@drugs.dv.isc.org> <20111004032836.A21501492790@drugs.dv.isc.org> <4E8A863D.7030209@sv.cmu.edu> <20111004044851.C04B81492CA3@drugs.dv.isc.org> Date: Tue, 4 Oct 2011 12:45:09 -0400 Message-ID: From: Phillip Hallam-Baker To: Warren Kumari Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IETF DANE WG list Subject: Re: [dane] Fwd: #36: Only requiring DNSSEC where it is needed 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, 04 Oct 2011 16:42:05 -0000 On Tue, Oct 4, 2011 at 11:47 AM, Warren Kumari wrote: > > On Oct 4, 2011, at 9:02 AM, Phillip Hallam-Baker wrote: > >> If an enterprise is using DNSSEC to secure its internal network, the >> root of trust for the devices in that network SHOULD and MUST flow >> from a key that is controlled by the enterprise and not by ICANN. > > > That's a fairly strong (and broad) statement, for which I do not think I = see much evidence (although I don't know that many enterprises that are sig= ning / validating internal stuff) =A0-- from other folk who have seen enter= prise deployments are you seeing enterprises use the IANA root or their own= ? > > I'm interested -- if DANE folk don't have much visibility here, maybe I'l= l shuffle this off to the dnssec-deployment list (or DNSOP / EXT / etc)... > > Well I have run up many private CAs for just that reason. Most of the '600' roots that the EFF claim to exist are actually enterprise intermediate certs that were created for exactly that purpose. Take those out and the number of issuing points falls bellow 50. It is pretty easy to fix the DNSSEC scheme. Each enterprise merely cross signs the root and publishes it in their own zone. ICANN even provides a CSR for this express purpose. --=20 Website: http://hallambaker.com/ From ajs@anvilwalrusden.com Tue Oct 4 10:24: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 13DDA21F8E10 for ; Tue, 4 Oct 2011 10:24:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bU00rCc4Xz01 for ; Tue, 4 Oct 2011 10:24:07 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 8CFDC21F8E08 for ; Tue, 4 Oct 2011 10:24:07 -0700 (PDT) Received: from shinkuro.com (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id A75F61ECB41C for ; Tue, 4 Oct 2011 17:27:06 +0000 (UTC) Date: Tue, 4 Oct 2011 13:27:10 -0400 From: Andrew Sullivan To: dane@ietf.org Message-ID: <20111004172710.GG58709@shinkuro.com> References: <4E8A196C.5060602@sv.cmu.edu> <20111004005833.64C0014911E0@drugs.dv.isc.org> <20111004032836.A21501492790@drugs.dv.isc.org> <4E8A863D.7030209@sv.cmu.edu> <20111004044851.C04B81492CA3@drugs.dv.isc.org> <20111004161114.GF58709@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] Fwd: #36: Only requiring DNSSEC where it is needed 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, 04 Oct 2011 17:24:08 -0000 On Tue, Oct 04, 2011 at 12:25:52PM -0400, Paul Wouters wrote: > not so much "want" but "need". If you need to internet to resolve your > internal names because of a missing DNSSEC chain element, you just broke > all internal resolving when there is a WAN outage. Can't be good for job > security :P > > Then there is the "internal only domains", that have no reference in > external DNS, so you are forced to configure a key and forwarder > anyway or else they will end up as "bogus". Another way to put this is that DNSSEC exposes you to yet another way in which your delusion of a single namespace with private chunks doesn't work ;-) There actually was a draft a number of years ago about doing DNSSEC in split-brain environments, but it failed because of the immediate problem of admitting that split-brain is a major piece of slightly-filthy technology on which everyone depends. MIF is busy jumping up and down on that electrified rail, however, so maybe the log jam will break. None of this gets us any closer to closure on the main topic, though, I think. I actually cannot fathom why anyone would go to the trouble of using TLSA without DNSSEC, so I fail to see the value in making the decision tree for an implementation more complicated and the attack surface bigger for what seems like a pretty negligible benefit. A -- Andrew Sullivan ajs@anvilwalrusden.com From cloos@jhcloos.com Tue Oct 4 13:25: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 6E04321F8F21 for ; Tue, 4 Oct 2011 13:25:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[AWL=0.852, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RJGeJaVgpCF5 for ; Tue, 4 Oct 2011 13:25:32 -0700 (PDT) Received: from eagle.jhcloos.com (eagle.jhcloos.com [IPv6:2001:1938:12d::53]) by ietfa.amsl.com (Postfix) with ESMTP id BE6FE21F8EF9 for ; Tue, 4 Oct 2011 13:25:32 -0700 (PDT) Received: by eagle.jhcloos.com (Postfix, from userid 10) id DBD6340180; Tue, 4 Oct 2011 20:28:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=eagle; t=1317760116; bh=nzSD4N4a7ZzduRYeLn4ezbPcOUP2+ztGDwBKHP2uEro=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=a5d/4kiRltItAmetjZlA3YbJFdD5BOE8GG/AdgvXwQO/Cz/JzJDz2yIw1fM0eJGnR vpaRHPypDrbCfd5o+6YjE0D8DHi0gJhg9FLwDm/UsKPjt8MGMwuW0lT9yadjMt3MCX aVF9+6GpC+JnM29l8wU5oQiln0BLpyQ2TtGhsviQ= Received: by carbon.jhcloos.org (Postfix, from userid 500) id 81785260042; Tue, 4 Oct 2011 20:20:04 +0000 (UTC) From: James Cloos To: Nicholas Weaver In-Reply-To: <2B08C85A-4422-464B-879E-DAE76F507272@ICSI.Berkeley.EDU> (Nicholas Weaver's message of "Tue, 4 Oct 2011 08:03:24 -0700") References: <060.8aca11012e6c9583642ba071c54be972@trac.tools.ietf.org> <075.e771c9a4f93afa495f330ae9d1ebfa5a@trac.tools.ietf.org> <20111004062737.GA23425@xs.powerdns.com> <7B75D74E-F0E2-4E83-96CC-25B53E05F896@icsi.berkeley.edu> <2B08C85A-4422-464B-879E-DAE76F507272@ICSI.Berkeley.EDU> User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/24.0.90 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2011 James Cloos OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Tue, 04 Oct 2011 16:20:04 -0400 Message-ID: Lines: 20 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:111004:nweaver@icsi.berkeley.edu::QTDkrrINfzg76n/p:00000000000000000000000000000000000NB9aI X-Hashcash: 1:30:111004:hallam@gmail.com::6sejGgNFLtSyOPxs:WD+rj X-Hashcash: 1:30:111004:dane@ietf.org::WwHYAVl0kxxqo/nA:000KyMDo Cc: dane@ietf.org Subject: Re: [dane] how about not talking about DNSSEC Re: #36: Only requiring DNSSEC where it is needed 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, 04 Oct 2011 20:25:34 -0000 >>>>> "NW" == Nicholas Weaver writes: NW> Today? Why not have every end host run its own resolver? There are still memory issues for just-big-enough virtuals and for embedded systems. But I've been using and advocating resolvers on each desktop/workstation/server type host since the mid '90s. Some environments have local-only zones; the resolving/verifying ns would require separate glue for those (in addition to the root glue) and a way to know when, if portable, it is in a location where said local zones could resolve. At the very least every administrative domain should have its own resolving (and now validating) nameserver. Or set of them, when- ever there are multiple hosts on the lan. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From jimsch@augustcellars.com Tue Oct 4 18:14: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 2EC1121F8AEA for ; Tue, 4 Oct 2011 18:14:46 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Huo1fzPlOh9K for ; Tue, 4 Oct 2011 18:14:45 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9C23A21F8AE9 for ; Tue, 4 Oct 2011 18:14:45 -0700 (PDT) Received: from Tobias (exodus.augustcellars.com [207.202.179.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id CA84B2C9F2; Tue, 4 Oct 2011 18:17:51 -0700 (PDT) From: "Jim Schaad" To: Date: Tue, 4 Oct 2011 18:56:24 -0700 Message-ID: <045d01cc8301$fd4204f0$f7c60ed0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us thread-index: AcyC6bXVIkJva4dqQqyPX5/ln84pbQ== X-Mailman-Approved-At: Tue, 04 Oct 2011 18:17:09 -0700 Cc: dane@ietf.org Subject: [dane] -12 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, 05 Oct 2011 01:14:46 -0000 1. Section 1.1 - This text needs to be updated to reflect other changes in the document. Tell me what a certificate association is before you talk about what is built from. A certificate association is formed from a piece of information identifying a certificate with the domain name where the data is found. The data used to identify the certificate consists of ...' 2. Section 2.1 - typo - /o one octet/a one octet/ Section 2.1.1 - I think that you need to be clearer about which certificate needs to pass validation, it is not the certificate that is found from the association record but rather the one presented by TLS. This is not clear, esp in the cases where the word certificate is used twice in the sentence to refer to different certificates. 3. Section 2.1.4 - I think that the field should be named "The Association Data Field" as in many cases there is not a certificate in this field OLD: The "certificate for association". This is the bytes containing the full certificate, SubjectPublicKeyInfo or the hash of the associated certificate or SubjectPublicKeyInfo. This is the certificate or the hash of the certificate itself, not of the TLS ASN.1 Certificate object. NEW: The "association data" to be matched. The field contains the bytes to be matched or the hash of the bytes to be matched. The source of the data to be matched is controlled by the Matching Type field. The data refers to the certificate in the association, not to the TLS ASN.1 Certificate object. 4. I am a layman in regards to DNS terminology. Does the term domain name refer to leafs as well as nodes, i.e. is www.example.com considered to be a domain name? I get confused since registering domain names would not get you that name but it could be slopping thinking on my part. 5. A forward reference to section 4 from section 2.1.1 would probably be helpful so that you know there is more detail later 6. I think that the text in section 4.3 should be expanded slightly to identify the self-issued certificate case as well. I was going to go to the TLS document and grab the text used there and find that although we have been assured that a self-issued certificate is allowed in TLS that there not only is no documentation on it but it says that it MAY be omitted since it is self-issued. Perhaps we should get some clarifying terminology from the TLS group before pursuing this. 7. I would request that you expand the text in section 5 regarding combination to the following Combination --- No support is provided to combine two TLSA certificate associations in a single operation. Support exists for having multiple TLSA certificate associations that are treated independently. 8. In the code section I might suggest // pass PKIX validation using TLSA record as trust anchor if (R.certUsage == 2) { for each PKIX validation chain H { if (C passes PKIX validation in H) { T = the trust anchor in H; if (Match(matchingType, Select(selectorType, T), R) { accept the TLS connection } } } } Jim From mrex@sap.com Tue Oct 4 18:39: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 1EE7521F8C33 for ; Tue, 4 Oct 2011 18:39:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.067 X-Spam-Level: X-Spam-Status: No, score=-10.067 tagged_above=-999 required=5 tests=[AWL=0.182, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LSv-7fCCFzCt for ; Tue, 4 Oct 2011 18:39:48 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 486EA21F8C32 for ; Tue, 4 Oct 2011 18:39:48 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p951gje4020642 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 5 Oct 2011 03:42:47 +0200 (MEST) From: Martin Rex Message-Id: <201110050142.p951gjec013233@fs4113.wdf.sap.corp> To: jimsch@augustcellars.com (Jim Schaad) Date: Wed, 5 Oct 2011 03:42:45 +0200 (MEST) In-Reply-To: <045d01cc8301$fd4204f0$f7c60ed0$@augustcellars.com> from "Jim Schaad" at Oct 4, 11 06:56:24 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: phoffman@imc.org, dane@ietf.org Subject: Re: [dane] -12 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: Wed, 05 Oct 2011 01:39:49 -0000 Jim Schaad wrote: > > 6. I think that the text in section 4.3 should be expanded slightly to > identify the self-issued certificate case as well. I was going to go to the > TLS document and grab the text used there and find that although we have > been assured that a self-issued certificate is allowed in TLS that there not > only is no documentation on it but it says that it MAY be omitted since it > is self-issued. Perhaps we should get some clarifying terminology from the > TLS group before pursuing this. Nope. In TLS, the server/end-entity certificate may not be omitted from the Certificate handshake message. The "MAY be omitted" applies only to a self-signed RootCA certificate at the end of the path. http://tools.ietf.org/html/rfc2246#page-39 The sender's certificate must come first in the list. The semantics of a Certificate handshake message with no Certificates is "Sender has no certificate" is limited to the client's Certificate handshake message. > > > 8. In the code section I might suggest > > // pass PKIX validation using TLSA record as trust anchor > if (R.certUsage == 2) { > for each PKIX validation chain H { > if (C passes PKIX validation in H) { > T = the trust anchor in H; > if (Match(matchingType, Select(selectorType, T), R) { > accept the TLS connection > } > } > } > } As I tried to explain in a previous message, this is backwards to how PKIX validation works and therefore does not compute. When trying to match for certUsage==2, one has to first search the certificate chain provided by the server for a match to the TLSA records, and when a match is found, then 1) if the TLSA match is on the server cert itself (the first cert from the server's Certificate handshake message), then *NO* PKIX certificate path validation can be performed. 2) if the TLSA match is on a later cert from the server's Certificate handshake message, then one has to call the PKIX certificate path validation function, providing the two required input parameters to this function - the cert that matched the TLSA record as trust anchor - the certs from the Server's Certificate handshake message up to (but not including) the cert that matched the TLSA record. -Martin From ietf@augustcellars.com Tue Oct 4 20:04: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 A914221F8B5B for ; Tue, 4 Oct 2011 20:04:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.43 X-Spam-Level: X-Spam-Status: No, score=-3.43 tagged_above=-999 required=5 tests=[AWL=0.169, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mdOVlclAFUmU for ; Tue, 4 Oct 2011 20:04:51 -0700 (PDT) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) by ietfa.amsl.com (Postfix) with ESMTP id C59D221F8B4E for ; Tue, 4 Oct 2011 20:04:51 -0700 (PDT) Received: from Tobias (exodus.augustcellars.com [207.202.179.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id 316DD38EF3; Tue, 4 Oct 2011 20:07:58 -0700 (PDT) From: "Jim Schaad" To: , "'Jim Schaad'" References: <045d01cc8301$fd4204f0$f7c60ed0$@augustcellars.com> from "Jim Schaad" at Oct 4, 11 06:56:24 pm <201110050142.p951gjec013233@fs4113.wdf.sap.corp> In-Reply-To: <201110050142.p951gjec013233@fs4113.wdf.sap.corp> Date: Tue, 4 Oct 2011 20:46:30 -0700 Message-ID: <046401cc8311$5f580b30$1e082190$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us thread-index: AQGlrv0fOFBLClyGIHLtJUdqoi+l4pW6tQKA Cc: phoffman@imc.org, dane@ietf.org Subject: Re: [dane] -12 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, 05 Oct 2011 03:04:52 -0000 > -----Original Message----- > From: dane-bounces@ietf.org [mailto:dane-bounces@ietf.org] On Behalf Of > Martin Rex > Sent: Tuesday, October 04, 2011 6:43 PM > To: Jim Schaad > Cc: phoffman@imc.org; dane@ietf.org > Subject: Re: [dane] -12 > > Jim Schaad wrote: > > > > 6. I think that the text in section 4.3 should be expanded slightly > > to identify the self-issued certificate case as well. I was going to > > go to the TLS document and grab the text used there and find that > > although we have been assured that a self-issued certificate is > > allowed in TLS that there not only is no documentation on it but it > > says that it MAY be omitted since it is self-issued. Perhaps we > > should get some clarifying terminology from the TLS group before pursuing > this. > > Nope. In TLS, the server/end-entity certificate may not be omitted from the > Certificate handshake message. The "MAY be omitted" applies only to a self- > signed RootCA certificate at the end of the path. > > http://tools.ietf.org/html/rfc2246#page-39 > > The sender's certificate must come first in the list. > > The semantics of a Certificate handshake message with no Certificates is > "Sender has no certificate" is limited to the client's Certificate handshake > message. > Actually a better argument is the fact that some bytes are required in the list - so that the cert could not be omitted anyway. I had too loose of a reading of the text - you are correct. > > > > > > > 8. In the code section I might suggest > > > > // pass PKIX validation using TLSA record as trust anchor > > if (R.certUsage == 2) { > > for each PKIX validation chain H { > > if (C passes PKIX validation in H) { > > T = the trust anchor in H; > > if (Match(matchingType, Select(selectorType, T), R) { > > accept the TLS connection > > } > > } > > } > > } > > > As I tried to explain in a previous message, this is backwards to how PKIX > validation works and therefore does not compute. > > When trying to match for certUsage==2, one has to first search the certificate > chain provided by the server for a match to the TLSA records, and when a > match is found, then > 1) if the TLSA match is on the server cert itself (the first cert from > the server's Certificate handshake message), then *NO* > PKIX certificate path validation can be performed. > 2) if the TLSA match is on a later cert from the server's Certificate > handshake message, then one has to call the PKIX certificate > path validation function, providing the two required input > parameters to this function > - the cert that matched the TLSA record as trust anchor > - the certs from the Server's Certificate handshake message > up to (but not including) the cert that matched the TLSA record. How this works depends on what sort of implementation of the code one has. If one is in a situation where there is only one certificate in the chain and it is the trust anchor, then it would be more accurate to say that PKIX validation has undefined behavior so one could define this as either passing or failing depending on how your code is written. My PKIX validator says that if the certificate is the same as a trust anchor the validation code passes without performing any actions. I have also ignored the question of how paths are constructed as well since that is not germane to the issue at hand. This code is descriptive not proscriptive so anything that gives an equivalent answer would be considered to be acceptable. Jim > > > -Martin > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From matt@mattmccutchen.net Tue Oct 4 21:00: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 04A9621F8B73 for ; Tue, 4 Oct 2011 21:00:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.627 X-Spam-Level: X-Spam-Status: No, score=-2.627 tagged_above=-999 required=5 tests=[AWL=-0.028, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F0XY3+qgAxvW for ; Tue, 4 Oct 2011 21:00:27 -0700 (PDT) Received: from homiemail-a2.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id 3240221F8B72 for ; Tue, 4 Oct 2011 21:00:27 -0700 (PDT) Received: from homiemail-a2.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a2.g.dreamhost.com (Postfix) with ESMTP id 11AA9280063; Tue, 4 Oct 2011 21:03:34 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:date:in-reply-to:references:content-type :content-transfer-encoding:message-id:mime-version; q=dns; s= mattmccutchen.net; b=PCT8R86SCPHM8OilE1iileTPsUY6Xm48CCS+du58GRt W/OxfT35K5wMXkak/1ug/H5J0XuGf+AlCFIpdXrzrUQkLi6hzctDIImDvUHfSL7z eETOl2K69pNeKmxh/MIitI8kpgyv9t1p8lHag8TJ0wUGJywY4+RdBMTnyDZIQOOo = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:date:in-reply-to:references:content-type :content-transfer-encoding:message-id:mime-version; s= mattmccutchen.net; bh=ZQUKNE73UAGkE8by8tPHw35+fFU=; b=l+dyUR1UlI ukqG94icqLcgW29mJc57EwOPrFnqcjBiwuGhIS5HpnWh9yj+GOycDOJJd0W6LI0k 1rsHWIvyVBWO5XBwzgjGiSO2mW+q3U01usWSJIAB5e9OVaCiwgTsd8/wfezwmUCn t4WzxlQnQAZygKb7xbxvzgwEgaAaisok4= Received: from [IPv6:::1] (c-98-248-34-40.hsd1.ca.comcast.net [98.248.34.40]) (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 B57C2280061; Tue, 4 Oct 2011 21:03:33 -0700 (PDT) From: Matt McCutchen To: Phillip Hallam-Baker Date: Tue, 04 Oct 2011 21:03:33 -0700 In-Reply-To: References: <201109272223.p8RMNPpA026467@fs4113.wdf.sap.corp> <4E856FB8.9000301@sidn.nl> <1317451765.2130.94.camel@localhost> <4E8A15C6.3000408@sv.cmu.edu> <1317707745.3944.45.camel@localhost> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3 Content-Transfer-Encoding: 7bit Message-ID: <1317787413.1977.20.camel@localhost> Mime-Version: 1.0 Cc: IETF DANE WG list Subject: Re: [dane] Fwd: #36: Only requiring DNSSEC where it is needed 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, 05 Oct 2011 04:00:28 -0000 On Tue, 2011-10-04 at 08:58 -0400, Phillip Hallam-Baker wrote: > DNSSEC deployment can and will be blocked by a government level > adversary. Since that is what we are facing here it seems pointless to > tie the spec to one platform we know the adversary can and will mount > a denial attack on. How does this relate to my message? Did you mean to reply to a different subthread? > Adam's proposal to put the chain in the cert is the way to do key > distribution on the basis of the DNSSEC hierarchy. Well, modulo the > fact that it works much better with legacy browsers if the token can > be put into an OCSP token. Right, in terms of reducing dependencies on third-party servers, stapling positive assertions to TLS is the way to go. It's just more work to implement than directly querying DNSSEC like I did in my prototype. (As Paul pointed out, stapling doesn't work for restrictive assertions.) -- Matt From matt@mattmccutchen.net Tue Oct 4 21:14: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 DAB1621F8B22 for ; Tue, 4 Oct 2011 21:14:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.626 X-Spam-Level: X-Spam-Status: No, score=-2.626 tagged_above=-999 required=5 tests=[AWL=-0.027, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pX6fbj7DHzXY for ; Tue, 4 Oct 2011 21:14:58 -0700 (PDT) Received: from homiemail-a14.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id 6D18621F8B1C for ; Tue, 4 Oct 2011 21:14:58 -0700 (PDT) Received: from homiemail-a14.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a14.g.dreamhost.com (Postfix) with ESMTP id 4BFC2392065; Tue, 4 Oct 2011 21:18:05 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:date:in-reply-to:references:content-type :content-transfer-encoding:message-id:mime-version; q=dns; s= mattmccutchen.net; b=Qjaqc8MIlhMAtbXAZ0CTydsuLaFwXhPXJhNhMzMHsfi visHLcGi5AyIiOuJ2DejS+el68slw96tbCskYOYFiQAMl6N2ktyhRkLBZsLdW9Ya 5lfeMWfxpnCDeV+7jTOmNJmDf2C/QqWJUhT29Rae5ixDaQHVb7g8bZGnMyBo7oXw = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:date:in-reply-to:references:content-type :content-transfer-encoding:message-id:mime-version; s= mattmccutchen.net; bh=/b5UtD9914tKIchnJM9dAzmsaEo=; b=FavD1T48ro VVphn87XWvzWNwIBa5aZdm1KZaAKfOU8fQbFbmpe9HE0pT6sB/NZCNd1NzQI9+UH nuAYxHubRbHcKQ8pYZhGCR/TxLgOW4U9NrxWNaF6wECScg6bNz0jj5uJSij6bTPT pfghWouWAPaq3gOkuhB0mfzyqPuGW6jkI= Received: from [IPv6:::1] (c-98-248-34-40.hsd1.ca.comcast.net [98.248.34.40]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a14.g.dreamhost.com (Postfix) with ESMTPSA id 24E45392063; Tue, 4 Oct 2011 21:18:05 -0700 (PDT) From: Matt McCutchen To: bert hubert Date: Tue, 04 Oct 2011 21:18:03 -0700 In-Reply-To: <20111004062737.GA23425@xs.powerdns.com> References: <060.8aca11012e6c9583642ba071c54be972@trac.tools.ietf.org> <075.e771c9a4f93afa495f330ae9d1ebfa5a@trac.tools.ietf.org> <20111004062737.GA23425@xs.powerdns.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3 Content-Transfer-Encoding: 7bit Message-ID: <1317788285.1977.32.camel@localhost> Mime-Version: 1.0 Cc: dane@ietf.org Subject: Re: [dane] how about not talking about DNSSEC Re: #36: Only requiring DNSSEC where it is needed 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, 05 Oct 2011 04:14:59 -0000 On Tue, 2011-10-04 at 08:27 +0200, bert hubert wrote: > DANE is great stuff, and it specifies how you could trust certificates. > > The DANE material is in turn protected by DNSSEC, so you could trust the > DANE material. > > I see zero reason to burden the DANE standard with details how how DNSSEC > SHOULD or MUST be used. > > This can only hurt us in the long run, say, if DNSSEC standard or practice > changes. Especially the latter. > > Any hopes that implementors might not do the right thing unless they "MUST" > do now weigh up to the downsides mentioned above. > > So how about we say as little as possible on DNSSEC? It's true that we could frame the spec in terms of an abstract integrity protection scheme for DNS data rather than specifically referring to DNSSEC, but I'm not sure what realistic gain in generality you foresee that would justify the decrease in directness. We do need to stipulate that additive assertions MUST NOT be processed unless they are integrity protected, otherwise DANE would regress security. It is also our duty to point out that, if clients wish to gain security from integrity-protected restrictive assertions, they must (1) fully enforce the rules of the integrity protection scheme to confirm the presence or absence of such assertions, failing closed if unable to do so, and (2) process such assertions when present. These two points constitute the essential DANE security model. If we are making other statements about DNSSEC, those might merit reconsideration. -- Matt From matt@mattmccutchen.net Tue Oct 4 21:18: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 5EB3621F8B38 for ; Tue, 4 Oct 2011 21:18:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.625 X-Spam-Level: X-Spam-Status: No, score=-2.625 tagged_above=-999 required=5 tests=[AWL=-0.026, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sp1K+xNOszpQ for ; Tue, 4 Oct 2011 21:18:12 -0700 (PDT) Received: from homiemail-a61.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id D2C4721F8B36 for ; Tue, 4 Oct 2011 21:18:12 -0700 (PDT) Received: from homiemail-a61.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a61.g.dreamhost.com (Postfix) with ESMTP id BE195578077; Tue, 4 Oct 2011 21:21:19 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:date:in-reply-to:references:content-type :content-transfer-encoding:message-id:mime-version; q=dns; s= mattmccutchen.net; b=WSev6bLYueiWjii4Z4P62d9pXIjwNlkogC1IwkxYvOG UkIuw1zljO1mwkjo3kByGo0krLFTv7nuMDQMu9Xb+14mgxtScgIkPL13iJAjLMeZ b21QPKX70jmRjtbHhuulkN/JgVKKAobYu0gloruKSjBxchaSjLYo5dxSbxfYAT7M = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:date:in-reply-to:references:content-type :content-transfer-encoding:message-id:mime-version; s= mattmccutchen.net; bh=+EfKW+MRMi6jeIKksrOVRrhFjMo=; b=oaraf8tUGS GQFamQWuKJxhUlZPRBxQUuYdfddUlj4CWMqzOqFYnhSyQ+dSn2b7UXwW0CTO4/3o 3mHMgYuekpv9G1+jDcqk38K4ntiMXzO1xNF574Rp40UTkTrH8BaK34gUAnE2K63q HpMKVneZpXoqsGAfzpFuIaLw3PBLnwejc= Received: from [IPv6:::1] (c-98-248-34-40.hsd1.ca.comcast.net [98.248.34.40]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a61.g.dreamhost.com (Postfix) with ESMTPSA id 99ADE578073; Tue, 4 Oct 2011 21:21:19 -0700 (PDT) From: Matt McCutchen To: Phillip Hallam-Baker Date: Tue, 04 Oct 2011 21:21:19 -0700 In-Reply-To: References: <060.8aca11012e6c9583642ba071c54be972@trac.tools.ietf.org> <075.e771c9a4f93afa495f330ae9d1ebfa5a@trac.tools.ietf.org> <20111004062737.GA23425@xs.powerdns.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3 Content-Transfer-Encoding: 7bit Message-ID: <1317788479.1977.35.camel@localhost> Mime-Version: 1.0 Cc: dane@ietf.org Subject: Re: [dane] how about not talking about DNSSEC Re: #36: Only requiring DNSSEC where it is needed 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, 05 Oct 2011 04:18:13 -0000 On Tue, 2011-10-04 at 08:48 -0400, Phillip Hallam-Baker wrote: > I don't think DNSSEC out to the end point client is even desirable. It > might be for a Web browser, it is certainly not desirable for embedded > devices. Since only about 10% of the computers in my house are desktop > or laptop devices and the proportion is dropping sharply, I don't see > a good case to nail DANE to one DNS security approach. The case is "the spec might as well be more direct", unless you can name an DNS security approach other than DNSSEC to which we would want to generalize. Note that delegation over a secure channel to an external DNSSEC resolver the client chooses to trust does not count as a different approach with respect to the discussion of DNSSEC in the spec. -- Matt From ahu@xs.powerdns.com Wed Oct 5 00:25: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 44A6121F8B1E for ; Wed, 5 Oct 2011 00:25:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.281 X-Spam-Level: X-Spam-Status: No, score=-2.281 tagged_above=-999 required=5 tests=[AWL=0.319, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S5DnLeE0ZPz0 for ; Wed, 5 Oct 2011 00:24:59 -0700 (PDT) Received: from xs.powerdns.com (xs.powerdns.com [IPv6:2001:888:2000:1d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 79E6221F8AFD for ; Wed, 5 Oct 2011 00:24:59 -0700 (PDT) Received: from ahu by xs.powerdns.com with local (Exim 4.71) (envelope-from ) id 1RBLta-0003pE-TN; Wed, 05 Oct 2011 09:28:02 +0200 Date: Wed, 5 Oct 2011 09:28:02 +0200 From: bert hubert To: Matt McCutchen Message-ID: <20111005072802.GA13563@xs.powerdns.com> References: <060.8aca11012e6c9583642ba071c54be972@trac.tools.ietf.org> <075.e771c9a4f93afa495f330ae9d1ebfa5a@trac.tools.ietf.org> <20111004062737.GA23425@xs.powerdns.com> <1317788285.1977.32.camel@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1317788285.1977.32.camel@localhost> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: dane@ietf.org Subject: Re: [dane] how about not talking about DNSSEC Re: #36: Only requiring DNSSEC where it is needed 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, 05 Oct 2011 07:25:00 -0000 On Tue, Oct 04, 2011 at 09:18:03PM -0700, Matt McCutchen wrote: > It's true that we could frame the spec in terms of an abstract integrity > protection scheme for DNS data rather than specifically referring to > DNSSEC, but I'm not sure what realistic gain in generality you foresee > that would justify the decrease in directness. It works like this. Standards are a lot like government laws. When we have a law that governs certain things, lawmakers try not to write the law to be too specific, since that would lead to frequent legislative activity just to keep things working. If you define a car too narrowly, people will find ways to build cars that are not "Cars". If we just specify DANE, and leave open how to make sure the data you get is the authentic data, we can leave all the rest to *other* standards. This leaves a lot of room for innovation. Trusted channels, DNSSEC successors, perhaps even 'stapled' certificates. If we however interweave DANE with DNSSEC, we will get a standard that is overbearing. It not only tells us how DANE works, it tells us how to specifically use DNSSEC. And while DNSSEC right now is the most obvious way to do it, it need not be the only way. I am also not sure that the DNSSEC advice we would dish out now will stand the test of time as well as the DANE fundamentals. > These two points constitute the essential DANE security model. If we > are making other statements about DNSSEC, those might merit > reconsideration. I agree fully. In general, we might simply say that only authenticated data MUST be used. Everything else doesn't get you anywhere. Bert From stephen.farrell@cs.tcd.ie Wed Oct 5 01:22: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 0A51021F85AA for ; Wed, 5 Oct 2011 01:22:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.599 X-Spam-Level: X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JQpemFw2t1bL for ; Wed, 5 Oct 2011 01:22:05 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfa.amsl.com (Postfix) with ESMTP id 318B021F85A8 for ; Wed, 5 Oct 2011 01:22:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id B68D2171C75 for ; Wed, 5 Oct 2011 09:25: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=1317803106; bh=6/Ru75MLn5e1Mh FWYMbUapw/gYCbTczj17iXQBQ5G9g=; b=22jY/mncwkb/uq18Fn6ulM7q1u+6f6 4WMZ3gXQahLUOtGgLDvtoDXqr62Dq0DhcXs8YcCI5af0knawg2XNreOD5q+lyiRn Zoh85l4ddtyl3N2P6SyFyoCYnU2+HyEsGKru15rICCSLFZWox9iiSCh1bdNq08kx i4vYC62UHVOUgnW4LjzrGgdWncdjeyzV7XwCqgeBvHTatREPwdEMKKASGuj1bqhP GYtFEaYhCSm9ac4SikoqFDZ+kCJP//pd5qDTfq/YMpUvt34A6pWnhsXDfXE4zAyw 8+lRi8rdoKcNAKSZGhgkPE9B4o32fU+tge8eU59I5xhzcWoV3B1YY5pQ== 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 EkW-UqezzPOa for ; Wed, 5 Oct 2011 09:25:06 +0100 (IST) Received: from [10.87.48.5] (unknown [86.45.56.229]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 62EAD171C72 for ; Wed, 5 Oct 2011 09:25:06 +0100 (IST) Message-ID: <4E8C1458.6040309@cs.tcd.ie> Date: Wed, 05 Oct 2011 09:24:56 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: dane@ietf.org References: <060.8aca11012e6c9583642ba071c54be972@trac.tools.ietf.org> <075.e771c9a4f93afa495f330ae9d1ebfa5a@trac.tools.ietf.org> <20111004062737.GA23425@xs.powerdns.com> <1317788285.1977.32.camel@localhost> <20111005072802.GA13563@xs.powerdns.com> In-Reply-To: <20111005072802.GA13563@xs.powerdns.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dane] how about not talking about DNSSEC Re: #36: Only requiring DNSSEC where it is needed 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, 05 Oct 2011 08:22:27 -0000 Some AD input on this in aspect of the thread: DANE MUST define an interoperable protocol. Note - I'm not saying anything about whether anything needs to be mandatory to use in any particular circumstance, I'm saying that the WG is tasked with defining an interoperable way to do some stuff that requires integrity of some DNS data. And afaik, we don't have thousands of DNS integrity mechanisms from which to choose. Just saying: "sprinkle dust; get DNS integrity" is not sufficient for DANE IMO. The WG need to specify how that integrity, which is at least sometimes required, can be achieved, and you need to do that in an interoperable way that covers the "last mile" issue. So I don't think you really have a "say nothing about DNSSEC" option to be honest. S. From bmanning@karoshi.com Wed Oct 5 02:27: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 BB7AB21F87F0 for ; Wed, 5 Oct 2011 02:27:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.216 X-Spam-Level: X-Spam-Status: No, score=-6.216 tagged_above=-999 required=5 tests=[AWL=0.383, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oe1aopKeGaM5 for ; Wed, 5 Oct 2011 02:27:46 -0700 (PDT) Received: from vacation.karoshi.com (vacation.karoshi.com [198.32.6.68]) by ietfa.amsl.com (Postfix) with ESMTP id 9A2FA21F85F2 for ; Wed, 5 Oct 2011 02:27:46 -0700 (PDT) Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id p959TBEE004008; Wed, 5 Oct 2011 09:29:32 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id p959SkOI004007; Wed, 5 Oct 2011 09:28:46 GMT Date: Wed, 5 Oct 2011 09:28:35 +0000 From: bmanning@vacation.karoshi.com To: Warren Kumari Message-ID: <20111005092835.GA3823@vacation.karoshi.com.> References: <4E8A15C6.3000408@sv.cmu.edu> <20111003201605.GN53886@shinkuro.com> <4E8A196C.5060602@sv.cmu.edu> <20111004005833.64C0014911E0@drugs.dv.isc.org> <20111004032836.A21501492790@drugs.dv.isc.org> <4E8A863D.7030209@sv.cmu.edu> <20111004044851.C04B81492CA3@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Cc: IETF DANE WG list Subject: Re: [dane] Fwd: #36: Only requiring DNSSEC where it is needed 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, 05 Oct 2011 09:27:47 -0000 On Tue, Oct 04, 2011 at 11:47:19AM -0400, Warren Kumari wrote: > > On Oct 4, 2011, at 9:02 AM, Phillip Hallam-Baker wrote: > > > If an enterprise is using DNSSEC to secure its internal network, the > > root of trust for the devices in that network SHOULD and MUST flow > > from a key that is controlled by the enterprise and not by ICANN. > > > That's a fairly strong (and broad) statement, for which I do not think I see much evidence (although I don't know that many enterprises that are signing / validating internal stuff) -- from other folk who have seen enterprise deployments are you seeing enterprises use the IANA root or their own? > > I'm interested -- if DANE folk don't have much visibility here, maybe I'll shuffle this off to the dnssec-deployment list (or DNSOP / EXT / etc)... > > I see many, many organizations that enrobe their corporate networks w/ corporate crypto. (VPN's come to mind) Not all corporate (or say military) networks are going to be connected, full time, all the time, to the ICANN visible root (see the ICANN report on alternate roots, esp in corporate networks .. its been a fact of life for decades) So i beleive that it would be short sighted to presume that -everyone- is part of the always on, always connected, Internet with an ICANN root. In my discussions about DNSSEC over the years, the stance I have always taken is that the ICANN root key is the -least- trustworthy key in my keyring, since so very few people actually have a business relationship with ICANN. I trust my corpoate generated crypto much more - since they pay me. And I trust my ISP more, since I pay them. ICANN's root key is the last key I trust. Afterall, they are the "last resort"... Right? /bill > > > > That is a very basic principle of security that is understood by > > pretty much anyone who is likely to be a DNSSEC early adopter. > > > > > > nsa.gov is not going to chain from the ICANN root. > > > > In fact the intra-governmental squabbling in the US federal govt, was > > so great that we could not even get them all to agree on one root for > > the federal govt. Hence the invention of the bridge CA. > > > > > > On Tue, Oct 4, 2011 at 12:48 AM, Mark Andrews wrote: > >> > >> In message <4E8A863D.7030209@sv.cmu.edu>, Zack Weinberg writes: > >>> On 2011-10-03 8:28 PM, Mark Andrews wrote: > >>>> While signing the root was a significant milestone it really as > > nothing to do with whether DNSSEC records will be passed on recursive > >>>> servers. You need to look at when DNSSEC aware recursive servers > >>>> shipped as they can pass on the records with or without trust anchors > >>>> being configured. > >>>> > >>>> For BIND you need to look at BIND 9.3.0 (DNSSECbis Jan 2005) and > >>>> BIND 9.6.0 (NSEC3 support Dec 2008). As far as BIND is concerned > >>>> all supported versions support NSEC3 and DNSSECbis. > >>> > >>> Until people start consuming DNSSEC data at the edge, nobody in the > >>> middle has any serious incentive to make sure it works; so I think > >>> your estimate of the state of the *installed base* of *everything that > >>> has to pass DNS traffic along* is over-optimistic. > >> > >> In most cases there are only two middle boxes to worry about. The > >> ISP's resolver and the CPE device. The resolver, if it is DNSSEC > >> aware, is already dealing with any upstream issues. That leaves > >> CPE devices which should be field updatable in most cases. > >> > >>> Nicholas Weaver had actual numbers which, as I recall, said it would be > >>> possible to start doing that consuming now, but *not* to treat DNSSEC > >>> outages as evidence of malicious tampering. > >>> > >>> zw > >>> _______________________________________________ > >>> dane mailing list > >>> dane@ietf.org > >>> https://www.ietf.org/mailman/listinfo/dane > >> -- > >> Mark Andrews, ISC > >> 1 Seymour St., Dundas Valley, NSW 2117, Australia > >> PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > >> _______________________________________________ > >> 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 From henry.story@bblfish.net Wed Oct 5 05:07: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 2CA6A21F8B3A for ; Wed, 5 Oct 2011 05:07:18 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0smBnGPmNQ3r for ; Wed, 5 Oct 2011 05:07:17 -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 0A75C21F8B03 for ; Wed, 5 Oct 2011 05:07:16 -0700 (PDT) Received: by wyh21 with SMTP id 21so1866225wyh.31 for ; Wed, 05 Oct 2011 05:10:24 -0700 (PDT) Received: by 10.216.21.74 with SMTP id q52mr6338144weq.36.1317816623791; Wed, 05 Oct 2011 05:10:23 -0700 (PDT) Received: from bblfish.home (AAubervilliers-651-1-158-238.w86-212.abo.wanadoo.fr. [86.212.197.238]) by mx.google.com with ESMTPS id h14sm2580247wbo.7.2011.10.05.05.10.22 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 05 Oct 2011 05:10:22 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=iso-8859-1 From: Henry Story In-Reply-To: <20111004062737.GA23425@xs.powerdns.com> Date: Wed, 5 Oct 2011 14:10:21 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9D116844-A59D-4901-8637-EEE8B69BBDE7@bblfish.net> References: <060.8aca11012e6c9583642ba071c54be972@trac.tools.ietf.org> <075.e771c9a4f93afa495f330ae9d1ebfa5a@trac.tools.ietf.org> <20111004062737.GA23425@xs.powerdns.com> To: bert hubert X-Mailer: Apple Mail (2.1244.3) Cc: dane@ietf.org Subject: Re: [dane] how about not talking about DNSSEC Re: #36: Only requiring DNSSEC where it is needed 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, 05 Oct 2011 12:07:18 -0000 On 4 Oct 2011, at 08:27, bert hubert wrote: > On Thu, Sep 29, 2011 at 09:56:11AM -0700, Zack Weinberg wrote: >>> A related issue is whether clients MUST (1) attempt a DNSSEC query, = (2) >>> fail the handshake unless the query completes with "secure" or = "verified >>> insecure" state, and (3) if a "secure" nonempty TLSA RRset is = returned, >>> process it as described in the spec. This requirement goes hand in = hand >>> with the current statement that clients MUST fail the handshake if = the >>> server cert does not match any TLSA RR; one is not meaningful = without the >>> other. So I think we should make both or neither of these = behaviors >>> conformance requirements (c.f. ticket:26). >>=20 >> Agree entirely (and I vote for "both"). Might want some wiggle room >> in the wording to allow for Adam's DANE-stapling scheme instead of >> client doing its own DNSSEC processing. >=20 > Hi everybody, >=20 > DANE is great stuff, and it specifies how you could trust = certificates. >=20 > The DANE material is in turn protected by DNSSEC, so you could trust = the > DANE material. >=20 > I see zero reason to burden the DANE standard with details how how = DNSSEC > SHOULD or MUST be used. >=20 > This can only hurt us in the long run, say, if DNSSEC standard or = practice > changes. Especially the latter. >=20 > Any hopes that implementors might not do the right thing unless they = "MUST" > do now weigh up to the downsides mentioned above. >=20 > So how about we say as little as possible on DNSSEC?=20 I think there is something to this: Separate semantics and behaviour. = Just have one short RFC that describes the information that goes into DNS, explain = what it means in terms such as: the owner of the domain asserts that for service S the public key used = by that service is pk or=20 the owner of the domain asserts that for service S the X509 = certificate used by that service is xxx or the owner of the domain asserts that for service S the X509 = certificate used by that service is signed by CA c Then have another document that describes how clients should behave, or = how they should reason about this.=20 I think how clients should behave is nearly obvious once you have the = pieces in place, at least obvious per application and context. So of = course if those data structures are on DNS unprotected, then you don't = gain much security with having the info there. On the other hand if the info is=20 The logic of such trust thinking is probably beyond an IETF group, and = should be moved to a space where logicians and engineers can get = together to specify things of this nature. Henry >=20 > Bert > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane Social Web Architect http://bblfish.net/ From mrex@sap.com Wed Oct 5 07: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 549CB21F8DDC for ; Wed, 5 Oct 2011 07:18:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.068 X-Spam-Level: X-Spam-Status: No, score=-10.068 tagged_above=-999 required=5 tests=[AWL=0.181, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ggpk1DQzFWk8 for ; Wed, 5 Oct 2011 07:18: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 5908E21F8DDB for ; Wed, 5 Oct 2011 07:18:54 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p95ELv7b018926 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 5 Oct 2011 16:21:57 +0200 (MEST) From: Martin Rex Message-Id: <201110051421.p95ELufR025367@fs4113.wdf.sap.corp> To: ietf@augustcellars.com (Jim Schaad) Date: Wed, 5 Oct 2011 16:21:56 +0200 (MEST) In-Reply-To: <046401cc8311$5f580b30$1e082190$@augustcellars.com> from "Jim Schaad" at Oct 4, 11 08:46:30 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: phoffman@imc.org, jimsch@augustcellars.com, dane@ietf.org Subject: Re: [dane] -12 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: Wed, 05 Oct 2011 14:18:55 -0000 Jim Schaad wrote: > > Martin Rex wrote: > > > > In TLS, the server/end-entity certificate may not be omitted from the > > Certificate handshake message. The "MAY be omitted" applies only to a > > self-signed RootCA certificate at the end of the path. > > > > http://tools.ietf.org/html/rfc2246#page-39 > > > > The sender's certificate must come first in the list. > > > > The semantics of a Certificate handshake message with no Certificates is > > "Sender has no certificate" is limited to the client's Certificate > > handshake message. > > Actually a better argument is the fact that some bytes are required in the > list - so that the cert could not be omitted anyway. I had too loose of a > reading of the text - you are correct. The certificate_list in TLSv1.0 can be empty (denoted by the lower boundary of the vector), but that is limited to the "sender has no certificate" semantics for the ClientCertificate handshake message that was newly added to TLSv1.0. Compare to SSLv3 http://tools.ietf.org/html/rfc6101#section-5.6.2 where no "empty" Certificate handshake message exists -- in SSLv3 the client signaled "sender has no certificate" with a warning-level SSL alert "no_certificate" instead. http://tools.ietf.org/html/rfc6101#section-5.6.6 > > > > > > > 8. In the code section I might suggest > > > > > > // pass PKIX validation using TLSA record as trust anchor > > > if (R.certUsage == 2) { > > > for each PKIX validation chain H { > > > if (C passes PKIX validation in H) { > > > T = the trust anchor in H; > > > if (Match(matchingType, Select(selectorType, T), R) { > > > accept the TLS connection > > > } > > > } > > > } > > > } > > > > > > As I tried to explain in a previous message, this is backwards to how PKIX > > validation works and therefore does not compute. > > > > When trying to match for certUsage==2, one has to first search the > > certificate chain provided by the server for a match to the TLSA > >records, and when a match is found, then > > 1) if the TLSA match is on the server cert itself (the first cert from > > the server's Certificate handshake message), then *NO* > > PKIX certificate path validation can be performed. > > 2) if the TLSA match is on a later cert from the server's Certificate > > handshake message, then one has to call the PKIX certificate > > path validation function, providing the two required input > > parameters to this function > > - the cert that matched the TLSA record as trust anchor > > - the certs from the Server's Certificate handshake message > > up to (but not including) the cert that matched the TLSA record. > > How this works depends on what sort of implementation of the code one has. > If one is in a situation where there is only one certificate in the chain > and it is the trust anchor, then it would be more accurate to say that PKIX > validation has undefined behavior so one could define this as either passing > or failing depending on how your code is written. My PKIX validator says > that if the certificate is the same as a trust anchor the validation code > passes without performing any actions. While this might be what your implementation does, it is not what a "PKIX validator" (conforming to rfc3280/rfc5280) is specified to do. > > I have also ignored the question of how paths are constructed as well since > that is not germane to the issue at hand. In theory, theory and practice are the same, in practice they differ substantially. TLS is explicitly specified to convey a well-formed and complete certificate path through the Certificate handshake message, so in theory, the only preprocessing that is necessary in order to call an rfc5280 section 6.1ff. PKIX certificate path validation for DANE usage type "2" is to chop of certs at the end of the path. In practice, a lot certificate path validation functions include the capability to ignore extra/unneded certificates that go beyond the certificate that is provided as "trust anchor", which is more than the original "X.509 certificate path validation function" calls for by specifying that self-signed certs in the path are ignroed. > > This code is descriptive not proscriptive so anything that gives an > equivalent answer would be considered to be acceptable. Although I do agree that most implementations of PKI and certificate path validation functions likely go beyond what rfc3280/rfc5280 section 6.1ff. specifies, I still believe that all specifications that refer to PKIX certificate path validation should be consistent with what PKIX certificate path validation actually specifies (including the required and exact input parameters to the path validation function). -Martin From hallam@gmail.com Wed Oct 5 08:24: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 925D621F8AF7 for ; Wed, 5 Oct 2011 08:24:51 -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.110, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FHpSi-aCWaW3 for ; Wed, 5 Oct 2011 08:24:50 -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 A2AA721F8A97 for ; Wed, 5 Oct 2011 08:24:50 -0700 (PDT) Received: by gyd12 with SMTP id 12so2043541gyd.31 for ; Wed, 05 Oct 2011 08:27:58 -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:content-transfer-encoding; bh=obS6HU5TocYTe8BwGZxu75MeD18EjkutzYtFKJrzvTc=; b=IgOaWBsDne6JNCL7x7sU00m4swOTQ7PZ48BpdcqKZ5fUJspoh1hPpvtqwTMB0ZPNKe yFSTx2rP3yRDJt1rNW76wg3+L1QnJgOMZNmDH1VAEzKPwdb+3fKqkTHay0/c25QHcEPQ NSDXvCLs2AiV7ujtkvhrvsUeL3wjOrQGE6XHM= MIME-Version: 1.0 Received: by 10.101.85.15 with SMTP id n15mr796582anl.30.1317828478682; Wed, 05 Oct 2011 08:27:58 -0700 (PDT) Received: by 10.100.212.14 with HTTP; Wed, 5 Oct 2011 08:27:58 -0700 (PDT) In-Reply-To: <20111005072802.GA13563@xs.powerdns.com> References: <060.8aca11012e6c9583642ba071c54be972@trac.tools.ietf.org> <075.e771c9a4f93afa495f330ae9d1ebfa5a@trac.tools.ietf.org> <20111004062737.GA23425@xs.powerdns.com> <1317788285.1977.32.camel@localhost> <20111005072802.GA13563@xs.powerdns.com> Date: Wed, 5 Oct 2011 11:27:58 -0400 Message-ID: From: Phillip Hallam-Baker To: bert hubert Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dane@ietf.org Subject: Re: [dane] how about not talking about DNSSEC Re: #36: Only requiring DNSSEC where it is needed 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, 05 Oct 2011 15:24:51 -0000 In other words, make sure that the spec is bound to 'DNS Security' not DNSSEC version 2011. That is my view as well. If I was working on DNSSEC at the mo I would be arguing against tight coupling lest DANE end up constraining change options in DNSSEC. On Wed, Oct 5, 2011 at 3:28 AM, bert hubert wro= te: > On Tue, Oct 04, 2011 at 09:18:03PM -0700, Matt McCutchen wrote: >> It's true that we could frame the spec in terms of an abstract integrity >> protection scheme for DNS data rather than specifically referring to >> DNSSEC, but I'm not sure what realistic gain in generality you foresee >> that would justify the decrease in directness. > > It works like this. Standards are a lot like government laws. When we hav= e a > law that governs certain things, lawmakers try not to write the law to be > too specific, since that would lead to frequent legislative activity just= to > keep things working. If you define a car too narrowly, people will find w= ays > to build cars that are not "Cars". > > If we just specify DANE, and leave open how to make sure the data you get= is > the authentic data, we can leave all the rest to *other* standards. > > This leaves a lot of room for innovation. Trusted channels, DNSSEC > successors, perhaps even 'stapled' certificates. > > If we however interweave DANE with DNSSEC, we will get a standard that is > overbearing. It not only tells us how DANE works, it tells us how to > specifically use DNSSEC. > > And while DNSSEC right now is the most obvious way to do it, it need not = be > the only way. I am also not sure that the DNSSEC advice we would dish out > now will stand the test of time as well as the DANE fundamentals. > >> These two points constitute the essential DANE security model. =A0If we >> are making other statements about DNSSEC, those might merit >> reconsideration. > > I agree fully. In general, we might simply say that only authenticated da= ta > MUST be used. =A0Everything else doesn't get you anywhere. > > =A0 =A0 =A0 =A0Bert > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > --=20 Website: http://hallambaker.com/ From paul@xelerance.com Wed Oct 5 09:10: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 1A70421F8CB8 for ; Wed, 5 Oct 2011 09:10:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.257 X-Spam-Level: X-Spam-Status: No, score=-4.257 tagged_above=-999 required=5 tests=[AWL=-1.658, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mIRyRBrs-Jdw for ; Wed, 5 Oct 2011 09:10:54 -0700 (PDT) Received: from mx.xelerance.com (mx.xelerance.com [193.110.157.188]) by ietfa.amsl.com (Postfix) with ESMTP id 278FE21F8CC9 for ; Wed, 5 Oct 2011 09:10:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx.xelerance.com (Postfix) with ESMTP id 7F4E9D6; Wed, 5 Oct 2011 12:13:51 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=xelerance.com; h= content-type:content-type:mime-version:user-agent:references :message-id:in-reply-to:subject:subject:from:from:date:date :received:received:received:received; s=smtp; t=1317831230; x= 1318436030; bh=vxl3eGMXB41/3sj7SEh0htVefI9mPBdon/HsiMXwkAg=; b=e MAYQMKQKnk/x3376DEdtDQnIpiobwFXRSBjnm4QQGNsWcBEBH+MFupNtf3x40pyJ DwMMt6QP42pwTHGp8yvBp9p00XM8H094ideeyf7JwlYN/DeAH8yEV+m1pPPcF0gn UQh8NWSttj3REQiFqJADosUz8X6NPlrRYgevqnz6sc= Received: from mx.xelerance.com ([127.0.0.1]) by localhost (mx.xelerance.com [127.0.0.1]) (amavisd-new, port 10026) with LMTP id cFLdh9P2Qn3e; Wed, 5 Oct 2011 12:13:50 -0400 (EDT) Received: from mail.xelerance.com (mail.xelerance.com [193.110.157.189]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.xelerance.com (Postfix) with ESMTPS id C2AE892; Wed, 5 Oct 2011 12:13:50 -0400 (EDT) Received: by mail.xelerance.com (Postfix, from userid 1001) id 21FCEF91; Wed, 5 Oct 2011 12:13:59 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.xelerance.com (Postfix) with ESMTP id 20C7BF19; Wed, 5 Oct 2011 12:13:59 -0400 (EDT) Date: Wed, 5 Oct 2011 12:13:59 -0400 (EDT) From: Paul Wouters To: Stephen Farrell In-Reply-To: <4E8C1458.6040309@cs.tcd.ie> Message-ID: References: <060.8aca11012e6c9583642ba071c54be972@trac.tools.ietf.org> <075.e771c9a4f93afa495f330ae9d1ebfa5a@trac.tools.ietf.org> <20111004062737.GA23425@xs.powerdns.com> <1317788285.1977.32.camel@localhost> <20111005072802.GA13563@xs.powerdns.com> <4E8C1458.6040309@cs.tcd.ie> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dane@ietf.org Subject: Re: [dane] how about not talking about DNSSEC Re: #36: Only requiring DNSSEC where it is needed 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, 05 Oct 2011 16:10:55 -0000 On Wed, 5 Oct 2011, Stephen Farrell wrote: > Just saying: "sprinkle dust; get DNS integrity" is not sufficient > for DANE IMO. The WG need to specify how that integrity, which > is at least sometimes required, can be achieved, and you need > to do that in an interoperable way that covers the "last mile" > issue. I think DANE should state that when DNSSEC is required, it should be DNSSEC including last mile protection. It should not try to specify how to solve the last mile issue on the client. Is that what you meant? I first read this as "DANE should specify the last mile solution", which I thought was out of scope for DANE. Paul From warren@kumari.net Wed Oct 5 09:41: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 2CBE321F8C85 for ; Wed, 5 Oct 2011 09:41:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.65 X-Spam-Level: X-Spam-Status: No, score=-104.65 tagged_above=-999 required=5 tests=[AWL=1.949, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b6Evj7RxAV3E for ; Wed, 5 Oct 2011 09:41:39 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 3145021F8C6C for ; Wed, 5 Oct 2011 09:41:38 -0700 (PDT) Received: from dhcp-172-19-119-117.cbf.corp.google.com (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id 483DE1B402B3; Wed, 5 Oct 2011 12:44:36 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warren Kumari In-Reply-To: <8C0CD951-CEC6-4313-A3FC-A325D9BC558A@kumari.net> Date: Wed, 5 Oct 2011 12:44:33 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <061.add9f922b5dfb2db7544981f78552e7e@trac.tools.ietf.org> <076.bdd0467de056ddca69582bc0104dce57@trac.tools.ietf.org> <1317264820.2975.58.camel@localhost> <8C0CD951-CEC6-4313-A3FC-A325D9BC558A@kumari.net> To: Warren Kumari X-Mailer: Apple Mail (2.1084) Cc: dane@ietf.org Subject: Re: [dane] #33: Publish enough information for the client to achieve the security of its favorite digest 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, 05 Oct 2011 16:41:40 -0000 Ok, and we are calling this. There was *not* support consensus for the 3 solutions (individually or = as a group) and so we will be closing the issue. I apologize in advance for the summary[0], but I wanted to capture the = view of the WG in one place, so this issue can finally be put to bed, = once and for all... W [0]: I realize that summarizing your views down to one sentence = necessarily loses much info -- please let me know if my summary = misrepresents your position... ---------------------------------------------------------- Paul Hoffman, Sept 28th: I do not support any of the three, for the = reasons given before. Martin Rex, Sept 28th: -.5 1. All digests of one cert in one RR -.5 2. Cartesian product requirement -.5 3. Group ID Jim Schaad, Sept 29th: You may not think it makes sense, however some of = us do. (in response to: "I do not see the situation in which the halfway = job of algorithm agility we have now makes sense.") Stephen Kent, Sept 29th: I am not in favor of any of these three options = for dealing with hash alg agility. Matt McCutchen, Sept 28th: 1. All digests of one cert in one RR: +1 2. Cartesian product requirement: +1 3. Group ID: +1 Jakob Schlyter, Sept 29th: no support from me. Richard Barnes, Sept 29th: That's a +1 for "no support". I included the = -3 to try and clarify that it was three negative votes :) Ondrej Sury, Sept 29th: 1. All digests of one cert in one RR (-1)2. Cartesian product = requirement (-1)3. Group ID (-1) Zack Weinberg, Sept 29th: I am +1 on the use case -- that is, I am in favor of providing for (what I understand to be) Matt's goals in *some* fashion. Of the available options: 1. All digests of one cert in one RR -1: unwieldy, complicates = client-side processing. 2. Cartesian product requirement -0: simple and reliable, but imposes = potentially enormous wire overhead. 3. Group ID +1 Bill Manning, Sept 29th: i agree w/ steve here. No support for any of = the three options. Phillip Hallam-Baker, Sept 30th: I agree with Steve, no support for any = of the mechanisms. -------------------- On Sep 29, 2011, at 9:32 AM, Warren Kumari wrote: >=20 > On Sep 28, 2011, at 10:53 PM, Matt McCutchen wrote: >=20 >> On Wed, 2011-09-28 at 17:02 -0400, Warren Kumari wrote: >>> And if folk do wish to show support for any of the 3 solutions I ask = that they do it by Friday 13:00UTC. >>=20 >> Man, that is a short consensus call. >=20 > If you had spoken to the chairs before kicking this off.... >=20 > But I realize I'm being petty, so fine, lets extend it till Wednesday, = that will be 7 days. >=20 > W >=20 >=20 >>=20 >>=20 >> For others' convenience in replying: >>=20 >> 1. All digests of one cert in one RR >> 2. Cartesian product requirement >> 3. Group ID >>=20 >> --=20 >> Matt >>=20 >> _______________________________________________ >> dane mailing list >> dane@ietf.org >> https://www.ietf.org/mailman/listinfo/dane >>=20 >=20 From trac+dane@trac.tools.ietf.org Wed Oct 5 10:28: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 48DFA1F0C5A for ; Wed, 5 Oct 2011 10:28:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.586 X-Spam-Level: X-Spam-Status: No, score=-102.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30LJ32AQMRT8 for ; Wed, 5 Oct 2011 10:28:48 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 5B23E21F8BAB for ; Wed, 5 Oct 2011 10:28:48 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1RBVJp-0003ts-ME; Wed, 05 Oct 2011 13:31:45 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "dane issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-dane-protocol@tools.ietf.org, jakob@kirei.se, matt@mattmccutchen.net, rbarnes@bbn.com, warren@kumari.net X-Trac-Project: dane Date: Wed, 05 Oct 2011 17:31:45 -0000 X-URL: http://tools.ietf.org/dane/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dane/trac/ticket/33#comment:5 Message-ID: <076.9519880983aae7c4df61f7e4cf7fec9e@trac.tools.ietf.org> References: <061.add9f922b5dfb2db7544981f78552e7e@trac.tools.ietf.org> X-Trac-Ticket-ID: 33 In-Reply-To: <061.add9f922b5dfb2db7544981f78552e7e@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-dane-protocol@tools.ietf.org, jakob@kirei.se, matt@mattmccutchen.net, rbarnes@bbn.com, warren@kumari.net, dane@ietf.org X-SA-Exim-Mail-From: trac+dane@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20111005172848.5B23E21F8BAB@ietfa.amsl.com> Resent-Date: Wed, 5 Oct 2011 10:28:48 -0700 (PDT) Resent-From: trac+dane@trac.tools.ietf.org Cc: dane@ietf.org Subject: Re: [dane] #33: Publish enough information for the client to achieve the security of its favorite digest X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 17:28:49 -0000 #33: Publish enough information for the client to achieve the security of its favorite digest Changes (by warren@…): * status: new => closed * resolution: => wontfix Comment: There was *not* support consensus for the 3 solutions (individually or as a group) and so we will be closing the issue. Ref: http://www.ietf.org/mail-archive/web/dane/current/msg03631.html -- ----------------------+----------------------------------------- Reporter: matt@… | Owner: draft-ietf-dane-protocol@… Type: defect | Status: closed Priority: major | Milestone: Component: protocol | Version: Severity: - | Resolution: wontfix Keywords: | ----------------------+----------------------------------------- Ticket URL: dane From ahu@xs.powerdns.com Wed Oct 5 13:58: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 C624F1F0C65 for ; Wed, 5 Oct 2011 13:58:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.321 X-Spam-Level: X-Spam-Status: No, score=-2.321 tagged_above=-999 required=5 tests=[AWL=0.279, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fp6MerXGtQxJ for ; Wed, 5 Oct 2011 13:58:55 -0700 (PDT) Received: from xs.powerdns.com (xs.powerdns.com [IPv6:2001:888:2000:1d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 08BFB1F0C5F for ; Wed, 5 Oct 2011 13:58:54 -0700 (PDT) Received: from ahu by xs.powerdns.com with local (Exim 4.71) (envelope-from ) id 1RBYbG-0001kT-H7; Wed, 05 Oct 2011 23:01:58 +0200 Date: Wed, 5 Oct 2011 23:01:58 +0200 From: bert hubert To: Stephen Farrell Message-ID: <20111005210158.GB598@xs.powerdns.com> References: <060.8aca11012e6c9583642ba071c54be972@trac.tools.ietf.org> <075.e771c9a4f93afa495f330ae9d1ebfa5a@trac.tools.ietf.org> <20111004062737.GA23425@xs.powerdns.com> <1317788285.1977.32.camel@localhost> <20111005072802.GA13563@xs.powerdns.com> <4E8C1458.6040309@cs.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E8C1458.6040309@cs.tcd.ie> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: dane@ietf.org Subject: Re: [dane] how about not talking about DNSSEC Re: #36: Only requiring DNSSEC where it is needed 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, 05 Oct 2011 20:58:55 -0000 On Wed, Oct 05, 2011 at 09:24:56AM +0100, Stephen Farrell wrote: > So I don't think you really have a "say nothing about DNSSEC" > option to be honest. Ok - how about specifying that DNSSEC is an appropriate way to get authenticated data? And to only trust authenticated data? That would get all the benefits, and none of the downsides (ie, tying down either DNSSEC or DANE unnecessarily). Bert -- PowerDNS Website: http://www.powerdns.com/ PowerDNS Community Website: http://wiki.powerdns.com/ From ajs@anvilwalrusden.com Wed Oct 5 14:09: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 A670B21F8C44 for ; Wed, 5 Oct 2011 14:09:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X3n8G43StEHr for ; Wed, 5 Oct 2011 14:09:04 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 0A41921F8C36 for ; Wed, 5 Oct 2011 14:09:03 -0700 (PDT) Received: from shinkuro.com (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id C96AF1ECB41C for ; Wed, 5 Oct 2011 21:12:05 +0000 (UTC) Date: Wed, 5 Oct 2011 17:12:10 -0400 From: Andrew Sullivan To: dane@ietf.org Message-ID: <20111005211209.GO63242@shinkuro.com> References: <060.8aca11012e6c9583642ba071c54be972@trac.tools.ietf.org> <075.e771c9a4f93afa495f330ae9d1ebfa5a@trac.tools.ietf.org> <20111004062737.GA23425@xs.powerdns.com> <1317788285.1977.32.camel@localhost> <20111005072802.GA13563@xs.powerdns.com> <4E8C1458.6040309@cs.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E8C1458.6040309@cs.tcd.ie> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] how about not talking about DNSSEC Re: #36: Only requiring DNSSEC where it is needed 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, 05 Oct 2011 21:09:04 -0000 On Wed, Oct 05, 2011 at 09:24:56AM +0100, Stephen Farrell wrote: > for DANE IMO. The WG need to specify how that integrity, which > is at least sometimes required, can be achieved, and you need > to do that in an interoperable way that covers the "last mile" > issue. It's worth observing, at the same time, that the DNSSEC documents _themselves_ punt on this issue. RFC 4035 says this: 4.9.3. Handling of the AD Bit A non-validating security-aware stub resolver MAY chose to examine the setting of the AD bit in response messages that it receives in order to determine whether the security-aware recursive name server that sent the response claims to have cryptographically verified the data in the Answer and Authority sections of the response message. Note, however, that the responses received by a security-aware stub resolver are heavily dependent on the local policy of the security-aware recursive name server. Therefore, there may be little practical value in checking the status of the AD bit, except perhaps as a debugging aid. In any case, a security-aware stub resolver MUST NOT place any reliance on signature validation allegedly performed on its behalf, except when the security-aware stub resolver obtained the data in question from a trusted security-aware recursive name server via a secure channel. So, if you know the policy of your upstream resolver (and it's good enough), and you know you got the AD bit over a secure channel, then and only then may you rely on that validation. I know of one large vendor that claims it supports DNSSEC validation, and this is exactly the mechanism they're using (via IPSec-delivered policy controls at client configuration time, and IPSec-based connections from those clients to the recursive resolver). So we can't exactly wave this away as a corner case, and they're still not doing DNSSEC at the end point. Won't help you at home, of course, but if you're in your Enterprisey Office Land, it presumably would. I therefore think that Bert's suggestion downthread is not a bad idea. A -- Andrew Sullivan ajs@anvilwalrusden.com From warren@kumari.net Wed Oct 5 14:27: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 3D4B421F8CB1 for ; Wed, 5 Oct 2011 14:27:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.685 X-Spam-Level: X-Spam-Status: No, score=-104.685 tagged_above=-999 required=5 tests=[AWL=1.914, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WNTRu02Piw9w for ; Wed, 5 Oct 2011 14:27:12 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id CAC0721F8CAD for ; Wed, 5 Oct 2011 14:27:12 -0700 (PDT) Received: from dhcp-172-19-119-117.cbf.corp.google.com (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id C4A481B402B3; Wed, 5 Oct 2011 17:30:20 -0400 (EDT) From: Warren Kumari Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 5 Oct 2011 17:30:19 -0400 Message-Id: To: IETF DANE WG list Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [dane] Closing issues #14 and #16 (OpenPGP and Bare Public Keys (once supported by TLS)) 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, 05 Oct 2011 21:27:13 -0000 Hi all, Unless I hear strong objections I am planning on closing Issue #14 - = Bare Public Keys (once supported by TLS) ( = http://trac.tools.ietf.org/wg/dane/trac/ticket/14 ) and Issue #16 - = OpenPGP Certificates = (http://trac.tools.ietf.org/wg/dane/trac/ticket/16). #14 can be reopened after TLS supports BPK (which IMO would be cool).... Would the WG like to discuss #16 or did the discussions in #29 cover it = well enough? W= From mrex@sap.com Wed Oct 5 14:29: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 8FEEF21F8D14 for ; Wed, 5 Oct 2011 14:29:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.069 X-Spam-Level: X-Spam-Status: No, score=-10.069 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3qdqgsfFTs5P for ; Wed, 5 Oct 2011 14:29:25 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 6903321F8D0C for ; Wed, 5 Oct 2011 14:29:25 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p95LWT8O019683 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 5 Oct 2011 23:32:29 +0200 (MEST) From: Martin Rex Message-Id: <201110052132.p95LWTkf020080@fs4113.wdf.sap.corp> To: ajs@anvilwalrusden.com (Andrew Sullivan) Date: Wed, 5 Oct 2011 23:32:29 +0200 (MEST) In-Reply-To: <20111005211209.GO63242@shinkuro.com> from "Andrew Sullivan" at Oct 5, 11 05:12:10 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] how about not talking about DNSSEC Re: #36: Only 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: Wed, 05 Oct 2011 21:29:26 -0000 Andrew Sullivan wrote: > > On Wed, Oct 05, 2011 at 09:24:56AM +0100, Stephen Farrell wrote: > > > for DANE IMO. The WG need to specify how that integrity, which > > is at least sometimes required, can be achieved, and you need > > to do that in an interoperable way that covers the "last mile" > > issue. > > It's worth observing, at the same time, that the DNSSEC documents > _themselves_ punt on this issue. RFC 4035 says this: > > 4.9.3. Handling of the AD Bit > > A non-validating security-aware stub resolver MAY chose to examine > the setting of the AD bit in response messages that it receives in > order to determine whether the security-aware recursive name server > that sent the response claims to have cryptographically verified the > data in the Answer and Authority sections of the response message. > Note, however, that the responses received by a security-aware stub > resolver are heavily dependent on the local policy of the > security-aware recursive name server. Therefore, there may be little > practical value in checking the status of the AD bit, except perhaps > as a debugging aid. In any case, a security-aware stub resolver MUST > NOT place any reliance on signature validation allegedly performed on > its behalf, except when the security-aware stub resolver obtained the > data in question from a trusted security-aware recursive name server > via a secure channel. > > So, if you know the policy of your upstream resolver (and it's good > enough), and you know you got the AD bit over a secure channel, then > and only then may you rely on that validation. I know of one large > vendor that claims it supports DNSSEC validation, and this is exactly > the mechanism they're using (via IPSec-delivered policy controls at > client configuration time, and IPSec-based connections from those > clients to the recursive resolver). So we can't exactly wave this > away as a corner case, and they're still not doing DNSSEC at the end > point. Won't help you at home, of course, but if you're in your > Enterprisey Office Land, it presumably would. If your Enterprixey Office Land lives in a seperate DNS universe (with Internet DNS completely unavailable on the internal network) which is the most reasonable configuration if you're running a seperate network, then a "trustworthy" resolver is a non-solution. My preferred solution would be to tunnel all the necessary DNS records through a TLS extension, where it will transparently work as good as TLS itself and be independent of any firewalls, HTTP-CONNECT proxies, DNS forwards and whathaveyou. And I would be glad if my favourite browser would support a sensible TLS server cert pinning and alternatively TLS server-supports-DANE-via-TLSext pinning. The root-key-rollover for DNS-disconnected browsers/clients would need a solution, though. -Martin From warren@kumari.net Wed Oct 5 14:32: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 CC1D411E80C4 for ; Wed, 5 Oct 2011 14:32:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.718 X-Spam-Level: X-Spam-Status: No, score=-104.718 tagged_above=-999 required=5 tests=[AWL=1.881, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 41G+zva25SAn for ; Wed, 5 Oct 2011 14:32:23 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 5845B11E80C2 for ; Wed, 5 Oct 2011 14:32:23 -0700 (PDT) Received: from dhcp-172-19-119-117.cbf.corp.google.com (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id B38701B402B3; Wed, 5 Oct 2011 17:35:31 -0400 (EDT) From: Warren Kumari Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 5 Oct 2011 17:35:29 -0400 Message-Id: <202D9FA6-2D5A-4DC3-90D3-45C88C3AD538@kumari.net> To: IETF DANE WG list Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [dane] Closing issue #12. 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, 05 Oct 2011 21:32:23 -0000 Unless I hear strong objections I am planning on closing Issue #12 -- = Efficiency Improvements = (http://trac.tools.ietf.org/wg/dane/trac/ticket/12, opened 9 months = ago!) I believe that there has been sufficient discussion on the prefixed DNS = domain names and similar (1, 3, 19, etc) to make this issue closable... W= From stephen.farrell@cs.tcd.ie Wed Oct 5 17:01: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 2FF9121F8B49 for ; Wed, 5 Oct 2011 17:01:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.299 X-Spam-Level: X-Spam-Status: No, score=-104.299 tagged_above=-999 required=5 tests=[AWL=2.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FDI2WCj5xAjL for ; Wed, 5 Oct 2011 17:00:52 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfa.amsl.com (Postfix) with ESMTP id 8228521F8B25 for ; Wed, 5 Oct 2011 17:00:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 696C315356E; Thu, 6 Oct 2011 01:03:56 +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=1317859436; bh=owEgxG66CygHoV +SvTa0/CqTaxKkQ0EIX5yMNpbutQg=; b=ZlHzoSTmOrlt3E+CUiWI396k8FVKeA oTuZeO8bZZ9WMNC3fRDKnEp9jNXSFLbhBINIQiR15pyXHsYcP9Vt7kwD8Xi1vRZS o5WYceBorT68J2n9TyAizz2yNX2QbmaQsqrJHm2cycYoyPkZylkJ9XJYvEuSnNBM XvcvaUPeusDnFdO36pZOkUCTfxOjHXG92tyqu7q/gRMjG61vj9tvMZUu7tSHYMVK LGggTGEwh5drSc/G6dbNa9ZUVpBHWTqQwDkoo/P/rWXbZ0uobn/dtQzzkGIxnQod uLJGPclcv/EdyWw+AxQ4sT759+s9tJFy/328OVxSW247aU3FEv4/a3ww== 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 pJWgUXhjoE4p; Thu, 6 Oct 2011 01:03:56 +0100 (IST) Received: from [10.109.111.61] (62-50-199-254.client.stsn.net [62.50.199.254]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 857C8171C66; Thu, 6 Oct 2011 01:03:55 +0100 (IST) Message-ID: <4E8CF063.7020403@cs.tcd.ie> Date: Thu, 06 Oct 2011 01:03:47 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Andrew Sullivan References: <060.8aca11012e6c9583642ba071c54be972@trac.tools.ietf.org> <075.e771c9a4f93afa495f330ae9d1ebfa5a@trac.tools.ietf.org> <20111004062737.GA23425@xs.powerdns.com> <1317788285.1977.32.camel@localhost> <20111005072802.GA13563@xs.powerdns.com> <4E8C1458.6040309@cs.tcd.ie> <20111005211209.GO63242@shinkuro.com> In-Reply-To: <20111005211209.GO63242@shinkuro.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dane@ietf.org Subject: Re: [dane] how about not talking about DNSSEC Re: #36: Only requiring DNSSEC where it is needed 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, 06 Oct 2011 00:01:13 -0000 Hi Andrew, Trying to clarify... On 10/05/2011 10:12 PM, Andrew Sullivan wrote: > On Wed, Oct 05, 2011 at 09:24:56AM +0100, Stephen Farrell wrote: > >> for DANE IMO. The WG need to specify how that integrity, which >> is at least sometimes required, can be achieved, and you need >> to do that in an interoperable way that covers the "last mile" >> issue. > > It's worth observing, at the same time, that the DNSSEC documents > _themselves_ punt on this issue. RFC 4035 says this: > > 4.9.3. Handling of the AD Bit > > A non-validating security-aware stub resolver MAY chose to examine > the setting of the AD bit in response messages that it receives in > order to determine whether the security-aware recursive name server > that sent the response claims to have cryptographically verified the > data in the Answer and Authority sections of the response message. > Note, however, that the responses received by a security-aware stub > resolver are heavily dependent on the local policy of the > security-aware recursive name server. Therefore, there may be little > practical value in checking the status of the AD bit, except perhaps > as a debugging aid. In any case, a security-aware stub resolver MUST > NOT place any reliance on signature validation allegedly performed on > its behalf, except when the security-aware stub resolver obtained the > data in question from a trusted security-aware recursive name server > via a secure channel. > > So, if you know the policy of your upstream resolver (and it's good > enough), and you know you got the AD bit over a secure channel, then > and only then may you rely on that validation. I know of one large > vendor that claims it supports DNSSEC validation, and this is exactly > the mechanism they're using (via IPSec-delivered policy controls at > client configuration time, and IPSec-based connections from those > clients to the recursive resolver). So we can't exactly wave this > away as a corner case, and they're still not doing DNSSEC at the end > point. Won't help you at home, of course, but if you're in your > Enterprisey Office Land, it presumably would. > > I therefore think that Bert's suggestion downthread is not a bad idea. I was trying (perhaps not well) to say that it would not be acceptable for DANE to simply assert that some DNS data needs integrity without specifying how to achieve that. It could be that the WG adopt the kind of position you relate above (smelly as it is, IMO for non-enterprise use-cases) but the main point is that it a) has to be specified and b) has to be interoperable. Again, I am not saying which specific DNS data needs what specific mechanism to protect it when - that's stuff the WG know way better than I do. I'm also not saying the WG need to pick one and only one way to do stuff, (good though that is), nor am I saying when the WG's favorite mechanisms MUST|SHOULD|MAY need to be applied. I'm just saying that whatever you guys figure out, it needs to be good enough for a fairly crappy programmer (like me, I'm qualified there:-) to be able to use the resulting RFC(s) to achieve interop and so that deployments of that code could (if I've not screwed up as a mediocre programmer) achieve whatever the WG consider the necessary security properties. I continue to disbelieve that simply asserting "integrity required" is sufficient for the above and that, in the end, the WG *will* need to talk about DNSSEC and how it relates to DANE data. S. PS: Yeah - sometimes our new sandcastles are built on our less than ideal old sandcastles. I'm sure that'll still be true long after I'm retired as well. From henry.story@bblfish.net Thu Oct 6 00:59: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 5C27921F8CFE for ; Thu, 6 Oct 2011 00:59:14 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xRBCXihvEWJl for ; Thu, 6 Oct 2011 00:59:11 -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 703BB21F8CF4 for ; Thu, 6 Oct 2011 00:59:11 -0700 (PDT) Received: by wwf22 with SMTP id 22so2661821wwf.13 for ; Thu, 06 Oct 2011 01:02:21 -0700 (PDT) Received: by 10.216.55.210 with SMTP id k60mr565760wec.61.1317888140951; Thu, 06 Oct 2011 01:02:20 -0700 (PDT) Received: from bblfish.home (AAubervilliers-651-1-158-238.w86-212.abo.wanadoo.fr. [86.212.197.238]) by mx.google.com with ESMTPS id i29sm8719152wbp.22.2011.10.06.01.02.18 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 06 Oct 2011 01:02:18 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Henry Story In-Reply-To: <4E8CF063.7020403@cs.tcd.ie> Date: Thu, 6 Oct 2011 10:02:17 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3447831E-F073-4991-A8B7-2E079C2DA489@bblfish.net> References: <060.8aca11012e6c9583642ba071c54be972@trac.tools.ietf.org> <075.e771c9a4f93afa495f330ae9d1ebfa5a@trac.tools.ietf.org> <20111004062737.GA23425@xs.powerdns.com> <1317788285.1977.32.camel@localhost> <20111005072802.GA13563@xs.powerdns.com> <4E8C1458.6040309@cs.tcd.ie> <20111005211209.GO63242@shinkuro.com> <4E8CF063.7020403@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1244.3) Cc: dane@ietf.org Subject: Re: [dane] how about not talking about DNSSEC Re: #36: Only requiring DNSSEC where it is needed 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, 06 Oct 2011 07:59:14 -0000 On 6 Oct 2011, at 02:03, Stephen Farrell wrote: >=20 > Hi Andrew, >=20 > Trying to clarify... >=20 > On 10/05/2011 10:12 PM, Andrew Sullivan wrote: >> On Wed, Oct 05, 2011 at 09:24:56AM +0100, Stephen Farrell wrote: >>=20 >>> for DANE IMO. The WG need to specify how that integrity, which >>> is at least sometimes required, can be achieved, and you need >>> to do that in an interoperable way that covers the "last mile" >>> issue. >>=20 >> It's worth observing, at the same time, that the DNSSEC documents >> _themselves_ punt on this issue. RFC 4035 says this: >>=20 >> 4.9.3. Handling of the AD Bit >>=20 >> A non-validating security-aware stub resolver MAY chose to examine >> the setting of the AD bit in response messages that it receives in >> order to determine whether the security-aware recursive name = server >> that sent the response claims to have cryptographically verified = the >> data in the Answer and Authority sections of the response message. >> Note, however, that the responses received by a security-aware = stub >> resolver are heavily dependent on the local policy of the >> security-aware recursive name server. Therefore, there may be = little >> practical value in checking the status of the AD bit, except = perhaps >> as a debugging aid. In any case, a security-aware stub resolver = MUST >> NOT place any reliance on signature validation allegedly performed = on >> its behalf, except when the security-aware stub resolver obtained = the >> data in question from a trusted security-aware recursive name = server >> via a secure channel. >>=20 >> So, if you know the policy of your upstream resolver (and it's good >> enough), and you know you got the AD bit over a secure channel, then >> and only then may you rely on that validation. I know of one large >> vendor that claims it supports DNSSEC validation, and this is exactly >> the mechanism they're using (via IPSec-delivered policy controls at >> client configuration time, and IPSec-based connections from those >> clients to the recursive resolver). So we can't exactly wave this >> away as a corner case, and they're still not doing DNSSEC at the end >> point. Won't help you at home, of course, but if you're in your >> Enterprisey Office Land, it presumably would. >>=20 >> I therefore think that Bert's suggestion downthread is not a bad = idea. >=20 > I was trying (perhaps not well) to say that it would not be > acceptable for DANE to simply assert that some DNS data needs > integrity without specifying how to achieve that. >=20 > It could be that the WG adopt the kind of position you relate above > (smelly as it is, IMO for non-enterprise use-cases) but the main > point is that it a) has to be specified and b) has to be > interoperable. >=20 > Again, I am not saying which specific DNS data needs what specific > mechanism to protect it when - that's stuff the WG know way better > than I do. I'm also not saying the WG need to pick one and only > one way to do stuff, (good though that is), nor am I saying when > the WG's favorite mechanisms MUST|SHOULD|MAY need to be applied. >=20 > I'm just saying that whatever you guys figure out, it needs to > be good enough for a fairly crappy programmer (like me, I'm qualified > there:-) to be able to use the resulting RFC(s) to achieve interop and > so that deployments of that code could (if I've not screwed up as > a mediocre programmer) achieve whatever the WG consider the > necessary security properties. IT all depends what kind of programmer you are. If you are the one that = needs to=20 program the piece to know what data to put where in DNS then you can = have one RFC specialising in the meaning of the data.=20 Then you can have another RFC on how to secure it. Then another one on how to build a client. Those are three separate tasks. By trying to combine them, you make your = life very complicated in this group. >=20 > I continue to disbelieve that simply asserting "integrity required" > is sufficient for the above and that, in the end, the WG *will* need > to talk about DNSSEC and how it relates to DANE data. >=20 > S. >=20 > PS: Yeah - sometimes our new sandcastles are built on our less > than ideal old sandcastles. I'm sure that'll still be true long > after I'm retired as well. > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane Social Web Architect http://bblfish.net/ From stephen.farrell@cs.tcd.ie Thu Oct 6 01:06: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 D03A821F8C2F for ; Thu, 6 Oct 2011 01:06:51 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 37AwVwkkPXTW for ; Thu, 6 Oct 2011 01:06:51 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfa.amsl.com (Postfix) with ESMTP id 2163921F8C1E for ; Thu, 6 Oct 2011 01:06:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id E801F171C41; Thu, 6 Oct 2011 09:09:56 +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=1317888596; bh=n4JOAA90djoz4e 0n0AApmpAYQirL8v75OjQn0vLKFhI=; b=R4gCVcbvD4lnz8TYMCdewuzMW2AGlM UbgBhW7RbmkYagDj8XIRx4AUxijVZ+21530ZfwuTo+qoxFK3JK+GXuOMAm66QOzl R8yUReco2UuOt5TpZtcnQcv6jYApOJCGExsZP5SWJsJ0933SS0oLUEnj/m9mbLC6 xWb74S93Qy2YiAZ5MLYpSDjV4xzPuujihn7nAcDs05gTPr541wh5Q88Ncju3OHBD c/nAArnfXC1z5Yp2594I+tE5pT75u/hStgNplmAuqAHc/5Vh51x7C6avLl36Qiwo KXQpCR6wNSPD+6MR/Bw+hC81KK83WFT7kOiTXlfxFJysNi3iSRDof9+g== 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 gxT4zbaR0d74; Thu, 6 Oct 2011 09:09:56 +0100 (IST) Received: from [195.37.70.181] (unknown [195.37.70.181]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 45A8B171C3F; Thu, 6 Oct 2011 09:09:53 +0100 (IST) Message-ID: <4E8D6246.5040600@cs.tcd.ie> Date: Thu, 06 Oct 2011 09:09:42 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Henry Story References: <060.8aca11012e6c9583642ba071c54be972@trac.tools.ietf.org> <075.e771c9a4f93afa495f330ae9d1ebfa5a@trac.tools.ietf.org> <20111004062737.GA23425@xs.powerdns.com> <1317788285.1977.32.camel@localhost> <20111005072802.GA13563@xs.powerdns.com> <4E8C1458.6040309@cs.tcd.ie> <20111005211209.GO63242@shinkuro.com> <4E8CF063.7020403@cs.tcd.ie> <3447831E-F073-4991-A8B7-2E079C2DA489@bblfish.net> In-Reply-To: <3447831E-F073-4991-A8B7-2E079C2DA489@bblfish.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dane@ietf.org Subject: Re: [dane] how about not talking about DNSSEC Re: #36: Only requiring DNSSEC where it is needed 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, 06 Oct 2011 08:06:51 -0000 On 10/06/2011 09:02 AM, Henry Story wrote: > IT all depends what kind of programmer you are. If you are the one that needs to > program the piece to know what data to put where in DNS then you can have one > RFC specialising in the meaning of the data. > > Then you can have another RFC on how to secure it. > > Then another one on how to build a client. > > Those are three separate tasks. By trying to combine them, you make your life very complicated in this group. I said nothing about how things get reduced to text in RFCs. There are, as you say, loads of ways to do that. The "how to secure it" work however, has to be done, and not in the infinitely far future IMO. S. From ajs@anvilwalrusden.com Thu Oct 6 06:45: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 EBEFE21F8B6C for ; Thu, 6 Oct 2011 06:45:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FcVzQdaD77Pa for ; Thu, 6 Oct 2011 06:45:38 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 70C1A21F8B5F for ; Thu, 6 Oct 2011 06:45:38 -0700 (PDT) Received: from shinkuro.com (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 192FD1ECB41C for ; Thu, 6 Oct 2011 13:48:40 +0000 (UTC) Date: Thu, 6 Oct 2011 09:48:46 -0400 From: Andrew Sullivan To: dane@ietf.org Message-ID: <20111006134845.GC67889@shinkuro.com> References: <060.8aca11012e6c9583642ba071c54be972@trac.tools.ietf.org> <075.e771c9a4f93afa495f330ae9d1ebfa5a@trac.tools.ietf.org> <20111004062737.GA23425@xs.powerdns.com> <1317788285.1977.32.camel@localhost> <20111005072802.GA13563@xs.powerdns.com> <4E8C1458.6040309@cs.tcd.ie> <20111005211209.GO63242@shinkuro.com> <4E8CF063.7020403@cs.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E8CF063.7020403@cs.tcd.ie> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] how about not talking about DNSSEC Re: #36: Only requiring DNSSEC where it is needed 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, 06 Oct 2011 13:45:39 -0000 On Thu, Oct 06, 2011 at 01:03:47AM +0100, Stephen Farrell wrote: > I was trying (perhaps not well) to say that it would not be > acceptable for DANE to simply assert that some DNS data needs > integrity without specifying how to achieve that. > > It could be that the WG adopt the kind of position you relate above > (smelly as it is, IMO for non-enterprise use-cases) but the main > point is that it a) has to be specified and b) has to be > interoperable. It sounds to me, then, that the only sane thing for DANE to say is MUST use DNSSEC, and leave it at that. RFC 4035 tells you at the moment what you need to do to secure the last hop. If there's an update to DNSSEC such that that changes, the "MUST use DNSSEC" for everything DANE says need not change (because it can get included by reference). I know there are those in this thread who think that's already too prescriptive, but as I have previously argued, I can't imagine anyone using TLSA without DNSSEC, which is the only technology we have for DNS integrity assurance right now. I would be quite stronly opposed to a lot of operational advice about how to use DNSSEC going into any documents from this WG. It's completely off-charter, and there's a perfectly good chartered WG over in OPSAREA whose job that is. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From rbarnes@bbn.com Thu Oct 6 08:02: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 4763A21F8A7A for ; Thu, 6 Oct 2011 08:02:13 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0spPUru8AT+G for ; Thu, 6 Oct 2011 08:02:12 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id BF50221F88A0 for ; Thu, 6 Oct 2011 08:02:12 -0700 (PDT) Received: from dhcp89-089-029.bbn.com ([128.89.89.29]:51026) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1RBpVi-0004PA-RC; Thu, 06 Oct 2011 11:05:22 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <20111006134845.GC67889@shinkuro.com> Date: Thu, 6 Oct 2011 11:05:22 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <66EBCA86-A1AB-49EF-9E00-D654202F17E9@bbn.com> References: <060.8aca11012e6c9583642ba071c54be972@trac.tools.ietf.org> <075.e771c9a4f93afa495f330ae9d1ebfa5a@trac.tools.ietf.org> <20111004062737.GA23425@xs.powerdns.com> <1317788285.1977.32.camel@localhost> <20111005072802.GA13563@xs.powerdns.com> <4E8C1458.6040309@cs.tcd.ie> <20111005211209.GO63242@shinkuro.com> <4E8CF063.7020403@cs.tcd.ie> <20111006134845.GC67889@shinkuro.com> To: Andrew Sullivan X-Mailer: Apple Mail (2.1084) Cc: dane@ietf.org Subject: Re: [dane] how about not talking about DNSSEC Re: #36: Only requiring DNSSEC where it is needed 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, 06 Oct 2011 15:02:13 -0000 To be clear, do you mean "MUST use DNSSEC for all types of DANE record", = or that when there is a record that requires DNSSEC, we just need to say = "use DNSSEC"? Thanks, --Richard On Oct 6, 2011, at 9:48 AM, Andrew Sullivan wrote: > On Thu, Oct 06, 2011 at 01:03:47AM +0100, Stephen Farrell wrote: >=20 >> I was trying (perhaps not well) to say that it would not be >> acceptable for DANE to simply assert that some DNS data needs >> integrity without specifying how to achieve that. >>=20 >> It could be that the WG adopt the kind of position you relate above >> (smelly as it is, IMO for non-enterprise use-cases) but the main >> point is that it a) has to be specified and b) has to be >> interoperable. >=20 > It sounds to me, then, that the only sane thing for DANE to say is > MUST use DNSSEC, and leave it at that. RFC 4035 tells you at the > moment what you need to do to secure the last hop. If there's an > update to DNSSEC such that that changes, the "MUST use DNSSEC" for > everything DANE says need not change (because it can get included by > reference). I know there are those in this thread who think that's > already too prescriptive, but as I have previously argued, I can't > imagine anyone using TLSA without DNSSEC, which is the only technology > we have for DNS integrity assurance right now. >=20 > I would be quite stronly opposed to a lot of operational advice about > how to use DNSSEC going into any documents from this WG. It's > completely off-charter, and there's a perfectly good chartered WG over > in OPSAREA whose job that is. >=20 > Best, >=20 > A >=20 > --=20 > Andrew Sullivan > ajs@anvilwalrusden.com > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From ajs@anvilwalrusden.com Thu Oct 6 09:10: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 0330621F8DAF for ; Thu, 6 Oct 2011 09:10:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dpPlP4yq78tP for ; Thu, 6 Oct 2011 09:09:48 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 2069221F8DE2 for ; Thu, 6 Oct 2011 09:09:36 -0700 (PDT) Received: from shinkuro.com (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id C7A741ECB41C for ; Thu, 6 Oct 2011 16:12:39 +0000 (UTC) Date: Thu, 6 Oct 2011 12:12:46 -0400 From: Andrew Sullivan To: dane@ietf.org Message-ID: <20111006161245.GE67889@shinkuro.com> References: <075.e771c9a4f93afa495f330ae9d1ebfa5a@trac.tools.ietf.org> <20111004062737.GA23425@xs.powerdns.com> <1317788285.1977.32.camel@localhost> <20111005072802.GA13563@xs.powerdns.com> <4E8C1458.6040309@cs.tcd.ie> <20111005211209.GO63242@shinkuro.com> <4E8CF063.7020403@cs.tcd.ie> <20111006134845.GC67889@shinkuro.com> <66EBCA86-A1AB-49EF-9E00-D654202F17E9@bbn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <66EBCA86-A1AB-49EF-9E00-D654202F17E9@bbn.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] how about not talking about DNSSEC Re: #36: Only requiring DNSSEC where it is needed 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, 06 Oct 2011 16:10:12 -0000 On Thu, Oct 06, 2011 at 11:05:22AM -0400, Richard L. Barnes wrote: > To be clear, do you mean "MUST use DNSSEC for all types of DANE record", or that when there is a record that requires DNSSEC, we just need to say "use DNSSEC"? > I guess the latter. I still think people would be mad to use any DANE record without DNSSEC, but I know not everyone agrees and I certainly am not going to argue about that decision. -- Andrew Sullivan ajs@anvilwalrusden.com From paul@xelerance.com Thu Oct 6 11:38: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 4519721F8C55 for ; Thu, 6 Oct 2011 11:38:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.233 X-Spam-Level: X-Spam-Status: No, score=-4.233 tagged_above=-999 required=5 tests=[AWL=-1.634, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lSb9RcIm5wOn for ; Thu, 6 Oct 2011 11:38:49 -0700 (PDT) Received: from mx.xelerance.com (mx.xelerance.com [193.110.157.188]) by ietfa.amsl.com (Postfix) with ESMTP id 79F6E21F87E2 for ; Thu, 6 Oct 2011 11:38:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx.xelerance.com (Postfix) with ESMTP id F2E76DB; Thu, 6 Oct 2011 14:41:56 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=xelerance.com; h= content-type:content-type:mime-version:user-agent:references :message-id:in-reply-to:subject:subject:from:from:date:date :received:received:received:received; s=smtp; t=1317926516; x= 1318531316; bh=jUbZaPTkECKE8Pm2JOWgWPy+/Aq50Sa5nB1y0e/LoIs=; b=b PkW493h3XlXcM9OS/JdgIZQy+C4lOwhhFwTp8CmXuDMZyLJEQcbeaR7zl9rMhFiX l5J4tJU42L9Ur9JHB/QOKuorbsaqI9KPPlLTNCpX7+E6Ma5Lqxb4gS+5WAyiSws/ TpOck0xtoazjcCYISLlSxMdBU8RNIoXxSaGocpC89Q= Received: from mx.xelerance.com ([127.0.0.1]) by localhost (mx.xelerance.com [127.0.0.1]) (amavisd-new, port 10026) with LMTP id b03zjEdsU1yi; Thu, 6 Oct 2011 14:41:56 -0400 (EDT) Received: from mail.xelerance.com (mail.xelerance.com [193.110.157.189]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.xelerance.com (Postfix) with ESMTPS id 66C2ACE; Thu, 6 Oct 2011 14:41:55 -0400 (EDT) Received: by mail.xelerance.com (Postfix, from userid 1001) id 567FAF14; Thu, 6 Oct 2011 14:41:53 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.xelerance.com (Postfix) with ESMTP id 556E7F0C; Thu, 6 Oct 2011 14:41:53 -0400 (EDT) Date: Thu, 6 Oct 2011 14:41:53 -0400 (EDT) From: Paul Wouters To: Andrew Sullivan In-Reply-To: <20111006161245.GE67889@shinkuro.com> Message-ID: References: <075.e771c9a4f93afa495f330ae9d1ebfa5a@trac.tools.ietf.org> <20111004062737.GA23425@xs.powerdns.com> <1317788285.1977.32.camel@localhost> <20111005072802.GA13563@xs.powerdns.com> <4E8C1458.6040309@cs.tcd.ie> <20111005211209.GO63242@shinkuro.com> <4E8CF063.7020403@cs.tcd.ie> <20111006134845.GC67889@shinkuro.com> <66EBCA86-A1AB-49EF-9E00-D654202F17E9@bbn.com> <20111006161245.GE67889@shinkuro.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dane@ietf.org Subject: Re: [dane] how about not talking about DNSSEC Re: #36: Only requiring DNSSEC where it is needed 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, 06 Oct 2011 18:38:50 -0000 On Thu, 6 Oct 2011, Andrew Sullivan wrote: > On Thu, Oct 06, 2011 at 11:05:22AM -0400, Richard L. Barnes wrote: >> To be clear, do you mean "MUST use DNSSEC for all types of DANE record", or that when there is a record that requires DNSSEC, we just need to say "use DNSSEC"? > > I guess the latter. I still think people would be mad to use any DANE > record without DNSSEC, but I know not everyone agrees and I certainly > am not going to argue about that decision. You cannot conclusively answer "when there is a record" without dnssec. Paul From paul.hoffman@vpnc.org Thu Oct 6 14:28: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 E3D8B21F8D0A for ; Thu, 6 Oct 2011 14:28:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.567 X-Spam-Level: X-Spam-Status: No, score=-102.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FD-eFS+l9jrB for ; Thu, 6 Oct 2011 14:28:40 -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 2E48D21F8D07 for ; Thu, 6 Oct 2011 14:28:40 -0700 (PDT) Received: from [10.20.30.100] (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 p96LVoKM002300 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 6 Oct 2011 14:31:51 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1244.3) From: Paul Hoffman In-Reply-To: <060.8aca11012e6c9583642ba071c54be972@trac.tools.ietf.org> Date: Thu, 6 Oct 2011 14:31:50 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <80C62DC7-259D-48C9-B4B6-BFE6DA68B5F5@vpnc.org> References: <060.8aca11012e6c9583642ba071c54be972@trac.tools.ietf.org> To: IETF DANE WG list X-Mailer: Apple Mail (2.1244.3) Subject: Re: [dane] #36: Only requiring DNSSEC where it is needed 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, 06 Oct 2011 21:28:41 -0000 When Jakob and I discussed the idea of making DNSSEC optional for = certificate types 0 and 1 while still making it mandatory for type 2, we focused on = the security effects on relying parties (clients) but not zone owners = (servers). A few people objected to our proposal based on concern for the zone = owners, and we agree that they too should be considered when making the decision = about requiring DNSSEC. If the WG agrees with this change, the following explanation (or = something like it) should appear in the document. Please let us know what you think. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Relying Parties Scenario RP-with: If a TLSA record of type 0 and 1 is received with = DNSSEC, then the relying party is sure that the zone owner is specifying that particular certificate. Scenario RP-without: If a TLSA record of type 0 and 1 is received = without DNSSEC, then the relying party can still safely use the TLSA record to = limit the PKIX validation. In Scenario RP-without, an attacker cannot make the relying party use a certificate that would have otherwise been unusable = for authenticating the TLS server. Zone Owners Scenario ZO-with: If a TLSA record of type 0 and 1 is hosted with = DNSSEC, then the zone owner has done everything they can to assure integrity of the = content of the records to the relying party. Scenario ZO-with-RP-with: In scenario ZO-with, if the relying party = uses DNSSEC, they will either receive the published TLSA records or, if = the records were modified by an attacker, they will not get the records = at all. In Scenario ZO-with-RP-with, an attacker gains no advantage by = changing the data or stripping the signature because the result of doing so are = the same as Scenario RP-without. Scenario ZO-with-RP-without: In scenario ZO-with, if the relying = party does not use DNSSEC, then the relying party can still safely use the TLSA = record to limit the PKIX validation; for an attacker, the results of = Scenario ZO-with-RP-without are the same as Scenario RP-without. Scenario ZO-without: If a TLSA record of type 0 and 1 is hosted without DNSSEC, the result is always the same as for Scenario RP-without. --Paul Hoffman= From mrex@sap.com Thu Oct 6 15:04: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 E99AD1F0C70 for ; Thu, 6 Oct 2011 15:04:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.071 X-Spam-Level: X-Spam-Status: No, score=-10.071 tagged_above=-999 required=5 tests=[AWL=0.178, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rXscbi+Er8JK for ; Thu, 6 Oct 2011 15:04:40 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 32CDC1F0C6D for ; Thu, 6 Oct 2011 15:04:40 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p96M7nvo019960 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 7 Oct 2011 00:07:49 +0200 (MEST) From: Martin Rex Message-Id: <201110062207.p96M7nil014763@fs4113.wdf.sap.corp> To: paul.hoffman@vpnc.org (Paul Hoffman) Date: Fri, 7 Oct 2011 00:07:49 +0200 (MEST) In-Reply-To: <80C62DC7-259D-48C9-B4B6-BFE6DA68B5F5@vpnc.org> from "Paul Hoffman" at Oct 6, 11 02:31: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] #36: Only requiring DNSSEC where it is needed 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, 06 Oct 2011 22:04:41 -0000 Paul Hoffman wrote: > > Relying Parties > > Scenario RP-with: If a TLSA record of type 0 and 1 is received with DNSSEC, > then the relying party is sure that the zone owner is specifying that > particular certificate. Correct. > > Scenario RP-without: If a TLSA record of type 0 and 1 is received without > DNSSEC, then the relying party can still safely use the TLSA record to limit > the PKIX validation. In Scenario RP-without, an attacker cannot make the > relying party use a certificate that would have otherwise been unusable for > authenticating the TLS server. Still wrong. A TLSA record of type 0 or 1 is entirely useless without DNSSEC, because it can be fabricated at will by an active attacker. What the attacker can not "fabricate" is to get the Server cert signed an arbitrary CA from the TLS X.509 PKI. But that is entirely irrelevant here, we are discussing _only_ DANE operation. And DANE without DNSSEC is entirely useless, because there is no additional protection compared to pre-DANE clients, therefore looking at the records at all is a complete waste of CPU cycles. -Martin From zack.weinberg@gmail.com Thu Oct 6 15:40: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 3F35C21F8B75 for ; Thu, 6 Oct 2011 15:40:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.03 X-Spam-Level: X-Spam-Status: No, score=-3.03 tagged_above=-999 required=5 tests=[AWL=-0.053, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2n3wRyeUZYWd for ; Thu, 6 Oct 2011 15:39:59 -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 A947C21F8B74 for ; Thu, 6 Oct 2011 15:39:59 -0700 (PDT) Received: by yxt33 with SMTP id 33so3764827yxt.31 for ; Thu, 06 Oct 2011 15:43:11 -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:content-type; bh=ufFoMilkZ2YRk+TpXCOqI3uz24nCY2TGNadlQW2VTeI=; b=b6jlEf0b043eoT0DC0FjFJCVKJVxsq01+4WO0CC36stUTUF0hnfgfvMoEAmoX8z0Mz fkQy8qBFPyiI1ejj7mpmK1DnBGvjVEmIZrATQixGHPiijkPksx78q4WE8mRAWYooaISy qf1Odfd12z8edhozdLY9OYOdvzWB9wRnbynkY= MIME-Version: 1.0 Received: by 10.68.17.136 with SMTP id o8mr8778286pbd.104.1317940991078; Thu, 06 Oct 2011 15:43:11 -0700 (PDT) Sender: zack.weinberg@gmail.com Received: by 10.68.59.105 with HTTP; Thu, 6 Oct 2011 15:43:10 -0700 (PDT) In-Reply-To: <201110062207.p96M7nil014763@fs4113.wdf.sap.corp> References: <80C62DC7-259D-48C9-B4B6-BFE6DA68B5F5@vpnc.org> <201110062207.p96M7nil014763@fs4113.wdf.sap.corp> Date: Thu, 6 Oct 2011 15:43:10 -0700 X-Google-Sender-Auth: Wfj45hehS7qTQOWe9xS3HsvrdmM Message-ID: From: Zack Weinberg To: dane@ietf.org Content-Type: text/plain; charset=UTF-8 Subject: Re: [dane] #36: Only requiring DNSSEC where it is needed 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, 06 Oct 2011 22:40:00 -0000 On Thu, Oct 6, 2011 at 3:07 PM, Martin Rex wrote: >> Scenario RP-without: If a TLSA record of type 0 and 1 is received without >> DNSSEC, then the relying party can still safely use the TLSA record to limit >> the PKIX validation. In Scenario RP-without, an attacker cannot make the >> relying party use a certificate that would have otherwise been unusable for >> authenticating the TLS server. > > Still wrong. > > A TLSA record of type 0 or 1 is entirely useless without DNSSEC, > because it can be fabricated at will by an active attacker. Against an active network attacker who can intercept and fabricate any packet, I agree. However, an unauthenticated (but assumed-legitimate) type 0/1 record might offer additional protection against a limited network attacker who can reterminate TLS sessions but can *not* tamper with DNS traffic, and who additionally *does* have an improperly issued certificate for the server whose communications they wish to intercept. Whether this is a realistic attacker I do not know, but I'm inclined to rate it unlikely. I can imagine scenarios where the attacker can't touch UDP for some reason, but it seems to me that an attacker who has an improperly issued certificate and the means to use it at all is likely to be able to do arbitrary packet manipulation. Also, this should be weighed against the false sense of security that unauthenticated type 0/1 records might produce, when facing an attacker who *can* forge unauthenticated DNS responses, and the possibility of a novel DoS by generating completely bogus ones. In conclusion, I still don't like unauthenticated TLSA records of any kind. Also, I don't have time to close-read the proposed text right now, but my initial impression is that it tends to confuse rather than clarify. (I do still intend to completely rewrite the spec for clarity's sake, but I don't know when I'm gonna get to it.) zw From dotis@mail-abuse.org Thu Oct 6 16:14: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 5EA8F21F8AFC for ; Thu, 6 Oct 2011 16:14:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.343 X-Spam-Level: X-Spam-Status: No, score=-103.343 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SJBT3RGfdXnn for ; Thu, 6 Oct 2011 16:14:14 -0700 (PDT) Received: from SJDC-SDIRelay1.sdi.trendmicro.com (sjdc-sdirelay1.sdi.trendmicro.com [150.70.64.59]) by ietfa.amsl.com (Postfix) with ESMTP id DCDD621F877F for ; Thu, 6 Oct 2011 16:14:14 -0700 (PDT) Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by SJDC-SDIRelay1.sdi.trendmicro.com (Postfix) with ESMTP id B7B003B0075 for ; Thu, 6 Oct 2011 23:17:23 +0000 (UTC) Received: from US-DOUGO-MAC.local (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id AD4F2A9443B for ; Thu, 6 Oct 2011 23:17:25 +0000 (UTC) Message-ID: <4E8E3705.1040305@mail-abuse.org> Date: Thu, 06 Oct 2011 16:17:25 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: dane@ietf.org References: <80C62DC7-259D-48C9-B4B6-BFE6DA68B5F5@vpnc.org> <201110062207.p96M7nil014763@fs4113.wdf.sap.corp> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dane] #36: Only requiring DNSSEC where it is needed 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, 06 Oct 2011 23:14:15 -0000 On 10/6/11 3:43 PM, Zack Weinberg wrote: > On Thu, Oct 6, 2011 at 3:07 PM, Martin Rex wrote: >>> Scenario RP-without: If a TLSA record of type 0 and 1 is received without >>> DNSSEC, then the relying party can still safely use the TLSA record to limit >>> the PKIX validation. In Scenario RP-without, an attacker cannot make the >>> relying party use a certificate that would have otherwise been unusable for >>> authenticating the TLS server. >> Still wrong. >> >> A TLSA record of type 0 or 1 is entirely useless without DNSSEC, >> because it can be fabricated at will by an active attacker. > Against an active network attacker who can intercept and fabricate any > packet, I agree. > > However, an unauthenticated (but assumed-legitimate) type 0/1 record > might offer additional protection against a limited network attacker > who can reterminate TLS sessions but can *not* tamper with DNS > traffic, and who additionally *does* have an improperly issued > certificate for the server whose communications they wish to > intercept. > > Whether this is a realistic attacker I do not know, but I'm inclined > to rate it unlikely. I can imagine scenarios where the attacker can't > touch UDP for some reason, but it seems to me that an attacker who has > an improperly issued certificate and the means to use it at all is > likely to be able to do arbitrary packet manipulation. Also, this > should be weighed against the false sense of security that > unauthenticated type 0/1 records might produce, when facing an > attacker who *can* forge unauthenticated DNS responses, and the > possibility of a novel DoS by generating completely bogus ones. > > In conclusion, I still don't like unauthenticated TLSA records of any > kind. Also, I don't have time to close-read the proposed text right > now, but my initial impression is that it tends to confuse rather than > clarify. (I do still intend to completely rewrite the spec for > clarity's sake, but I don't know when I'm gonna get to it.) Martin and Zack make a good point. A MitM attacks are not uncommon. These may result from exploited network functions, corrupted spanning trees, adjacent compromised hosts, CPE equipment, etc, etc. Since DANE improves security by avoiding reliance on otherwise untrustworthy network elements, why avoid a need to deploy DNSSEC on which DANE is intended to rely? -Doug From paul.hoffman@vpnc.org Thu Oct 6 16:40: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 11C0921F8D18 for ; Thu, 6 Oct 2011 16:40:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.567 X-Spam-Level: X-Spam-Status: No, score=-102.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wT15hhFH-eZ5 for ; Thu, 6 Oct 2011 16:40:35 -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 9094821F8D17 for ; Thu, 6 Oct 2011 16:40:35 -0700 (PDT) Received: from [10.20.30.100] (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 p96NhkkD080129 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 6 Oct 2011 16:43:47 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <201110062207.p96M7nil014763@fs4113.wdf.sap.corp> Date: Thu, 6 Oct 2011 16:43:46 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201110062207.p96M7nil014763@fs4113.wdf.sap.corp> To: mrex@sap.com X-Mailer: Apple Mail (2.1244.3) Cc: dane@ietf.org Subject: Re: [dane] #36: Only requiring DNSSEC where it is needed 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, 06 Oct 2011 23:40:36 -0000 On Oct 6, 2011, at 3:07 PM, Martin Rex wrote: > Paul Hoffman wrote: >> Scenario RP-without: If a TLSA record of type 0 and 1 is received = without >> DNSSEC, then the relying party can still safely use the TLSA record = to limit >> the PKIX validation. In Scenario RP-without, an attacker cannot make = the >> relying party use a certificate that would have otherwise been = unusable for >> authenticating the TLS server. >=20 > Still wrong. >=20 > A TLSA record of type 0 or 1 is entirely useless without DNSSEC, > because it can be fabricated at will by an active attacker. >=20 > What the attacker can not "fabricate" is to get the Server cert signed > an arbitrary CA from the TLS X.509 PKI. =20 Are you saying that there is no useful attack for an attacker? If so we = are agreeing; if not, I don't see what useful attack you are proposing. > But that is entirely irrelevant > here, we are discussing _only_ DANE operation. And DANE without = DNSSEC > is entirely useless, because there is no additional protection > compared to pre-DANE clients, therefore looking at the records at > all is a complete waste of CPU cycles. Following that line of argument, certs type 0 and 1 *with* DNSSEC are "a = complete waste of CPU cycles", yes? Asked another way, what additional = value to the relying party is a type 0 or 1 certificate association if = they are sure that it came from the domain? --Paul Hoffman From mrex@sap.com Thu Oct 6 16:42: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 ADBB021F8AED for ; Thu, 6 Oct 2011 16:42:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.072 X-Spam-Level: X-Spam-Status: No, score=-10.072 tagged_above=-999 required=5 tests=[AWL=0.177, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id diQiYRYJeuWM for ; Thu, 6 Oct 2011 16:42:42 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 91A3221F8538 for ; Thu, 6 Oct 2011 16:42:42 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p96Njk2A028821 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 7 Oct 2011 01:45:51 +0200 (MEST) From: Martin Rex Message-Id: <201110062345.p96NjkRb020895@fs4113.wdf.sap.corp> To: zack.weinberg@sv.cmu.edu (Zack Weinberg) Date: Fri, 7 Oct 2011 01:45:46 +0200 (MEST) In-Reply-To: from "Zack Weinberg" at Oct 6, 11 03:43:10 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] #36: Only requiring DNSSEC where it is needed 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, 06 Oct 2011 23:42:43 -0000 Zack Weinberg wrote: > > I don't have time to close-read the proposed text right > now, but my initial impression is that it tends to confuse rather than > clarify. I did not understand the new proposed text about zone owners at all and would probably have to read it carefully a few more times in order to figure out what it means and whether that makes sense... > Martin Rex wrote: > > > > A TLSA record of type 0 or 1 is entirely useless without DNSSEC, > > because it can be fabricated at will by an active attacker. > > Against an active network attacker who can intercept and fabricate any > packet, I agree. > > However, an unauthenticated (but assumed-legitimate) type 0/1 record > might offer additional protection against a limited network attacker > who can reterminate TLS sessions but can *not* tamper with DNS > traffic, and who additionally *does* have an improperly issued > certificate for the server whose communications they wish to > intercept. > > Whether this is a realistic attacker I do not know, but I'm inclined > to rate it unlikely. I consider those scenarios where it could help unrealistic and statistically insignificant and I'm more worried about the negative side effects. What does it take for an attacker to make a client talk to a fake server in posession of a fraudulent server cert from the TLS X.509 PKI that will succeed PKIX cert path validation? Either the attacker has to successfully spoof DNS A records (make your client connect to the fake server) or the attacker has complete control over the network or networking gear and can transparently MITM your network connections with the network addresses of the real server. An attacker could use it for his advantage when a DANE-aware TLS client would believe in fake TLSA records, because by spoofing TLSA records the attacker could ensure that the DANE-aware TLS client will abort all connections to he *REAL* server with an error an only establish connections with the fake server without a warning. This is particularly true if the client configures the IP-Address of the real server in the local /etc/hosts (so that the A record can not get spoofed). Believing in insecure TLSA would ensure that all connections to the real server that the attacker did not manage to transparently MITM will get aborted with a DANE-validation error, whereas all connections to the fake server will succeed without error. Personally, I do not even see evaluating insecure TLSA records of type 0/1 in the "obscurity" domain, but in the "pure faith" domain. About as effective as putting up a warning sign like this: http://lechatnoirboutique.com/proddetail.php?prod=FSNoticeAttackCity -Martin From zack.weinberg@gmail.com Thu Oct 6 16:45: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 E1CAC21F8B45 for ; Thu, 6 Oct 2011 16:45:47 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2jG9ZQ3qCpK7 for ; Thu, 6 Oct 2011 16:45:47 -0700 (PDT) Received: from mail-pz0-f50.google.com (mail-pz0-f50.google.com [209.85.210.50]) by ietfa.amsl.com (Postfix) with ESMTP id 7A0DC21F8B35 for ; Thu, 6 Oct 2011 16:45:47 -0700 (PDT) Received: by pzk37 with SMTP id 37so8336811pzk.9 for ; Thu, 06 Oct 2011 16:48:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=Q8GH/IUATD86U1zu2MIF6ZX7Ym+Goj8zOWMznCDRnSQ=; b=LapVBey2un29zf7sLK02k2tkTHRs0eaQQSxvmqTpYhYv48M5HM8hYKjvJ+yFVWv0Mu XuFwFBQRDdlJcRS+sBpom5fizQ9zu/xn1V649cl/imh3cUBOHlmtBLXXbxazP/JsjG+c D4dgjOsIdHUZZ8pLTaan71SxAvCEECIvO5pjo= Received: by 10.68.9.39 with SMTP id w7mr9527674pba.18.1317944939377; Thu, 06 Oct 2011 16:48:59 -0700 (PDT) Received: from visnet-71.csl.sri.com (visnet-71.csl.sri.com. [130.107.98.71]) by mx.google.com with ESMTPS id e3sm24527578pbi.7.2011.10.06.16.48.58 (version=SSLv3 cipher=OTHER); Thu, 06 Oct 2011 16:48:58 -0700 (PDT) Sender: Zack Weinberg Message-ID: <4E8E3E6A.8090401@sv.cmu.edu> Date: Thu, 06 Oct 2011 16:48:58 -0700 From: Zack Weinberg User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: mrex@sap.com References: <201110062345.p96NjkRb020895@fs4113.wdf.sap.corp> In-Reply-To: <201110062345.p96NjkRb020895@fs4113.wdf.sap.corp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dane@ietf.org Subject: Re: [dane] #36: Only requiring DNSSEC where it is needed 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, 06 Oct 2011 23:45:48 -0000 On 2011-10-06 4:45 PM, Martin Rex wrote: > An attacker could use it for his advantage when a DANE-aware TLS client > would believe in fake TLSA records, because by spoofing TLSA records > the attacker could ensure that the DANE-aware TLS client will abort > all connections to he *REAL* server with an error an only establish > connections with the fake server without a warning. This is particularly > true if the client configures the IP-Address of the real server > in the local /etc/hosts (so that the A record can not get spoofed). For avoidance of doubt, this is essentially the scenario I was imagining when I said that unauthenticated type-0/1 TLSA could provide a false sense of security in the presence of a network attacker who could forge DNS records. zw From paul.hoffman@vpnc.org Thu Oct 6 16:46: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 6FD0A11E8080 for ; Thu, 6 Oct 2011 16:46:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.567 X-Spam-Level: X-Spam-Status: No, score=-102.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q+IE47S2tHpn for ; Thu, 6 Oct 2011 16:46:14 -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 D0EDE11E8089 for ; Thu, 6 Oct 2011 16:46:13 -0700 (PDT) Received: from [10.20.30.100] (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 p96NnPuR083560 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 6 Oct 2011 16:49:25 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Thu, 6 Oct 2011 16:49:24 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <80C62DC7-259D-48C9-B4B6-BFE6DA68B5F5@vpnc.org> <201110062207.p96M7nil014763@fs4113.wdf.sap.corp> To: Zack Weinberg X-Mailer: Apple Mail (2.1244.3) Cc: dane@ietf.org Subject: Re: [dane] #36: Only requiring DNSSEC where it is needed 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, 06 Oct 2011 23:46:14 -0000 On Oct 6, 2011, at 3:43 PM, Zack Weinberg wrote: > On Thu, Oct 6, 2011 at 3:07 PM, Martin Rex wrote: >>> Scenario RP-without: If a TLSA record of type 0 and 1 is received = without >>> DNSSEC, then the relying party can still safely use the TLSA record = to limit >>> the PKIX validation. In Scenario RP-without, an attacker cannot make = the >>> relying party use a certificate that would have otherwise been = unusable for >>> authenticating the TLS server. >>=20 >> Still wrong. >>=20 >> A TLSA record of type 0 or 1 is entirely useless without DNSSEC, >> because it can be fabricated at will by an active attacker. >=20 > Against an active network attacker who can intercept and fabricate any > packet, I agree. I'll ask the same question I ask Martin: what attack is made possible by = such an attacker that has any value to the attacker? > However, an unauthenticated (but assumed-legitimate) type 0/1 record > might offer additional protection against a limited network attacker > who can reterminate TLS sessions but can *not* tamper with DNS > traffic, and who additionally *does* have an improperly issued > certificate for the server whose communications they wish to > intercept. >=20 > Whether this is a realistic attacker I do not know, but I'm inclined > to rate it unlikely. =20 It seems reasonably likely to be of value to me. Assume the relying = party talks to the same TLS host twice, and an attacker becomes active = between those two events. If the TTL on the TLSA record from the first = event is still in effect for the second event, the attack fails. > I can imagine scenarios where the attacker can't > touch UDP for some reason, but it seems to me that an attacker who has > an improperly issued certificate and the means to use it at all is > likely to be able to do arbitrary packet manipulation. Also, this > should be weighed against the false sense of security that > unauthenticated type 0/1 records might produce, when facing an > attacker who *can* forge unauthenticated DNS responses, and the > possibility of a novel DoS by generating completely bogus ones. An attacker who can create a DoS by generating bogus TLSA records can do = the same with bogus A records. TLSA does not introduce anything new = there, does it? > In conclusion, I still don't like unauthenticated TLSA records of any > kind. Also, I don't have time to close-read the proposed text right > now, but my initial impression is that it tends to confuse rather than > clarify. =20 That would be bad; please so find time to read it and poke holes in any = of the attack scenarios. > (I do still intend to completely rewrite the spec for > clarity's sake, but I don't know when I'm gonna get to it.) That would be much appreciated as well. --Paul Hoffman From mrex@sap.com Thu Oct 6 17:07: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 7272221F8876 for ; Thu, 6 Oct 2011 17:07:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.072 X-Spam-Level: X-Spam-Status: No, score=-10.072 tagged_above=-999 required=5 tests=[AWL=0.177, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nsVAzKMYy2uU for ; Thu, 6 Oct 2011 17:07:35 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 1C44D21F8801 for ; Thu, 6 Oct 2011 17:07:34 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p970Ai0i027629 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 7 Oct 2011 02:10:44 +0200 (MEST) From: Martin Rex Message-Id: <201110070010.p970AhUU022074@fs4113.wdf.sap.corp> To: zack.weinberg@sv.cmu.edu (Zack Weinberg) Date: Fri, 7 Oct 2011 02:10:43 +0200 (MEST) In-Reply-To: from "Zack Weinberg" at Oct 6, 11 03:43:10 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] #36: Only requiring DNSSEC where it is needed 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, 07 Oct 2011 00:07:40 -0000 Zack Weinberg wrote: > > In conclusion, I still don't like unauthenticated TLSA records of any > kind. Believing in completely unprotected assertions rarely makes sense in security protocols. If the Server would be sending an X.509 cert with a stripped digital signature, should the TLS client believe in the assertion to be correct anyway (not being able to verify it against trust anchors) or unconditionally abort? If the client's OCSP request would be answered with an unsigned OCSP response, should the client still evaluate the response or ignore it? If the client downloaded a CRL where the digital signature had been removed, should it still be evaluating the CRL or entirely ignore it? I firmly believe that it is (a) a bad idea to add TLSA records to zones that are not DNSSEC signed and (b) a bad idea to evaluate TLSA records for which the DNSSEC signature verification could not be performed (that includes NXDOMAIN rather than NSEC/NSEC3 responses). -Martin From paul@xelerance.com Thu Oct 6 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 09B3F21F8C09 for ; Thu, 6 Oct 2011 17:15:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[AWL=-1.611, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5DIZk5XKCbCk for ; Thu, 6 Oct 2011 17:15:47 -0700 (PDT) Received: from mx.xelerance.com (mx.xelerance.com [193.110.157.188]) by ietfa.amsl.com (Postfix) with ESMTP id 411E421F8B94 for ; Thu, 6 Oct 2011 17:15:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx.xelerance.com (Postfix) with ESMTP id 41B89DB; Thu, 6 Oct 2011 20:18:56 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=xelerance.com; h= content-type:content-type:mime-version:user-agent:references :message-id:in-reply-to:subject:subject:from:from:date:date :received:received:received:received; s=smtp; t=1317946735; x= 1318551535; bh=UU1E/YgIUx6DEvhkpLRs75SV8Y0htZZzrLig56GKoME=; b=Q T1pa9LzLTDsfiKjNUbpT2UId9lYQU6QLz2kUok/wcLYE210wvjDAcg6vxHqDuKBk qCiWCRb8sE5nvU6Nz8XZVPGaVM8R7hIu3QL6elYRjJkOuCjYXPrkl5FMKSh/Ervb FQwEAyeEBoG2EFpZ1ntg+HWWVDSi1Hwp017c7I0Tlg= Received: from mx.xelerance.com ([127.0.0.1]) by localhost (mx.xelerance.com [127.0.0.1]) (amavisd-new, port 10026) with LMTP id LmwsfzZE-esT; Thu, 6 Oct 2011 20:18:55 -0400 (EDT) Received: from mail.xelerance.com (mail.xelerance.com [193.110.157.189]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.xelerance.com (Postfix) with ESMTPS id 0C6BCCE; Thu, 6 Oct 2011 20:18:54 -0400 (EDT) Received: by mail.xelerance.com (Postfix, from userid 1001) id 1D2A9F14; Thu, 6 Oct 2011 20:18:52 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.xelerance.com (Postfix) with ESMTP id 16D30F03; Thu, 6 Oct 2011 20:18:52 -0400 (EDT) Date: Thu, 6 Oct 2011 20:18:52 -0400 (EDT) From: Paul Wouters To: Paul Hoffman In-Reply-To: Message-ID: References: <80C62DC7-259D-48C9-B4B6-BFE6DA68B5F5@vpnc.org> <201110062207.p96M7nil014763@fs4113.wdf.sap.corp> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: dane@ietf.org Subject: Re: [dane] #36: Only requiring DNSSEC where it is needed 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, 07 Oct 2011 00:15:48 -0000 On Thu, 6 Oct 2011, Paul Hoffman wrote: > It seems reasonably likely to be of value to me. Assume the relying party talks to the same TLS host twice, and an attacker becomes active between those two events. If the TTL on the TLSA record from the first event is still in effect for the second event, the attack fails. This scenario adds nothing to caching the PKIX certificate with using HSTS. If you assume the client already connected once and can re-use cached information, there is nothing TLSA adds to that. You can then even obtain a TLSA within the PKIX cert that is actually covered by a signature from the PKIX CA chain. It further assumes a browser that is not restarted or keeps cache between runs. And the attacker would only just have to wait TTL seconds and forge the next request for the TLSA record and return NXDOMAIN (unvalidated!) anyway, so at best it is a temporary stop-gap. It's simply not worth the complicated scenario descriptions of "zones", "scenarios" and RP-without and ZO-with-RP-without terminology. This is becoming rather the 0.001% corner case for use of DANE without DNSSEC. I will claim that implementors making mistakes on when DNSSEC validation can be absent will cause a higher failure error then the temporary gain from this obscure corner case. I'm not in favour of distributing public keys or hashes without cryptographic protection in general and then using such information to make cryptographic decisions (comparing hashes). It's bad practise. Paul From zack.weinberg@gmail.com Thu Oct 6 17:15: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 EC63421F8C1E for ; Thu, 6 Oct 2011 17:15:51 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z56PRs1xGlL7 for ; Thu, 6 Oct 2011 17:15:51 -0700 (PDT) Received: from mail-pz0-f50.google.com (mail-pz0-f50.google.com [209.85.210.50]) by ietfa.amsl.com (Postfix) with ESMTP id 1E4C121F8B94 for ; Thu, 6 Oct 2011 17:15:49 -0700 (PDT) Received: by pzk37 with SMTP id 37so8392146pzk.9 for ; Thu, 06 Oct 2011 17:19:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=ZYiwDorSuOyHD5KUD2seIqNehWvnbP6paAwFc0/Xiwc=; b=eeyj5IEqm7zNmVczg5bihPlFAOUJNNBwBrXpU7lZ2GfnD5OTgsscHM4s9BRzFrtGdN PWsKWTW9gH+wDA7iJHEaLA4VPHnU57oVQtITqpqxuoHnciIH3kGcLxXPdPvVu/kbp/Oj GM880wrFLQCD4kpv5ffX0hcmKvagOfGn8octc= Received: by 10.68.31.132 with SMTP id a4mr9667755pbi.26.1317946741645; Thu, 06 Oct 2011 17:19:01 -0700 (PDT) Received: from visnet-71.csl.sri.com (visnet-71.csl.sri.com. [130.107.98.71]) by mx.google.com with ESMTPS id e7sm24828581pbq.1.2011.10.06.17.19.01 (version=SSLv3 cipher=OTHER); Thu, 06 Oct 2011 17:19:01 -0700 (PDT) Sender: Zack Weinberg Message-ID: <4E8E4574.5080809@sv.cmu.edu> Date: Thu, 06 Oct 2011 17:19:00 -0700 From: Zack Weinberg User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: dane@ietf.org References: <80C62DC7-259D-48C9-B4B6-BFE6DA68B5F5@vpnc.org> <201110062207.p96M7nil014763@fs4113.wdf.sap.corp> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dane] #36: Only requiring DNSSEC where it is needed 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, 07 Oct 2011 00:15:52 -0000 On 2011-10-06 4:49 PM, Paul Hoffman wrote: > On Oct 6, 2011, at 3:43 PM, Zack Weinberg wrote: >> On Thu, Oct 6, 2011 at 3:07 PM, Martin Rex wrote: >>> A TLSA record of type 0 or 1 is entirely useless without DNSSEC, >>> because it can be fabricated at will by an active attacker. >> >> Against an active network attacker who can intercept and fabricate any >> packet, I agree. > > I'll ask the same question I ask Martin: what attack is made possible > by such an attacker that has any value to the attacker? Well, there's the attack Martin just described, against a site that has *not* deployed TLSA, where the attacker poisons the victim's DNS cache with a TLSA record that specifies *the attacker's* (forged) certificate, thus achieving DoS precisely when their own MITM is inactive. (Precisely the inverse of the scenario you described, where the local DNS cache *protects* from an attacker who can't forge these records.) It is my impression that local DNS caches don't last very long, which makes both sides of that coin not all that compelling to me. What I _am_ worried about, though, is a server operator who deploys an unauthenticated TLSA0/1 record and honestly believes that this will defend against a MITM armed with a forged certificate, because the possibility that the MITM can tamper with the DNS has not occurred to them! Remarkable foolishness? Perhaps, but nobody ever went broke by overestimating the foolishness of any given group of people, eh? > Assume the relyingparty talks to the same TLS host twice, and > an attacker becomes active between those two events. If the TTL > on the TLSA record from the first event is still in effect for > the second event, the attack fails. See above re: expiry of local DNS caches. > An attacker who can create a DoS by generating bogus TLSA records > can do the same with bogus A records. TLSA does not introduce > anything new there, does it? A records can be pinned in /etc/hosts; TLSA forgery might permit a DoS against someone who's been so diligent as to do so. (I imagine that very, very few people do this, but it is a possibility.) >> Also, I don't have time to close-read the proposed text right >> now, but my initial impression is that it tends to confuse >> rather than clarify. > > That would be bad; please so find time to read it and poke holes > in any of the attack scenarios. It would help me if you said approximately where you mean to add this to the current draft. zw From paul@xelerance.com Thu Oct 6 17:21: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 8308021F8C04 for ; Thu, 6 Oct 2011 17:21:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.188 X-Spam-Level: X-Spam-Status: No, score=-4.188 tagged_above=-999 required=5 tests=[AWL=-1.589, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zu-ZQeXwHXyp for ; Thu, 6 Oct 2011 17:21:01 -0700 (PDT) Received: from mx.xelerance.com (mx.xelerance.com [193.110.157.188]) by ietfa.amsl.com (Postfix) with ESMTP id C1B2B21F8B33 for ; Thu, 6 Oct 2011 17:21:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx.xelerance.com (Postfix) with ESMTP id D8092DB; Thu, 6 Oct 2011 20:24:11 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=xelerance.com; h= content-type:content-type:mime-version:user-agent:references :message-id:in-reply-to:subject:subject:from:from:date:date :received:received:received:received; s=smtp; t=1317947051; x= 1318551851; bh=RCWlg1JfU/rKmm4kJo2sv+2kGkNH3QL8m0eXBKfdbL8=; b=E AxTGT6BqNSEMKjRIYO0gMlg0gwSSPLbzN6IBNcCMKm/h+DjsWp52sNABEgBy4N3p KFCna1/pfSfsVp6DY2FcNarwgmifXI6oOU2YpqOG58KNcAD0zX3AI3FjGPyJm1K7 3jKreVrUnuz1BBlVsZJEipii5ES2fQlUfXFyUiWuqE= Received: from mx.xelerance.com ([127.0.0.1]) by localhost (mx.xelerance.com [127.0.0.1]) (amavisd-new, port 10026) with LMTP id PljNb8mHpI2S; Thu, 6 Oct 2011 20:24:11 -0400 (EDT) Received: from mail.xelerance.com (mail.xelerance.com [193.110.157.189]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.xelerance.com (Postfix) with ESMTPS id 2E05ECE; Thu, 6 Oct 2011 20:24:11 -0400 (EDT) Received: by mail.xelerance.com (Postfix, from userid 1001) id 69687F14; Thu, 6 Oct 2011 20:24:09 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.xelerance.com (Postfix) with ESMTP id 6847EF03; Thu, 6 Oct 2011 20:24:09 -0400 (EDT) Date: Thu, 6 Oct 2011 20:24:09 -0400 (EDT) From: Paul Wouters To: Zack Weinberg In-Reply-To: <4E8E4574.5080809@sv.cmu.edu> Message-ID: References: <80C62DC7-259D-48C9-B4B6-BFE6DA68B5F5@vpnc.org> <201110062207.p96M7nil014763@fs4113.wdf.sap.corp> <4E8E4574.5080809@sv.cmu.edu> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dane@ietf.org Subject: Re: [dane] #36: Only requiring DNSSEC where it is needed 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, 07 Oct 2011 00:21:02 -0000 On Thu, 6 Oct 2011, Zack Weinberg wrote: > Well, there's the attack Martin just described, against a site that has *not* > deployed TLSA, where the attacker poisons the victim's DNS cache with a TLSA > record that specifies *the attacker's* (forged) certificate, thus achieving > DoS precisely when their own MITM is inactive. (Precisely the inverse of the > scenario you described, where the local DNS cache *protects* from an attacker > who can't forge these records.) The idea PaulH presented I think was one where an insecure dane record can reduce the scope of PKIX validated certs, not assert anything outside the PKIX scope, so in this scenario the DANE record would be ignored, because it is outside the scope of what the PKIX chain said was valid. Paul From paul.hoffman@vpnc.org Thu Oct 6 17:27: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 E32B021F8B34 for ; Thu, 6 Oct 2011 17:27:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.567 X-Spam-Level: X-Spam-Status: No, score=-102.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id okH6wdmZpRpz for ; Thu, 6 Oct 2011 17:27:43 -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 718A521F8B31 for ; Thu, 6 Oct 2011 17:27:43 -0700 (PDT) Received: from [10.20.30.100] (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 p970UrDY008089 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 6 Oct 2011 17:30:54 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Thu, 6 Oct 2011 17:30:53 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <80C62DC7-259D-48C9-B4B6-BFE6DA68B5F5@vpnc.org> <201110062207.p96M7nil014763@fs4113.wdf.sap.corp> <4E8E4574.5080809@sv.cmu.edu> To: Paul Wouters X-Mailer: Apple Mail (2.1244.3) Cc: dane@ietf.org Subject: Re: [dane] #36: Only requiring DNSSEC where it is needed 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, 07 Oct 2011 00:27:44 -0000 On Oct 6, 2011, at 5:24 PM, Paul Wouters wrote: > On Thu, 6 Oct 2011, Zack Weinberg wrote: >=20 >> Well, there's the attack Martin just described, against a site that = has *not* deployed TLSA, where the attacker poisons the victim's DNS = cache with a TLSA record that specifies *the attacker's* (forged) = certificate, thus achieving DoS precisely when their own MITM is = inactive. (Precisely the inverse of the scenario you described, where = the local DNS cache *protects* from an attacker who can't forge these = records.) >=20 > The idea PaulH presented I think was one where an insecure dane record = can > reduce the scope of PKIX validated certs, not assert anything outside = the PKIX > scope, so in this scenario the DANE record would be ignored, because = it is > outside the scope of what the PKIX chain said was valid. Exactly right. Zack: you do understand that this proposal is to not = require DNSSEC on types 0 and 1 *only*, yes? --Paul Hoffman From paul.hoffman@vpnc.org Thu Oct 6 17:35: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 7F4401F0C3F for ; Thu, 6 Oct 2011 17:35:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.567 X-Spam-Level: X-Spam-Status: No, score=-102.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9YF20DT8Rwaw for ; Thu, 6 Oct 2011 17:35:36 -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 E5A641F0C3D for ; Thu, 6 Oct 2011 17:35:35 -0700 (PDT) Received: from [10.20.30.100] (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 p970cikx012691 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 6 Oct 2011 17:38:45 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Thu, 6 Oct 2011 17:38:44 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7A0088BD-44B1-40BD-B00E-8AC14507486C@vpnc.org> References: <80C62DC7-259D-48C9-B4B6-BFE6DA68B5F5@vpnc.org> <201110062207.p96M7nil014763@fs4113.wdf.sap.corp> To: Paul Wouters X-Mailer: Apple Mail (2.1244.3) Cc: dane@ietf.org Subject: Re: [dane] #36: Only requiring DNSSEC where it is needed 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, 07 Oct 2011 00:35:36 -0000 On Oct 6, 2011, at 5:18 PM, Paul Wouters wrote: > On Thu, 6 Oct 2011, Paul Hoffman wrote: >=20 >> It seems reasonably likely to be of value to me. Assume the relying = party talks to the same TLS host twice, and an attacker becomes active = between those two events. If the TTL on the TLSA record from the first = event is still in effect for the second event, the attack fails. >=20 > This scenario adds nothing to caching the PKIX certificate with > using HSTS. If you assume the client already connected once and > can re-use cached information, there is nothing TLSA adds to that. > You can then even obtain a TLSA within the PKIX cert that is actually > covered by a signature from the PKIX CA chain. Correct. TLSA is useful for HTTP-over-TLS that does not use HSTS, as = well as (foo-that-is-not-HTTP)-over-TLS as well. > It further assumes a browser that is not restarted or keeps cache > between runs. And the attacker would only just have to wait TTL = seconds > and forge the next request for the TLSA record and return NXDOMAIN > (unvalidated!) anyway, so at best it is a temporary stop-gap. Just to be clear, we are not assuming an HTTP browser. Also, the = description above applies if the client restarts; it only does not apply = if the DNS cache is flushed. And, yes, it is only a temporary stop-gap, = but one that we do not have today. > It's simply not worth the complicated scenario descriptions of = "zones", > "scenarios" and RP-without and ZO-with-RP-without terminology. That terminology is there for folks who say that there is an attack = introduced by cert types 0 and 1 being not covered by DNSSEC. The = terminology does not change the protocol. > This is becoming rather the 0.001% corner case for use of DANE without > DNSSEC. I will claim that implementors making mistakes on when DNSSEC > validation can be absent will cause a higher failure error then the > temporary gain from this obscure corner case. If you are only concerned with HTTP browsers that use HSTS, I might = agree. However, the WG is supposed to be dealing with all TLS clients, = such as those for SIP, email, and so on. > I'm not in favour of distributing public keys or hashes without > cryptographic protection in general and then using such information > to make cryptographic decisions (comparing hashes). It's bad practise. If we thought that DNSSEC was already well-deployed to clients today or = next year, I would agree with you. But we all know it is not. Thus, this = proposal. --Paul Hoffman From mrex@sap.com Thu Oct 6 18:23: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 895A921F8B3E for ; Thu, 6 Oct 2011 18:23:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.073 X-Spam-Level: X-Spam-Status: No, score=-10.073 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N5rLISvtzxLY for ; Thu, 6 Oct 2011 18:23:39 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id A6AF321F8B28 for ; Thu, 6 Oct 2011 18:23:38 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p971QlBM011845 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 7 Oct 2011 03:26:47 +0200 (MEST) From: Martin Rex Message-Id: <201110070126.p971QlC3026408@fs4113.wdf.sap.corp> To: paul.hoffman@vpnc.org (Paul Hoffman) Date: Fri, 7 Oct 2011 03:26:47 +0200 (MEST) In-Reply-To: <7A0088BD-44B1-40BD-B00E-8AC14507486C@vpnc.org> from "Paul Hoffman" at Oct 6, 11 05:38:44 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] #36: Only requiring DNSSEC where it is needed 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, 07 Oct 2011 01:23:39 -0000 Paul Hoffman wrote: > > That terminology is there for folks who say that there is an attack > introduced by cert types 0 and 1 being not covered by DNSSEC. > The terminology does not change the protocol. I think we're talking past each other, and may simply have to agree to disagree to end this debate. If you believe the PKIX folks (and in particular the commercial CA operators) then DANE cert types 0 and 1 are entirely useless (i.e. needless complexity) because subverting a CA is impossible. DANE cert types 0 and 1 are only really useful against attackers for which (1) obtaining TLS server certs that validate und TLS X.509 PKI is quite doable and either (2a) reliably DNS-spoofing your TLS client is easy or (2b) reliably MITM your TLS clients network connections is easy. Under those premises it really does not make sense to deceive yourself that unprotected TLSA records provide any security value at all. I firmly believe they do not, but they will likely create the dangerously false impression that unsigned DNS records are trustworthy in any way. > > If we thought that DNSSEC was already well-deployed to clients today > or next year, I would agree with you. But we all know it is not. > Thus, this proposal. Then let's put our energy into creating an TLS extension for conveying the necessary DNSSEC records from the TLS server to the TLS client inband. By creating the dangerously misleading impression that DNS replies are trustworthy without DNSSEC, you will only further delay adoption of both, DNSSEC and DANE. -Martin From zack.weinberg@gmail.com Thu Oct 6 19:01: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 3ACF621F8B03 for ; Thu, 6 Oct 2011 19:01:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.027 X-Spam-Level: X-Spam-Status: No, score=-3.027 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W+4M13Luo5aW for ; Thu, 6 Oct 2011 19:01:40 -0700 (PDT) Received: from mail-pz0-f50.google.com (mail-pz0-f50.google.com [209.85.210.50]) by ietfa.amsl.com (Postfix) with ESMTP id B82FC21F8541 for ; Thu, 6 Oct 2011 19:01:40 -0700 (PDT) Received: by pzk37 with SMTP id 37so8578771pzk.9 for ; Thu, 06 Oct 2011 19:04:53 -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=HY8uKnA3qLP0cuUYl+oL0Qn70XNHSrgH92PGwbdkYyw=; b=UyJ4himoDRe5Fae1muVDmkfLO8Mj6SJUcAicokQw0h698POmZkxtXoMop8Q/POpcaH 9N2LUh2epdBi8PGW/nC8YEv2fzsFXrGK53fabBuPAOc1LVXiz50++oyS5HgHBkXBf2mA LaWiQtea8/uMeh0j67k43joK8v6U4bXjRBfNc= MIME-Version: 1.0 Received: by 10.68.74.65 with SMTP id r1mr2194983pbv.87.1317953093047; Thu, 06 Oct 2011 19:04:53 -0700 (PDT) Sender: zack.weinberg@gmail.com Received: by 10.68.59.105 with HTTP; Thu, 6 Oct 2011 19:04:52 -0700 (PDT) In-Reply-To: References: <80C62DC7-259D-48C9-B4B6-BFE6DA68B5F5@vpnc.org> <201110062207.p96M7nil014763@fs4113.wdf.sap.corp> <4E8E4574.5080809@sv.cmu.edu> Date: Thu, 6 Oct 2011 19:04:52 -0700 X-Google-Sender-Auth: NR0upjATc2brDy4i3Xf8lSdhiAc Message-ID: From: Zack Weinberg To: Paul Hoffman Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: dane@ietf.org Subject: Re: [dane] #36: Only requiring DNSSEC where it is needed 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, 07 Oct 2011 02:01:41 -0000 On Thu, Oct 6, 2011 at 5:30 PM, Paul Hoffman wrote: > On Oct 6, 2011, at 5:24 PM, Paul Wouters wrote: >> On Thu, 6 Oct 2011, Zack Weinberg wrote: >>> Well, there's the attack Martin just described, against a site that has= *not* deployed TLSA, where the attacker poisons the victim's DNS cache wit= h a TLSA record that specifies *the attacker's* (forged) certificate, thus = achieving DoS precisely when their own MITM is inactive. (Precisely the inv= erse of the scenario you described, where the local DNS cache *protects* fr= om an attacker who can't forge these records.) >> >> The idea PaulH presented I think was one where an insecure dane record c= an >> reduce the scope of PKIX validated certs, not assert anything outside th= e PKIX >> scope, Yes, I understood that. >> so in this scenario the DANE record would be ignored, because it is >> outside the scope of what the PKIX chain said was valid. Not if the attacker has an improperly issued server certificate that does in fact chain to some root certificate the victim relies on. That's already a disaster, but unsecured TLSA records potentially make it *worse*, by causing the RP not to trust the legitimate server's certificate anymore. That is my understanding of Martin's scenario. > Exactly right. Zack: you do understand that this proposal is to not requi= re DNSSEC on types 0 and 1 *only*, yes? Yes. I have been arguing that even that is a bad idea from the beginning. zw From zack.weinberg@gmail.com Thu Oct 6 19:04: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 9B97A21F8BA0 for ; Thu, 6 Oct 2011 19:04:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.025 X-Spam-Level: X-Spam-Status: No, score=-3.025 tagged_above=-999 required=5 tests=[AWL=-0.048, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qsoQs56sBN0o for ; Thu, 6 Oct 2011 19:04:22 -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 20DC021F8B3F for ; Thu, 6 Oct 2011 19:04:22 -0700 (PDT) Received: by gyd12 with SMTP id 12so3878152gyd.31 for ; Thu, 06 Oct 2011 19:07:34 -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=gFent8kzyakiV6GULioAFCunTBvP3o/NAlmr20NcB6c=; b=crHfnLJDR05ueJfhKc/6MOEZCPhXqhY5usiGcaKh3RRZ+Dli4NrLypB24fP9Y58l5V /SFdLOEG81qEETF3QU1uHw9HvidsjftfsXzMwoeAMJgRUagDz4gz+iNOMbLcADfAYeXs fE8psGwIBIC/Kfc7cSprYPeuh1Q4JxXjqGge0= MIME-Version: 1.0 Received: by 10.68.6.98 with SMTP id z2mr10256005pbz.36.1317953254054; Thu, 06 Oct 2011 19:07:34 -0700 (PDT) Sender: zack.weinberg@gmail.com Received: by 10.68.59.105 with HTTP; Thu, 6 Oct 2011 19:07:33 -0700 (PDT) In-Reply-To: <7A0088BD-44B1-40BD-B00E-8AC14507486C@vpnc.org> References: <80C62DC7-259D-48C9-B4B6-BFE6DA68B5F5@vpnc.org> <201110062207.p96M7nil014763@fs4113.wdf.sap.corp> <7A0088BD-44B1-40BD-B00E-8AC14507486C@vpnc.org> Date: Thu, 6 Oct 2011 19:07:33 -0700 X-Google-Sender-Auth: Hs8aPcMnC7wa6rWe5NZNeaDmssc Message-ID: From: Zack Weinberg To: Paul Hoffman Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: dane@ietf.org Subject: Re: [dane] #36: Only requiring DNSSEC where it is needed 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, 07 Oct 2011 02:04:22 -0000 On Thu, Oct 6, 2011 at 5:38 PM, Paul Hoffman wrote: > On Oct 6, 2011, at 5:18 PM, Paul Wouters wrote: >> This is becoming rather the 0.001% corner case for use of DANE without >> DNSSEC. =C2=A0I will claim that implementors making mistakes on when DNS= SEC >> validation can be absent will cause a higher failure error then the >> temporary gain from this obscure corner case. > > If you are only concerned with HTTP browsers that use HSTS, I might agree= . > However, the WG is supposed to be dealing with all TLS clients, such as > those for SIP, email, and so on. I do not see why non-HTTP clients are any more or less vulnerable than HTTP clients in the scenarios we are talking about. Please elaborate. zw From i.grok@comcast.net Fri Oct 7 07:19: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 085AD21F8B3E for ; Fri, 7 Oct 2011 07:19:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.647 X-Spam-Level: X-Spam-Status: No, score=-102.647 tagged_above=-999 required=5 tests=[AWL=-0.048, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zeCJBum8ZtI0 for ; Fri, 7 Oct 2011 07:19:15 -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 2B64F21F8BA4 for ; Fri, 7 Oct 2011 07:19:15 -0700 (PDT) Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by qmta03.westchester.pa.mail.comcast.net with comcast id hqKV1h0050Fqzac53qNVGl; Fri, 07 Oct 2011 14:22:29 +0000 Received: from odin.ulthar.us ([68.33.77.0]) by omta08.westchester.pa.mail.comcast.net with comcast id hqNU1h00E00PQ6U3UqNVlC; Fri, 07 Oct 2011 14:22:29 +0000 Received: from odin.ulthar.us (localhost [127.0.0.1]) by odin.ulthar.us (8.14.4/8.14.3) with ESMTP id p97EMR1V002494 for ; Fri, 7 Oct 2011 10:22:27 -0400 Received: (from draco@localhost) by odin.ulthar.us (8.14.4/8.14.4/Submit) id p97EMQQT002492 for dane@ietf.org; Fri, 7 Oct 2011 10:22:26 -0400 Date: Fri, 7 Oct 2011 10:22:26 -0400 From: Scott Schmit To: dane@ietf.org Message-ID: <20111007142226.GB11338@odin.ulthar.us> Mail-Followup-To: dane@ietf.org References: <201110062207.p96M7nil014763@fs4113.wdf.sap.corp> 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] #36: Only requiring DNSSEC where it is needed 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, 07 Oct 2011 14:19:16 -0000 On Thu, Oct 06, 2011 at 04:43:46PM -0700, Paul Hoffman wrote: > On Oct 6, 2011, at 3:07 PM, Martin Rex wrote: > > Paul Hoffman wrote: > >> Scenario RP-without: If a TLSA record of type 0 and 1 is received without > >> DNSSEC, then the relying party can still safely use the TLSA record to limit > >> the PKIX validation. In Scenario RP-without, an attacker cannot make the > >> relying party use a certificate that would have otherwise been unusable for > >> authenticating the TLS server. > > > > Still wrong. > > > > A TLSA record of type 0 or 1 is entirely useless without DNSSEC, > > because it can be fabricated at will by an active attacker. > > > > What the attacker can not "fabricate" is to get the Server cert signed > > an arbitrary CA from the TLS X.509 PKI. > > Are you saying that there is no useful attack for an attacker? If so we are agreeing; if not, I don't see what useful attack you are proposing. > > > But that is entirely irrelevant > > here, we are discussing _only_ DANE operation. And DANE without DNSSEC > > is entirely useless, because there is no additional protection > > compared to pre-DANE clients, therefore looking at the records at > > all is a complete waste of CPU cycles. > > Following that line of argument, certs type 0 and 1 *with* DNSSEC are "a complete waste of CPU cycles", yes? Asked another way, what additional value to the relying party is a type 0 or 1 certificate association if they are sure that it came from the domain? If DNSSEC is required, there are two failure cases: A) The DNSSEC data is secure, but the PKIX chain doesn't match B) The DNSSEC data is bogus For A, the RP knows that one of the following is true: A1) One of the CAs trusted by the RP's TA list is compromised A2) One of the DNSKEYs in the DNSSEC chain is compromised A3) There's been a misconfiguration A3 is a constant issue. Putting that aside, the RP can weigh the relative probability of A1 or A2 and determine if it wants to proceed anyway. Depending on the size of the unconstrained TA/trusted CA pool, A1 is probably far likelier than A2. If A2 is likelier to you than A1, you probably aren't going to bother use DANE. For B, the RP knows that one of the following is true: A3) There's been a misconfiguration B1) It's under attack B2) It's on a network that is "benignly" manipulating DNS (see B1) B3) It's using DNS servers that don't comply with the latest specs (so stop relying on them & retry) Because DNSSEC is required in this scenario, we can't even compare the record to the PKIX cert chain. Something is clearly wrong. If we make DNSSEC optional for type 0/1, we have these cases: A) The DNSSEC data is secure, but the PKIX chain doesn't match B) The DNSSEC data is bogus C) The DNSSEC data is unsecure, and the chain doesn't match D) DNSSEC was used, the RP ignores DNSSEC, and the chain doesn't match (not sure if anyone is proposing this or not) For C, the RP knows that one of the following is true: A1) One of the CAs trusted by the RP's TA list is compromised A3) There's been a misconfiguration C1) One of the authoritative servers in the NS chain is compromised C2) One of the DNS resolvers the RP is relying on have been poisoned C3) Some other MITM is manipulating the DNS traffic Again putting aside A3, the RP must weigh the probability of C1-3 vs A1. C1-3 is relatively easier. Of course, perhaps both A1 and one of C1-3 is true. In any case, A1 is no longer clearly more likely than the alternatives. So now DANE is only useful when it isn't needed? For D, depending on what form the "DNSSEC is optional for 0/1" takes, it may be allowable for a DANE client to ignore the DNSSEC information completely, in which case you not only get all the failure cases from C, but also A & B because you didn't recognise them. But if you require that a DANE client check DNSSEC, but allow for unsecure (not bogus) records, you get all the downsides of DNSSEC checking (B2, B3, increased probability of A3) as well as C1-3 for the unsigned data. I don't think the benefit is really worthwhile. I suppose a consequence of requiring DNSSEC for all cases is that the market chooses not to use DANE because too much stuff breaks DNSSEC. That's a risk. But if DANE is watered down to be too little benefit, the market will choose something else anyway. -- Scott Schmit From mrex@sap.com Fri Oct 7 16:54: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 6599221F8BB8 for ; Fri, 7 Oct 2011 16:54:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.075 X-Spam-Level: X-Spam-Status: No, score=-10.075 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3pVhTZqwfqZm for ; Fri, 7 Oct 2011 16:53:59 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 8C12721F8B35 for ; Fri, 7 Oct 2011 16:53:59 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p97Nv4nE027812 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 8 Oct 2011 01:57:09 +0200 (MEST) From: Martin Rex Message-Id: <201110072357.p97Nv30f027932@fs4113.wdf.sap.corp> To: i.grok@comcast.net (Scott Schmit) Date: Sat, 8 Oct 2011 01:57:03 +0200 (MEST) In-Reply-To: <20111007142226.GB11338@odin.ulthar.us> from "Scott Schmit" at Oct 7, 11 10:22:26 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] #36: Only requiring DNSSEC where it is needed 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, 07 Oct 2011 23:54:00 -0000 Scott Schmit wrote: > > If DNSSEC is required, there are two failure cases: > A) The DNSSEC data is secure, but the PKIX chain doesn't match > B) The DNSSEC data is bogus "DNSSEC data is secure" lumps two situations together, and "PKIX chain doesn't match" also appears to lump two situations together. (the latter seems to be a defect of the dane-protocols I-D). The traditional server certificate check consists of a few independent checks: (a1) PKIX cert path validation of server cert (rfc5280, section 6.1ff) (a2) matching of server cert with server hostname (rfc2818 section 3.1 or rfc6125) (b) matching against "pinned" server cert (e.g. rfc6125 section 6.2.2 or http://www.w3.org/TR/wsc-ui/#sec-interactively Secure DNSSEC responses also come in various flavours (I) NSEC/NSEC3 ("proof of non-existence") (II) TLSA records > > For A, the RP knows that one of the following is true: > A1) One of the CAs trusted by the RP's TA list is compromised Huh? If an attacker has compromised a CA, then both PKIX cert path validation and traditional server name matching with succeed. And there is no way for the RP to *know* anything here, that would more likely amount to coffee ground reading rather than scientific certainty. > > A2) One of the DNSKEYs in the DNSSEC chain is compromised At he moment, it is probably *much* easier to sneak records into the database that feeds the DNSSEC zone signing process than to attack the crypto functions or keys. > > A3) There's been a misconfiguration > > A3 is a constant issue. Agreed. > > Putting that aside, the RP can weigh the relative probability > of A1 or A2 and determine if it wants to proceed anyway. I don't know whether you think of code or user when you write "RP can weigh". Personally, I'm violently opposed for *code* attempting heuristics here, and I was under the impression that "RP" refers only to code, and never to "decision based on risk assessment by a(n interactive) human user". > > A3) There's been a misconfiguration > C1) One of the authoritative servers in the NS chain is compromised > C2) One of the DNS resolvers the RP is relying on have been poisoned > C3) Some other MITM is manipulating the DNS traffic > > Again putting aside A3, the RP must weigh the probability of C1-3 vs A1. Rather than attacking the crypto stuff, an attacker might break into the real server, steal the real servers TLS server credential and then mount an attack on TLS clients where it can transparently MITM the network traffic. PKIX cert path validation, server identity matching and DNSSEC-protected TLSA records will all validate. No need to attack any of the latter. MITM attacks on TLS clients aren't that hard, in particular on mobile clients. IPv6 neighbour discovery was a nice enabler for transparent connection MITM. :-/ transparent MITM of network connections is standard functionality of networking gear. WLAN access points with captive portals do it all the time. -Martin From mrex@sap.com Fri Oct 7 17:40: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 060ED21F8B74 for ; Fri, 7 Oct 2011 17:40:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.076 X-Spam-Level: X-Spam-Status: No, score=-10.076 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A-CE3nXkPppJ for ; Fri, 7 Oct 2011 17:40:51 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 4AD2121F8B2A for ; Fri, 7 Oct 2011 17:40:50 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p980i0fZ025985 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 8 Oct 2011 02:44:00 +0200 (MEST) From: Martin Rex Message-Id: <201110080044.p980i02o000918@fs4113.wdf.sap.corp> To: bmanning@vacation.karoshi.com Date: Sat, 8 Oct 2011 02:44:00 +0200 (MEST) In-Reply-To: <20111008001956.GA2398@vacation.karoshi.com.> from "bmanning@vacation.karoshi.com" at Oct 8, 11 00:19:56 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] #36: Only requiring DNSSEC where it is needed 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: Sat, 08 Oct 2011 00:40:52 -0000 bmanning@vacation.karoshi.com wrote: > > On Sat, Oct 08, 2011 at 01:57:03AM +0200, Martin Rex wrote: > > Scott Schmit wrote: > > > > > > If DNSSEC is required, there are two failure cases: > > > A) The DNSSEC data is secure, but the PKIX chain doesn't match > > > B) The DNSSEC data is bogus > > > > "DNSSEC data is secure" lumps two situations together, and > > define "secure" please. > > DNSSEC NSEC(x) records provide a check to ensure additioanl RRs are not > injected into a cache - which are not part of the authoritative zone data. > DNSSIG records provide a cryptogrpahic signature over the RR's being moved. > > DNSSEC tools protect caches by ensuring the accuracy and integrity of RR's > which are fetched. So if this is what you mean by "lumps two situations together" > then sure, I agree w/ you. For many/most of the folks in the DNSSEC space, > this is enough to call DNSSEC processed data -secure- even though the data is > not covered by the other facets of "security". DNSSEC, for example, does > not provide confidentiality - which is reason enough for some to say DNSSEC > is not secure. > > so - please define secure in this (DANE/DNSSEC) context. DANE-enabled TLS clients will encounter TLS servers where the DNS zone has DNSSEC enabled, but no TLSA records are maintained. In that case a DNS lookup www.example.com. will return an IP address, but the DNS lookup for _443._tcp.www.example.com. would have to result in an NSEC/NSEC3 response rather than NXDOMAIN, I assume. -Martin From i.grok@comcast.net Fri Oct 7 19:43: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 1104D21F8B3A for ; Fri, 7 Oct 2011 19:43:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.645 X-Spam-Level: X-Spam-Status: No, score=-102.645 tagged_above=-999 required=5 tests=[AWL=-0.046, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20UdXJuNr29X for ; Fri, 7 Oct 2011 19:43:48 -0700 (PDT) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [76.96.59.243]) by ietfa.amsl.com (Postfix) with ESMTP id 4C73121F8564 for ; Fri, 7 Oct 2011 19:43:48 -0700 (PDT) Received: from omta04.westchester.pa.mail.comcast.net ([76.96.62.35]) by qmta13.westchester.pa.mail.comcast.net with comcast id i2mj1h0020ldTLk5D2n418; Sat, 08 Oct 2011 02:47:04 +0000 Received: from odin.ulthar.us ([68.33.77.0]) by omta04.westchester.pa.mail.comcast.net with comcast id i2n31h00S00PQ6U3Q2n3rA; Sat, 08 Oct 2011 02:47: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 p982l1ds004395 for ; Fri, 7 Oct 2011 22:47:02 -0400 Received: (from draco@localhost) by odin.ulthar.us (8.14.4/8.14.4/Submit) id p982l1lL004393 for dane@ietf.org; Fri, 7 Oct 2011 22:47:01 -0400 Date: Fri, 7 Oct 2011 22:47:01 -0400 From: Scott Schmit To: dane@ietf.org Message-ID: <20111008024701.GA4030@odin.ulthar.us> Mail-Followup-To: dane@ietf.org References: <20111007142226.GB11338@odin.ulthar.us> <201110072357.p97Nv30f027932@fs4113.wdf.sap.corp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201110072357.p97Nv30f027932@fs4113.wdf.sap.corp> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] #36: Only requiring DNSSEC where it is needed 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: Sat, 08 Oct 2011 02:43:49 -0000 On Sat, Oct 08, 2011 at 01:57:03AM +0200, Martin Rex wrote: > Scott Schmit wrote: > > If DNSSEC is required, there are two failure cases: > > A) The DNSSEC data is secure, but the PKIX chain doesn't match > > B) The DNSSEC data is bogus > > "DNSSEC data is secure" lumps two situations together, and > "PKIX chain doesn't match" also appears to lump two situations together. > (the latter seems to be a defect of the dane-protocols I-D). I'm not sure where you're trying to go with this. I was responding to Paul's question about what value signing usage 0/1 TLSA records has. You're right that we could have secure denial of existence, but in that case, we fall back to standard PKIX processing, and DANE is no longer relevant. The matching I was referring to was DANE matching, not PKIX processing to ensure that the certificate matches the domain name. If the latter fails, the certificate isn't going to work with or without DANE, so it's not a DANE failure case. > > For A, the RP knows that one of the following is true: > > A1) One of the CAs trusted by the RP's TA list is compromised > > Huh? If an attacker has compromised a CA, then both PKIX cert path > validation and traditional server name matching with succeed. Yes, but the DANE matching won't. > And there is no way for the RP to *know* anything here, that would more > likely amount to coffee ground reading rather than scientific certainty. For the record, I never claimed that the RP knows *which* is the case. But if that's how you read "know", substitute "has good reason to believe" instead. As I'm sure you realize, we're trying to weigh the trade-offs of requiring or not requiring DNSSEC protection of usage 0/1 TLSA records. Security isn't black & white, it's about risk assessment. In my email, I tried to enumerate the failure cases & the possible causes. The RP must weigh the likelihood of the various causes and decide what to do in response. Of course, most users aren't equipped to make that decision, so it's done by the software developers on their behalf in the form of the client itself. We need to think about how protocol changes affect that risk assessment to determine if the reward is worthwhile. > > A2) One of the DNSKEYs in the DNSSEC chain is compromised > > At he moment, it is probably *much* easier to sneak records into the > database that feeds the DNSSEC zone signing process than to > attack the crypto functions or keys. Right. I meant "the CA-like entities that sign DS records". Still, I'd argue that if you don't control what your key signs, you don't really have control over your key and it's effectively compromised until you regain control. I hope this clears up any confusion. -- Scott Schmit From paul.hoffman@vpnc.org Mon Oct 10 17:20: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 5676A21F889A for ; Mon, 10 Oct 2011 17:20:32 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XRaWq6sahJfb for ; Mon, 10 Oct 2011 17:20:31 -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 C054421F888A for ; Mon, 10 Oct 2011 17:20:31 -0700 (PDT) Received: from [10.20.30.100] (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 p9B0K8n0098282 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 10 Oct 2011 17:20:08 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <045d01cc8301$fd4204f0$f7c60ed0$@augustcellars.com> Date: Mon, 10 Oct 2011 17:20:07 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7EF76632-07BC-496E-B420-0CED01A487C5@vpnc.org> References: <045d01cc8301$fd4204f0$f7c60ed0$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.1244.3) Cc: dane@ietf.org Subject: Re: [dane] -12 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, 11 Oct 2011 00:20:32 -0000 Sorry for the delay in getting back to you, and thanks for the review. = We'll make these changes in the -13, except as noted below. On Oct 4, 2011, at 6:56 PM, Jim Schaad wrote: > 4. I am a layman in regards to DNS terminology. Does the term domain = name > refer to leafs as well as nodes, i.e. is www.example.com considered to = be a > domain name? I get confused since registering domain names would not = get > you that name but it could be slopping thinking on my part. "Domain name" means any name in the DNS hierarchy (probably excluding = the nameless root). > 6. I think that the text in section 4.3 should be expanded slightly = to > identify the self-issued certificate case as well. I was going to go = to the > TLS document and grab the text used there and find that although we = have > been assured that a self-issued certificate is allowed in TLS that = there not > only is no documentation on it but it says that it MAY be omitted = since it > is self-issued. Perhaps we should get some clarifying terminology = from the > TLS group before pursuing this. The issue of self-issued certificates is being dealt with in the PKIX = WG. We need to wait for the conclusion of that discussion. > 8. In the code section I might suggest >=20 > // pass PKIX validation using TLSA record as trust anchor > if (R.certUsage =3D=3D 2) { > for each PKIX validation chain H { > if (C passes PKIX validation in H) { > T =3D the trust anchor in H; > if (Match(matchingType, Select(selectorType, T), R) { > accept the TLS connection > } > } > } > } I would want to hear from more folks on this. Martin doesn't like the = change, and I think our current pseudocode is accurate. --Paul Hoffman From paul.hoffman@vpnc.org Tue Oct 11 11:42: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 1B84D21F8F3A for ; Tue, 11 Oct 2011 11:42:45 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5PTi02Hm6Djw for ; Tue, 11 Oct 2011 11:42:44 -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 A890D21F8F29 for ; Tue, 11 Oct 2011 11:42:44 -0700 (PDT) Received: from [10.20.30.100] (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 p9BIghte037107 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 11 Oct 2011 11:42:44 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1244.3) From: Paul Hoffman In-Reply-To: <20111008024701.GA4030@odin.ulthar.us> Date: Tue, 11 Oct 2011 11:42:43 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8D02C4FF-E71C-45AF-AC41-F667AEB3ABF4@vpnc.org> References: <20111007142226.GB11338@odin.ulthar.us> <201110072357.p97Nv30f027932@fs4113.wdf.sap.corp> <20111008024701.GA4030@odin.ulthar.us> To: IETF DANE WG list X-Mailer: Apple Mail (2.1244.3) Subject: Re: [dane] #36: Only requiring DNSSEC where it is needed 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, 11 Oct 2011 18:42:45 -0000 It truly doesn't feel like there is rough consensus in favor of our = proposal, so Jakob and I withdraw it. Based on the feedback received, we = will certainly try to clarify the use of DNSSEC in the next draft. --Paul Hoffman= From ekr@rtfm.com Tue Oct 11 17:38: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 7F57121F8C92 for ; Tue, 11 Oct 2011 17:38:21 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cvdVGvqAa0fq for ; Tue, 11 Oct 2011 17:38:21 -0700 (PDT) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by ietfa.amsl.com (Postfix) with ESMTP id DDDAC21F8C6C for ; Tue, 11 Oct 2011 17:38:20 -0700 (PDT) Received: by vws11 with SMTP id 11so232731vws.27 for ; Tue, 11 Oct 2011 17:38:20 -0700 (PDT) Received: by 10.52.91.7 with SMTP id ca7mr21107326vdb.29.1318379900227; Tue, 11 Oct 2011 17:38:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.161.20 with HTTP; Tue, 11 Oct 2011 17:37:40 -0700 (PDT) From: Eric Rescorla Date: Tue, 11 Oct 2011 17:37:40 -0700 Message-ID: To: dane@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [dane] Text in S 4.4 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, 12 Oct 2011 00:38:21 -0000 S 4.4 reads in part: An application that complies with this document first requests TLSA records in order to make certificate associations. If that application receives zero usable certificate associations, it processes TLS in the normal fashion; otherwise, that application attempts to match each certificate association with the TLS server's end entity certificate. If such a match is found, that application continues the TLS handshake and ignores any remaining certificate associations; otherwise, that application MUST abort the TLS handshake with an "access_denied" error. I'm not sure this is the right answer. I see three issues here: 1. Should there be a mandatory fail here. 2. Should that fail be expressed as a TLS alert. 3. Should that alert be access denied. Taking these in order. 1. It's not clear to me that this MUST is that useful, since after all, one can just process DANE records, throw an error up the user and then by "noncompliant" but still functional. This looks to me like a case of over-specification of policy rather than mechanism. 2. It's not at all clear to me that this ought to be a TLS alert. It's not uncommon to have cert name checking (for instance) happen outside of TLS (especially if the stack doesn't know better), and this seems like functionality that naturally occurs outside of the TLS stack. I note that some TLS stacks don't appear to allow the application to issue alerts (I just looked at OpenSSL and don't see such a facilty). So, this seems like an unwise requirement. 3. It's not obvious to me that "access_denied" is the right alert, at least based on this snipped. TLS provides the following alerts for cases where certs are something other than acceptable: bad_certificate A certificate was corrupt, contained signatures that did not verify correctly, etc. unsupported_certificate A certificate was of an unsupported type. certificate_revoked A certificate was revoked by its signer. certificate_expired A certificate has expired or is not currently valid. certificate_unknown Some other (unspecified) issue arose in processing the certificate, rendering it unacceptable. illegal_parameter A field in the handshake was out of range or inconsistent with other fields. This message is always fatal. unknown_ca A valid certificate chain or partial chain was received, but the certificate was not accepted because the CA certificate could not be located or couldn't be matched with a known, trusted CA. This message is always fatal. access_denied A valid certificate was received, but when access control was applied, the sender decided not to proceed with negotiation. This message is always fatal. Consider the case where the EE cert doesn't chain anywhere (i.e., wouldn't pass validation even without DANE). access_denied is clearly not the right alert. Similarly, if the certificate association in DANE specifies a CA, and the cert passes PKIX validation but not with a diferent CA, that looks a lot more like "unknown_ca" or "certificate_unknown". If DANE is going to specify a specific alert, I suspect it's going to have to be several alerts and the WG will need to more clearly lay out which ones are needed when. -Ekr From mrex@sap.com Tue Oct 11 19: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 8F1AC21F84DD for ; Tue, 11 Oct 2011 19:15:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.949 X-Spam-Level: X-Spam-Status: No, score=-8.949 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UzZ+hCZWnStf for ; Tue, 11 Oct 2011 19:15:29 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id DAEA921F8558 for ; Tue, 11 Oct 2011 19:15:28 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p9C2FQAF023794 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 12 Oct 2011 04:15:26 +0200 (MEST) From: Martin Rex Message-Id: <201110120215.p9C2FPe6013843@fs4113.wdf.sap.corp> To: ekr@rtfm.com (Eric Rescorla) Date: Wed, 12 Oct 2011 04:15:25 +0200 (MEST) In-Reply-To: from "Eric Rescorla" at Oct 11, 11 05:37:40 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] Text in S 4.4 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: Wed, 12 Oct 2011 02:15:29 -0000 Eric Rescorla wrote: > > S 4.4 reads in part: > > An application that complies with this document first requests TLSA > records in order to make certificate associations. If that > application receives zero usable certificate associations, it > processes TLS in the normal fashion; otherwise, that application > attempts to match each certificate association with the TLS server's > end entity certificate. If such a match is found, that application > continues the TLS handshake and ignores any remaining certificate > associations; otherwise, that application MUST abort the TLS > handshake with an "access_denied" error. > > I'm not sure this is the right answer. > > I see three issues here: > > 1. Should there be a mandatory fail here. > 2. Should that fail be expressed as a TLS alert. > 3. Should that alert be access denied. I was also confused by that "access_denied": http://www.ietf.org/mail-archive/web/dane/current/msg03372.html and believe that DANE should rather define API-level behaviour here (and access_denied does not make sense at the API in this situation), whereas the fatal SSL alert the client should send before closing the connection when the TLS decides to abort the connection, because of a failed DANE validation, is a seperate issue. -Martin From mrex@sap.com Tue Oct 11 19:20: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 319E521F86C1 for ; Tue, 11 Oct 2011 19:20:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.599 X-Spam-Level: X-Spam-Status: No, score=-9.599 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FcqaLi2uWf+z for ; Tue, 11 Oct 2011 19:20:38 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 503A221F8669 for ; Tue, 11 Oct 2011 19:20:37 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p9C2KUD9026294 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 12 Oct 2011 04:20:35 +0200 (MEST) From: Martin Rex Message-Id: <201110120220.p9C2KUhX014361@fs4113.wdf.sap.corp> To: mrex@sap.com Date: Wed, 12 Oct 2011 04:20:30 +0200 (MEST) In-Reply-To: <201110120215.p9C2FPe6013843@fs4113.wdf.sap.corp> from "Martin Rex" at Oct 12, 11 04:15:25 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] Text in S 4.4 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: Wed, 12 Oct 2011 02:20:41 -0000 I sent this off to fast (somewhat dazed), it was unclear about TLS client and application caller, fixed below. Martin Rex wrote: > > Eric Rescorla wrote: > > > > S 4.4 reads in part: > > > > An application that complies with this document first requests TLSA > > records in order to make certificate associations. If that > > application receives zero usable certificate associations, it > > processes TLS in the normal fashion; otherwise, that application > > attempts to match each certificate association with the TLS server's > > end entity certificate. If such a match is found, that application > > continues the TLS handshake and ignores any remaining certificate > > associations; otherwise, that application MUST abort the TLS > > handshake with an "access_denied" error. > > > > I'm not sure this is the right answer. > > > > I see three issues here: > > > > 1. Should there be a mandatory fail here. > > 2. Should that fail be expressed as a TLS alert. > > 3. Should that alert be access denied. I was also confused by that "access_denied": http://www.ietf.org/mail-archive/web/dane/current/msg03372.html and believe that DANE should rather define API-level behaviour here (and access_denied does not make sense at the API in this situation), whereas the fatal SSL alert the TLS client should send before closing the connection when the application (DANE/TLS caller) decides to abort the connection, because of a failed DANE validation, is a seperate issue. -Martin From paul.hoffman@vpnc.org Tue Oct 11 20:20: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 A90D421F84CC for ; Tue, 11 Oct 2011 20:20:25 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LoZmkrbFzoI0 for ; Tue, 11 Oct 2011 20:20:25 -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 A4EF521F8BCB for ; Tue, 11 Oct 2011 20:20:24 -0700 (PDT) Received: from [10.20.30.100] (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 p9C3KNpG011026 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 11 Oct 2011 20:20:23 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <201110120220.p9C2KUhX014361@fs4113.wdf.sap.corp> Date: Tue, 11 Oct 2011 20:20:22 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201110120220.p9C2KUhX014361@fs4113.wdf.sap.corp> To: mrex@sap.com X-Mailer: Apple Mail (2.1244.3) Cc: dane@ietf.org Subject: Re: [dane] Text in S 4.4 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, 12 Oct 2011 03:20:25 -0000 On Oct 11, 2011, at 7:20 PM, Martin Rex wrote: > I sent this off to fast (somewhat dazed), it was unclear about > TLS client and application caller, fixed below. >=20 > Martin Rex wrote: >>=20 >> Eric Rescorla wrote: >>>=20 >>> S 4.4 reads in part: >>>=20 >>> An application that complies with this document first requests = TLSA >>> records in order to make certificate associations. If that >>> application receives zero usable certificate associations, it >>> processes TLS in the normal fashion; otherwise, that application >>> attempts to match each certificate association with the TLS = server's >>> end entity certificate. If such a match is found, that = application >>> continues the TLS handshake and ignores any remaining certificate >>> associations; otherwise, that application MUST abort the TLS >>> handshake with an "access_denied" error. >>>=20 >>> I'm not sure this is the right answer. >>>=20 >>> I see three issues here: >>>=20 >>> 1. Should there be a mandatory fail here. >>> 2. Should that fail be expressed as a TLS alert. >>> 3. Should that alert be access denied. >=20 >=20 > I was also confused by that "access_denied": >=20 > http://www.ietf.org/mail-archive/web/dane/current/msg03372.html >=20 > and believe that DANE should rather define API-level behaviour here > (and access_denied does not make sense at the API in this situation), > whereas the fatal SSL alert the TLS client should send before closing = the > connection when the application (DANE/TLS caller) decides to abort the > connection, because of a failed DANE validation, is a seperate issue. Your answer is still not clear to me. Are you saying for #2 "failure = should be expressed as both an API-level behavior *and* send a TLS fatal = alert", or "failure should be expressed as an API-level behavior and = maybe also send a TLS fatal alert", or ...? --Paul Hoffman From paul.hoffman@vpnc.org Tue Oct 11 20:28: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 8957521F8C9C for ; Tue, 11 Oct 2011 20:28: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=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r3HngfFeMFEX for ; Tue, 11 Oct 2011 20:28:40 -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 136EE21F8C9B for ; Tue, 11 Oct 2011 20:28:40 -0700 (PDT) Received: from [10.20.30.100] (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 p9C3SdKJ011330 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 11 Oct 2011 20:28:39 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1244.3) From: Paul Hoffman In-Reply-To: Date: Tue, 11 Oct 2011 20:28:38 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <712CCE0F-000B-4E65-9407-41AF1D150B19@vpnc.org> References: To: IETF DANE WG list X-Mailer: Apple Mail (2.1244.3) Subject: Re: [dane] Text in S 4.4 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, 12 Oct 2011 03:28:40 -0000 On Oct 11, 2011, at 5:37 PM, Eric Rescorla wrote: > 1. Should there be a mandatory fail here. > 2. Should that fail be expressed as a TLS alert. > 3. Should that alert be access denied. #1 and #2 are linked in that, if we do not do a "mandatory fail as a = fatal TLS alert", we would need to design a DANE API. We haven't done = that yet, and maybe we need to, but currently we can get away with using = the TLS signaling mechanism because we use fatal for #1 and TLS gives us = a way to fail in a well-defined fashion. If we stay with the TLS alert, = an application will still know why the error happened so it can log it = or tell the user; there is just no standardized mechanism for that. For #3, if we still go with a TLS fatal alert, we can specify "in case = X, use alert Xa, but in case Y, use alert Ya", although the only value = for that is to give the application some extra debugging information = that it might log or tell the user. Note that neither the application = nor the user can actually change anything by knowing the difference = between X and Y, but people here might think it is valuable to know = these things. --Paul Hoffman From mrex@sap.com Tue Oct 11 20:43: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 37E1521F8C97 for ; Tue, 11 Oct 2011 20:43:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.816 X-Spam-Level: X-Spam-Status: No, score=-9.816 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6CJPeAN2mKvR for ; Tue, 11 Oct 2011 20:43:50 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 83E8621F8C88 for ; Tue, 11 Oct 2011 20:43:50 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p9C3hl4h008639 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 12 Oct 2011 05:43:48 +0200 (MEST) From: Martin Rex Message-Id: <201110120343.p9C3hlga018847@fs4113.wdf.sap.corp> To: paul.hoffman@vpnc.org (Paul Hoffman) Date: Wed, 12 Oct 2011 05:43:47 +0200 (MEST) In-Reply-To: <712CCE0F-000B-4E65-9407-41AF1D150B19@vpnc.org> from "Paul Hoffman" at Oct 11, 11 08:28:38 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] Text in S 4.4 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: Wed, 12 Oct 2011 03:43:51 -0000 Paul Hoffman wrote: > > On Oct 11, 2011, at 5:37 PM, Eric Rescorla wrote: > > > 1. Should there be a mandatory fail here. > > 2. Should that fail be expressed as a TLS alert. > > 3. Should that alert be access denied. > > #1 and #2 are linked in that, if we do not do a "mandatory fail as > a fatal TLS alert", we would need to design a DANE API. It is IMO quite inappropriate to talk about an SSL alert there. We NEED to define API semantics instead! Defining a real DANE API is unnecessary. TLS does the same in a few places (creating requirements for the API between TLS and the calling application, without actually defining an API). > > We haven't done that yet, and maybe we need to, but currently we can > get away with using the TLS signaling mechanism because we use fatal > for #1 and TLS gives us a way to fail in a well-defined fashion. I'm sorry, I can't follow your line of thought here. If you are think of "TLS signaling mechanism" in terms of SSL alerts here, that is pretty useless. That signaling mechanism is for communication with the peer only. But what we need here is a semantics how the DANE client reports a DANE validation failure at the local API to the application caller, because the application caller MUST decide (per TLS spec!) whether to abort the connection or to ignore the DANE validation failure and continue. There is *NO* mandatory to abort for PKIX failure (which often happen due to the use of self-signed server certs or server certs issued by organizational CAs.) and their neither ought to be any mandatory to abort DANE validation failure either. Having it fail by default is sufficient. -Martin From mrex@sap.com Tue Oct 11 20:47: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 6ADF721F8C97 for ; Tue, 11 Oct 2011 20:47:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.924 X-Spam-Level: X-Spam-Status: No, score=-9.924 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W44VXJ+Sn8SU for ; Tue, 11 Oct 2011 20:47:56 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 3D03721F8C2A for ; Tue, 11 Oct 2011 20:47:51 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p9C3lnG4002480 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 12 Oct 2011 05:47:49 +0200 (MEST) From: Martin Rex Message-Id: <201110120347.p9C3lmix018978@fs4113.wdf.sap.corp> To: paul.hoffman@vpnc.org (Paul Hoffman) Date: Wed, 12 Oct 2011 05:47:48 +0200 (MEST) In-Reply-To: from "Paul Hoffman" at Oct 11, 11 08:20: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] Text in S 4.4 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: Wed, 12 Oct 2011 03:47:57 -0000 Paul Hoffman wrote: > > Martin Rex wrote: > > > > I was also confused by that "access_denied": > > > > http://www.ietf.org/mail-archive/web/dane/current/msg03372.html > > > > and believe that DANE should rather define API-level behaviour here > > (and access_denied does not make sense at the API in this situation), > > whereas the fatal SSL alert the TLS client should send before closing the > > connection when the application (DANE/TLS caller) decides to abort the > > connection, because of a failed DANE validation, is a seperate issue. > > > Your answer is still not clear to me. Are you saying for > #2 "failure should be expressed as both an API-level behavior > *and* send a TLS fatal alert", or "failure should be expressed > as an API-level behavior and maybe also send a TLS fatal alert", or ...? DANE must specify the semantics that needs to be exposed to the calling app here. mentioning which SSL alert should be send if the calling app decides to abort the connection due to a DANE validation failure would be OK. For a TLS client that is validating a server certificate, "bad_certificate" would be OK. "access_denied" would looks quite misplaced. -Martin From ekr@rtfm.com Tue Oct 11 21:37: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 4D50F21F8CAE for ; Tue, 11 Oct 2011 21:37:59 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JdyuIRtFs8sK for ; Tue, 11 Oct 2011 21:37:58 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id BCB4321F8CAD for ; Tue, 11 Oct 2011 21:37:58 -0700 (PDT) Received: by vcbfo11 with SMTP id fo11so286886vcb.31 for ; Tue, 11 Oct 2011 21:37:58 -0700 (PDT) Received: by 10.52.174.107 with SMTP id br11mr21725861vdc.12.1318394278120; Tue, 11 Oct 2011 21:37:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.161.20 with HTTP; Tue, 11 Oct 2011 21:37:18 -0700 (PDT) In-Reply-To: <712CCE0F-000B-4E65-9407-41AF1D150B19@vpnc.org> References: <712CCE0F-000B-4E65-9407-41AF1D150B19@vpnc.org> From: Eric Rescorla Date: Tue, 11 Oct 2011 21:37:18 -0700 Message-ID: To: Paul Hoffman Content-Type: text/plain; charset=ISO-8859-1 Cc: IETF DANE WG list Subject: Re: [dane] Text in S 4.4 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, 12 Oct 2011 04:37:59 -0000 On Tue, Oct 11, 2011 at 8:28 PM, Paul Hoffman wrote: > On Oct 11, 2011, at 5:37 PM, Eric Rescorla wrote: > >> 1. Should there be a mandatory fail here. >> 2. Should that fail be expressed as a TLS alert. >> 3. Should that alert be access denied. > > #1 and #2 are linked in that, if we do not do a "mandatory fail as a fatal TLS alert", we would need to design a DANE API. I'm not sure that this is true. For instance, you could say "MUST terminate the connection." Why does that require an alert. For that matter, why can't you just say "MUST be regarded as suspect and SHOULD terminate the connection. -Ekr From zack.weinberg@gmail.com Tue Oct 11 22:03: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 4CDF221F8B7A for ; Tue, 11 Oct 2011 22:03:05 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QZThFyKD-94c for ; Tue, 11 Oct 2011 22:03:04 -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 BBBEF21F8AD6 for ; Tue, 11 Oct 2011 22:03:04 -0700 (PDT) Received: by gyh20 with SMTP id 20so392230gyh.31 for ; Tue, 11 Oct 2011 22:03:03 -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=BdNMu+q+mV7JotBd9qcFIteeWXJ1pxpjn7ZfNdy0+lo=; b=qousBxkkLrohdbPdP688vbwvAKV2xhkJoCmaDlaAFpyCCNE3/XbbKgcoZKtOGqezAA 0zvb9N/EhfwNercXcEa5yF95UEl01nSyT8vLyPS3R1prNV3iwKwF2geOtYR3/cy8ttdq zdV1V6IKUTxPaU17lxd1PPtOnpVWxJnCTl3iM= MIME-Version: 1.0 Received: by 10.68.59.10 with SMTP id v10mr51895520pbq.16.1318395782995; Tue, 11 Oct 2011 22:03:02 -0700 (PDT) Sender: zack.weinberg@gmail.com Received: by 10.68.60.74 with HTTP; Tue, 11 Oct 2011 22:03:02 -0700 (PDT) In-Reply-To: References: <712CCE0F-000B-4E65-9407-41AF1D150B19@vpnc.org> Date: Tue, 11 Oct 2011 22:03:02 -0700 X-Google-Sender-Auth: f8TGrYbVHGXfU8OljRLRZrwA1VA Message-ID: From: Zack Weinberg To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Cc: Paul Hoffman , IETF DANE WG list Subject: Re: [dane] Text in S 4.4 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, 12 Oct 2011 05:03:05 -0000 On Tue, Oct 11, 2011 at 9:37 PM, Eric Rescorla wrote: > > I'm not sure that this is true. For instance, you could say "MUST > terminate the connection." Why does that require > an alert. For that matter, why can't you just say "MUST be regarded as > suspect and SHOULD terminate the > connection. In the current draft of my rewrite-for-clarity of DANE, I used very similar wording. I think it is entirely appropriate to stay away from specifics of *how* the client terminates the connection and how the failure is communicated from library to application software. (I have "MUST terminate the connection", but let's not restart that argument here.) zw From paul.hoffman@vpnc.org Wed Oct 12 08:10: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 5554D21F8B2F for ; Wed, 12 Oct 2011 08:10:56 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MDiGPjeFFKHH for ; Wed, 12 Oct 2011 08:10:55 -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 AF6EF21F8B20 for ; Wed, 12 Oct 2011 08:10:55 -0700 (PDT) Received: from [10.20.30.100] (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 p9CFAsNP036719 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 12 Oct 2011 08:10:55 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Wed, 12 Oct 2011 08:10:55 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6D0F718A-97C1-452E-AA56-5C13C664C546@vpnc.org> References: <712CCE0F-000B-4E65-9407-41AF1D150B19@vpnc.org> To: Eric Rescorla X-Mailer: Apple Mail (2.1244.3) Cc: IETF DANE WG list Subject: Re: [dane] Text in S 4.4 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, 12 Oct 2011 15:10:56 -0000 On Oct 11, 2011, at 9:37 PM, Eric Rescorla wrote: > On Tue, Oct 11, 2011 at 8:28 PM, Paul Hoffman = wrote: >> On Oct 11, 2011, at 5:37 PM, Eric Rescorla wrote: >>=20 >>> 1. Should there be a mandatory fail here. >>> 2. Should that fail be expressed as a TLS alert. >>> 3. Should that alert be access denied. >>=20 >> #1 and #2 are linked in that, if we do not do a "mandatory fail as a = fatal TLS alert", we would need to design a DANE API. >=20 > I'm not sure that this is true. For instance, you could say "MUST > terminate the connection." Why does that require > an alert. For that matter, why can't you just say "MUST be regarded as > suspect and SHOULD terminate the > connection. OK, I thought that #2 was a question about "DANE API" versus "do it in = TLS". So that I'm not speaking for you, are you saying that #2 is about = "TLS alert" versus "terminate connection"? --Paul Hoffman From ekr@rtfm.com Wed Oct 12 08: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 6D49F21F8BA0 for ; Wed, 12 Oct 2011 08:28:39 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xp4FInomzi55 for ; Wed, 12 Oct 2011 08:28:39 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id E149821F8B31 for ; Wed, 12 Oct 2011 08:28:38 -0700 (PDT) Received: by vcbfo11 with SMTP id fo11so823540vcb.31 for ; Wed, 12 Oct 2011 08:28:38 -0700 (PDT) Received: by 10.52.91.7 with SMTP id ca7mr24036910vdb.29.1318433318374; Wed, 12 Oct 2011 08:28:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.161.20 with HTTP; Wed, 12 Oct 2011 08:27:58 -0700 (PDT) In-Reply-To: <6D0F718A-97C1-452E-AA56-5C13C664C546@vpnc.org> References: <712CCE0F-000B-4E65-9407-41AF1D150B19@vpnc.org> <6D0F718A-97C1-452E-AA56-5C13C664C546@vpnc.org> From: Eric Rescorla Date: Wed, 12 Oct 2011 08:27:58 -0700 Message-ID: To: Paul Hoffman Content-Type: text/plain; charset=ISO-8859-1 Cc: IETF DANE WG list Subject: Re: [dane] Text in S 4.4 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, 12 Oct 2011 15:28:39 -0000 On Wed, Oct 12, 2011 at 8:10 AM, Paul Hoffman wrote: > On Oct 11, 2011, at 9:37 PM, Eric Rescorla wrote: > >> On Tue, Oct 11, 2011 at 8:28 PM, Paul Hoffman wrote: >>> On Oct 11, 2011, at 5:37 PM, Eric Rescorla wrote: >>> >>>> 1. Should there be a mandatory fail here. >>>> 2. Should that fail be expressed as a TLS alert. >>>> 3. Should that alert be access denied. >>> >>> #1 and #2 are linked in that, if we do not do a "mandatory fail as a fatal TLS alert", we would need to design a DANE API. >> >> I'm not sure that this is true. For instance, you could say "MUST >> terminate the connection." Why does that require >> an alert. For that matter, why can't you just say "MUST be regarded as >> suspect and SHOULD terminate the >> connection. > > > OK, I thought that #2 was a question about "DANE API" versus "do it in TLS". So that I'm not speaking for you, are you saying that #2 is about "TLS alert" versus "terminate connection"? I'm not sure I understand the question. The current text requires that the connection be terminated with a fatal TLS alert. I think it's an open question whether that should be the requirement as opposed to simply requiring that the application not proceed with the connection and leave the manner unspecified. -Ekr From mrex@sap.com Wed Oct 12 09:34:54 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 44BEE21F8CA9 for ; Wed, 12 Oct 2011 09:34:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.989 X-Spam-Level: X-Spam-Status: No, score=-9.989 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4WPTzpfVoRDM for ; Wed, 12 Oct 2011 09:34:53 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 79D4D21F8C98 for ; Wed, 12 Oct 2011 09:34:53 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p9CGYojI017059 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 12 Oct 2011 18:34:50 +0200 (MEST) From: Martin Rex Message-Id: <201110121634.p9CGYnx2011876@fs4113.wdf.sap.corp> To: zack.weinberg@sv.cmu.edu (Zack Weinberg) Date: Wed, 12 Oct 2011 18:34:49 +0200 (MEST) In-Reply-To: from "Zack Weinberg" at Oct 11, 11 10:03:02 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] Text in S 4.4 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: Wed, 12 Oct 2011 16:34:54 -0000 Zack Weinberg wrote: > > On Tue, Oct 11, 2011 at 9:37 PM, Eric Rescorla wrote: > > > > I'm not sure that this is true. For instance, you could say "MUST > > terminate the connection." Why does that require > > an alert. For that matter, why can't you just say "MUST be regarded as > > suspect and SHOULD terminate the > > connection. > > In the current draft of my rewrite-for-clarity of DANE, I used very > similar wording. I think it is entirely appropriate to stay away from > specifics of *how* the client terminates the connection and how the > failure is communicated from library to application software. > > (I have "MUST terminate the connection", but let's not restart that > argument here.) Wedlocking the possibility to enable TLS on a server to the DNS admin is just as alien and inappropriate as wedlocking it to customers of commercial CAs. The decision to abort a connection in case of a DANE validation of the TLS server certificate needs to be an rfc2119-style "SHOULD" directed at the user/consumer(!) of the technology "TLS", rather than the implementor (of DANE application utility functions for a TLS software distribution). -Martin From trac+dane@trac.tools.ietf.org Wed Oct 12 20:03: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 864A621F8C61 for ; Wed, 12 Oct 2011 20:03:02 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9rFNRvTpd5hM for ; Wed, 12 Oct 2011 20:03:01 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id A561821F8C53 for ; Wed, 12 Oct 2011 20:03:01 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1REBZQ-0003Zh-Dx; Wed, 12 Oct 2011 23:02:56 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "dane issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-dane-protocol@tools.ietf.org, ietf@augustcellars.com X-Trac-Project: dane Date: Thu, 13 Oct 2011 03:02:56 -0000 X-URL: http://tools.ietf.org/dane/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dane/trac/ticket/38 Message-ID: <061.a82f8aa3c92f33e7b664930cf373f215@trac.tools.ietf.org> X-Trac-Ticket-ID: 38 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-dane-protocol@tools.ietf.org, ietf@augustcellars.com, dane@ietf.org X-SA-Exim-Mail-From: trac+dane@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20111013030301.A561821F8C53@ietfa.amsl.com> Resent-Date: Wed, 12 Oct 2011 20:03:01 -0700 (PDT) Resent-From: trac+dane@trac.tools.ietf.org Cc: dane@ietf.org Subject: [dane] #38: Dane and EAP-FAST X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 03:03:02 -0000 #38: Dane and EAP-FAST EAP-FAST is based on TLS and thus it would make sense to allow support of DANE to be part of this EAP method. THis is not an issue for those cases where the base protocol is running directly on TCP, however it is an issue of one is running the EAP method over RADIUS or DIAMETER as there is no current defined prefix for such a method. -- -------------------------+---------------------------------------- Reporter: ietf@… | Owner: draft-ietf-dane-protocol@… Type: enhancement | Status: new Priority: major | Milestone: Component: protocol | Version: Severity: - | Keywords: -------------------------+---------------------------------------- Ticket URL: dane From ondrej.sury@nic.cz Fri Oct 14 06:48: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 56E7C21F8C60 for ; Fri, 14 Oct 2011 06:48:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L+5UJNLYv-DO for ; Fri, 14 Oct 2011 06:48: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 98FF321F8C5F for ; Fri, 14 Oct 2011 06:48:24 -0700 (PDT) Received: from kimac.office.nic.cz (fw.nic.cz [217.31.207.1]) by mail.nic.cz (Postfix) with ESMTPSA id 490712A0C50; Fri, 14 Oct 2011 15:48:23 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1318600103; bh=fSpzbfEHUOj3DB8SHp2HSXT0zWt+Ck5D7Od8nBFDcXc=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=NxkT2raPucx5m7gj4SL0Um68RSgfGFRilWpfLZgg5gZiuwcFCKakBycaTT40FWaO+ uMysDNA8CN/Y1nmg3r0caNtl0xhp1SKKqLEN1sjr/fcKC1uGm9Q9b86+523Wth9I+o 4k+uS/jBuF8Mn/8oQlxf5caCn1MKjej31mqQbv/4= Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <20111006134845.GC67889@shinkuro.com> Date: Fri, 14 Oct 2011 15:48:22 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <060.8aca11012e6c9583642ba071c54be972@trac.tools.ietf.org> <075.e771c9a4f93afa495f330ae9d1ebfa5a@trac.tools.ietf.org> <20111004062737.GA23425@xs.powerdns.com> <1317788285.1977.32.camel@localhost> <20111005072802.GA13563@xs.powerdns.com> <4E8C1458.6040309@cs.tcd.ie> <20111005211209.GO63242@shinkuro.com> <4E8CF063.7020403@cs.tcd.ie> <20111006134845.GC67889@shinkuro.com> To: Andrew Sullivan X-Mailer: Apple Mail (2.1251.1) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: dane@ietf.org Subject: Re: [dane] how about not talking about DNSSEC Re: #36: Only requiring DNSSEC where it is needed 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, 14 Oct 2011 13:48:25 -0000 On 6. 10. 2011, at 15:48, Andrew Sullivan wrote: > On Thu, Oct 06, 2011 at 01:03:47AM +0100, Stephen Farrell wrote: >=20 >> I was trying (perhaps not well) to say that it would not be >> acceptable for DANE to simply assert that some DNS data needs >> integrity without specifying how to achieve that. >>=20 >> It could be that the WG adopt the kind of position you relate above >> (smelly as it is, IMO for non-enterprise use-cases) but the main >> point is that it a) has to be specified and b) has to be >> interoperable. >=20 > It sounds to me, then, that the only sane thing for DANE to say is > MUST use DNSSEC, and leave it at that. RFC 4035 tells you at the > moment what you need to do to secure the last hop. If there's an > update to DNSSEC such that that changes, the "MUST use DNSSEC" for > everything DANE says need not change (because it can get included by > reference). I know there are those in this thread who think that's > already too prescriptive, but as I have previously argued, I can't > imagine anyone using TLSA without DNSSEC, which is the only technology > we have for DNS integrity assurance right now. >=20 > I would be quite stronly opposed to a lot of operational advice about > how to use DNSSEC going into any documents from this WG. It's > completely off-charter, and there's a perfectly good chartered WG over > in OPSAREA whose job that is. +1 on this position from me. DNSSEC is the technology for securing DNS we have now in IETF. If there is anything shiny, the DANE could be updated to use this. Hence I am against being too general by saying non-specific "DNS security". O. -- 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 ------------------------------------------- From ondrej.sury@nic.cz Fri Oct 14 06:52: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 81F3121F8B40 for ; Fri, 14 Oct 2011 06:52:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3WnxomsDF03Z for ; Fri, 14 Oct 2011 06:52:35 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id C0CAF21F8B3E for ; Fri, 14 Oct 2011 06:52:34 -0700 (PDT) Received: from kimac.office.nic.cz (fw.nic.cz [217.31.207.1]) by mail.nic.cz (Postfix) with ESMTPSA id 161632A2DA7; Fri, 14 Oct 2011 15:52:34 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1318600354; bh=+nFOFRhU/xvNAVPLRRU2CD+E1igeUWvllWjjNbRmUC4=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=Npc71a6Jlva+3tjsK4/CYHWchBQwyGsrB3Jk8D8ypyg7tv3mG3TuUarJm3/Wip1t/ 5qu4+kkJmXEVFF98P2g8ItDQX0FWjl3kQXa/Fi3ctjsdLUTc6ea2rCR02lDjgjZK4F cX5EfHqZ8J/1BqUTG+DEEYzs6Glt5qBlOnCTnNGk= Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: Date: Fri, 14 Oct 2011 15:52:33 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0A9F15DC-0D40-4C7E-A46F-D2F819C266AB@nic.cz> References: <80C62DC7-259D-48C9-B4B6-BFE6DA68B5F5@vpnc.org> <201110062207.p96M7nil014763@fs4113.wdf.sap.corp> To: Zack Weinberg X-Mailer: Apple Mail (2.1251.1) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: dane@ietf.org Subject: Re: [dane] #36: Only requiring DNSSEC where it is needed 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, 14 Oct 2011 13:52:38 -0000 On 7. 10. 2011, at 0:43, Zack Weinberg wrote: > On Thu, Oct 6, 2011 at 3:07 PM, Martin Rex wrote: >>> Scenario RP-without: If a TLSA record of type 0 and 1 is received = without >>> DNSSEC, then the relying party can still safely use the TLSA record = to limit >>> the PKIX validation. In Scenario RP-without, an attacker cannot make = the >>> relying party use a certificate that would have otherwise been = unusable for >>> authenticating the TLS server. >>=20 >> Still wrong. >>=20 >> A TLSA record of type 0 or 1 is entirely useless without DNSSEC, >> because it can be fabricated at will by an active attacker. >=20 > Against an active network attacker who can intercept and fabricate any > packet, I agree. >=20 > However, an unauthenticated (but assumed-legitimate) type 0/1 record > might offer additional protection against a limited network attacker > who can reterminate TLS sessions but can *not* tamper with DNS > traffic, and who additionally *does* have an improperly issued > certificate for the server whose communications they wish to > intercept. >=20 > Whether this is a realistic attacker I do not know, but I'm inclined > to rate it unlikely. I can imagine scenarios where the attacker can't > touch UDP for some reason Doesn't have to be such complicated scenario. It could be the attacker who sits close(r) to the server "wire", but not close enough to the DNS "wire". O. -- 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 ------------------------------------------- From ondrej.sury@nic.cz Fri Oct 14 07:02: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 DDDCA21F8B3E for ; Fri, 14 Oct 2011 07:02:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P0YwDBSNtuAR for ; Fri, 14 Oct 2011 07:02:05 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 22E6021F8B23 for ; Fri, 14 Oct 2011 07:02:05 -0700 (PDT) Received: from kimac.office.nic.cz (fw.nic.cz [217.31.207.1]) by mail.nic.cz (Postfix) with ESMTPSA id 14DFF2A2DC9; Fri, 14 Oct 2011 16:02:04 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1318600924; bh=V/jmYFGzSWpk4R0I0050c8O41RSMWq7W2psD6sDNVng=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=upVusduBkPrQI7i0uVSbSkSe2j+LN8e9an9g/Xhh8x1z8g9MLvuMGrfULqJbAxM8c n08qyWd5ClEo0OOqLVJMbrPdZZYFwGuLrgi2ogRKLFANssZY0ckXlrlJukaWvB0tTM 5YOI/ma8OrwPT7WXyPg5V2MhlTA8ZsykY/AWhNVg= Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <201110062345.p96NjkRb020895@fs4113.wdf.sap.corp> Date: Fri, 14 Oct 2011 16:02:03 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0294E053-33AD-463D-A8A5-58636549F2A0@nic.cz> References: <201110062345.p96NjkRb020895@fs4113.wdf.sap.corp> To: mrex@sap.com X-Mailer: Apple Mail (2.1251.1) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: DANE WG Subject: Re: [dane] #36: Only requiring DNSSEC where it is needed 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, 14 Oct 2011 14:02:06 -0000 On 7. 10. 2011, at 1:45, Martin Rex wrote: >> Martin Rex wrote: >>>=20 >>> A TLSA record of type 0 or 1 is entirely useless without DNSSEC, >>> because it can be fabricated at will by an active attacker. >>=20 >> Against an active network attacker who can intercept and fabricate = any >> packet, I agree. >>=20 >> However, an unauthenticated (but assumed-legitimate) type 0/1 record >> might offer additional protection against a limited network attacker >> who can reterminate TLS sessions but can *not* tamper with DNS >> traffic, and who additionally *does* have an improperly issued >> certificate for the server whose communications they wish to >> intercept. >>=20 >> Whether this is a realistic attacker I do not know, but I'm inclined >> to rate it unlikely. >=20 > I consider those scenarios where it could help unrealistic and = statistically > insignificant and I'm more worried about the negative side effects. >=20 > What does it take for an attacker to make a client talk to a fake = server > in posession of a fraudulent server cert from the TLS X.509 PKI that > will succeed PKIX cert path validation? > =20 > Either the attacker has to successfully spoof DNS A records (make your > client connect to the fake server) or the attacker has complete = control > over the network or networking gear and can transparently MITM your > network connections with the network addresses of the real server. Let's see... youtube.com HTTP servers are in 209.85.148.0/24 (advertised as = 209.85.128.0/17 in BGP), but youtube.com DNS servers are in 216.239.34.0/24 (advertised = as /24). So an attacker could f.e. hijack 209.85.148.0/24, but you will still get protection from DANE unless the attacker also hijacks 216.239.34.0/24. And it's not that unrealistic scenario, since similar hijack already had happened in the past. O. -- 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 ------------------------------------------- From mrex@sap.com Fri Oct 14 07:38: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 80EDC21F8C95 for ; Fri, 14 Oct 2011 07:38:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.913 X-Spam-Level: X-Spam-Status: No, score=-9.913 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8FtsfPy4Swov for ; Fri, 14 Oct 2011 07:38:57 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id C998D21F8C04 for ; Fri, 14 Oct 2011 07:38:56 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p9EEcs7Y029495 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 14 Oct 2011 16:38:54 +0200 (MEST) From: Martin Rex Message-Id: <201110141438.p9EEcr1e018769@fs4113.wdf.sap.corp> To: ondrej.sury@nic.cz (=?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?=) Date: Fri, 14 Oct 2011 16:38:53 +0200 (MEST) In-Reply-To: <0294E053-33AD-463D-A8A5-58636549F2A0@nic.cz> from "=?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?=" at Oct 14, 11 04:02:03 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] #36: Only requiring DNSSEC where it is needed 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, 14 Oct 2011 14:38:57 -0000 O. wrote: > > On 7. 10. 2011, at 1:45, Martin Rex wrote: > > > > Either the attacker has to successfully spoof DNS A records (make your > > client connect to the fake server) or the attacker has complete control > > over the network or networking gear and can transparently MITM your > > network connections with the network addresses of the real server. > > Let's see... > > youtube.com HTTP servers are in 209.85.148.0/24 (advertised as > 209.85.128.0/17 in BGP), but youtube.com DNS servers are in > 216.239.34.0/24 (advertised as /24). > > So an attacker could f.e. hijack 209.85.148.0/24, but you will still get > protection from DANE unless the attacker also hijacks 216.239.34.0/24. > > And it's not that unrealistic scenario, since similar hijack already had > happened in the past. You're missing the point. The TLS/DANE client will be unable to distinguish an attacker sitting close to the server and an attacker sitting close to itself, so the client has ZERO chance to know whether an _unprotected_ TLSA record that it received is original or was spoofed/inserted by an attacker. Btw. for inserting/spoofing DNS records it is *NOT* necessary to MITM network connections (although this facilitates a few things). -Martin From ondrej.sury@nic.cz Fri Oct 14 07:44: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 A329B21F8CBD for ; Fri, 14 Oct 2011 07:44:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Az5I1gJYUZs1 for ; Fri, 14 Oct 2011 07:44:17 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id B263A21F8CA8 for ; Fri, 14 Oct 2011 07:44:17 -0700 (PDT) Received: from kimac.office.nic.cz (fw.nic.cz [217.31.207.1]) by mail.nic.cz (Postfix) with ESMTPSA id AE6762A2E3F; Fri, 14 Oct 2011 16:44:16 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1318603456; bh=ojdMglG56aAJj4U5ErExqgDYDB9a+sTE9a8HX1FNMuM=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=ASp2OZqTb88u/L60i5SXkMC01HCV/Cy9ml/dUkPkNk1lGw9YTmR4cF4IbRbGD86vg lAfmNSBufmNLxmWVCDc/je6sNHAQVkwdPRiBPhP8oV3Q6Lg9myS0Bmq5TYEu9uMa2v QC/HJ7Gvl/WoJpD4hbEtvKkoSUIRZKajSW7eHhI8= Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <201110141438.p9EEcr1e018769@fs4113.wdf.sap.corp> Date: Fri, 14 Oct 2011 16:44:16 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4E3745D3-E653-4E1F-A27A-5FE6353F2C7D@nic.cz> References: <201110141438.p9EEcr1e018769@fs4113.wdf.sap.corp> To: mrex@sap.com X-Mailer: Apple Mail (2.1251.1) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: dane@ietf.org Subject: Re: [dane] #36: Only requiring DNSSEC where it is needed 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, 14 Oct 2011 14:44:18 -0000 On 14. 10. 2011, at 16:38, Martin Rex wrote: > O. wrote: >>=20 >> On 7. 10. 2011, at 1:45, Martin Rex wrote: >>>=20 >>> Either the attacker has to successfully spoof DNS A records (make = your >>> client connect to the fake server) or the attacker has complete = control >>> over the network or networking gear and can transparently MITM your >>> network connections with the network addresses of the real server. >>=20 >> Let's see... >>=20 >> youtube.com HTTP servers are in 209.85.148.0/24 (advertised as >> 209.85.128.0/17 in BGP), but youtube.com DNS servers are in >> 216.239.34.0/24 (advertised as /24). >>=20 >> So an attacker could f.e. hijack 209.85.148.0/24, but you will still = get >> protection from DANE unless the attacker also hijacks = 216.239.34.0/24. >>=20 >> And it's not that unrealistic scenario, since similar hijack already = had >> happened in the past. >=20 >=20 > You're missing the point. Looks like we both are :). Lemme clarify. > The TLS/DANE client will be unable to distinguish an attacker sitting > close to the server and an attacker sitting close to itself, so > the client has ZERO chance to know whether an _unprotected_ TLSA = record > that it received is original or was spoofed/inserted by an attacker. I know, but you (or Zack) have argued that it has a zero value, because the TLS CERT and TLSA DNS record will be spoofed at the same time. I am just arguing that there are some use cases where even unprotected TLSA record will make things better. I think we agree that it doesn't make things worse, don't we? Ondrej -- 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 ------------------------------------------- From henry.story@bblfish.net Fri Oct 14 07:45: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 BDFB221F8CC5 for ; Fri, 14 Oct 2011 07:45:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FgyvuedCB-Ny for ; Fri, 14 Oct 2011 07:45:16 -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 A756021F8CB9 for ; Fri, 14 Oct 2011 07:45:16 -0700 (PDT) Received: by wwf22 with SMTP id 22so2457644wwf.13 for ; Fri, 14 Oct 2011 07:45:16 -0700 (PDT) Received: by 10.216.181.5 with SMTP id k5mr2205649wem.20.1318602223368; Fri, 14 Oct 2011 07:23:43 -0700 (PDT) Received: from bblfish.home (AAubervilliers-651-1-129-100.w86-198.abo.wanadoo.fr. [86.198.96.100]) by mx.google.com with ESMTPS id ek13sm14501970wbb.3.2011.10.14.07.23.38 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 14 Oct 2011 07:23:38 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=utf-8 From: Henry Story In-Reply-To: Date: Fri, 14 Oct 2011 16:23:37 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6E8483A4-E314-4CF8-9C13-7350E10C4A61@bblfish.net> References: <060.8aca11012e6c9583642ba071c54be972@trac.tools.ietf.org> <075.e771c9a4f93afa495f330ae9d1ebfa5a@trac.tools.ietf.org> <20111004062737.GA23425@xs.powerdns.com> <1317788285.1977.32.camel@localhost> <20111005072802.GA13563@xs.powerdns.com> <4E8C1458.6040309@cs.tcd.ie> <20111005211209.GO63242@shinkuro.com> <4E8CF063.7020403@cs.tcd.ie> <20111006134845.GC67889@shinkuro.com> To: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= X-Mailer: Apple Mail (2.1251.1) Cc: dane@ietf.org Subject: Re: [dane] how about not talking about DNSSEC Re: #36: Only requiring DNSSEC where it is needed 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, 14 Oct 2011 14:45:17 -0000 On 14 Oct 2011, at 15:48, Ond=C5=99ej Sur=C3=BD wrote: >=20 > On 6. 10. 2011, at 15:48, Andrew Sullivan wrote: >=20 >> On Thu, Oct 06, 2011 at 01:03:47AM +0100, Stephen Farrell wrote: >>=20 >>> I was trying (perhaps not well) to say that it would not be >>> acceptable for DANE to simply assert that some DNS data needs >>> integrity without specifying how to achieve that. >>>=20 >>> It could be that the WG adopt the kind of position you relate above >>> (smelly as it is, IMO for non-enterprise use-cases) but the main >>> point is that it a) has to be specified and b) has to be >>> interoperable. >>=20 >> It sounds to me, then, that the only sane thing for DANE to say is >> MUST use DNSSEC, and leave it at that. RFC 4035 tells you at the >> moment what you need to do to secure the last hop. If there's an >> update to DNSSEC such that that changes, the "MUST use DNSSEC" for >> everything DANE says need not change (because it can get included by >> reference). I know there are those in this thread who think that's >> already too prescriptive, but as I have previously argued, I can't >> imagine anyone using TLSA without DNSSEC, which is the only = technology >> we have for DNS integrity assurance right now. >>=20 >> I would be quite stronly opposed to a lot of operational advice about >> how to use DNSSEC going into any documents from this WG. It's >> completely off-charter, and there's a perfectly good chartered WG = over >> in OPSAREA whose job that is. >=20 >=20 > +1 on this position from me. >=20 > DNSSEC is the technology for securing DNS we have now in IETF. If = there > is anything shiny, the DANE could be updated to use this. Hence I am > against being too general by saying non-specific "DNS security". Of course DNSsec is the right thing for security. But I think the aim of = this is just to split the work in two: 1. Just speak about the DNS data structures. publish an RFC for that 2. Write another RFC that explains how this ties to DNSEC in particular The point is that it is obvious that if you put your data in DNS with = the sec, then the claims made by your DNS cannot be relied upon.=20 Every endpoint just makes a claim. If you cannot trust the endpoint or = you cannot trust that you received the message from the endpoint then you cannot = trust the claim. That is simple to understand.=20 The other thing is what a TLS client should do when it receives claims from multiple parties. Well what it will do will of course depend = on who it trusts the most, and how it wishes to combine trust assertions. This is clearly = quite an open field. If a CA is super trustworthy and the DNS provider is not at all then it = may be better to ignore the dns provider. If it is the other way around, then the DNS provider = gets the advantage.=20 If both agree then we are in heaven. Henry >=20 > O. > -- > 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 > ------------------------------------------- >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane Social Web Architect http://bblfish.net/ From henry.story@bblfish.net Fri Oct 14 07:46: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 D08DC21F85F1 for ; Fri, 14 Oct 2011 07:46:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id saNGqTL8e5m7 for ; Fri, 14 Oct 2011 07:46:16 -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 E061521F85DB for ; Fri, 14 Oct 2011 07:46:15 -0700 (PDT) Received: by wyg24 with SMTP id 24so3494877wyg.31 for ; Fri, 14 Oct 2011 07:46:15 -0700 (PDT) Received: by 10.216.134.166 with SMTP id s38mr2902157wei.71.1318603573593; Fri, 14 Oct 2011 07:46:13 -0700 (PDT) Received: from bblfish.home (AAubervilliers-651-1-129-100.w86-198.abo.wanadoo.fr. [86.198.96.100]) by mx.google.com with ESMTPS id 11sm4426705wby.15.2011.10.14.07.46.10 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 14 Oct 2011 07:46:12 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=utf-8 From: Henry Story In-Reply-To: <6E8483A4-E314-4CF8-9C13-7350E10C4A61@bblfish.net> Date: Fri, 14 Oct 2011 16:46:09 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <060.8aca11012e6c9583642ba071c54be972@trac.tools.ietf.org> <075.e771c9a4f93afa495f330ae9d1ebfa5a@trac.tools.ietf.org> <20111004062737.GA23425@xs.powerdns.com> <1317788285.1977.32.camel@localhost> <20111005072802.GA13563@xs.powerdns.com> <4E8C1458.6040309@cs.tcd.ie> <20111005211209.GO63242@shinkuro.com> <4E8CF063.7020403@cs.tcd.ie> <20111006134845.GC67889@shinkuro.com> <6E8483A4-E314-4CF8-9C13-7350E10C4A61@bblfish.net> To: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= X-Mailer: Apple Mail (2.1251.1) Cc: dane@ietf.org Subject: Re: [dane] how about not talking about DNSSEC Re: #36: Only requiring DNSSEC where it is needed 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, 14 Oct 2011 14:46:17 -0000 Btw, just an other point. Splitting the syntax form the semantics has = been done before at the IETF: The Atom Working group produces 1 spec on the Atom = Syntax, and then one on the atom protocol. Henry On 14 Oct 2011, at 16:23, Henry Story wrote: >=20 > On 14 Oct 2011, at 15:48, Ond=C5=99ej Sur=C3=BD wrote: >=20 >>=20 >> On 6. 10. 2011, at 15:48, Andrew Sullivan wrote: >>=20 >>> On Thu, Oct 06, 2011 at 01:03:47AM +0100, Stephen Farrell wrote: >>>=20 >>>> I was trying (perhaps not well) to say that it would not be >>>> acceptable for DANE to simply assert that some DNS data needs >>>> integrity without specifying how to achieve that. >>>>=20 >>>> It could be that the WG adopt the kind of position you relate above >>>> (smelly as it is, IMO for non-enterprise use-cases) but the main >>>> point is that it a) has to be specified and b) has to be >>>> interoperable. >>>=20 >>> It sounds to me, then, that the only sane thing for DANE to say is >>> MUST use DNSSEC, and leave it at that. RFC 4035 tells you at the >>> moment what you need to do to secure the last hop. If there's an >>> update to DNSSEC such that that changes, the "MUST use DNSSEC" for >>> everything DANE says need not change (because it can get included by >>> reference). I know there are those in this thread who think that's >>> already too prescriptive, but as I have previously argued, I can't >>> imagine anyone using TLSA without DNSSEC, which is the only = technology >>> we have for DNS integrity assurance right now. >>>=20 >>> I would be quite stronly opposed to a lot of operational advice = about >>> how to use DNSSEC going into any documents from this WG. It's >>> completely off-charter, and there's a perfectly good chartered WG = over >>> in OPSAREA whose job that is. >>=20 >>=20 >> +1 on this position from me. >>=20 >> DNSSEC is the technology for securing DNS we have now in IETF. If = there >> is anything shiny, the DANE could be updated to use this. Hence I am >> against being too general by saying non-specific "DNS security". >=20 > Of course DNSsec is the right thing for security. But I think the aim = of this is just > to split the work in two: >=20 > 1. Just speak about the DNS data structures. publish an RFC for that > 2. Write another RFC that explains how this ties to DNSEC in = particular >=20 > The point is that it is obvious that if you put your data in DNS with = the sec, then > the claims made by your DNS cannot be relied upon.=20 >=20 > Every endpoint just makes a claim. If you cannot trust the endpoint or = you cannot > trust that you received the message from the endpoint then you cannot = trust the claim. > That is simple to understand.=20 >=20 > The other thing is what a TLS client should do when it receives > claims from multiple parties. Well what it will do will of course = depend on who it trusts > the most, and how it wishes to combine trust assertions. This is = clearly quite an open field. > If a CA is super trustworthy and the DNS provider is not at all then = it may be better to ignore > the dns provider. If it is the other way around, then the DNS provider = gets the advantage.=20 > If both agree then we are in heaven. >=20 > Henry >=20 >=20 >=20 >=20 >>=20 >> O. >> -- >> 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 >> ------------------------------------------- >>=20 >> _______________________________________________ >> dane mailing list >> dane@ietf.org >> https://www.ietf.org/mailman/listinfo/dane >=20 > Social Web Architect > http://bblfish.net/ >=20 Social Web Architect http://bblfish.net/ From paul.hoffman@vpnc.org Fri Oct 14 08:01: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 D0CEA21F8C6F for ; Fri, 14 Oct 2011 08:01:45 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YbQ6-H47ZOvw for ; Fri, 14 Oct 2011 08:01:45 -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 6BE7721F8C65 for ; Fri, 14 Oct 2011 08:01:45 -0700 (PDT) Received: from [10.20.30.100] (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 p9EF1ijd011693 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 14 Oct 2011 08:01:45 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1251.1) From: Paul Hoffman In-Reply-To: Date: Fri, 14 Oct 2011 08:01:45 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <060.8aca11012e6c9583642ba071c54be972@trac.tools.ietf.org> <075.e771c9a4f93afa495f330ae9d1ebfa5a@trac.tools.ietf.org> <20111004062737.GA23425@xs.powerdns.com> <1317788285.1977.32.camel@localhost> <20111005072802.GA13563@xs.powerdns.com> <4E8C1458.6040309@cs.tcd.ie> <20111005211209.GO63242@shinkuro.com> <4E8CF063.7020403@cs.tcd.ie> <20111006134845.GC67889@shinkuro.com> <6E8483A4-E314-4CF8-9C13-7350E10C4A61@bblfish.net> To: IETF DANE WG list X-Mailer: Apple Mail (2.1251.1) Subject: Re: [dane] how about not talking about DNSSEC Re: #36: Only requiring DNSSEC where it is needed 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, 14 Oct 2011 15:01:45 -0000 On Oct 14, 2011, at 7:46 AM, Henry Story wrote: > Btw, just an other point. Splitting the syntax form the semantics has = been done > before at the IETF: The Atom Working group produces 1 spec on the Atom = Syntax, > and then one on the atom protocol. This is a terrible idea for a new DNS RRtype. The example that Henry = gives is a poor one for the DANE WG. The format was meant to be able to = be read and written in many different fashions; the protocol document = was for exactly one way of writing the format. (I am quite familiar with = the situation given that I was co-chair of the WG...) --Paul Hoffman From henry.story@bblfish.net Fri Oct 14 08:08: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 BF03521F889A for ; Fri, 14 Oct 2011 08:08:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.149 X-Spam-Level: X-Spam-Status: No, score=-3.149 tagged_above=-999 required=5 tests=[AWL=0.450, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EUAC+z+XRBfs for ; Fri, 14 Oct 2011 08:08:44 -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 E1F6721F87D3 for ; Fri, 14 Oct 2011 08:08:43 -0700 (PDT) Received: by wwf22 with SMTP id 22so2483553wwf.13 for ; Fri, 14 Oct 2011 08:08:42 -0700 (PDT) Received: by 10.227.200.146 with SMTP id ew18mr3190423wbb.16.1318604921829; Fri, 14 Oct 2011 08:08:41 -0700 (PDT) Received: from bblfish.home (AAubervilliers-651-1-129-100.w86-198.abo.wanadoo.fr. [86.198.96.100]) by mx.google.com with ESMTPS id k26sm14667811wbo.16.2011.10.14.08.08.40 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 14 Oct 2011 08:08:41 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Henry Story In-Reply-To: Date: Fri, 14 Oct 2011 17:08:39 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8C27EE62-F7E8-4FFA-ADC2-1EC0B5549D1F@bblfish.net> References: <060.8aca11012e6c9583642ba071c54be972@trac.tools.ietf.org> <075.e771c9a4f93afa495f330ae9d1ebfa5a@trac.tools.ietf.org> <20111004062737.GA23425@xs.powerdns.com> <1317788285.1977.32.camel@localhost> <20111005072802.GA13563@xs.powerdns.com> <4E8C1458.6040309@cs.tcd.ie> <20111005211209.GO63242@shinkuro.com> <4E8CF063.7020403@cs.tcd.ie> <20111006134845.GC67889@shinkuro.com> <6E8483A4-E314-4CF8-9C13-7350E10C4A61@bblfish.net> To: Paul Hoffman X-Mailer: Apple Mail (2.1251.1) Cc: IETF DANE WG list Subject: Re: [dane] how about not talking about DNSSEC Re: #36: Only requiring DNSSEC where it is needed 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, 14 Oct 2011 15:08:44 -0000 On 14 Oct 2011, at 17:01, Paul Hoffman wrote: > On Oct 14, 2011, at 7:46 AM, Henry Story wrote: >=20 >> Btw, just an other point. Splitting the syntax form the semantics has = been done >> before at the IETF: The Atom Working group produces 1 spec on the = Atom Syntax, >> and then one on the atom protocol. >=20 > This is a terrible idea for a new DNS RRtype. The example that Henry = gives is a poor one for the DANE WG. The format was meant to be able to = be read and written in many different fashions; the protocol document = was for exactly one way of writing the format. (I am quite familiar with = the situation given that I was co-chair of the WG...) Why is it a terrible idea? DNS is not any different than any other = publication mechanism. It's archaic ok, but really it just published = data. So all you are doing by publishing something there is making a = statement, just as you are by putting an atom feed or document on the = web.=20 The nice thing is that you could have one part done already, and then = move to the more complicated piece of proofs and trust, which are = independent of what is being said. Henry >=20 > --Paul Hoffman >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane Social Web Architect http://bblfish.net/ From mrex@sap.com Fri Oct 14 08:09: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 B80DB21F8C6A for ; Fri, 14 Oct 2011 08:09:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.918 X-Spam-Level: X-Spam-Status: No, score=-9.918 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EFhu4JdHLhMw for ; Fri, 14 Oct 2011 08:09:08 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id EA0AC21F8C5D for ; Fri, 14 Oct 2011 08:09:07 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p9EF95tX010928 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 14 Oct 2011 17:09:05 +0200 (MEST) From: Martin Rex Message-Id: <201110141509.p9EF95TT020539@fs4113.wdf.sap.corp> To: ondrej.sury@nic.cz (=?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?=) Date: Fri, 14 Oct 2011 17:09:05 +0200 (MEST) In-Reply-To: <4E3745D3-E653-4E1F-A27A-5FE6353F2C7D@nic.cz> from "=?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?=" at Oct 14, 11 04:44:16 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] #36: Only requiring DNSSEC where it is needed 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, 14 Oct 2011 15:09:08 -0000 O. wrote: > > Martin Rex wrote: > > > > The TLS/DANE client will be unable to distinguish an attacker sitting > > close to the server and an attacker sitting close to itself, so > > the client has ZERO chance to know whether an _unprotected_ TLSA record > > that it received is original or was spoofed/inserted by an attacker. > > I know, but you (or Zack) have argued that it has a zero value, because > the TLS CERT and TLSA DNS record will be spoofed at the same time. On the contrary. The ONLY purpose of DNS TLSA records of usage 0/1 is to provide a means to the DNS admin to repudiate certs that look fine under TLS X.509 PKI validation. And that functionality is entirely lost without DNSSEC, because an attacker could spoof TLSA records if the client would accept them without DNSSEC, and the client has no means to notice that it was spoofed. It is vital that when the client can not DNSSEC validate TLSA records exactly as if DANE validation was impossible to perform. And once you are at that point, looking at the contents of unprotected TLSA records is a waste of time, and implementers who do will regularly fail to implement it in the fashion "no DANE validation possible". > > I am just arguing that there are some use cases where even unprotected > TLSA record will make things better. I think we agree that it doesn't > make things worse, don't we? No, it will not make things better, but it can easily make things much worse. Unless a TLSA client is able to DNSSEC validate the response, it has no clue whether it received all the information that the DNS admin put in there. It could be that some of those middleboxes (home gateways, firewalls and what-have-you) fail to forward only specific records (instead of all records of a type), so if you fail a TLS connect because the (non-malicious, just dense) middle box on your path and beyond your control does not forward specific records, then we've newly created an interop problem. Given that we *KNOW* that there are a number of serious problems with forwarding of DNS data in the installed base, we should not go down this path. -Martin From warren@kumari.net Sat Oct 15 02:25: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 6B4CA21F8B52 for ; Sat, 15 Oct 2011 02:25:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.185 X-Spam-Level: X-Spam-Status: No, score=-104.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3zSTXT-1toqr for ; Sat, 15 Oct 2011 02:25:26 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 051CB21F8AFD for ; Sat, 15 Oct 2011 02:25:25 -0700 (PDT) Received: from my.router (host17-9-static.198-31-b.business.telecomitalia.it [31.198.9.17]) by vimes.kumari.net (Postfix) with ESMTPSA id 887DA1B402B3 for ; Sat, 15 Oct 2011 05:25:24 -0400 (EDT) From: Warren Kumari Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Sat, 15 Oct 2011 05:25:48 -0400 Message-Id: <4AD0428F-DD47-4EAD-9595-A1CAC177F04A@kumari.net> To: DANE WG Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [dane] Traveling, away from keyboard... 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: Sat, 15 Oct 2011 09:25:26 -0000 Hi Dane, I am currently traveling (in Italy from 10/13-10/21) and will have = limited access to mail (the hotel I'm in has no Internet :-( ). I'll be in Senegal from 10/6-10/19, but apparently the hotel (and = convention center) there has good bits, so=85 I leave you in Ondrej's more than capable hands=85 W= From hallam@gmail.com Sun Oct 16 09:17: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 8FB7621F86A5 for ; Sun, 16 Oct 2011 09:17:27 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EFpuTTTUvgGF for ; Sun, 16 Oct 2011 09:17:26 -0700 (PDT) Received: from mail-yx0-f179.google.com (mail-yx0-f179.google.com [209.85.213.179]) by ietfa.amsl.com (Postfix) with ESMTP id DF9F721F8696 for ; Sun, 16 Oct 2011 09:17:25 -0700 (PDT) Received: by yxn35 with SMTP id 35so2635845yxn.38 for ; Sun, 16 Oct 2011 09:17:23 -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=fW/69cUhVWVTK5wsL94s0FexaYCIfkA4B1s0dt1Zlws=; b=npAkYUYYTrrZdqS9D53JniXJzAOIAJuvLI0Ox/EEYPTvpLxzfq6XsIfrfOiprywY6p OsZd4hMHigBFS/ZLfFFvuSyiInxK6E5q/kGTTWRVsoydWNUwfGk/NgZlErf+c0DoWna3 wsPUa+stKhqD+cFav2VJdKnJHX9ipvgR3XEdA= MIME-Version: 1.0 Received: by 10.101.180.25 with SMTP id h25mr3302596anp.8.1318781842947; Sun, 16 Oct 2011 09:17:22 -0700 (PDT) Received: by 10.100.212.14 with HTTP; Sun, 16 Oct 2011 09:17:22 -0700 (PDT) In-Reply-To: <8C27EE62-F7E8-4FFA-ADC2-1EC0B5549D1F@bblfish.net> References: <060.8aca11012e6c9583642ba071c54be972@trac.tools.ietf.org> <075.e771c9a4f93afa495f330ae9d1ebfa5a@trac.tools.ietf.org> <20111004062737.GA23425@xs.powerdns.com> <1317788285.1977.32.camel@localhost> <20111005072802.GA13563@xs.powerdns.com> <4E8C1458.6040309@cs.tcd.ie> <20111005211209.GO63242@shinkuro.com> <4E8CF063.7020403@cs.tcd.ie> <20111006134845.GC67889@shinkuro.com> <6E8483A4-E314-4CF8-9C13-7350E10C4A61@bblfish.net> <8C27EE62-F7E8-4FFA-ADC2-1EC0B5549D1F@bblfish.net> Date: Sun, 16 Oct 2011 12:17:22 -0400 Message-ID: From: Phillip Hallam-Baker To: Henry Story Content-Type: multipart/alternative; boundary=001636c92b9c49007204af6cd349 Cc: Paul Hoffman , IETF DANE WG list Subject: Re: [dane] how about not talking about DNSSEC Re: #36: Only requiring DNSSEC where it is needed 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, 16 Oct 2011 16:17:27 -0000 --001636c92b9c49007204af6cd349 Content-Type: text/plain; charset=ISO-8859-1 +1 At this point it seems highly unlikely that DANE will be deployed in the browser using only DNS transport for the reasons stated by the browser providers. The legacy DNS infrastructure is just not good enough to rely on it as a mechanism for key distribution. The Kaminsky/Langley approach of pickling out the chain into the cert (or the OCSP token) is likely to be the preferred mode of DANE use for a very considerable time. Separating these concerns is going to be essential to achieving deployment. On Fri, Oct 14, 2011 at 11:08 AM, Henry Story wrote: > > On 14 Oct 2011, at 17:01, Paul Hoffman wrote: > > > On Oct 14, 2011, at 7:46 AM, Henry Story wrote: > > > >> Btw, just an other point. Splitting the syntax form the semantics has > been done > >> before at the IETF: The Atom Working group produces 1 spec on the Atom > Syntax, > >> and then one on the atom protocol. > > > > This is a terrible idea for a new DNS RRtype. The example that Henry > gives is a poor one for the DANE WG. The format was meant to be able to be > read and written in many different fashions; the protocol document was for > exactly one way of writing the format. (I am quite familiar with the > situation given that I was co-chair of the WG...) > > Why is it a terrible idea? DNS is not any different than any other > publication mechanism. It's archaic ok, but really it just published data. > So all you are doing by publishing something there is making a statement, > just as you are by putting an atom feed or document on the web. > > The nice thing is that you could have one part done already, and then move > to the more complicated piece of proofs and trust, which are independent of > what is being said. > > > > Henry > > > > > > --Paul Hoffman > > > > _______________________________________________ > > dane mailing list > > dane@ietf.org > > https://www.ietf.org/mailman/listinfo/dane > > Social Web Architect > http://bblfish.net/ > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > -- Website: http://hallambaker.com/ --001636c92b9c49007204af6cd349 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable +1

At this point it seems highly unlikely that DANE will= be deployed in the browser using only DNS transport for the reasons stated= by the browser providers. The legacy DNS infrastructure is just not good e= nough to rely on it as a mechanism for key distribution.

The Kaminsky/Langley approach of pickling out the chain= into the cert (or the OCSP token) is likely to be the preferred mode of DA= NE use for a very considerable time.

Separating th= ese concerns is going to be essential to achieving deployment.


On Fri, Oct 14, 2011 at 11:08 AM, H= enry Story <henry.story@bblfish.net> wrote:

On 14 Oct 2011, at 17:01, Paul Hoffman wrote:

> On Oct 14, 2011, at 7:46 AM, Henry Story wrote:
>
>> Btw, just an other point. Splitting the syntax form the semantics = has been done
>> before at the IETF: The Atom Working group produces 1 spec on the = Atom Syntax,
>> and then one on the atom protocol.
>
> This is a terrible idea for a new DNS RRtype. The example that Henry g= ives is a poor one for the DANE WG. The format was meant to be able to be r= ead and written in many different fashions; the protocol document was for e= xactly one way of writing the format. (I am quite familiar with the situati= on given that I was co-chair of the WG...)

Why is it a terrible idea? DNS is not any different than any other pu= blication mechanism. It's archaic ok, but really it just published data= . So all you are doing by publishing something there is making a statement,= just as you are by putting an atom feed or document on the web.

The nice thing is that you could have one part done already, and then move = to the more complicated piece of proofs and trust, which are independent of= what is being said.



Henry


>
> --Paul Hoffman
>
> _______________________________________________
> dane mailing list
> dane@ietf.org
> https://www.ietf.org/mailman/listinfo/dane

Social Web Architect
http://bblfish.net/
___________________________________= ____________
dane mailing list
dane@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/dane



--
= Website: http://hallambaker.com/
--001636c92b9c49007204af6cd349-- From hallam@gmail.com Sun Oct 16 09:40: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 0404D21F86F6 for ; Sun, 16 Oct 2011 09:40:29 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tYykOowkbVnw for ; Sun, 16 Oct 2011 09:40:28 -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 1D93E21F86EE for ; Sun, 16 Oct 2011 09:40:28 -0700 (PDT) Received: by ywb26 with SMTP id 26so1137618ywb.31 for ; Sun, 16 Oct 2011 09:40: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=u2R4aYV/kiv07hjNe8Au+xXYfyjG2Hi5+NjLgkn/Vjw=; b=Cbcx9tevo3St17AnwPWjcvc2pQ1eJFDNjnE2Y5JhoCjgbi5Eqyvau34YwADnrohS9i 2VK+LqWYp2VMwwK49FxSfuSZQI2Hv2HrKUcxzVJ4iI7RbmXv2qAXt7SNDTOS8DKsxkM9 bT0KpOH65r5d687A7aXQVCWNt66OJ5gtQtOjE= MIME-Version: 1.0 Received: by 10.101.180.25 with SMTP id h25mr3313399anp.8.1318783227562; Sun, 16 Oct 2011 09:40:27 -0700 (PDT) Received: by 10.100.212.14 with HTTP; Sun, 16 Oct 2011 09:40:27 -0700 (PDT) In-Reply-To: References: <712CCE0F-000B-4E65-9407-41AF1D150B19@vpnc.org> <6D0F718A-97C1-452E-AA56-5C13C664C546@vpnc.org> Date: Sun, 16 Oct 2011 12:40:27 -0400 Message-ID: From: Phillip Hallam-Baker To: Eric Rescorla Content-Type: multipart/alternative; boundary=001636c92b9cd08aeb04af6d2505 Cc: Paul Hoffman , IETF DANE WG list Subject: Re: [dane] Text in S 4.4 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, 16 Oct 2011 16:40:29 -0000 --001636c92b9cd08aeb04af6d2505 Content-Type: text/plain; charset=ISO-8859-1 +1 to EKR This spec is unacceptable to me unless this is changed Trying to redefine the semantics of TLS and PKIX is futile and childish. It is not going to happen regardless of how many people say they agree in the WG because the test is IETF consensus. And that is not going to be driven by a narrow clique with zero implementation support. DANE is becoming an obstacle to addressing the problems that it seeks to address. There are now other initiatives underway in other forums. On Wed, Oct 12, 2011 at 11:27 AM, Eric Rescorla wrote: > On Wed, Oct 12, 2011 at 8:10 AM, Paul Hoffman > wrote: > > On Oct 11, 2011, at 9:37 PM, Eric Rescorla wrote: > > > >> On Tue, Oct 11, 2011 at 8:28 PM, Paul Hoffman > wrote: > >>> On Oct 11, 2011, at 5:37 PM, Eric Rescorla wrote: > >>> > >>>> 1. Should there be a mandatory fail here. > >>>> 2. Should that fail be expressed as a TLS alert. > >>>> 3. Should that alert be access denied. > >>> > >>> #1 and #2 are linked in that, if we do not do a "mandatory fail as a > fatal TLS alert", we would need to design a DANE API. > >> > >> I'm not sure that this is true. For instance, you could say "MUST > >> terminate the connection." Why does that require > >> an alert. For that matter, why can't you just say "MUST be regarded as > >> suspect and SHOULD terminate the > >> connection. > > > > > > OK, I thought that #2 was a question about "DANE API" versus "do it in > TLS". So that I'm not speaking for you, are you saying that #2 is about "TLS > alert" versus "terminate connection"? > > I'm not sure I understand the question. The current text requires that > the connection be terminated > with a fatal TLS alert. I think it's an open question whether that > should be the requirement as opposed > to simply requiring that the application not proceed with the > connection and leave the manner > unspecified. > > -Ekr > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > -- Website: http://hallambaker.com/ --001636c92b9cd08aeb04af6d2505 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable +1 to EKR

This spec is unacceptable to me unless this is= changed


Trying to redefine the sem= antics of TLS and PKIX is futile and childish. It is not going to happen re= gardless of how many people say they agree in the WG because the test is IE= TF consensus. And that is not going to be driven by a narrow clique with ze= ro implementation support.

DANE is becoming an obstacle to addressing the problems= that it seeks to address.

There are now other ini= tiatives underway in other forums.


On Wed, Oct 12, 2011 at 11:27 AM, Eric Rescorla <ekr@rtfm.com> wrote:
On Wed, Oct 12, 2011 at 8:10 AM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
> On Oct 11, 2011, at 9:37 PM, Eric Rescorla wrote:
>
>> On Tue, Oct 11, 2011 at 8:28 PM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
>>> On Oct 11, 2011, at 5:37 PM, Eric Rescorla wrote:
>>>
>>>> 1. Should there be a mandatory fail here.
>>>> 2. Should that fail be expressed as a TLS alert.
>>>> 3. Should that alert be access denied.
>>>
>>> #1 and #2 are linked in that, if we do not do a "mandator= y fail as a fatal TLS alert", we would need to design a DANE API.
>>
>> I'm not sure that this is true. For instance, you could say &q= uot;MUST
>> terminate the connection." Why does that require
>> an alert. For that matter, why can't you just say "MUST b= e regarded as
>> suspect and SHOULD terminate the
>> connection.
>
>
> OK, I thought that #2 was a question about "DANE API" versus= "do it in TLS". So that I'm not speaking for you, are you sa= ying that #2 is about "TLS alert" versus "terminate connecti= on"?

I'm not sure I understand the question. The current text requires= that
the connection be terminated
with a fatal TLS alert. I think it's an open question whether that
should be the requirement as opposed
to simply requiring that the application not proceed with the
connection and leave the manner
unspecified.

-Ekr
_________________________________________= ______
dane mailing list
dane@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/dane



--
= Website: http://hallambaker.com/
--001636c92b9cd08aeb04af6d2505-- From richard@highwayman.com Mon Oct 17 10:30: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 CC83A21F8C9E for ; Mon, 17 Oct 2011 10:30:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_93=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id APVwwnBNqa0o for ; Mon, 17 Oct 2011 10:30:18 -0700 (PDT) Received: from lon1-post-2.mail.demon.net (lon1-post-2.mail.demon.net [195.173.77.149]) by ietfa.amsl.com (Postfix) with ESMTP id 6F47521F8C97 for ; Mon, 17 Oct 2011 10:30:18 -0700 (PDT) Received: from happyday.demon.co.uk ([80.177.121.10] helo=happyday.al.cl.cam.ac.uk) by lon1-post-2.mail.demon.net with esmtp (Exim 4.69) id 1RFr0z-0005Gi-al for dane@ietf.org; Mon, 17 Oct 2011 17:30:17 +0000 Message-ID: <3Cxem7J2VGnOFAN3@highwayman.com> Date: Mon, 17 Oct 2011 18:27:18 +0100 To: dane@ietf.org From: Richard Clayton MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailer: Turnpike Integrated Version 5.03 M Subject: [dane] Call for Papers: Securing and Trusting Internet Names, SATIN 2012 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Richard Clayton List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 17:30:20 -0000 The usual apologies if you see multiple copies of this CFP, but the inhabitants of this mailing list are more likely than most to wish to submit papers! Call for Papers: Securing and Trusting Internet Names, SATIN 2012 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D When: Thursday 22 & Friday 23 March 2012 Note that IETF 83 is in Paris, CZ the following week Where: National Physical Laboratory (NPL) Teddington, London, UK Timetable: Submissions due: Sun 22 Jan 2012, 11:59 PST Notification of Acceptance: Wed 22 Feb 2012 Final Papers Due: Mon 13 Mar 2012 Overview =3D=3D=3D=3D=3D=3D=3D=3D The domain name system, on which the Internet entirely relies, has always been inherently insecure. Spoofing of IP source addresses means that any wide area UDP protocol (such as DNS) can be forged. Cache poisoning attacks can be made less likely but not prevented altogether. ISPs, or others who can intercept traffic, can redirect end users to sites of their choosing. Users can choose (or have forced upon them) DNS services that suppress access to sites for policy reasons. DNSSEC, which addresses some of these issues, has been under development for years - but is finally ready for use; although some of the finer details are still being worked out. However, even at the current scale of deployment, implementation issues are creating unexpected levels of traffic, and that is before the bad guys make any contribution. Meanwhile DNSCURVE is being promoted as a lightweight method of securing the links to and between name servers, which addresses some, but by no means all, of the security issues. DNSSEC is also being seen by some as a distributed, secure, key distribution system, which could support new applications, or replace existing mechanisms for establishing trust in the identity of endpoints. The IETF's DANE working group is already addressing these issues. Others merely see DNSSEC as a way of defeating marketers who want to inject targeted advertising into browser sessions. But how effective will these ideas be if we continue with our existing APIs and stub resolvers? There are significant issues with DNS besides just its integrity. DNS services can be used to amplify denial-of-service attacks to create very substantial traffic flows. Malware has also been using the DNS for rendezvous arrangements, and has avoided countermeasures by exploiting the DNS system through "fluxing" and other techniques. There are also signs of a "tragedy of the commons" as legitimate companies fill the DNS with large numbers of names, or set low TTLs, to give a performance "edge". Meanwhile, some applications pre-fetch DNS answers, with little heed to the impact on the infrastructure. This latter technique raises privacy issues, as indeed does the proposal to 'leak' partial identities of requestors who contact recursive resolvers, with the aim of providing different answers to machines in different blocks of address space. All of this makes DNS, once amongst the most boring of topics, into one of the more exciting. The first running of this workshop in April 2011 was a big success, and this second event will be equally significant. Topics =3D=3D=3D=3D=3D=3D SATIN aims to provide a forum for academic work on the security of the DNS alongside industry presentations on practical experiences in providing name services. This workshop will expose the academics to the real problems that industry is encountering, and show industry what academia has to offer them. To improve the flow of information (and as was most successful at the first SATIN workshop) presentations will be restricted to 15 minutes with 15 minutes of general discussion to follow. Submissions must be made under either an "academic" or "industry" label (relating entirely to the content rather than the affiliations of any author), because the two types will be judged by different standards. Academic work will be viewed as an "extended abstract" and should aim to meet the general standard for acceptance into normal conferences in the field. However, since this is a workshop, early results and initial ideas are welcomed. Industry submissions should be relevant, insightful, and technical, and should provide information that cannot be gleaned from reading sales brochures or manuals. In all cases, real-world operational, implementation, and experimental results will be preferred, and these results should inform the DNS protocol development process wherever relevant or possible. Topics of interest include but are not limited to: Attacks on naming services DNSSEC DNSCURVE Alternative methods of securing name services APIs for DNS resolvers Using DNS as a platform for other applications Denial of service and the DNS Malware and the DNS DNS caching on the modern Internet Privacy and the DNS Application behaviour and the DNS Security economics of naming services Passive DNS Operational experience Measurement studies New threats and challenges Questions regarding whether a topic would be suitable are welcome and=20 should be sent to the programme chair, richard.clayton AT npl.co.uk Workshop Organizers =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Programme Chair: Richard Clayton NPL and University of Cambridge Programme Committee: Nevil Brownlee, University of Auckland Ben Laurie Google Anne-Marie Eklund L=F6winder .SE (The Internet Infrastructure Foundation) Dan Massey Colorado State University Douglas Maughan Department of Homeland Security Andrew W Moore University of Cambridge Jose Nazario Arbor Networks Roberto Perdisci University of Georgia Dave Piscitello ICANN Paul Vixie ISC Nicholas Weaver ICSI & UC Berkeley Jonathan Williams NPL Submissions =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D All submissions must be in IEEE two column format and no longer than eight (8) 8.5'' x 11'' pages, including figures, tables, and references. That means that the text must be set in two columns in 10 point type on 12 point (single-spaced) leading, with the text block being no more than 7.2'' wide by 9.6'' deep. Author names and affiliations should appear on the title page. The use of LaTeX and the IEEEtrans.cls file to create submissions is very strongly encouraged: http://conferences.npl.co.uk/satin/format.html Submissions must be submitted in PDF format via the SATIN 2012 website: http://conferences.npl.co.uk/satin/submit.html Simultaneous submission of the same work to multiple venues, submission of previously published work, or plagiarism, is dishonest and/or fraudulent and action may be taken if this occurs. Note, however, that we expect that many papers accepted for SATIN will eventually be extended as full papers suitable for presentation at other conferences. About the National Physical Laboratory =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The National Physical Laboratory (NPL) is one of the UK's leading science and research facilities. It is a world-leading centre of excellence in developing and applying the most accurate standards, science and technology available. NPL occupies a unique position as the UK's National Measurement Institute and sits at the intersection between scientific discovery and real world application. Its expertise and original research have underpinned quality of life, innovation and competitiveness for UK citizens and business for more than a century. NPL is collaborating with the University of Cambridge in a three year programme to develop robust and accurate measurements of Internet security mechanisms. Measuring and understanding the deployment of DNSSEC and other trust mechanisms for Internet names is a key part of this ongoing programme. More at: http://conferences.npl.co.uk/satin/ --=20 Dr Richard Clayton tel: +44 1223 763570, mobile: +44 7887 794090 Computer Laboratory, University of Cambridge, CB3 0FD National Physical Laboratory, Hampton Road, Teddington, TW11 0LW From warren@kumari.net Mon Oct 17 11:04: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 E465611E809A for ; Mon, 17 Oct 2011 11:04:16 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t8gWQ3eCMUXR for ; Mon, 17 Oct 2011 11:04:16 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id E234111E8098 for ; Mon, 17 Oct 2011 11:04:15 -0700 (PDT) Received: from [192.168.1.8] (83-103-81-66.ip.fastwebnet.it [83.103.81.66]) by vimes.kumari.net (Postfix) with ESMTPSA id 89CEF1B4002B; Mon, 17 Oct 2011 14:04:14 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warren Kumari In-Reply-To: Date: Mon, 17 Oct 2011 14:04:12 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <1EB97373-27C6-43EF-A824-FD1CA0FF857F@kumari.net> References: <060.8aca11012e6c9583642ba071c54be972@trac.tools.ietf.org> <075.e771c9a4f93afa495f330ae9d1ebfa5a@trac.tools.ietf.org> <20111004062737.GA23425@xs.powerdns.com> <1317788285.1977.32.camel@localhost> <20111005072802.GA13563@xs.powerdns.com> <4E8C1458.6040309@cs.tcd.ie> <20111005211209.GO63242@shinkuro.com> <4E8CF063.7020403@cs.tcd.ie> <20111006134845.GC67889@shinkuro.com> <6E8483A4-E314-4CF8-9C13-7350E10C4A61@bblfish.net> <8C27EE62-F7E8-4FFA-ADC2-1EC0B5549D1F@bblfish.net> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1084) Cc: IETF DANE WG list , Paul Hoffman Subject: Re: [dane] how about not talking about DNSSEC Re: #36: Only requiring DNSSEC where it is needed 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, 17 Oct 2011 18:04:17 -0000 Apologies for terseness, grumpy tone not intentional -- very limited = Internet access. On Oct 16, 2011, at 12:17 PM, Phillip Hallam-Baker wrote: > +1 >=20 > At this point it seems highly unlikely that DANE will be deployed in = the browser using only DNS transport for the reasons stated by the = browser providers. The legacy DNS infrastructure is just not good enough = to rely on it as a mechanism for key distribution. >=20 > The Kaminsky/Langley approach of pickling out the chain into the cert = (or the OCSP token) is likely to be the preferred mode of DANE use for a = very considerable time. While cool and sexy, I don't think that it can be called DANE -- from = the charter: "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=20 keys which are associated with a service located at a domain name. " and=20 "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." If the WG is sufficiently motivated we can discuss charter amendment, = but I think it would be better to first complete the "how to do this = with DNS" (the D in DANE) before starting on "how to do this with foo" W >=20 > Separating these concerns is going to be essential to achieving = deployment. >=20 >=20 > On Fri, Oct 14, 2011 at 11:08 AM, Henry Story = wrote: >=20 > On 14 Oct 2011, at 17:01, Paul Hoffman wrote: >=20 > > On Oct 14, 2011, at 7:46 AM, Henry Story wrote: > > > >> Btw, just an other point. Splitting the syntax form the semantics = has been done > >> before at the IETF: The Atom Working group produces 1 spec on the = Atom Syntax, > >> and then one on the atom protocol. > > > > This is a terrible idea for a new DNS RRtype. The example that Henry = gives is a poor one for the DANE WG. The format was meant to be able to = be read and written in many different fashions; the protocol document = was for exactly one way of writing the format. (I am quite familiar with = the situation given that I was co-chair of the WG...) >=20 > Why is it a terrible idea? DNS is not any different than any other = publication mechanism. It's archaic ok, but really it just published = data. So all you are doing by publishing something there is making a = statement, just as you are by putting an atom feed or document on the = web. >=20 > The nice thing is that you could have one part done already, and then = move to the more complicated piece of proofs and trust, which are = independent of what is being said. >=20 >=20 >=20 > Henry >=20 >=20 > > > > --Paul Hoffman > > > > _______________________________________________ > > dane mailing list > > dane@ietf.org > > https://www.ietf.org/mailman/listinfo/dane >=20 > Social Web Architect > http://bblfish.net/ >=20 > _______________________________________________ > 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 hallam@gmail.com Mon Oct 17 11:32: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 0432421F8B79 for ; Mon, 17 Oct 2011 11:32:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.765 X-Spam-Level: X-Spam-Status: No, score=-2.765 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dg-LMB-wCi1F for ; Mon, 17 Oct 2011 11:32:29 -0700 (PDT) Received: from mail-yx0-f179.google.com (mail-yx0-f179.google.com [209.85.213.179]) by ietfa.amsl.com (Postfix) with ESMTP id D963E21F8B72 for ; Mon, 17 Oct 2011 11:32:28 -0700 (PDT) Received: by yxn35 with SMTP id 35so3979553yxn.38 for ; Mon, 17 Oct 2011 11:32:28 -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=D5WmzyE48eR0Z9y1x8p8bTW7p8njjmhNwhQkbjyL8CY=; b=e6wRfmZTK9Ymqdd59Nx3ZHGySNqKbmeAvJ0mCBle/j0XfeyvCHSmhm1TkE3AIoJXmX Cb8C+ZtXXAPf2avEQ3+EmrURlpALMAZgZyUOFrQO/MEIgtX7gjzzKR5J5m/Jbimv3/AU HQyzjkNTVDZ0Jy4MJRa3uUKYTJ39tUkIJxJ/8= MIME-Version: 1.0 Received: by 10.101.57.11 with SMTP id j11mr3838608ank.162.1318876348021; Mon, 17 Oct 2011 11:32:28 -0700 (PDT) Received: by 10.100.212.14 with HTTP; Mon, 17 Oct 2011 11:32:27 -0700 (PDT) In-Reply-To: References: <060.8aca11012e6c9583642ba071c54be972@trac.tools.ietf.org> <075.e771c9a4f93afa495f330ae9d1ebfa5a@trac.tools.ietf.org> <20111004062737.GA23425@xs.powerdns.com> <1317788285.1977.32.camel@localhost> <20111005072802.GA13563@xs.powerdns.com> <4E8C1458.6040309@cs.tcd.ie> Date: Mon, 17 Oct 2011 14:32:27 -0400 Message-ID: From: Phillip Hallam-Baker To: Paul Wouters Content-Type: multipart/alternative; boundary=001636ed75ac39fafa04af82d4cd Cc: dane@ietf.org Subject: Re: [dane] how about not talking about DNSSEC Re: #36: Only requiring DNSSEC where it is needed 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, 17 Oct 2011 18:32:30 -0000 --001636ed75ac39fafa04af82d4cd Content-Type: text/plain; charset=ISO-8859-1 I think there are two sets of issues 1) To what degree and in what ways can a DANE statement be trusted without authentication 2) How is DNSSEC used as a mechanism to establish the authenticity of a DANE statement? I agree with Stephen that DANE has to do (2). Even if I am not going to use DNSSEC itself as my authentication scheme, I am going to use something that maps onto DNSSEC in some way. So just lijke DANE has to specify how it is used with TLS, DANE has to specify how it is used with DNSSEC. But that does not mean that it is acceptable to state MUST use DNSSEC. On Wed, Oct 5, 2011 at 12:13 PM, Paul Wouters wrote: > On Wed, 5 Oct 2011, Stephen Farrell wrote: > > Just saying: "sprinkle dust; get DNS integrity" is not sufficient >> for DANE IMO. The WG need to specify how that integrity, which >> is at least sometimes required, can be achieved, and you need >> to do that in an interoperable way that covers the "last mile" >> issue. >> > > I think DANE should state that when DNSSEC is required, it should > be DNSSEC including last mile protection. It should not try to > specify how to solve the last mile issue on the client. > > Is that what you meant? I first read this as "DANE should specify > the last mile solution", which I thought was out of scope for DANE. > > Paul > > ______________________________**_________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/**listinfo/dane > -- Website: http://hallambaker.com/ --001636ed75ac39fafa04af82d4cd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I think there are two sets of issues

1) To what degree a= nd in what ways can a DANE statement be trusted without authentication

2) How is DNSSEC used as a mechanism to establish the = authenticity of a DANE statement?


I agree with Stephen that DANE has to do= (2). Even if I am not going to use DNSSEC itself as my authentication sche= me, I am going to use something that maps onto DNSSEC in some way.=A0

So just lijke DANE has to specify how it is used with T= LS, DANE has to specify how it is used with DNSSEC. But that does not mean = that it is acceptable to state MUST use DNSSEC.

On Wed, Oct 5, 2011 at 12:13 PM, Paul Wouters <paul@xelerance.com> wrote:
=
On Wed, 5 Oct 2011, Stephen Farrell wrote:

Just saying: "sprinkle dust; get DNS integrity" is not sufficient=
for DANE IMO. The WG need to specify how that integrity, which
is at least sometimes required, can be achieved, and you need
to do that in an interoperable way that covers the "last mile" issue.

I think DANE should state that when DNSSEC is required, it should
be DNSSEC including last mile protection. It should not try to
specify how to solve the last mile issue on the client.

Is that what you meant? I first read this as "DANE should specify
the last mile solution", which I thought was out of scope for DANE.
Paul

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



--
= Website: http://hallambaker.com/
--001636ed75ac39fafa04af82d4cd-- From mrex@sap.com Mon Oct 17 11:43: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 E172221F8BB1 for ; Mon, 17 Oct 2011 11:43:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.071 X-Spam-Level: X-Spam-Status: No, score=-10.071 tagged_above=-999 required=5 tests=[AWL=0.178, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ory8l1iiuzz0 for ; Mon, 17 Oct 2011 11:43:22 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 29CE821F8B5C for ; Mon, 17 Oct 2011 11:43:22 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p9HIh4wF009450 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 17 Oct 2011 20:43:04 +0200 (MEST) From: Martin Rex Message-Id: <201110171843.p9HIh34e000144@fs4113.wdf.sap.corp> To: warren@kumari.net (Warren Kumari) Date: Mon, 17 Oct 2011 20:43:03 +0200 (MEST) In-Reply-To: <1EB97373-27C6-43EF-A824-FD1CA0FF857F@kumari.net> from "Warren Kumari" at Oct 17, 11 02:04:12 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] how about not talking about DNSSEC Re: #36: Only 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, 17 Oct 2011 18:43:24 -0000 Warren Kumari wrote: > > Phillip Hallam-Baker wrote: > > > > At this point it seems highly unlikely that DANE will be deployed in > > the browser using only DNS transport for the reasons stated by the > > browser providers. The legacy DNS infrastructure is just not good > > enough to rely on it as a mechanism for key distribution. > > > > The Kaminsky/Langley approach of pickling out the chain into the > > cert (or the OCSP token) is likely to be the preferred mode of DANE > > use for a very considerable time. Or a TLS extension (i.e. the Server returning all necessary DNSSEC records marshalled into a ServerHelloExtension after the client indicated support and willingness to receive this information by offering the extension in a ClientHelloExtension. > > While cool and sexy, I don't think that it can be called DANE -- from > the charter: > > "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. > " > > and > > "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." > > If the WG is sufficiently motivated we can discuss charter amendment, > but I think it would be better to first complete the "how to do this > with DNS" (the D in DANE) before starting on "how to do this with foo" I agree with PHB that DANE should limit itself to describe which DNSSEC records are necessary and need to be verified in what fashion, and that we entirely exclude the mechanims of how to obtain them from the DANE spec. domain (53/udp) and domain (53/tcp) are just two possibilities for obtaining DNSSEC information, but they're certainly not the only ones. The DANE spec ought to be entirely independent of the transport through which the DNSSEC records are obtained and focus on the operations necessary to validate the information. The security properties of DNSSEC are by intention to make it independent from transport (data origin authentication and data integrity protection) so that it properties are not affected by intermediate DNS server caching this data. -Martin From mrex@sap.com Mon Oct 17 11:59: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 87FF321F8C20 for ; Mon, 17 Oct 2011 11:59:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.089 X-Spam-Level: X-Spam-Status: No, score=-10.089 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vU7YeWcusm7C for ; Mon, 17 Oct 2011 11:59:31 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id D13F421F8C26 for ; Mon, 17 Oct 2011 11:59:30 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p9HIx76p012104 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 17 Oct 2011 20:59:07 +0200 (MEST) From: Martin Rex Message-Id: <201110171859.p9HIx6KU001078@fs4113.wdf.sap.corp> To: hallam@gmail.com (Phillip Hallam-Baker) Date: Mon, 17 Oct 2011 20:59:06 +0200 (MEST) In-Reply-To: from "Phillip Hallam-Baker" at Oct 17, 11 02:32:27 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] how about not talking about DNSSEC Re: #36: Only 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, 17 Oct 2011 18:59:31 -0000 Phillip Hallam-Baker wrote: > > I think there are two sets of issues > > 1) To what degree and in what ways can a DANE statement be trusted without > authentication > > 2) How is DNSSEC used as a mechanism to establish the authenticity of a DANE > statement? > > I agree with Stephen that DANE has to do (2). Even if I am not going to use > DNSSEC itself as my authentication scheme, I am going to use something that > maps onto DNSSEC in some way. > > So just lijke DANE has to specify how it is used with TLS, DANE has to > specify how it is used with DNSSEC. But that does not mean that it is > acceptable to state MUST use DNSSEC. I disagree here. I would very much like DANE to require DNSSEC validation (MUST), and ignore DANE-related DNS records (really, really SHOULD NOT) that are not DNSSEC validated. But I'm violently opposed to mandating that DNSSEC records must be obtained by a DANE client over domain (53/udp) or domain (53/tcp) transports. It should be at the discretion of DANE clients to cache whichever DNSSEC records they see fit -- and to obtain DNSSEC records through alternative means, e.g. through a TLS extension, OCSP extension or Server Cert extension. Personally I dislike Server cert extensions where it incurs frequent server cert changes (this is alien to server cert pinning) and I dislike OCSP requests by the client, because of their privacy issues, unless the OCSP responses are conveyed by the peer himself, e.g. through a stapled-OCSP-responses TLS extension. -Martin From hallam@gmail.com Mon Oct 17 16:59: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 68EBD11E8096 for ; Mon, 17 Oct 2011 16:59:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.39 X-Spam-Level: X-Spam-Status: No, score=-3.39 tagged_above=-999 required=5 tests=[AWL=0.208, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 92aB0-vQmY7t for ; Mon, 17 Oct 2011 16:59:06 -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 9FDDA11E8095 for ; Mon, 17 Oct 2011 16:59:06 -0700 (PDT) Received: by ywa8 with SMTP id 8so35497ywa.31 for ; Mon, 17 Oct 2011 16:59: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=yJ0G01hoOxSplXrQbM1ueso+SOR7xle4h6Wnj6VGoaw=; b=ls4x6skND7rUGg926b0IDyH9agmH8Ix2UTOE1KR8RQ1F9AaeBCD7oSbPpanVFP3BFb ewhhTNrQpCHdh4iJaFdHNpeq54QBRBOKQR9YpSIP5mvzTSZiW30o0vfAI3J6uXf+o4jv hYWnYypmw3d7dLKGqRzo20U6kxBBVmfBC13fE= MIME-Version: 1.0 Received: by 10.101.85.15 with SMTP id n15mr9247anl.30.1318895946215; Mon, 17 Oct 2011 16:59:06 -0700 (PDT) Received: by 10.100.212.14 with HTTP; Mon, 17 Oct 2011 16:59:06 -0700 (PDT) In-Reply-To: <201110171859.p9HIx6KU001078@fs4113.wdf.sap.corp> References: <201110171859.p9HIx6KU001078@fs4113.wdf.sap.corp> Date: Mon, 17 Oct 2011 19:59:06 -0400 Message-ID: From: Phillip Hallam-Baker To: mrex@sap.com Content-Type: multipart/alternative; boundary=001636ed667d5eb06604af8764e5 Cc: dane@ietf.org Subject: Re: [dane] how about not talking about DNSSEC Re: #36: Only 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, 17 Oct 2011 23:59:07 -0000 --001636ed667d5eb06604af8764e5 Content-Type: text/plain; charset=ISO-8859-1 What if people want to use Convegence rather than DNSSEC? I have a real problem with placing exclusive reliance on a PKI where the operator is attempting to reserve the right to drop names from the registry without a court order. On Mon, Oct 17, 2011 at 2:59 PM, Martin Rex wrote: > Phillip Hallam-Baker wrote: > > > > I think there are two sets of issues > > > > 1) To what degree and in what ways can a DANE statement be trusted > without > > authentication > > > > 2) How is DNSSEC used as a mechanism to establish the authenticity of a > DANE > > statement? > > > > I agree with Stephen that DANE has to do (2). Even if I am not going to > use > > DNSSEC itself as my authentication scheme, I am going to use something > that > > maps onto DNSSEC in some way. > > > > So just lijke DANE has to specify how it is used with TLS, DANE has to > > specify how it is used with DNSSEC. But that does not mean that it is > > acceptable to state MUST use DNSSEC. > > > I disagree here. > > I would very much like DANE to require DNSSEC validation (MUST), and > ignore DANE-related DNS records (really, really SHOULD NOT) that are > not DNSSEC validated. > > But I'm violently opposed to mandating that DNSSEC records must be > obtained by a DANE client over domain (53/udp) or domain (53/tcp) > transports. > > It should be at the discretion of DANE clients to cache whichever DNSSEC > records they see fit -- and to obtain DNSSEC records through alternative > means, e.g. through a TLS extension, OCSP extension or Server Cert > extension. > Personally I dislike Server cert extensions where it incurs frequent > server cert changes (this is alien to server cert pinning) > and I dislike OCSP requests by the client, because of their privacy > issues, unless the OCSP responses are conveyed by the peer himself, > e.g. through a stapled-OCSP-responses TLS extension. > > > -Martin > -- Website: http://hallambaker.com/ --001636ed667d5eb06604af8764e5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable What if people want to use Convegence rather than DNSSEC?

I have a real problem with placing exclusive reliance on a PKI where the = operator is attempting to reserve the right to drop names from the registry= without a court order.


On Mon, Oct 17, 2011 at 2:59 PM, Martin = Rex <mrex@sap.com&= gt; wrote:
Phillip Hallam-Baker wrote:
>
> I think there are two sets of issues
>
> 1) To what degree and in what ways can a DANE statement be trusted wit= hout
> authentication
>
> 2) How is DNSSEC used as a mechanism to establish the authenticity of = a DANE
> statement?
>
> I agree with Stephen that DANE has to do (2). Even if I am not going t= o use
> DNSSEC itself as my authentication scheme, I am going to use something= that
> maps onto DNSSEC in some way.
>
> So just lijke DANE has to specify how it is used with TLS, DANE has to=
> specify how it is used with DNSSEC. But that does not mean that it is<= br> > acceptable to state MUST use DNSSEC.


I disagree here.

I would very much like DANE to require DNSSEC validation (MUST), and
ignore DANE-related DNS records (really, really SHOULD NOT) that are
not DNSSEC validated.

But I'm violently opposed to mandating that DNSSEC records must be
obtained by a DANE client over domain (53/udp) or domain (53/tcp)
transports.

It should be at the discretion of DANE clients to cache whichever DNSSEC records they see fit -- and to obtain DNSSEC records through alternative means, e.g. through a TLS extension, OCSP extension or Server Cert extensio= n.
Personally I dislike Server cert extensions where it incurs frequent
server cert changes (this is alien to server cert pinning)
and I dislike OCSP requests by the client, because of their privacy
issues, unless the OCSP responses are conveyed by the peer himself,
e.g. through a stapled-OCSP-responses TLS extension.


-Martin



--
Websi= te: http://hallambaker.com/

--001636ed667d5eb06604af8764e5-- From paul@xelerance.com Mon Oct 17 20:14: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 205E21F0C5D for ; Mon, 17 Oct 2011 20:14:11 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qrw0ubyeAtFk for ; Mon, 17 Oct 2011 20:14:10 -0700 (PDT) Received: from mx.xelerance.com (mx.xelerance.com [193.110.157.188]) by ietfa.amsl.com (Postfix) with ESMTP id 483761F0C5A for ; Mon, 17 Oct 2011 20:14:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx.xelerance.com (Postfix) with ESMTP id CAAAA11E; Mon, 17 Oct 2011 23:13:46 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=xelerance.com; h= content-type:content-type:mime-version:user-agent:references :message-id:in-reply-to:subject:subject:from:from:date:date :received:received:received:received; s=smtp; t=1318907625; x= 1319512425; bh=EbguvdJBOG2UqmsDbA9PLwiHiEOnXCHQcCJAw7KRWGk=; b=k 4lFgKd27FsaG8AhpZD/NGn0uzn9wh1+EsbfFHb2lRFM56dxSUEd4NWG458V5Fr0G zqyvdmhFrNB1m5g4K+rG9KnBffbUuo8FQV/9slYOPfIlX3iOGsoBVf/3AaOhWBSN uWSVsgp8XDpUN8z25fCXR2cwbRYpy0TjKHRNbtmLEk= Received: from mx.xelerance.com ([127.0.0.1]) by localhost (mx.xelerance.com [127.0.0.1]) (amavisd-new, port 10026) with LMTP id cZCtTevgtG7B; Mon, 17 Oct 2011 23:13:45 -0400 (EDT) Received: from mail.xelerance.com (mail.xelerance.com [193.110.157.189]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.xelerance.com (Postfix) with ESMTPS id 0F53549; Mon, 17 Oct 2011 23:13:45 -0400 (EDT) Received: by mail.xelerance.com (Postfix, from userid 1001) id 0FA52EF3; Mon, 17 Oct 2011 23:13:43 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.xelerance.com (Postfix) with ESMTP id 0A1ABEF0; Mon, 17 Oct 2011 23:13:43 -0400 (EDT) Date: Mon, 17 Oct 2011 23:13:42 -0400 (EDT) From: Paul Wouters To: Phillip Hallam-Baker In-Reply-To: Message-ID: References: <201110171859.p9HIx6KU001078@fs4113.wdf.sap.corp> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dane@ietf.org Subject: Re: [dane] how about not talking about DNSSEC Re: #36: Only 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, 18 Oct 2011 03:14:11 -0000 On Mon, 17 Oct 2011, Phillip Hallam-Baker wrote: > What if people want to use Convegence rather than DNSSEC? Then they are not using DANE. Out of scope for this draft and WG. > I have a real problem with placing exclusive reliance on a PKI where the operator is attempting to reserve the right to drop names from the registry without a court order. That problem is also out of scope for DANE. If the registry drops your domain, you no longer have a domain. No DNS, no DNSSEC, no DANE. Choosing your operator or registry is out of scope for DANE. Can we please stay or target here. Thanks. Paul From warren@kumari.net Mon Oct 17 23:04: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 1B9DB11E80D0 for ; Mon, 17 Oct 2011 23:04:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.901 X-Spam-Level: X-Spam-Status: No, score=-105.901 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id icxoNH7aawio for ; Mon, 17 Oct 2011 23:04:46 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 20FEC11E8089 for ; Mon, 17 Oct 2011 23:04:45 -0700 (PDT) Received: from [192.168.1.4] (83-103-81-66.ip.fastwebnet.it [83.103.81.66]) by vimes.kumari.net (Postfix) with ESMTPSA id A9B1D1B4041E; Tue, 18 Oct 2011 02:04:44 -0400 (EDT) References: <201110171859.p9HIx6KU001078@fs4113.wdf.sap.corp> In-Reply-To: Mime-Version: 1.0 (iPhone Mail 8L1) Content-Type: text/plain; charset=us-ascii Message-Id: <3C39002A-5864-4F0C-85A1-7B0A2D618BC4@kumari.net> Content-Transfer-Encoding: quoted-printable X-Mailer: iPhone Mail (8L1) From: Warren Kumari Date: Tue, 18 Oct 2011 08:04:34 +0200 To: Paul Wouters Cc: "dane@ietf.org" Subject: Re: [dane] how about not talking about DNSSEC Re: #36: Only 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, 18 Oct 2011 06:04:47 -0000 Warren Kumari ------ Please excuse typing, etc -- This was sent from a device with a tiny keyboar= d. On Oct 18, 2011, at 5:13 AM, Paul Wouters wrote: > On Mon, 17 Oct 2011, Phillip Hallam-Baker wrote: >=20 >> What if people want to use Convegence rather than DNSSEC? >=20 > Then they are not using DANE. Out of scope for this draft and WG. +lots >=20 >> I have a real problem with placing exclusive reliance on a PKI where the o= perator is attempting to reserve the right to drop names from the registry w= ithout a court order. >=20 > That problem is also out of scope for DANE. If the registry drops your dom= ain, > you no longer have a domain. No DNS, no DNSSEC, no DANE. Choosing your ope= rator > or registry is out of scope for DANE. >=20 > Can we please stay or target here. Thanks. +even more lots... Folk are welcome to use Convergence, stapling, pickling, a wet noodle, etc.= , but this is not the right forum to discuss them. If we don't get a move on= with DANE itself, the other solutions may end up becoming the standard - wh= ich may be perfectly fine, but it would be sad if that occurred purely becau= se standards developed in the IETF take too long... So, as Paul said, let's stay on topic... W >=20 > Paul > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane >=20 From henry.story@bblfish.net Mon Oct 17 23:22: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 3828211E80D4 for ; Mon, 17 Oct 2011 23:22:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J4pi01d0r+Kl for ; Mon, 17 Oct 2011 23:22:23 -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 7B7FE11E8091 for ; Mon, 17 Oct 2011 23:22:20 -0700 (PDT) Received: by wwe6 with SMTP id 6so210045wwe.13 for ; Mon, 17 Oct 2011 23:22:19 -0700 (PDT) Received: by 10.227.200.146 with SMTP id ew18mr396095wbb.16.1318918939163; Mon, 17 Oct 2011 23:22:19 -0700 (PDT) Received: from bblfish.home (AAubervilliers-651-1-129-100.w86-198.abo.wanadoo.fr. [86.198.96.100]) by mx.google.com with ESMTPS id fo7sm1495168wbb.20.2011.10.17.23.22.17 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 17 Oct 2011 23:22:18 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Henry Story In-Reply-To: <3C39002A-5864-4F0C-85A1-7B0A2D618BC4@kumari.net> Date: Tue, 18 Oct 2011 08:22:16 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2649CF0B-6D48-4092-82CA-76EA8D00E554@bblfish.net> References: <201110171859.p9HIx6KU001078@fs4113.wdf.sap.corp> <3C39002A-5864-4F0C-85A1-7B0A2D618BC4@kumari.net> To: Warren Kumari X-Mailer: Apple Mail (2.1251.1) Cc: "dane@ietf.org" Subject: Re: [dane] how about not talking about DNSSEC Re: #36: Only 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, 18 Oct 2011 06:22:24 -0000 On 18 Oct 2011, at 08:04, Warren Kumari wrote: >=20 >=20 > Warren Kumari > ------ > Please excuse typing, etc -- This was sent from a device with a tiny = keyboard. >=20 > On Oct 18, 2011, at 5:13 AM, Paul Wouters wrote: >=20 >> On Mon, 17 Oct 2011, Phillip Hallam-Baker wrote: >>=20 >>> What if people want to use Convegence rather than DNSSEC? >>=20 >> Then they are not using DANE. Out of scope for this draft and WG. >=20 > +lots Convergence is working in a RESTful web way I believe. So in that case = it would probably use a different format to express the same semantic = content. DANE is clearly a DNS technology. No harm in working with the = old way of doing things, and defining it for this framework. They can = all complement each other. >>=20 >>> I have a real problem with placing exclusive reliance on a PKI where = the operator is attempting to reserve the right to drop names from the = registry without a court order. >>=20 >> That problem is also out of scope for DANE. If the registry drops = your domain, >> you no longer have a domain. No DNS, no DNSSEC, no DANE. Choosing = your operator >> or registry is out of scope for DANE. >>=20 >> Can we please stay or target here. Thanks. >=20 > +even more lots... >=20 > Folk are welcome to use Convergence, stapling, pickling, a wet = noodle, etc., but this is not the right forum to discuss them. If we = don't get a move on with DANE itself, the other solutions may end up = becoming the standard - which may be perfectly fine, but it would be sad = if that occurred purely because standards developed in the IETF take too = long... That is exactly why I suggested that DANE Should publish the formats = needed to express what is being said, and explain with those formats = mean declaratively: who is stating what about whome. That could be done = within a month. Then you can move on to the more complicated problems of = what should happen, and who should trust whome in another document. So = this would just be a way of speeding up the release of the DANE groups = work. Henry >=20 > So, as Paul said, let's stay on topic... >=20 > W >=20 >>=20 >> Paul >> _______________________________________________ >> dane mailing list >> dane@ietf.org >> https://www.ietf.org/mailman/listinfo/dane >>=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane Social Web Architect http://bblfish.net/ From trac+dane@trac.tools.ietf.org Tue Oct 18 00:53: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 37FB721F8C9A for ; Tue, 18 Oct 2011 00:53:17 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2kxN-ZD-0wSj for ; Tue, 18 Oct 2011 00:53:16 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id EFFFD21F8C94 for ; Tue, 18 Oct 2011 00:53:11 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1RG4Tx-0004ms-0Y; Tue, 18 Oct 2011 03:53:05 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "dane issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: henry.story@bblfish.net, matt@mattmccutchen.net, warren@kumari.net X-Trac-Project: dane Date: Tue, 18 Oct 2011 07:53:04 -0000 X-URL: http://tools.ietf.org/dane/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/dane/trac/ticket/14#comment:5 Message-ID: <070.f8cc77f727daff3d8016d45ddb3a5d89@trac.tools.ietf.org> References: <055.52e849c52f563625a28428b98f4ca55c@trac.tools.ietf.org> X-Trac-Ticket-ID: 14 In-Reply-To: <055.52e849c52f563625a28428b98f4ca55c@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: henry.story@bblfish.net, matt@mattmccutchen.net, warren@kumari.net, dane@ietf.org X-SA-Exim-Mail-From: trac+dane@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Cc: dane@ietf.org Subject: Re: [dane] #14: Bare Public Keys (once supported by TLS) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 07:53:17 -0000 #14: Bare Public Keys (once supported by TLS) Changes (by warren@…): * status: new => closed * resolution: => duplicate Comment: http://www.ietf.org/mail-archive/web/dane/current/msg03635.html This is being closed for cleanup / admin reasons. Once (hopefully not if) TLS supports BPK it is expected that this will be reopened.... I'm marking it as "duplicate", not because it is, but because none of the others seemed better.... -- --------------------------------+------------------------ Reporter: mlepinsk@… | Owner: Type: defect | Status: closed Priority: minor | Milestone: Component: protocol | Version: Severity: Active WG Document | Resolution: duplicate Keywords: | --------------------------------+------------------------ Ticket URL: dane From trac+dane@trac.tools.ietf.org Tue Oct 18 01:00: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 08DBC21F8CB3 for ; Tue, 18 Oct 2011 01:00:37 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Krze41i+CZEJ for ; Tue, 18 Oct 2011 01:00:36 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 25E6D21F8CB2 for ; Tue, 18 Oct 2011 01:00:36 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1RG4bD-0001ZG-0G; Tue, 18 Oct 2011 04:00:35 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "dane issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: warren@kumari.net X-Trac-Project: dane Date: Tue, 18 Oct 2011 08:00:34 -0000 X-URL: http://tools.ietf.org/dane/ X-Trac-Ticket-URL: http://wiki.tools.ietf.org/wg/dane/trac/ticket/16#comment:1 Message-ID: <070.6a7a617bb392b3a2caec39c3d272858e@trac.tools.ietf.org> References: <055.a8c1bf079e3d2a03cf5acf6a421383d2@trac.tools.ietf.org> X-Trac-Ticket-ID: 16 In-Reply-To: <055.a8c1bf079e3d2a03cf5acf6a421383d2@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: warren@kumari.net, dane@ietf.org X-SA-Exim-Mail-From: trac+dane@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Cc: dane@ietf.org Subject: Re: [dane] #16: OpenPGP Certificates X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 08:00:37 -0000 #16: OpenPGP Certificates Changes (by warren@…): * status: new => closed * resolution: => duplicate Comment: Ref: http://www.ietf.org/mail-archive/web/dane/current/msg03635.html The WG did not respond wanting to discuss this. See the discussions in #29. Closing. -- --------------------------------+------------------------ Reporter: mlepinsk@… | Owner: Type: enhancement | Status: closed Priority: major | Milestone: Component: protocol | Version: Severity: Active WG Document | Resolution: duplicate Keywords: | --------------------------------+------------------------ Ticket URL: dane From trac+dane@trac.tools.ietf.org Tue Oct 18 01:04: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 7B1B521F8C0C for ; Tue, 18 Oct 2011 01:04:30 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HKAXoCpd5Xj3 for ; Tue, 18 Oct 2011 01:04:29 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 3732521F8B5A for ; Tue, 18 Oct 2011 01:04:22 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1RG4es-0001kE-Bn; Tue, 18 Oct 2011 04:04:22 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "dane issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: warren@kumari.net X-Trac-Project: dane Date: Tue, 18 Oct 2011 08:04:22 -0000 X-URL: http://tools.ietf.org/dane/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/dane/trac/ticket/12#comment:1 Message-ID: <070.d147c08911931ad7a3aca2aca09b7559@trac.tools.ietf.org> References: <055.dea96ad1516eda873cb6fb22e8db115c@trac.tools.ietf.org> X-Trac-Ticket-ID: 12 In-Reply-To: <055.dea96ad1516eda873cb6fb22e8db115c@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: warren@kumari.net, dane@ietf.org X-SA-Exim-Mail-From: trac+dane@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Cc: dane@ietf.org Subject: Re: [dane] #12: Efficiency Improvements X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 08:04:30 -0000 #12: Efficiency Improvements Changes (by warren@…): * status: new => closed * resolution: => duplicate Comment: Ref: http://www.ietf.org/mail-archive/web/dane/current/msg03637.html This is a really old issue, that has been discussed in a number of tickets / venues. This is addressed in protocol document laying out the label and discussion on the prefixed DNS domain names and similar (1, 3, 19, etc) -- --------------------------------+------------------------ Reporter: mlepinsk@… | Owner: Type: enhancement | Status: closed Priority: minor | Milestone: Component: protocol | Version: Severity: Active WG Document | Resolution: duplicate Keywords: | --------------------------------+------------------------ Ticket URL: dane From warren@kumari.net Tue Oct 18 06:50:54 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 E3ADF21F84C2 for ; Tue, 18 Oct 2011 06:50:54 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YdXS2XyLv8Fv for ; Tue, 18 Oct 2011 06:50:54 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 2CE3221F84B4 for ; Tue, 18 Oct 2011 06:50:53 -0700 (PDT) Received: from [5.5.0.17] (vpn.snozzages.com [204.194.22.7]) by vimes.kumari.net (Postfix) with ESMTPSA id C85CB1B4002B for ; Tue, 18 Oct 2011 09:50:52 -0400 (EDT) From: Warren Kumari Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Tue, 18 Oct 2011 09:50:49 -0400 Message-Id: <18EF6A97-F80B-4BAC-A182-356D9480596A@kumari.net> To: IETF DANE WG list Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [dane] Meeting in Taipei. 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, 18 Oct 2011 13:50:55 -0000 Hello all, DANE is currently slated to meet on Monday in Taipei. We have had a number of interesting (and occasionally heated!) = discussions on list on a number of issues, and we finally appear to be = making progress on closing some of these issues.=20 The chairs (us!) are soliciting talks -- please let us know if you would = be willing to present something / if there is an open issue you are = willing to discuss. Please note that (as demonstrated by many (including us!)) you don't = need to be a consummate speaker to present something -- some employers = also are happier covering your attendance if you present=85 W From warren@kumari.net Wed Oct 19 05:46: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 A28F121F8A6F for ; Wed, 19 Oct 2011 05:46:36 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qNsoN0VV0MfX for ; Wed, 19 Oct 2011 05:46:36 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 3263521F8A57 for ; Wed, 19 Oct 2011 05:46:35 -0700 (PDT) Received: from [5.5.0.28] (vpn.snozzages.com [204.194.22.7]) by vimes.kumari.net (Postfix) with ESMTPSA id 036151B40673; Wed, 19 Oct 2011 08:46:33 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Warren Kumari In-Reply-To: <18EF6A97-F80B-4BAC-A182-356D9480596A@kumari.net> Date: Wed, 19 Oct 2011 08:46:30 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <7605D7FE-2582-415F-9254-6950EC092D97@kumari.net> References: <18EF6A97-F80B-4BAC-A182-356D9480596A@kumari.net> To: Warren Kumari X-Mailer: Apple Mail (2.1084) Cc: IETF DANE WG list Subject: Re: [dane] Meeting in Taipei. 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, 19 Oct 2011 12:46:36 -0000 After receiving some (off-list) mail, Ondrej and I chatted more, and we = would like to: A: close any open issues that we feel have been discussed and there is = consensus on[0]=85 B: ask folk to please open (**not** re-open) any final issues that you = feel need to be addressed, preferably in the next day or so. C: discuss each open issue at the face-to-face meeting in Taipei and = propose a resolution to the list. We are planning on only discussing topics that have issues open in the = tracker (unless we somehow get through all of them and have free time = :-P) -- please only open new topics, not slight variations on existing / = already discussed ones (also, this is not an opportunity for DoS / = throwing in the kitchen sink). We are (perhaps naively) hoping that we can discuss each issue = (calmly!), propose resolutions to the list and then soon after this = moving to WGLC -- we are planning on asking someone / someones to lead = this discussion... W On Oct 18, 2011, at 9:50 AM, Warren Kumari wrote: > Hello all, >=20 > DANE is currently slated to meet on Monday in Taipei. >=20 > We have had a number of interesting (and occasionally heated!) = discussions on list on a number of issues, and we finally appear to be = making progress on closing some of these issues.=20 >=20 > The chairs (us!) are soliciting talks -- please let us know if you = would be willing to present something / if there is an open issue you = are willing to discuss. > Please note that (as demonstrated by many (including us!)) you don't = need to be a consummate speaker to present something -- some employers = also are happier covering your attendance if you present=85 >=20 > W >=20 >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane >=20 From warren@kumari.net Tue Oct 25 08:10: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 7D65521F8B5B for ; Tue, 25 Oct 2011 08:10:38 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JuU2rc8hoCmX for ; Tue, 25 Oct 2011 08:10:35 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 18F1921F8B33 for ; Tue, 25 Oct 2011 08:10:17 -0700 (PDT) Received: from [10.196.208.139] (unknown [199.91.193.1]) by vimes.kumari.net (Postfix) with ESMTPSA id 3607D1B407D0; Tue, 25 Oct 2011 11:10:16 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Warren Kumari In-Reply-To: <7605D7FE-2582-415F-9254-6950EC092D97@kumari.net> Date: Tue, 25 Oct 2011 11:10:14 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <18EF6A97-F80B-4BAC-A182-356D9480596A@kumari.net> <7605D7FE-2582-415F-9254-6950EC092D97@kumari.net> To: Warren Kumari X-Mailer: Apple Mail (2.1084) Cc: IETF DANE WG list Subject: Re: [dane] Meeting in Taipei. 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, 25 Oct 2011 15:10:38 -0000 On Oct 19, 2011, at 8:46 AM, Warren Kumari wrote: > After receiving some (off-list) mail, Ondrej and I chatted more, and = we would like to: >=20 > A: close any open issues that we feel have been discussed and there is = consensus on[0]=85 >=20 > B: ask folk to please open (**not** re-open) any final issues that you = feel need to be addressed, preferably in the next day or so. >=20 > C: discuss each open issue at the face-to-face meeting in Taipei and = propose a resolution to the list. >=20 > We are planning on only discussing topics that have issues open in the = tracker (unless we somehow get through all of them and have free time = :-P) -- please only open new topics, not slight variations on existing / = already discussed ones (also, this is not an opportunity for DoS / = throwing in the kitchen sink). >=20 > We are (perhaps naively) hoping that we can discuss each issue = (calmly!), propose resolutions to the list and then soon after this = moving to WGLC -- we are planning on asking someone / someones to lead = this discussion=85 And we are pleased to announce that Richard L. Barnes has agreed to be = this person -- thanks Richard! Also, I'd like to apologize for being somewhat distracted, and not = getting item A done yet[0]. While this is entirely something that we = (your chairs) should be doing, we would be grateful if you nominate = issues that you feel have been sufficiently discussed and can be closed = / are no longer relevant (feel free to also include your view of = consensus).=20 W [0]: I've been on the road for 3 weeks (with particularly poor Internet = access) -- yes I *am* looking for sympathy and a cookie. >=20 > W >=20 >=20 >=20 > On Oct 18, 2011, at 9:50 AM, Warren Kumari wrote: >=20 >> Hello all, >>=20 >> DANE is currently slated to meet on Monday in Taipei. >>=20 >> We have had a number of interesting (and occasionally heated!) = discussions on list on a number of issues, and we finally appear to be = making progress on closing some of these issues.=20 >>=20 >> The chairs (us!) are soliciting talks -- please let us know if you = would be willing to present something / if there is an open issue you = are willing to discuss. >> Please note that (as demonstrated by many (including us!)) you don't = need to be a consummate speaker to present something -- some employers = also are happier covering your attendance if you present=85 >>=20 >> W >>=20 >>=20 >> _______________________________________________ >> dane mailing list >> dane@ietf.org >> https://www.ietf.org/mailman/listinfo/dane >>=20 >=20 From wwwrun@rfc-editor.org Wed Oct 26 15:52: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 5C64311E80B7; Wed, 26 Oct 2011 15:52:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.369 X-Spam-Level: X-Spam-Status: No, score=-102.369 tagged_above=-999 required=5 tests=[AWL=0.231, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id arCOuEXf+TAX; Wed, 26 Oct 2011 15:52:52 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id DEC4A11E80B6; Wed, 26 Oct 2011 15:52:49 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id C510898C283; Wed, 26 Oct 2011 15:52:49 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20111026225249.C510898C283@rfc-editor.org> Date: Wed, 26 Oct 2011 15:52:49 -0700 (PDT) Cc: dane@ietf.org, rfc-editor@rfc-editor.org Subject: [dane] RFC 6394 on Use Cases and Requirements for DNS-Based Authentication of Named Entities (DANE) 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, 26 Oct 2011 22:52:53 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6394 Title: Use Cases and Requirements for DNS-Based Authentication of Named Entities (DANE) Author: R. Barnes Status: Informational Stream: IETF Date: October 2011 Mailbox: rbarnes@bbn.com Pages: 12 Characters: 29477 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-dane-use-cases-05.txt URL: http://www.rfc-editor.org/rfc/rfc6394.txt Many current applications use the certificate-based authentication features in Transport Layer Security (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 certificate authorities (CAs), but additional information can be provided via the DNS itself. This document describes a set of use cases in which the DNS and DNS Security Extensions (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. [STANDARDS-TRACK] This document is a product of the DNS-based Authentication of Named Entities Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From paul@xelerance.com Mon Oct 31 19:12: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 A34991F0C42 for ; Mon, 31 Oct 2011 19:12:39 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wnPsE7Hb5QTu for ; Mon, 31 Oct 2011 19:12:38 -0700 (PDT) Received: from mx.xelerance.com (mx.xelerance.com [193.110.157.188]) by ietfa.amsl.com (Postfix) with ESMTP id 947A91F0C34 for ; Mon, 31 Oct 2011 19:12:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx.xelerance.com (Postfix) with ESMTP id EA3897E6 for ; Mon, 31 Oct 2011 22:12:35 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=xelerance.com; h= content-type:content-type:mime-version:user-agent:message-id :subject:subject:from:from:date:date:received:received:received :received; s=smtp; t=1320113553; x=1320718353; bh=lCkNeO7dQS5Ko1 P7QWwTQRgfp1DeKwfI2Mdh6EnL4W4=; b=ipz8vHR0Jp4dPYDksQEbS3tmDzDNXX lubpP2IAIZ5IHv+zD/82RzGdtDEUwKFu3fiT+7Y5ocZTq3zJt7+OLWDsB9Xj/3eM azb7kotzSJG9bdxAhiEjOZ1DUPHsQYvaCv69sDOWY59Om+DWLTkuPX+hzf8sizuT SjPu5QJvck8jQ= Received: from mx.xelerance.com ([127.0.0.1]) by localhost (mx.xelerance.com [127.0.0.1]) (amavisd-new, port 10026) with LMTP id PBE5cU00T8Vk for ; Mon, 31 Oct 2011 22:12:33 -0400 (EDT) Received: from mail.xelerance.com (mail.xelerance.com [193.110.157.189]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.xelerance.com (Postfix) with ESMTPS id 00E18590 for ; Mon, 31 Oct 2011 22:12:32 -0400 (EDT) Received: by mail.xelerance.com (Postfix, from userid 1001) id 64D46B13; Mon, 31 Oct 2011 22:12:32 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.xelerance.com (Postfix) with ESMTP id 5B42C92D for ; Mon, 31 Oct 2011 22:12:32 -0400 (EDT) Date: Mon, 31 Oct 2011 22:12:32 -0400 (EDT) From: Paul Wouters To: dane@ietf.org Message-ID: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) 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-01.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: Tue, 01 Nov 2011 02:12:39 -0000 Since this relates closely to DANE, Paul ---------- Forwarded message ---------- Date: Mon, 31 Oct 2011 19:21:11 From: Paul Wouters To: tls@ietf.org Subject: [TLS] New Version Notification for draft-wouters-tls-oob-pubkey-01.txt (fwd) X-Spam-Flag: NO This is the new version of the draft incorporating the feedback from Quebec City and the TLS list since then. It changes the draft from a new TLS extension to a new Certificate Type for raw keys. It also merges in the unpublished draft material from Hannes Tschofenig and Tero Kivinen whom had also been working on raw RSA TLS keys for use with CoAP (eg devices with no real time clock where PKIX validation cannot work) I did not yet change the draft from individual submission to working group item, as I was waiting for confirmation on the TLW WG list of the last Quebec City meeting. http://tools.ietf.org/html/draft-wouters-tls-oob-pubkey-01 Paul ---------- Forwarded message ---------- Date: Mon, 31 Oct 2011 17:44:35 From: internet-drafts@ietf.org Cc: weiler@tislabs.com, hannes.tschofenig@gmx.net, gnu@toad.com, paul@xelerance.com, kivinen@iki.fi To: paul@xelerance.com Subject: New Version Notification for draft-wouters-tls-oob-pubkey-01.txt X-Spam-Flag: NO A new version of I-D, draft-wouters-tls-oob-pubkey-01.txt has been successfully submitted by Paul Wouters and posted to the IETF repository. Filename: draft-wouters-tls-oob-pubkey Revision: 01 Title: TLS out-of-band public key validation Creation date: 2011-10-31 WG ID: Individual Submission Number of pages: 11 Abstract: This document specifies a new TLS certificate type for exchanging raw public keys or their fingerprints in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) for use with out-of-band authentication. Currently, TLS authentication can only occur via PKIX or OpenPGP certificates. By specifying a minimum resource for raw public key exchange, implementations can use alternative authentication methods. One such method is using DANE Resource Records secured by DNSSEC, Another use case is to provide authentication functionality when used with devices in a constrained environment that use whitelists and blacklists, as is the case with sensors and other embedded devices that are constrained by memory, computational, and communication limitations where the usage of PKIX is not feasible. The new certificate type specified can also be used to reduce the latency of a TLS client that is already in possession of a validated public key of the TLS server before it starts a (non-resumed) TLS handshake. The IETF Secretariat _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls