From stephen.farrell@cs.tcd.ie Tue May 1 01:46:56 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBCF721F86C9; Tue, 1 May 2012 01:46: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 bPXBPPiQ4nK8; Tue, 1 May 2012 01:46:55 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 7709921F856C; Tue, 1 May 2012 01:46:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id DF4351714F9; Tue, 1 May 2012 09:46:54 +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=1335862014; bh=5rZc4uaxrqcmIs xeUhnBNw4i3SkvVq0PUVGTsTTVrGg=; b=FLmLOsyxV8N7e2qJ0kg/WmTr4eCThO jyHkjFDeJtcQsQlcbPSArvmIbk/cyTcNfWgmPFLB1oc5MKPURNZROGnLXeezGb25 bJnFqcjONhX46XiIG/jz2gYioK3I5hWEo/djOQlPIBtuek/FrY1Y9RN7xCxNwPoc n3wYsgRLTI2Z5hX61KH+RcFmr0Ckv9w7J61N2Tzw/mb1CJX2LlG7hTd+ikSh0HfX BSne85gmSEUKGqzupclvgLJQIDKlgkP7z3e5OhPQZ4kCDk7rDNZGc4KtwYiMSAA1 w/uFsJtkSnxWtICaqHPd7+/IbFcdl69pGiaHGkUsh+X9syKfnsWyUTfw== 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 caHBGNFQXWCr; Tue, 1 May 2012 09:46:54 +0100 (IST) Received: from [IPv6:2001:770:10:203:a288:b4ff:fe9c:bc5c] (unknown [IPv6:2001:770:10:203:a288:b4ff:fe9c:bc5c]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 49C181714F7; Tue, 1 May 2012 09:46:52 +0100 (IST) Message-ID: <4F9FA2FC.7050402@cs.tcd.ie> Date: Tue, 01 May 2012 09:46:52 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120424 Thunderbird/12.0 MIME-Version: 1.0 To: Ned Freed References: <4F96D157.7020504@isode.com> <21AF6AE7-8BFB-457F-BB2D-39DA16206A8C@vpnc.org> <201204292309.q3TN9BcF027057@new.toad.com> <20120429235801.B8FB32036A98@drugs.dv.isc.org> <21E89A0F-05A8-4EF4-8F44-EA0D58F8F0E3@frobbit.se> <01OEXB2GEMB20006TF@mauve.mrochek.com> <01OEXJW3QF0G0006TF@mauve.mrochek.com> <4F9EFAFB.5050709@cs.tcd.ie> <01OEXMZ1FWDW0006TF@mauve.mrochek.com> <4F9F1039.8000402@cs.tcd.ie> <01OEXO8DBSKY0006TF@mauve.mrochek.com> <4F9F1C31.50602@cs.tcd.ie> <01OEXVCY097U0006TF@mauve.mrochek.com> <4F9F479A.10501@stpeter.im> <01OEY4K69WQE0006TF@mauve.mrochek.com> In-Reply-To: <01OEY4K69WQE0006TF@mauve.mrochek.com> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "apps-discuss@ietf.org" , dane@ietf.org, Paul Hoffman , iesg@ietf.org, Paul Wouters Subject: Re: [dane] [apps-discuss] AppsDir review of draft-ietf-dane-protocol-19 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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 May 2012 08:46:56 -0000 Hi Ned, On 05/01/2012 07:30 AM, Ned Freed wrote: >> On 4/30/12 6:52 PM, Ned Freed wrote: >>> >>>>> Again, I'm not taking any position on the interaction of TLSA records and >>>>> services that use SRV or SRV-like mechanisms. That said, I think most of the >>>>> comments are essentially saying that not discussing how TLSA records would >>>>> interact with such services at all - even if that discussion is simply to say >>>>> that those services need to specify how they are going to use TLSA records - >>>>> is a mistake. And I have to say that is a pretty compelling argument. >>> >>>> Could well be. What changes to the text in 1.3 of -20 do you think >>>> are needed if any? >>> >>>> " Note that this document does not cover how to associate >>>> certificates with domain names for application protocols that depend >>>> on SRV, NAPTR, and similar DNS resource records; it is expected that >>>> later updates to this document might cover methods for making those >>>> associations." >>> >>> Well, to be blunt, I think that by trying to avoid solving the problem now >>> while not giving up control over future solutions this ends up being >>> unacceptable to everyone. >>> >>> What if a service comes along that uses SRV records and wants to specify how >>> TLSA records are used to secure them? According to this text, it can't - the >>> clear implication here is that this has to be done by revising the DANE >>> specification itself. >>> >>> And what about existing services like email where it is arguably the case that >>> simply using TLSA records to secure the A/AAAA targets MX records is >>> sufficient? A very short "secure email transport" specification could >>> be writte that refers to the DANE specification, but this would also seem >>> to forbid that. >>> >>> I would much rather see a note that simply refers to future specification work >>> being needed, not specifically to a DANE revision being needed. > >> I had the same concern but then I realized that "later updates to this >> document might cover methods for making those associations" could be >> construed as referring to add-on documents that would officially update >> the DANE-RFC-to-be, not as saying that such changes would need to be >> made in the single DANEbis document that would cover all possible uses >> of the TLSA RR. > > That doesn't fix the problem. Anything that says "updates RFC FOO" is > effectively the same as a DANEbis spec. What I want is for other specification > to be able define how to use TLSA records to secure protocols that use more > elaborate DNS record mechanisms *without* having to update DANE. So I don't get the sensitivity here at all. There is, afaik, no plan for the DANE WG to be gatekeeper for anything, and nor is there any plan for the DANE WG to have a very long lifetime. I don't think is there a definite need e.g. for something that says how to use DANE with XMPP or SMTP to update the TLSA RFC - that might or might not be needed but we won't know until its being done. Nevertheless, how about if it said: "Note that this document does not cover how to associate certificates with domain names for application protocols that depend on SRV, NAPTR, and similar DNS resource records. It is expected that future documents will cover methods for making those associations. Those documents may or may not need to update this one." As Paul said, I don't think there's any problem if you've a better wording for that, so please do suggest some specific text if the above doesn't work. Cheers, S. From stephen.farrell@cs.tcd.ie Tue May 1 02:12:47 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26A3821F86B4 for ; Tue, 1 May 2012 02:12:47 -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 LBfnjbNJhfBu for ; Tue, 1 May 2012 02:12:46 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 0829921F8693 for ; Tue, 1 May 2012 02:12:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 7A5541714F9 for ; Tue, 1 May 2012 10:12:44 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:subject:mime-version :user-agent:from:date:message-id:received:received: x-virus-scanned; s=cs; t=1335863563; bh=mLwH6eyb5qyP/aOWijm2JcZd /FRGQPrp7Y0BPq7Og4E=; b=Xn9cLLb77NPOXBEdPOL2hK+B8SjxwjWssKqAjK0w 7Q6+qVUVXNoJYAQE4/KOKoJpb91CpXd2NeF7B8USb+GTS4a7yIFl/VLCwm4EZXTT DaSh1uPQZclWTxQC9fpoQ1EQAu5iiYkGeBUL/5SHszeY57TBbsgUTitrZ4iYTOTs tdDRbqbOT3wDYvhJTgJYcQ5FEF9kFWaUwJoseY8xqHQpQzJ8zskl0ntCHYz2u0rO eE3WrpbTK04ZT2P/9G9U4VlBoXWEkfdXZkG6wTXzrQnMRcVh3TiV+O4MbHDcfzyC DngM8OhRayO8btaSfgV8DerD9FnnRY896+16Npca39TA+Q== 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 cbfDKKo59fCH for ; Tue, 1 May 2012 10:12:43 +0100 (IST) Received: from [IPv6:2001:770:10:203:a288:b4ff:fe9c:bc5c] (unknown [IPv6:2001:770:10:203:a288:b4ff:fe9c:bc5c]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id C8264171471 for ; Tue, 1 May 2012 10:12:43 +0100 (IST) Message-ID: <4F9FA90B.9090607@cs.tcd.ie> Date: Tue, 01 May 2012 10:12:43 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120424 Thunderbird/12.0 MIME-Version: 1.0 To: dane X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [dane] DANE IETF LC state of play X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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 May 2012 09:12:47 -0000 Hi all, Well that's been a busy IETF LC. I think that shows that this is an important spec and the editors and chairs have done a great job so far on handling IETF LC comments, but I think there is a bit more work to do to be sure we're done and we may as well get that done now before the IESG are let loose on it:-) I went through the DANE WG archive of all the IETF LC comments and found the following ones where its not crystal clear from the archive that they're sorted. Notes: a) they might be just fine, e.g. if just one person comments and nobody else thought it important, then doing nothing is probably right. these just weren't clear from the archive so I wanna check; b) I only had time to scan the WG archive, if there are mails that were only to ietf@ietf.org or apps-discsuss that resolved these then I missed them, so just tell me about that, so I'll forward this to the other lists to check as well. So here's the list: 1) Jeff Hodges http://www.ietf.org/mail-archive/web/dane/current/msg04695.html http://www.ietf.org/mail-archive/web/dane/current/msg04713.html I mailed Jeff to see if -20 is ok. Silence can be taken to mean yes I think but since he had a bunch of things its hard to be sure. 2) PSA http://www.ietf.org/mail-archive/web/dane/current/msg04702.html http://www.ietf.org/mail-archive/web/dane/current/msg04790.html There are a few more small things still open in the last mail from earlier today. 3) Dave Cridland http://www.ietf.org/mail-archive/web/dane/current/msg04624.html I think there are still some occurrences of "certificate type" in section 8, (e.g. 3rd para, p18) so those weren't all fixed. I think that's the only remaining thing from Dave's review. 4) John Gilmore, http://www.ietf.org/mail-archive/web/dane/current/msg04635.html A.1 only has CA examples, what about non CA uses? I didn't see any reaction to that and it seems like a fair comment. 5) John Gilmore http://www.ietf.org/mail-archive/web/dane/current/msg04637.html John thinks there's a bias in sections 8/8.1, but I didn't see any reaction to that (other than mine, which just said "please do the right thing, whatever that is") 6) Mark Andrews http://www.ietf.org/mail-archive/web/dane/current/msg04657.html Again, not sure if there was follow-up. 7) PHB http://www.ietf.org/mail-archive/web/dane/current/msg04709.html Don't mandate client security policy (hardfail). I didn't see an obvious conclusion reached to make a change or not make a change. 8) Various on SRV http://www.ietf.org/mail-archive/web/dane/current/msg04793.html I think this might need a tweak to the SRV language in 1.3 (and just suggested one). Cheers, Stephen. From fanf2@hermes.cam.ac.uk Tue May 1 04:22:26 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8333221F8776; Tue, 1 May 2012 04:22:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.485 X-Spam-Level: X-Spam-Status: No, score=-6.485 tagged_above=-999 required=5 tests=[AWL=0.114, 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 PvrY87eHyvWW; Tue, 1 May 2012 04:22:25 -0700 (PDT) Received: from ppsw-52.csi.cam.ac.uk (ppsw-52.csi.cam.ac.uk [131.111.8.152]) by ietfa.amsl.com (Postfix) with ESMTP id BF0E021F8775; Tue, 1 May 2012 04:22:25 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:56571) by ppsw-52.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1SPB9x-0002mB-Ev (Exim 4.72) (return-path ); Tue, 01 May 2012 12:22:21 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1SPB9x-00029z-Jf (Exim 4.67) (return-path ); Tue, 01 May 2012 12:22:21 +0100 Date: Tue, 1 May 2012 12:22:21 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Ned Freed In-Reply-To: <01OEXVCY097U0006TF@mauve.mrochek.com> Message-ID: References: <4F96D157.7020504@isode.com> <21AF6AE7-8BFB-457F-BB2D-39DA16206A8C@vpnc.org> <201204292309.q3TN9BcF027057@new.toad.com> <20120429235801.B8FB32036A98@drugs.dv.isc.org> <21E89A0F-05A8-4EF4-8F44-EA0D58F8F0E3@frobbit.se> <01OEXB2GEMB20006TF@mauve.mrochek.com> <01OEXJW3QF0G0006TF@mauve.mrochek.com> <4F9EFAFB.5050709@cs.tcd.ie> <01OEXMZ1FWDW0006TF@mauve.mrochek.com> <4F9F1039.8000402@cs.tcd.ie> <01OEXO8DBSKY0006TF@mauve.mrochek.com> <4F9F1C31.50602@cs.tcd.ie> <01OEXVCY097U0006TF@mauve.mrochek.com> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: "apps-discuss@ietf.org" , dane@ietf.org, Paul Hoffman , iesg@ietf.org, Paul Wouters Subject: Re: [dane] [apps-discuss] AppsDir review of draft-ietf-dane-protocol-19 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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 May 2012 11:22:26 -0000 Ned Freed wrote: > > But even this may not be acceptable for all I know. It may turn out that using > DANE to secure the terminal A/AAAA records (modulo CNAMEs) is actually an > acceptable default for SRV/MX/NATPR-based services. I could easily be wrong, > but it seems to me that this is what all this additional discussion is about. I don't think it's as simple as that because RFC 6125 says certificates should match the SRV owner name not the target name. See also Dave Cridland's comments about XMPP. Tony. -- f.anthony.n.finch http://dotat.at/ Dover, Wight: Variable 3 or 4. Moderate becoming slight. Showers, fog patches. Moderate or good, occasionally very poor. From thierry.moreau@connotech.com Tue May 1 06:07:19 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7BD321F8630 for ; Tue, 1 May 2012 06:07:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.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 ehSRrWmbviIX for ; Tue, 1 May 2012 06:07:18 -0700 (PDT) Received: from mail.connotech.com (unknown [76.10.176.241]) by ietfa.amsl.com (Postfix) with ESMTP id 48A5C21E8707 for ; Tue, 1 May 2012 06:06:49 -0700 (PDT) Received: from [192.168.1.200] (unknown [192.168.1.200]) by mail.connotech.com (Postfix) with ESMTPA id EFE68308E6 for ; Tue, 1 May 2012 14:22:48 -0400 (EDT) Message-ID: <4F9FE1BE.5010208@connotech.com> Date: Tue, 01 May 2012 09:14:38 -0400 From: Thierry Moreau User-Agent: Thunderbird 2.0.0.17 (X11/20090608) MIME-Version: 1.0 To: dane Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [dane] Question re draft -20, TLSA record expiry X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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 May 2012 13:07:19 -0000 Hi, I reviewed the draft draft-ietf-dane-protocol-20. Great work! In section 5, item "Roll-over", I would be inclined to associate "expired TLSA records" with a combination of RRSIG signature expiry (an absolute time) and the original TTL field (the one data-integrity-protected by the RRSIG), not just the normal DNS TTL processing. Or maybe this extra scrutiny is implied by the DNSSEC validation function on which the "using entity" (my words) must rely anyway. Then I venture to propose the following text: "Note that the DNSSEC validation function [must/is expected to] provide a reliable TTL indication based on RRSIG fields including signature expiry and original TTL." This way it reminds the domain manager that key pair cryptoperiods are managed through the DNSSEC signature process. Thanks for the dedicated attention paid to the subtleties of DNSSEC piggybacked over the installed base of TLS server certification infrastructure! -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, QC, Canada H2M 2A1 Tel. +1-514-385-5691 From paul.hoffman@vpnc.org Tue May 1 10:24:16 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B234421E828C; Tue, 1 May 2012 10:24:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.541 X-Spam-Level: X-Spam-Status: No, score=-102.541 tagged_above=-999 required=5 tests=[AWL=0.058, 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 iLTfCdT3fRpt; Tue, 1 May 2012 10:24:16 -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 0AC7C21E81CF; Tue, 1 May 2012 10:24:15 -0700 (PDT) Received: from [10.20.30.102] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q41HOCES010811 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 1 May 2012 10:24:14 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <4F9F4DEE.1090309@stpeter.im> Date: Tue, 1 May 2012 10:24:12 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F95CA0B.8050202@stpeter.im> <4F9F4DEE.1090309@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1257) Cc: iesg@ietf.org, "apps-discuss@ietf.org" , dane@ietf.org Subject: Re: [dane] AppsDir review of draft-ietf-dane-protocol-19 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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 May 2012 17:24:16 -0000 On Apr 30, 2012, at 7:43 PM, Peter Saint-Andre wrote: >> 1b. The term "client-chosen port" makes it sound as if the client=20 >> can choose any port it pleases when connecting to the TLS server.=20 >> Yet typically the port is derived from a URI, "hardcoded" into the >> application protocol (sometimes as a fallback), or discovered via=20 >> the DNS (again, think SRV). We needn't reflect those alternatives=20 >> in the text, but at the least "appropriate" is better than=20 >> "client-chosen". >=20 > The change from "client-chosen port" to "client-define port" is > mystifying to me. Even assuming that "client-defined" was meant, it's > not clear to me what a client-defined port is, and I see no effective > difference between the old text and the new text. The intended difference was to say that the client gets to define which = port it is using based on pre-configured settings ("POP is always done = over TLS on port 995") or the way it interprets the URL or on something = else we cannot guess. I didn't feel that your proposal of "appropriate" = indicated to whom it needed to be appropriate, namely the client. Better suggestions are welcome. >> 4. In Section 2.2, the term "whitespace" is underspecified. Does=20 >> that include, say, any Unicode space separator (Unicode General=20 >> Category Zs) or also line separators (Unicode General Category Zl)=20 >> or only certain code points in the ASCII range? Further, is the=20 >> whitespace significant in the examples from Section 2.3? >=20 > I see no change in -20 to clarify this matter. We can add ", as described in " in the next = draft, or remove the whole sentence since it is already covered by an = Internet Standard. I think the former is better, but can do the latter = if you think that is clearer. >> 2. Section 1.1, uses the term "subdomain" in the sentence "This=20 >> prevents an untrustworthy signer from compromising anyone's keys=20 >> except those in their own subdomains." The term "subdomain" is not >> always well understood. I suggest explicitly citing Section 3.1 >> of RFC 1034 here. >=20 > Unchanged, but it's probably OK as-is. There are many DNS-related terms that are defined in 1034/1035; I don't = think calling each out will help the reader. > In a follow-up email message, I also noted: >=20 > ### >=20 > One more issue is nagging at me: there is no definition or citation > for "domain name" in Section 3. In particular, there is no indication > of whether internationalized domain names are allowed (and, if so, in > what format). I think it would good to make this clear by saying that > a domain name can be either a "traditional domain name" (RFC 1034) or > an "internationalized domain name" (RFC 5890); for the latter I think > it would be best to say that the IDN's internationalized labels are > represented only as A-labels. IMHO a short paragraph on this matter > would be appropriate in Section 3 or in a new section entitled > "Internationalization Considerations". >=20 > ### >=20 > I still think that this document needs to say something about IDNs. Please give specific wording for a specific location. I do not see any = place appropriate in this document to introduce IDNs and explain = A-labels in order to say "they're fine here". If you propose wording and = a location, I bet they will be fine. --Paul Hoffman From fanf2@hermes.cam.ac.uk Tue May 1 11:02:02 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3C3021E840E; Tue, 1 May 2012 11:02:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.491 X-Spam-Level: X-Spam-Status: No, score=-6.491 tagged_above=-999 required=5 tests=[AWL=0.108, 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 ubGTYAFe-Yzc; Tue, 1 May 2012 11:02:01 -0700 (PDT) Received: from ppsw-51.csi.cam.ac.uk (ppsw-51.csi.cam.ac.uk [131.111.8.151]) by ietfa.amsl.com (Postfix) with ESMTP id 5896D21E83FC; Tue, 1 May 2012 11:02:01 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:40533) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:fanf2) id 1SPHOi-0002Ue-Wl (Exim 4.72) (return-path ); Tue, 01 May 2012 19:02:00 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1SPHOi-0001PF-4Y (Exim 4.67) (return-path ); Tue, 01 May 2012 19:02:00 +0100 Date: Tue, 1 May 2012 19:02:00 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Peter Saint-Andre In-Reply-To: <4F9F4DEE.1090309@stpeter.im> Message-ID: References: <4F95CA0B.8050202@stpeter.im> <4F9F4DEE.1090309@stpeter.im> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: iesg@ietf.org, "apps-discuss@ietf.org" , dane@ietf.org Subject: Re: [dane] [apps-discuss] AppsDir review of draft-ietf-dane-protocol-19 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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 May 2012 18:02:02 -0000 Peter Saint-Andre wrote: > > The change from "client-chosen port" to "client-define port" is > mystifying to me. Even assuming that "client-defined" was meant, it's > not clear to me what a client-defined port is, and I see no effective > difference between the old text and the new text. I think the mistake is to talk about the client here. The client begins a connection to the service's port at that IP address. Tony. -- f.anthony.n.finch http://dotat.at/ South-east Iceland: Cyclonic 5 in far north, otherwise southwesterly 5 to 7. Moderate or rough. Occasional rain. Moderate or good, occasionally poor in north. From stpeter@stpeter.im Tue May 1 11:56:20 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1C2621E82BA; Tue, 1 May 2012 11:56:20 -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 Egg0u7nPxnrU; Tue, 1 May 2012 11:56:20 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 48DB221E822A; Tue, 1 May 2012 11:56:20 -0700 (PDT) Received: from [171.70.217.95] (unknown [171.70.217.95]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id CE68840058; Tue, 1 May 2012 13:11:14 -0600 (MDT) Message-ID: <4FA031D1.50006@stpeter.im> Date: Tue, 01 May 2012 11:56:17 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Tony Finch References: <4F95CA0B.8050202@stpeter.im> <4F9F4DEE.1090309@stpeter.im> In-Reply-To: X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: iesg@ietf.org, "apps-discuss@ietf.org" , dane@ietf.org Subject: Re: [dane] [apps-discuss] AppsDir review of draft-ietf-dane-protocol-19 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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 May 2012 18:56:21 -0000 On 5/1/12 11:02 AM, Tony Finch wrote: > Peter Saint-Andre wrote: >> >> The change from "client-chosen port" to "client-define port" is >> mystifying to me. Even assuming that "client-defined" was meant, it's >> not clear to me what a client-defined port is, and I see no effective >> difference between the old text and the new text. > > I think the mistake is to talk about the client here. The client begins a > connection to the service's port at that IP address. Usually, yes. Sometimes the client is configured to override the default port for the given service, as Paul noted. Could we just say "It then begins a connection to a particular port at that address"? Perhaps the method for determining the port isn't really relevant in this spec. Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Tue May 1 12:02:56 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF5AA21F8A21; Tue, 1 May 2012 12:02: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 VfThgG7rmIrG; Tue, 1 May 2012 12:02:56 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 1059D21F89A5; Tue, 1 May 2012 12:02:56 -0700 (PDT) Received: from [171.70.217.95] (unknown [171.70.217.95]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 4932440058; Tue, 1 May 2012 13:17:51 -0600 (MDT) Message-ID: <4FA0335E.7090306@stpeter.im> Date: Tue, 01 May 2012 12:02:54 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Paul Hoffman References: <4F95CA0B.8050202@stpeter.im> <4F9F4DEE.1090309@stpeter.im> In-Reply-To: X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: iesg@ietf.org, "apps-discuss@ietf.org" , dane@ietf.org Subject: Re: [dane] AppsDir review of draft-ietf-dane-protocol-19 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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 May 2012 19:02:57 -0000 On 5/1/12 10:24 AM, Paul Hoffman wrote: > On Apr 30, 2012, at 7:43 PM, Peter Saint-Andre wrote: > >>> 1b. The term "client-chosen port" makes it sound as if the client >>> can choose any port it pleases when connecting to the TLS >>> server. Yet typically the port is derived from a URI, "hardcoded" >>> into the application protocol (sometimes as a fallback), or >>> discovered via the DNS (again, think SRV). We needn't reflect >>> those alternatives in the text, but at the least "appropriate" is >>> better than "client-chosen". >> >> The change from "client-chosen port" to "client-define port" is >> mystifying to me. Even assuming that "client-defined" was meant, >> it's not clear to me what a client-defined port is, and I see no >> effective difference between the old text and the new text. > > The intended difference was to say that the client gets to define > which port it is using based on pre-configured settings ("POP is > always done over TLS on port 995") or the way it interprets the URL > or on something else we cannot guess. I didn't feel that your > proposal of "appropriate" indicated to whom it needed to be > appropriate, namely the client. > > Better suggestions are welcome. See other message. >>> 4. In Section 2.2, the term "whitespace" is underspecified. Does >>> that include, say, any Unicode space separator (Unicode General >>> Category Zs) or also line separators (Unicode General Category >>> Zl) or only certain code points in the ASCII range? Further, is >>> the whitespace significant in the examples from Section 2.3? >> >> I see no change in -20 to clarify this matter. > > We can add ", as described in " in the next > draft, or remove the whole sentence since it is already covered by an > Internet Standard. I think the former is better, but can do the > latter if you think that is clearer. Hmm. The text I'm referring to is: o The certificate association data field MUST be represented as a string of hexadecimal characters. Whitespace is allowed within the string of hexadecimal characters. How does RFC 1035 apply to the representation of the certificate association data field? >>> 2. Section 1.1, uses the term "subdomain" in the sentence "This >>> prevents an untrustworthy signer from compromising anyone's keys >>> except those in their own subdomains." The term "subdomain" is >>> not always well understood. I suggest explicitly citing Section >>> 3.1 of RFC 1034 here. >> >> Unchanged, but it's probably OK as-is. > > There are many DNS-related terms that are defined in 1034/1035; I > don't think calling each out will help the reader. You're right. >> In a follow-up email message, I also noted: >> >> ### >> >> One more issue is nagging at me: there is no definition or >> citation for "domain name" in Section 3. In particular, there is no >> indication of whether internationalized domain names are allowed >> (and, if so, in what format). I think it would good to make this >> clear by saying that a domain name can be either a "traditional >> domain name" (RFC 1034) or an "internationalized domain name" (RFC >> 5890); for the latter I think it would be best to say that the >> IDN's internationalized labels are represented only as A-labels. >> IMHO a short paragraph on this matter would be appropriate in >> Section 3 or in a new section entitled "Internationalization >> Considerations". >> >> ### >> >> I still think that this document needs to say something about >> IDNs. > > Please give specific wording for a specific location. I do not see > any place appropriate in this document to introduce IDNs and explain > A-labels in order to say "they're fine here". If you propose wording > and a location, I bet they will be fine. I'm tied up today, but I will try to formulate some text as soon as possible. Peter -- Peter Saint-Andre https://stpeter.im/ From paul.hoffman@vpnc.org Tue May 1 12:03:33 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFC3521F8A30 for ; Tue, 1 May 2012 12:03:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.543 X-Spam-Level: X-Spam-Status: No, score=-102.543 tagged_above=-999 required=5 tests=[AWL=0.056, 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 o2uJy3tK-Z7Y for ; Tue, 1 May 2012 12:03:33 -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 4A90421F8A21 for ; Tue, 1 May 2012 12:03:33 -0700 (PDT) Received: from [10.20.30.102] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q41J2gqM085679 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 1 May 2012 12:03:31 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 1 May 2012 12:03:31 -0700 References: <6.2.5.6.2.20120501105907.0a67cdb0@resistor.net> To: IETF DANE WG list Message-Id: <97884319-E7DF-4F89-A4D9-A59CEE6FA683@vpnc.org> Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) Subject: [dane] Fwd: [apps-discuss] DANE IETF LC state of play X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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 May 2012 19:03:34 -0000 Begin forwarded message: > From: SM > Subject: Re: [apps-discuss] [dane] DANE IETF LC state of play > Date: May 1, 2012 11:23:04 AM PDT > To: Paul Hoffman > Cc: Apps Discuss >=20 > Hi Paul, > At 10:27 01-05-2012, Paul Hoffman wrote: >> Those interpretations were by people who didn't believe the text that = MX and SRV were purposely not addressed. >=20 > Ok. >=20 >> I believe I did: I repeated the "we're not addressing this" text so = it appears twice. >=20 > Sorry, I must have missed that. >=20 >> They are not addressed because they have nothing to do with the = protocol in the document. Please let me know if you still disagree, and = send proposed text to the DANE WG. >=20 > I'll post the text here as part of IETF Last Call comments if it is ok = with you/the WG. I am not including the arguments to avoid rehashing = what was said before. Please ask if the arguments are needed. >=20 > In section 1.3: >=20 > Proposed text: >=20 > "Note that this document does not cover how to associate certificates > with domain names for application protocols that depend on MX, SRV, = NAPTR, > and similar DNS resource records; it is expected that later updates = to > this document might cover methods for making those associations." >=20 > I suggest removing the following text in Section 3: >=20 > 'To request a TLSA resource record for an SMTP server running the > STARTTLS protocol on port 25 at "mail.example.com", > "_25._tcp.mail.example.com" is used.' >=20 > in Section 8: >=20 > A DNS administrator who goes rogue and changes both the A, AAAA, = CNAME > and/or TLSA records for a domain name can cause the user to go to an > unauthorized server that will appear authorized, unless the client > performs PKIX certification path validation and rejects the > certificate. >=20 > If the authentication mechanism for adding or changing TLSA data in = a > zone is weaker than the authentication mechanism for changing the A > AAAA, and/or CNAME records, a man-in-the-middle who can redirect = traffic > to their site may be able to impersonate the attacked host in TLS if > they can use the weaker authentication mechanism. >=20 > Regards, > -sm=20 From paul.hoffman@vpnc.org Tue May 1 12:18:49 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8958A21E8425; Tue, 1 May 2012 12:18:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.543 X-Spam-Level: X-Spam-Status: No, score=-102.543 tagged_above=-999 required=5 tests=[AWL=0.056, 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 54LCG57jSCvd; Tue, 1 May 2012 12:18:49 -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 F408621E8370; Tue, 1 May 2012 12:18:48 -0700 (PDT) Received: from [10.20.30.102] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q41JIIAw086234 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 1 May 2012 12:18:19 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <4FA031D1.50006@stpeter.im> Date: Tue, 1 May 2012 12:18:17 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3F51E575-D6DC-44B0-A17B-AD8B228CD404@vpnc.org> References: <4F95CA0B.8050202@stpeter.im> <4F9F4DEE.1090309@stpeter.im> <4FA031D1.50006@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1257) Cc: iesg@ietf.org, "apps-discuss@ietf.org" , dane@ietf.org Subject: Re: [dane] [apps-discuss] AppsDir review of draft-ietf-dane-protocol-19 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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 May 2012 19:18:49 -0000 On May 1, 2012, at 11:56 AM, Peter Saint-Andre wrote: > On 5/1/12 11:02 AM, Tony Finch wrote: >> Peter Saint-Andre wrote: >>>=20 >>> The change from "client-chosen port" to "client-define port" is >>> mystifying to me. Even assuming that "client-defined" was meant, = it's >>> not clear to me what a client-defined port is, and I see no = effective >>> difference between the old text and the new text. >>=20 >> I think the mistake is to talk about the client here. The client = begins a >> connection to the service's port at that IP address. >=20 > Usually, yes. Sometimes the client is configured to override the = default > port for the given service, as Paul noted. >=20 > Could we just say "It then begins a connection to a particular port at > that address"? Perhaps the method for determining the port isn't = really > relevant in this spec. Works for me. What do others think? Current: It then begins a connection to a client-defined port at that address, = and sends an initial message there. Proposed: It then begins a connection to a particular port at that address, and = sends an initial message there. --Paul Hoffman From paul.hoffman@vpnc.org Tue May 1 12:20:51 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28E2B21E843F; Tue, 1 May 2012 12:20:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.544 X-Spam-Level: X-Spam-Status: No, score=-102.544 tagged_above=-999 required=5 tests=[AWL=0.055, 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 rnGlxbjcaXEq; Tue, 1 May 2012 12:20:50 -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 8D6C721E8370; Tue, 1 May 2012 12:20:50 -0700 (PDT) Received: from [10.20.30.102] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q41JKkdM086294 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 1 May 2012 12:20:48 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <4FA0335E.7090306@stpeter.im> Date: Tue, 1 May 2012 12:20:46 -0700 Content-Transfer-Encoding: 7bit Message-Id: <5C578F9E-D666-4596-8A37-5C546ECCD3D0@vpnc.org> References: <4F95CA0B.8050202@stpeter.im> <4F9F4DEE.1090309@stpeter.im> <4FA0335E.7090306@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1257) Cc: iesg@ietf.org, "apps-discuss@ietf.org" , dane@ietf.org Subject: Re: [dane] AppsDir review of draft-ietf-dane-protocol-19 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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 May 2012 19:20:51 -0000 On May 1, 2012, at 12:02 PM, Peter Saint-Andre wrote: >>>> 4. In Section 2.2, the term "whitespace" is underspecified. Does >>>> that include, say, any Unicode space separator (Unicode General >>>> Category Zs) or also line separators (Unicode General Category >>>> Zl) or only certain code points in the ASCII range? Further, is >>>> the whitespace significant in the examples from Section 2.3? >>> >>> I see no change in -20 to clarify this matter. >> >> We can add ", as described in " in the next >> draft, or remove the whole sentence since it is already covered by an >> Internet Standard. I think the former is better, but can do the >> latter if you think that is clearer. > > Hmm. The text I'm referring to is: > > o The certificate association data field MUST be represented as a > string of hexadecimal characters. Whitespace is allowed within > the string of hexadecimal characters. > > How does RFC 1035 apply to the representation of the certificate > association data field? The representation is happening in a DNS zone file. >>> In a follow-up email message, I also noted: >>> >>> ### >>> >>> One more issue is nagging at me: there is no definition or >>> citation for "domain name" in Section 3. In particular, there is no >>> indication of whether internationalized domain names are allowed >>> (and, if so, in what format). I think it would good to make this >>> clear by saying that a domain name can be either a "traditional >>> domain name" (RFC 1034) or an "internationalized domain name" (RFC >>> 5890); for the latter I think it would be best to say that the >>> IDN's internationalized labels are represented only as A-labels. >>> IMHO a short paragraph on this matter would be appropriate in >>> Section 3 or in a new section entitled "Internationalization >>> Considerations". >>> >>> ### >>> >>> I still think that this document needs to say something about >>> IDNs. >> >> Please give specific wording for a specific location. I do not see >> any place appropriate in this document to introduce IDNs and explain >> A-labels in order to say "they're fine here". If you propose wording >> and a location, I bet they will be fine. > > I'm tied up today, but I will try to formulate some text as soon as > possible. No rush: IDNs will be with us for a long time. :-) --Paul Hoffman From warren@kumari.net Tue May 1 12:26:09 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F08421E80C5; Tue, 1 May 2012 12:26:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.539 X-Spam-Level: X-Spam-Status: No, score=-106.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 e7XgCoUNGYwP; Tue, 1 May 2012 12:26:08 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 8BB9A21E8084; Tue, 1 May 2012 12:26:08 -0700 (PDT) Received: from dhcp-172-19-119-246.cbf.corp.google.com (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id 596031B40057; Tue, 1 May 2012 15:26:07 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warren Kumari In-Reply-To: <3F51E575-D6DC-44B0-A17B-AD8B228CD404@vpnc.org> Date: Tue, 1 May 2012 15:26:05 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F95CA0B.8050202@stpeter.im> <4F9F4DEE.1090309@stpeter.im> <4FA031D1.50006@stpeter.im> <3F51E575-D6DC-44B0-A17B-AD8B228CD404@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1084) Cc: apps-discuss@ietf.org, dane list Subject: Re: [dane] [apps-discuss] AppsDir review of draft-ietf-dane-protocol-19 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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 May 2012 19:26:09 -0000 [ -IESG] On May 1, 2012, at 3:18 PM, Paul Hoffman wrote: > On May 1, 2012, at 11:56 AM, Peter Saint-Andre wrote: >=20 >> On 5/1/12 11:02 AM, Tony Finch wrote: >>> Peter Saint-Andre wrote: >>>>=20 >>>> The change from "client-chosen port" to "client-define port" is >>>> mystifying to me. Even assuming that "client-defined" was meant, = it's >>>> not clear to me what a client-defined port is, and I see no = effective >>>> difference between the old text and the new text. >>>=20 >>> I think the mistake is to talk about the client here. The client = begins a >>> connection to the service's port at that IP address. >>=20 >> Usually, yes. Sometimes the client is configured to override the = default >> port for the given service, as Paul noted. >>=20 >> Could we just say "It then begins a connection to a particular port = at >> that address"? Perhaps the method for determining the port isn't = really >> relevant in this spec. >=20 > Works for me. What do others think? >=20 > Current: > It then begins a connection to a client-defined port at that address, = and sends an initial message there. > Proposed: > It then begins a connection to a particular port at that address, and = sends an initial message there. LGTM. W >=20 > --Paul Hoffman >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane >=20 From ned.freed@mrochek.com Tue May 1 12:26:25 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ED0F21E82CD; Tue, 1 May 2012 12:26:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[AWL=0.105, 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 1RC9BDcWglvs; Tue, 1 May 2012 12:26:24 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id D595F21E8053; Tue, 1 May 2012 12:26:24 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OEYVHXWDIO000VVF@mauve.mrochek.com>; Tue, 1 May 2012 12:26:20 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OENEYWYFI80006TF@mauve.mrochek.com>; Tue, 1 May 2012 12:26:16 -0700 (PDT) Message-id: <01OEYVHVJRM80006TF@mauve.mrochek.com> Date: Tue, 01 May 2012 12:12:52 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Tue, 01 May 2012 12:22:21 +0100" MIME-version: 1.0 Content-type: TEXT/PLAIN References: <4F96D157.7020504@isode.com> <21AF6AE7-8BFB-457F-BB2D-39DA16206A8C@vpnc.org> <201204292309.q3TN9BcF027057@new.toad.com> <20120429235801.B8FB32036A98@drugs.dv.isc.org> <21E89A0F-05A8-4EF4-8F44-EA0D58F8F0E3@frobbit.se> <01OEXB2GEMB20006TF@mauve.mrochek.com> <01OEXJW3QF0G0006TF@mauve.mrochek.com> <4F9EFAFB.5050709@cs.tcd.ie> <01OEXMZ1FWDW0006TF@mauve.mrochek.com> <4F9F1039.8000402@cs.tcd.ie> <01OEXO8DBSKY0006TF@mauve.mrochek.com> <4F9F1C31.50602@cs.tcd.ie> <01OEXVCY097U0006TF@mauve.mrochek.com> To: Tony Finch Cc: Ned Freed , "apps-discuss@ietf.org" , dane@ietf.org, Paul Hoffman , iesg@ietf.org, Paul Wouters Subject: Re: [dane] [apps-discuss] AppsDir review of draft-ietf-dane-protocol-19 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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 May 2012 19:26:25 -0000 > Ned Freed wrote: > > > > But even this may not be acceptable for all I know. It may turn out that using > > DANE to secure the terminal A/AAAA records (modulo CNAMEs) is actually an > > acceptable default for SRV/MX/NATPR-based services. I could easily be wrong, > > but it seems to me that this is what all this additional discussion is about. > I don't think it's as simple as that because RFC 6125 says certificates > should match the SRV owner name not the target name. See also Dave > Cridland's comments about XMPP. That's actualy A Good Thing, because it means that there's nobody can argue that there's a simple addition to this document that will address the SRV case. Now all that remains is to open the door to using TLSA without having to update this specification. Ned From ned.freed@mrochek.com Tue May 1 19:57:57 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11B4D21E80C9; Tue, 1 May 2012 19:57:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.496 X-Spam-Level: X-Spam-Status: No, score=-2.496 tagged_above=-999 required=5 tests=[AWL=0.103, 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 aW4inFSm0ybI; Tue, 1 May 2012 19:57:56 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 26B8221E809B; Tue, 1 May 2012 19:57:56 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OEZB9QI02O000SA3@mauve.mrochek.com>; Tue, 1 May 2012 19:57:51 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OENEYWYFI80006TF@mauve.mrochek.com>; Tue, 1 May 2012 19:57:47 -0700 (PDT) Message-id: <01OEZB9OC9VW0006TF@mauve.mrochek.com> Date: Tue, 01 May 2012 19:55:56 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Tue, 01 May 2012 09:46:52 +0100" <4F9FA2FC.7050402@cs.tcd.ie> MIME-version: 1.0 Content-type: TEXT/PLAIN References: <4F96D157.7020504@isode.com> <21AF6AE7-8BFB-457F-BB2D-39DA16206A8C@vpnc.org> <201204292309.q3TN9BcF027057@new.toad.com> <20120429235801.B8FB32036A98@drugs.dv.isc.org> <21E89A0F-05A8-4EF4-8F44-EA0D58F8F0E3@frobbit.se> <01OEXB2GEMB20006TF@mauve.mrochek.com> <01OEXJW3QF0G0006TF@mauve.mrochek.com> <4F9EFAFB.5050709@cs.tcd.ie> <01OEXMZ1FWDW0006TF@mauve.mrochek.com> <4F9F1039.8000402@cs.tcd.ie> <01OEXO8DBSKY0006TF@mauve.mrochek.com> <4F9F1C31.50602@cs.tcd.ie> <01OEXVCY097U0006TF@mauve.mrochek.com> <4F9F479A.10501@stpeter.im> <01OEY4K69WQE0006TF@mauve.mrochek.com> <4F9FA2FC.7050402@cs.tcd.ie> To: Stephen Farrell Cc: Ned Freed , "apps-discuss@ietf.org" , dane@ietf.org, Paul Hoffman , iesg@ietf.org, Paul Wouters Subject: Re: [dane] [apps-discuss] AppsDir review of draft-ietf-dane-protocol-19 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 02 May 2012 02:57:57 -0000 > Hi Ned, > On 05/01/2012 07:30 AM, Ned Freed wrote: > >> On 4/30/12 6:52 PM, Ned Freed wrote: > >>> > >>>>> Again, I'm not taking any position on the interaction of TLSA records and > >>>>> services that use SRV or SRV-like mechanisms. That said, I think most of the > >>>>> comments are essentially saying that not discussing how TLSA records would > >>>>> interact with such services at all - even if that discussion is simply to say > >>>>> that those services need to specify how they are going to use TLSA records - > >>>>> is a mistake. And I have to say that is a pretty compelling argument. > >>> > >>>> Could well be. What changes to the text in 1.3 of -20 do you think > >>>> are needed if any? > >>> > >>>> " Note that this document does not cover how to associate > >>>> certificates with domain names for application protocols that depend > >>>> on SRV, NAPTR, and similar DNS resource records; it is expected that > >>>> later updates to this document might cover methods for making those > >>>> associations." > >>> > >>> Well, to be blunt, I think that by trying to avoid solving the problem now > >>> while not giving up control over future solutions this ends up being > >>> unacceptable to everyone. > >>> > >>> What if a service comes along that uses SRV records and wants to specify how > >>> TLSA records are used to secure them? According to this text, it can't - the > >>> clear implication here is that this has to be done by revising the DANE > >>> specification itself. > >>> > >>> And what about existing services like email where it is arguably the case that > >>> simply using TLSA records to secure the A/AAAA targets MX records is > >>> sufficient? A very short "secure email transport" specification could > >>> be writte that refers to the DANE specification, but this would also seem > >>> to forbid that. > >>> > >>> I would much rather see a note that simply refers to future specification work > >>> being needed, not specifically to a DANE revision being needed. > > > >> I had the same concern but then I realized that "later updates to this > >> document might cover methods for making those associations" could be > >> construed as referring to add-on documents that would officially update > >> the DANE-RFC-to-be, not as saying that such changes would need to be > >> made in the single DANEbis document that would cover all possible uses > >> of the TLSA RR. > > > > That doesn't fix the problem. Anything that says "updates RFC FOO" is > > effectively the same as a DANEbis spec. What I want is for other specification > > to be able define how to use TLSA records to secure protocols that use more > > elaborate DNS record mechanisms *without* having to update DANE. > So I don't get the sensitivity here at all. There is, afaik, no > plan for the DANE WG to be gatekeeper for anything, and nor is > there any plan for the DANE WG to have a very long lifetime. When why does the language say otherwise? > I don't think is there a definite need e.g. for something that > says how to use DANE with XMPP or SMTP to update the TLSA RFC - > that might or might not be needed but we won't know until its > being done. But that's what it currently says is needed. > Nevertheless, how about if it said: > "Note that this document does not cover how to associate > certificates with domain names for application protocols that depend > on SRV, NAPTR, and similar DNS resource records. It is expected that > future documents will cover methods for making those associations. > Those documents may or may not need to update this one." That's essentially the change I suggested making. > As Paul said, I don't think there's any problem if you've a > better wording for that, so please do suggest some specific text > if the above doesn't work. The wording you suggest is fine with me, and addresses my concern. Ned From marka@isc.org Tue May 1 20:38:33 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3951921E802C; Tue, 1 May 2012 20:38:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.493 X-Spam-Level: X-Spam-Status: No, score=-2.493 tagged_above=-999 required=5 tests=[AWL=0.106, 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 i-a+nTkQPyT0; Tue, 1 May 2012 20:38:32 -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 A507B21E8013; Tue, 1 May 2012 20:38:32 -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 "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id B51AC5F990B; Wed, 2 May 2012 03:38:15 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:a15a:151c:b5dd:907]) (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 17FE0216C36; Wed, 2 May 2012 03:38:13 +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 DC27A205548E; Wed, 2 May 2012 13:38:08 +1000 (EST) To: Tony Finch From: Mark Andrews References: <4F96D157.7020504@isode.com> <21AF6AE7-8BFB-457F-BB2D-39DA16206A8C@vpnc.org> <201204292309.q3TN9BcF027057@new.toad.com> <20120429235801.B8FB32036A98@drugs.dv.isc.org> <21E89A0F-05A8-4EF4-8F44-EA0D58F8F0E3@frobbit.se> <01OEXB2GEMB20006TF@mauve.mrochek.com> <01OEXJW3QF0G0006TF@mauve.mrochek.com> <4F9EFAFB.5050709@cs.tcd.ie> <01OEXMZ1FWDW0006TF@mauve.mrochek.com> <4F9F1039.8000402@cs.tcd.ie> <01OEXO8DBSKY0006TF@mauve.mrochek.com> <4F9F1C31.50602@cs.tcd.ie> <01OEXVCY097U0006TF@mauve.mrochek.com> In-reply-to: Your message of "Tue, 01 May 2012 12:22:21 +0100." Date: Wed, 02 May 2012 13:38:08 +1000 Message-Id: <20120502033808.DC27A205548E@drugs.dv.isc.org> Cc: Ned Freed , "apps-discuss@ietf.org" , dane@ietf.org, Paul Hoffman , iesg@ietf.org, Paul Wouters Subject: Re: [dane] [apps-discuss] AppsDir review of draft-ietf-dane-protocol-19 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 02 May 2012 03:38:33 -0000 In message , Tony F inch writes: > Ned Freed wrote: > > > > But even this may not be acceptable for all I know. It may turn out that us > ing > > DANE to secure the terminal A/AAAA records (modulo CNAMEs) is actually an > > acceptable default for SRV/MX/NATPR-based services. I could easily be wrong > , > > but it seems to me that this is what all this additional discussion is abou > t. > > I don't think it's as simple as that because RFC 6125 says certificates > should match the SRV owner name not the target name. See also Dave > Cridland's comments about XMPP. Should != must. None of the examples in RFC 6125 deal with a store and forward protocol that uses trusted third parties. SMTP is a example of such a protocol and if implements using SRV rather than MX it would be a exception. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From fanf2@hermes.cam.ac.uk Wed May 2 01:59:44 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0BBD21F8A39; Wed, 2 May 2012 01:59:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.496 X-Spam-Level: X-Spam-Status: No, score=-6.496 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rE-KMJx1vRrk; Wed, 2 May 2012 01:59:43 -0700 (PDT) Received: from ppsw-51.csi.cam.ac.uk (ppsw-51.csi.cam.ac.uk [131.111.8.151]) by ietfa.amsl.com (Postfix) with ESMTP id BBB6D21F8A36; Wed, 2 May 2012 01:59:43 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:37378) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:fanf2) id 1SPVPS-0002EW-XJ (Exim 4.72) (return-path ); Wed, 02 May 2012 09:59:42 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1SPVPS-0004GL-4R (Exim 4.67) (return-path ); Wed, 02 May 2012 09:59:42 +0100 Date: Wed, 2 May 2012 09:59:42 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Peter Saint-Andre In-Reply-To: <4FA031D1.50006@stpeter.im> Message-ID: References: <4F95CA0B.8050202@stpeter.im> <4F9F4DEE.1090309@stpeter.im> <4FA031D1.50006@stpeter.im> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: iesg@ietf.org, "apps-discuss@ietf.org" , dane@ietf.org Subject: Re: [dane] [apps-discuss] AppsDir review of draft-ietf-dane-protocol-19 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 02 May 2012 08:59:45 -0000 Peter Saint-Andre wrote: > On 5/1/12 11:02 AM, Tony Finch wrote: > > > > I think the mistake is to talk about the client here. The client begins a > > connection to the service's port at that IP address. > > Usually, yes. Sometimes the client is configured to override the default > port for the given service, as Paul noted. My point is that the correct port is defined by the service's configuration, which belongs to the server not to the client. I didn't mean to imply the service's port is well-known - it might come from SRV records or from URLs etc. > Could we just say "It then begins a connection to a particular port at > that address"? Works for me. > Perhaps the method for determining the port isn't really > relevant in this spec. Right. A bit like the question of which name is authenticated :-) Tony. -- f.anthony.n.finch http://dotat.at/ German Bight, Humber: Variable 3 or 4, becoming north or northeast 4 or 5. Slight or moderate. Fair. Moderate or good, occasionally poor. From fanf2@hermes.cam.ac.uk Wed May 2 02:01:24 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 557DF21F8903; Wed, 2 May 2012 02:01:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.501 X-Spam-Level: X-Spam-Status: No, score=-6.501 tagged_above=-999 required=5 tests=[AWL=0.098, 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 FXsoPd7QWIqD; Wed, 2 May 2012 02:01:23 -0700 (PDT) Received: from ppsw-51.csi.cam.ac.uk (ppsw-51.csi.cam.ac.uk [131.111.8.151]) by ietfa.amsl.com (Postfix) with ESMTP id 8375C21F883C; Wed, 2 May 2012 02:01:23 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:44704) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:fanf2) id 1SPVR4-0003D9-YV (Exim 4.72) (return-path ); Wed, 02 May 2012 10:01:22 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1SPVR4-0004e0-KL (Exim 4.67) (return-path ); Wed, 02 May 2012 10:01:22 +0100 Date: Wed, 2 May 2012 10:01:22 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Mark Andrews In-Reply-To: <20120502033808.DC27A205548E@drugs.dv.isc.org> Message-ID: References: <4F96D157.7020504@isode.com> <21AF6AE7-8BFB-457F-BB2D-39DA16206A8C@vpnc.org> <201204292309.q3TN9BcF027057@new.toad.com> <20120429235801.B8FB32036A98@drugs.dv.isc.org> <21E89A0F-05A8-4EF4-8F44-EA0D58F8F0E3@frobbit.se> <01OEXB2GEMB20006TF@mauve.mrochek.com> <01OEXJW3QF0G0006TF@mauve.mrochek.com> <4F9EFAFB.5050709@cs.tcd.ie> <01OEXMZ1FWDW0006TF@mauve.mrochek.com> <4F9F1039.8000402@cs.tcd.ie> <01OEXO8DBSKY0006TF@mauve.mrochek.com> <4F9F1C31.50602@cs.tcd.ie> <01OEXVCY097U0006TF@mauve.mrochek.com> <20120502033808.DC27A205548E@drugs.dv.isc.org> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: "apps-discuss@ietf.org" , dane@ietf.org Subject: Re: [dane] [apps-discuss] AppsDir review of draft-ietf-dane-protocol-19 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 02 May 2012 09:01:24 -0000 Mark Andrews wrote: > Tony Finch writes: > > Ned Freed wrote: > > > > > > But even this may not be acceptable for all I know. It may turn out that using > > > DANE to secure the terminal A/AAAA records (modulo CNAMEs) is actually an > > > acceptable default for SRV/MX/NATPR-based services. I could easily be wrong, > > > but it seems to me that this is what all this additional discussion is about. > > > > I don't think it's as simple as that because RFC 6125 says certificates > > should match the SRV owner name not the target name. See also Dave > > Cridland's comments about XMPP. > > Should != must. Indeed, I used the word precisely :-) Tony. -- f.anthony.n.finch http://dotat.at/ Trafalgar: Cyclonic 5 to 7, occasionally gale 8 at first, decreasing 4 at times. Moderate or rough. Rain or thundery showers. Moderate or good, occasionally poor. From mrex@sap.com Wed May 2 06:47:44 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21E5721F85D8; Wed, 2 May 2012 06:47:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.125 X-Spam-Level: X-Spam-Status: No, score=-10.125 tagged_above=-999 required=5 tests=[AWL=0.124, 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 jIGaFtyU8YAQ; Wed, 2 May 2012 06:47:43 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 5EB0F21F85D7; Wed, 2 May 2012 06:47:43 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q42Dldqi011053 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 2 May 2012 15:47:40 +0200 (MEST) From: Martin Rex Message-Id: <201205021347.q42Dld6J017934@fs4113.wdf.sap.corp> To: ned.freed@mrochek.com (Ned Freed) Date: Wed, 2 May 2012 15:47:39 +0200 (MEST) In-Reply-To: <01OEZB9OC9VW0006TF@mauve.mrochek.com> from "Ned Freed" at May 1, 12 07:55:56 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: ned.freed@mrochek.com, apps-discuss@ietf.org, dane@ietf.org, paul.hoffman@vpnc.org, iesg@ietf.org, paul@nohats.ca Subject: Re: [dane] [apps-discuss] 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, 02 May 2012 13:47:44 -0000 Ned Freed wrote: > > > I don't think is there a definite need e.g. for something that > > says how to use DANE with XMPP or SMTP to update the TLSA RFC - > > that might or might not be needed but we won't know until its > > being done. > > But that's what it currently says is needed. > > > Nevertheless, how about if it said: > > > "Note that this document does not cover how to associate > > certificates with domain names for application protocols that depend > > on SRV, NAPTR, and similar DNS resource records. It is expected that > > future documents will cover methods for making those associations. > > Those documents may or may not need to update this one." > > That's essentially the change I suggested making. Writing that those apps-protocol-specific documents (defining how to use a particular protocol with TLSA/DANE-protocol) might need to update the TLSA/DANE-protocol document is misleading (and IMHO should be avoided). http://tools.ietf.org/html/rfc2223#section-12 defines the "Updates:" metadata for RFCs to have a very narrow and purely editorial meaning. "Updates:" is meant to refer to those situations where a paragraph or section of a new document **completely** replaces the same paragraph or section of a previous RFC. It is probably much more common to "extend" an existing protocol or describe/define additional usage scenarios without changing the original specification, simply by using the extensibility of the original protocol. Normally, such "expected usage" should not use the editorial rfc2223-Updates: metadata. But the use of the Updates:&Obsoletes: meta-data tags in RFCs is not consistent, a number of RFC seem to ignore the rfc2223 definitions of what these headers are supposed to indicate. -Martin From mrex@sap.com Wed May 2 06:59:37 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0382121F85F2; Wed, 2 May 2012 06:59:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.127 X-Spam-Level: X-Spam-Status: No, score=-10.127 tagged_above=-999 required=5 tests=[AWL=0.122, 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 hTEI5JflTUnx; Wed, 2 May 2012 06:59:36 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 41CB921F85E5; Wed, 2 May 2012 06:59:35 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q42DxXmp025332 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 2 May 2012 15:59:33 +0200 (MEST) From: Martin Rex Message-Id: <201205021359.q42DxVtm018679@fs4113.wdf.sap.corp> To: marka@isc.org (Mark Andrews) Date: Wed, 2 May 2012 15:59:31 +0200 (MEST) In-Reply-To: <20120502033808.DC27A205548E@drugs.dv.isc.org> from "Mark Andrews" at May 2, 12 01:38:08 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: ned.freed@mrochek.com, apps-discuss@ietf.org, dane@ietf.org, paul.hoffman@vpnc.org, iesg@ietf.org, paul@nohats.ca Subject: Re: [dane] [apps-discuss] AppsDir review of 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, 02 May 2012 13:59:37 -0000 Mark Andrews wrote: > > Tony Finch writes: >> >> Ned Freed wrote: >>> >>> But even this may not be acceptable for all I know. It may turn out >>> that using DANE to secure the terminal A/AAAA records (modulo CNAMEs) >>> is actually an acceptable default for SRV/MX/NATPR-based services. >>> I could easily be wrong, but it seems to me that this is what all >>> this additional discussion is about. >> >> I don't think it's as simple as that because RFC 6125 says certificates >> should match the SRV owner name not the target name. See also Dave >> Cridland's comments about XMPP. > > Should != must. I think that is a misunderstanding. The XMPP document may explicitly account for a local policy to override the decision to continue communication because of a mismatch and chose "should" over "must" for that, assuming that MUST is unconditional and not subject to local policy. Some specifications in the security area (and PKIX in particular) use a different approach, using MUST all over the place, silently assuming that local policy overrides MUSTS in specs all the time... (and some of the language in DANE-protocol is the same, generously sprinkling MUST all over the place, and causing confusion about when a MUST is really a MUST (i.e. not subject to local policy). Personally, I prefer shoulds to musts for situations where local policy is supposed to apply. -Martin From marka@isc.org Wed May 2 07:12:59 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4783821F85D3; Wed, 2 May 2012 07:12:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 xHziZPcpsFf8; Wed, 2 May 2012 07:12:58 -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 A60FC21F85AF; Wed, 2 May 2012 07:12:58 -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 "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id 482B45F98E1; Wed, 2 May 2012 14:12:42 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:44e0:7e51:4c1e:891f]) (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 61E35216C33; Wed, 2 May 2012 14:12:39 +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 5BFB4205A95B; Thu, 3 May 2012 00:12:35 +1000 (EST) To: mrex@sap.com From: Mark Andrews References: <201205021359.q42DxVtm018679@fs4113.wdf.sap.corp> In-reply-to: Your message of "Wed, 02 May 2012 15:59:31 +0200." <201205021359.q42DxVtm018679@fs4113.wdf.sap.corp> Date: Thu, 03 May 2012 00:12:35 +1000 Message-Id: <20120502141235.5BFB4205A95B@drugs.dv.isc.org> Cc: ned.freed@mrochek.com, apps-discuss@ietf.org, dane@ietf.org, paul.hoffman@vpnc.org, iesg@ietf.org, paul@nohats.ca Subject: Re: [dane] [apps-discuss] AppsDir review of X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 02 May 2012 14:12:59 -0000 In message <201205021359.q42DxVtm018679@fs4113.wdf.sap.corp>, Martin Rex writes: > Mark Andrews wrote: > > > > Tony Finch writes: > >> > >> Ned Freed wrote: > >>> > >>> But even this may not be acceptable for all I know. It may turn out > >>> that using DANE to secure the terminal A/AAAA records (modulo CNAMEs) > >>> is actually an acceptable default for SRV/MX/NATPR-based services. > >>> I could easily be wrong, but it seems to me that this is what all > >>> this additional discussion is about. > >> > >> I don't think it's as simple as that because RFC 6125 says certificates > >> should match the SRV owner name not the target name. See also Dave > >> Cridland's comments about XMPP. > > > > Should != must. > > I think that is a misunderstanding. > > The XMPP document may explicitly account for a local policy to override > the decision to continue communication because of a mismatch and chose > "should" over "must" for that, assuming that MUST is unconditional > and not subject to local policy. > > Some specifications in the security area (and PKIX in particular) > use a different approach, using MUST all over the place, silently > assuming that local policy overrides MUSTS in specs all the time... > (and some of the language in DANE-protocol is the same, generously > sprinkling MUST all over the place, and causing confusion about > when a MUST is really a MUST (i.e. not subject to local policy). > > Personally, I prefer shoulds to musts for situations where local > policy is supposed to apply. > > -Martin This isn't a local policy issue. It's a appropriate fit for the protocol issue. Most protocols where you will be using SRV you can use the owner of the SRV record but there are some where it does not make sense. By forcing the security model to be too rigid you stop SRV being used in ways it was designed to be used. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From fanf2@hermes.cam.ac.uk Wed May 2 07:13:49 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F266B21F85DF; Wed, 2 May 2012 07:13:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.505 X-Spam-Level: X-Spam-Status: No, score=-6.505 tagged_above=-999 required=5 tests=[AWL=0.094, 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 wDwge56nM2D2; Wed, 2 May 2012 07:13:48 -0700 (PDT) Received: from ppsw-52.csi.cam.ac.uk (ppsw-52.csi.cam.ac.uk [131.111.8.152]) by ietfa.amsl.com (Postfix) with ESMTP id 1594721F85D3; Wed, 2 May 2012 07:13:47 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:39794) by ppsw-52.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1SPaJM-000634-Ea (Exim 4.72) (return-path ); Wed, 02 May 2012 15:13:44 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1SPaJM-0000O6-Ax (Exim 4.67) (return-path ); Wed, 02 May 2012 15:13:44 +0100 Date: Wed, 2 May 2012 15:13:44 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Martin Rex In-Reply-To: <201205021359.q42DxVtm018679@fs4113.wdf.sap.corp> Message-ID: References: <201205021359.q42DxVtm018679@fs4113.wdf.sap.corp> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: apps-discuss@ietf.org, dane@ietf.org Subject: Re: [dane] [apps-discuss] AppsDir review of X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 02 May 2012 14:13:49 -0000 Martin Rex wrote: > Mark Andrews wrote: > > > > Should != must. > > I think that is a misunderstanding. No, I think Mark is right. RFC 6125 is guidance for protocol designers, so the "should" is a recommendation about how to decide which identity is authenticated when adding TLS to a protocol. Whether local policy can override this decision is something else entirely. Tony. -- f.anthony.n.finch http://dotat.at/ Fisher: Northwesterly 4 or 5, increasing 6 in north. Slight or moderate. Fair. Moderate or good. From ned.freed@mrochek.com Wed May 2 09:27:53 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38D2C21F8637; Wed, 2 May 2012 09:27:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.497 X-Spam-Level: X-Spam-Status: No, score=-2.497 tagged_above=-999 required=5 tests=[AWL=0.102, 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 jvxOYpTQCjSo; Wed, 2 May 2012 09:27:52 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 6BB4121F85F9; Wed, 2 May 2012 09:27:52 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OF03JXNYZK000RFH@mauve.mrochek.com>; Wed, 2 May 2012 09:27:47 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OF030DGDDC0006TG@mauve.mrochek.com>; Wed, 2 May 2012 09:27:45 -0700 (PDT) Message-id: <01OF03JVQP0C0006TG@mauve.mrochek.com> Date: Wed, 02 May 2012 09:13:44 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Wed, 02 May 2012 15:47:39 +0200 (MEST)" <201205021347.q42Dld6J017934@fs4113.wdf.sap.corp> MIME-version: 1.0 Content-type: TEXT/PLAIN References: <01OEZB9OC9VW0006TF@mauve.mrochek.com> <201205021347.q42Dld6J017934@fs4113.wdf.sap.corp> To: Martin Rex Cc: ned.freed@mrochek.com, apps-discuss@ietf.org, dane@ietf.org, paul.hoffman@vpnc.org, iesg@ietf.org, paul@nohats.ca Subject: Re: [dane] [apps-discuss] X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 02 May 2012 16:27:53 -0000 > Ned Freed wrote: > > > > > I don't think is there a definite need e.g. for something that > > > says how to use DANE with XMPP or SMTP to update the TLSA RFC - > > > that might or might not be needed but we won't know until its > > > being done. > > > > But that's what it currently says is needed. > > > > > Nevertheless, how about if it said: > > > > > "Note that this document does not cover how to associate > > > certificates with domain names for application protocols that depend > > > on SRV, NAPTR, and similar DNS resource records. It is expected that > > > future documents will cover methods for making those associations. > > > Those documents may or may not need to update this one." > > > > That's essentially the change I suggested making. > Writing that those apps-protocol-specific documents (defining how to > use a particular protocol with TLSA/DANE-protocol) might need to update the > TLSA/DANE-protocol document is misleading (and IMHO should be avoided). > http://tools.ietf.org/html/rfc2223#section-12 > defines the "Updates:" metadata for RFCs to have a very narrow and purely > editorial meaning. "Updates:" is meant to refer to those situations > where a paragraph or section of a new document **completely** replaces > the same paragraph or section of a previous RFC. That section doesn't say or even imply that the change has to be purely editorial in nature. (The word "editorial" appears nowhere in the section and neither do the words "paragraph" or "section".) And even if it did, the facts are that Updates: is routinely used by documents that make a substantial technical change to a previous document. A particularly relevant example of this is the EAI specification RFC 6532, which states that it "Updates: RFC 2045" and the nature of this update is to remove a MUST NOT, which is just about as substantial a technical change as you can make. So if there's a bug here (and I don't think there is), the bug is in RFC 2223. Not in this use of Updates:. > It is probably much more common to "extend" an existing protocol or > describe/define additional usage scenarios without changing the original > specification, simply by using the extensibility of the original protocol. Sure, but it is also common to make a technical change and call it an update. You may not like that, but that's how it works. > Normally, such "expected usage" should not use the editorial > rfc2223-Updates: metadata. But the use of the Updates:&Obsoletes: > meta-data tags in RFCs is not consistent, a number of RFC seem to > ignore the rfc2223 definitions of what these headers are supposed > to indicate. Again, if there's any inconsistency, it's in RFC 2223. Ned From mrex@sap.com Wed May 2 10:50:55 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1391D21F85C9; Wed, 2 May 2012 10:50:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.128 X-Spam-Level: X-Spam-Status: No, score=-10.128 tagged_above=-999 required=5 tests=[AWL=0.121, 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 yEyxtuCE54gK; Wed, 2 May 2012 10:50:54 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 384C721F85C6; Wed, 2 May 2012 10:50:53 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q42Hoq01001031 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 2 May 2012 19:50:52 +0200 (MEST) From: Martin Rex Message-Id: <201205021750.q42HopRD001898@fs4113.wdf.sap.corp> To: ned.freed@mrochek.com (Ned Freed) Date: Wed, 2 May 2012 19:50:51 +0200 (MEST) In-Reply-To: <01OF03JVQP0C0006TG@mauve.mrochek.com> from "Ned Freed" at May 2, 12 09:13:44 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: ned.freed@mrochek.com, apps-discuss@ietf.org, dane@ietf.org, paul.hoffman@vpnc.org, iesg@ietf.org, paul@nohats.ca Subject: Re: [dane] [apps-discuss] 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, 02 May 2012 17:50:55 -0000 Ned Freed wrote: > > > Ned Freed wrote: > > > > > > > I don't think is there a definite need e.g. for something that > > > > says how to use DANE with XMPP or SMTP to update the TLSA RFC - > > > > that might or might not be needed but we won't know until its > > > > being done. > > > > > > But that's what it currently says is needed. > > > > > > > Nevertheless, how about if it said: > > > > > > > "Note that this document does not cover how to associate > > > > certificates with domain names for application protocols that depend > > > > on SRV, NAPTR, and similar DNS resource records. It is expected that > > > > future documents will cover methods for making those associations. > > > > Those documents may or may not need to update this one." > > > > > > That's essentially the change I suggested making. > > > > Writing that those apps-protocol-specific documents (defining how to > > use a particular protocol with TLSA/DANE-protocol) might need to update the > > TLSA/DANE-protocol document is misleading (and IMHO should be avoided). > > > http://tools.ietf.org/html/rfc2223#section-12 > > > defines the "Updates:" metadata for RFCs to have a very narrow and purely > > editorial meaning. "Updates:" is meant to refer to those situations > > where a paragraph or section of a new document **completely** replaces > > the same paragraph or section of a previous RFC. > > That section doesn't say or even imply that the change has to be purely > editorial in nature. (The word "editorial" appears nowhere in the section and > neither do the words "paragraph" or "section".) The rfc2223 document title is "Instruction to RFC Authors". The Updates: header has a purely editorial meaning for the *new* document, but the result can certainly be very technical for the *old* document! Updates: should only be used if the change is supposed to apply not only to implementations of the *new* document, but that all new implementors of the *old* (=updated) document should ignore certain parts of the old document and use the new document instead. But in order for this to work, - a section in the new document is *REQUIRED* which list exactly which pieces of the *old* (=updated) document are completely replaced by which pieces of the new document - retaining full interop with old implementations based on only the full spec, and clear distinction of features that were added or dropped in the updated parts. > > > It is probably much more common to "extend" an existing protocol or > > describe/define additional usage scenarios without changing the original > > specification, simply by using the extensibility of the original protocol. > > Sure, but it is also common to make a technical change and call it an update. > You may not like that, but that's how it works. That is not necessarily a contradiction. But there is a certain mess in the meta-data of published RFCs. Publishing a change to specification will not magically change the behaviour of an installed base, therefore "changes" need to account for the reality of life. -Martin From mrex@sap.com Wed May 2 11:07:47 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6D0F11E808F; Wed, 2 May 2012 11:07:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.13 X-Spam-Level: X-Spam-Status: No, score=-10.13 tagged_above=-999 required=5 tests=[AWL=0.119, 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 91A3DKLZFFbU; Wed, 2 May 2012 11:07:47 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 0D05511E8081; Wed, 2 May 2012 11:07:46 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q42I7jWr003159 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 2 May 2012 20:07:45 +0200 (MEST) From: Martin Rex Message-Id: <201205021807.q42I7iZW002794@fs4113.wdf.sap.corp> To: dot@dotat.at (Tony Finch) Date: Wed, 2 May 2012 20:07:44 +0200 (MEST) In-Reply-To: from "Tony Finch" at May 2, 12 03:13:44 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: apps-discuss@ietf.org, dane@ietf.org Subject: Re: [dane] [apps-discuss] AppsDir review of 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, 02 May 2012 18:07:48 -0000 Tony Finch wrote: > > Martin Rex wrote: > > Mark Andrews wrote: > > > > > > Should != must. > > > > I think that is a misunderstanding. > > No, I think Mark is right. RFC 6125 is guidance for protocol designers, > so the "should" is a recommendation about how to decide which identity is > authenticated when adding TLS to a protocol. Whether local policy can > override this decision is something else entirely. The idea behind this should is that it completely obviates the need of a secure directory and secure lookup service and is easier to understand and configure and therefore easier to operate securely. The idea behind DANE is that it can be implemented and evaluated as a module, and provides a similar service as a public CA that issues DV-validated SSL certs. If there are apps protocols that would like to perform fancy name transformations on the that is passed as input to an implementation of DANE-protocol, then this apps protocol will have to specify (and implement) the security for any such name transformations when they are not based on a trusted local source, because the DANE module does not know about (and therefore does not care about) any such transformations. Any necessity of such name transformations is likely to also cause problems with obtaining and using "traditional" PKIX certificates (TLSA usage types 0&1). Apps which currently have such a PKIX-problem first ought to fix their architecture so that the TLSA usage 0&1 vs 2&3 becomes a true option for the consumer of the technology, rather than focus on subverting usage type 2&3 only and leaving the problems that preclude TLSA usages 0&1 unsolved. -Martin From ned.freed@mrochek.com Wed May 2 11:23:19 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2101421E8063; Wed, 2 May 2012 11:23:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 K1Q68pbXJjH1; Wed, 2 May 2012 11:23:18 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 571ED21E804A; Wed, 2 May 2012 11:23:18 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OF07L2359S000WLL@mauve.mrochek.com>; Wed, 2 May 2012 11:23:14 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OENEYWYFI80006TF@mauve.mrochek.com>; Wed, 2 May 2012 11:23:11 -0700 (PDT) Message-id: <01OF07L047040006TF@mauve.mrochek.com> Date: Wed, 02 May 2012 11:10:49 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Wed, 02 May 2012 19:50:51 +0200 (MEST)" <201205021750.q42HopRD001898@fs4113.wdf.sap.corp> MIME-version: 1.0 Content-type: TEXT/PLAIN References: <01OF03JVQP0C0006TG@mauve.mrochek.com> <201205021750.q42HopRD001898@fs4113.wdf.sap.corp> To: Martin Rex Cc: ned.freed@mrochek.com, apps-discuss@ietf.org, dane@ietf.org, paul.hoffman@vpnc.org, iesg@ietf.org, paul@nohats.ca Subject: Re: [dane] [apps-discuss] X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 02 May 2012 18:23:19 -0000 > Ned Freed wrote: > > > > > Ned Freed wrote: > > > > > > > > > I don't think is there a definite need e.g. for something that > > > > > says how to use DANE with XMPP or SMTP to update the TLSA RFC - > > > > > that might or might not be needed but we won't know until its > > > > > being done. > > > > > > > > But that's what it currently says is needed. > > > > > > > > > Nevertheless, how about if it said: > > > > > > > > > "Note that this document does not cover how to associate > > > > > certificates with domain names for application protocols that depend > > > > > on SRV, NAPTR, and similar DNS resource records. It is expected that > > > > > future documents will cover methods for making those associations. > > > > > Those documents may or may not need to update this one." > > > > > > > > That's essentially the change I suggested making. > > > > > > > Writing that those apps-protocol-specific documents (defining how to > > > use a particular protocol with TLSA/DANE-protocol) might need to update the > > > TLSA/DANE-protocol document is misleading (and IMHO should be avoided). > > > > > http://tools.ietf.org/html/rfc2223#section-12 > > > > > defines the "Updates:" metadata for RFCs to have a very narrow and purely > > > editorial meaning. "Updates:" is meant to refer to those situations > > > where a paragraph or section of a new document **completely** replaces > > > the same paragraph or section of a previous RFC. > > > > That section doesn't say or even imply that the change has to be purely > > editorial in nature. (The word "editorial" appears nowhere in the section and > > neither do the words "paragraph" or "section".) > The rfc2223 document title is "Instruction to RFC Authors". The Updates: > header has a purely editorial meaning for the *new* document, but the > result can certainly be very technical for the *old* document! And that's quite simply nonsense. It has a technical meaning in both cases. In the new document it's informing the reader that this document changes or adds to a previous specification. > Updates: should only be used if the change is supposed to apply not only > to implementations of the *new* document, but that all new implementors of > the *old* (=updated) document should ignore certain parts of the old > document and use the new document instead. Which is exactly the sense in which it is being used here. Although I think it unlikely given how limited DANE is, it is nevertheless possible that some subsequent use of TLSA will require tweaking of something in the DANE specification. We're not omnipotent and we don't always get every detail right. Of course this brings up the question as to when the level of change rises to the point where an revision that obsoletes the original is required. This is a judgement call that needs to be made on a case-by-case basis. > But in order for this to work, > - a section in the new document is *REQUIRED* which list exactly > which pieces of the *old* (=updated) document are completely > replaced by which pieces of the new document I rather suspect I can find any number of examples where that wasn't done, but yes, I agree that it is best done this way. RFC 6532 certainly used this approach. But this actually supports the notion that we use be using the term "updates" here, to make it clear that if changes are made they need to be done this way. > - retaining full interop with old implementations based on only > the full spec, and clear distinction of features that were > added or dropped in the updated parts. This, OTOH, is unduly constraining. The RFC 6532 is again on point - it made a change (allowing nested encodings) that could conceivably cause interoperability problems, although that is believed to be unlikely. Such cases should be rare, and when they do come up full consideration needs to be given to the consequences, but saying it should never be allowed under any circumstances is excessive. > > > > > It is probably much more common to "extend" an existing protocol or > > > describe/define additional usage scenarios without changing the original > > > specification, simply by using the extensibility of the original protocol. > > > > Sure, but it is also common to make a technical change and call it an update. > > You may not like that, but that's how it works. > That is not necessarily a contradiction. > But there is a certain mess in the meta-data of published RFCs. > Publishing a change to specification will not magically change > the behaviour of an installed base, therefore "changes" need to > account for the reality of life. On this, at least, we agree. But the bigger problem is how to clean it up. On that score I'm a bit sort on helpful suggestions. Ned From mrex@sap.com Wed May 2 11:53:20 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C84B011E80B2; Wed, 2 May 2012 11:53:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.231 X-Spam-Level: X-Spam-Status: No, score=-9.231 tagged_above=-999 required=5 tests=[AWL=-0.782, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_34=0.6, J_CHICKENPOX_46=0.6, J_CHICKENPOX_84=0.6, 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 j6-udFn5t6DH; Wed, 2 May 2012 11:53:20 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id CF94D11E80B1; Wed, 2 May 2012 11:53:19 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q42IrIZV028717 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 2 May 2012 20:53:18 +0200 (MEST) From: Martin Rex Message-Id: <201205021853.q42IrHJJ005341@fs4113.wdf.sap.corp> To: ned.freed@mrochek.com (Ned Freed) Date: Wed, 2 May 2012 20:53:17 +0200 (MEST) In-Reply-To: <01OF07L047040006TF@mauve.mrochek.com> from "Ned Freed" at May 2, 12 11:10:49 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: ned.freed@mrochek.com, apps-discuss@ietf.org, dane@ietf.org, paul.hoffman@vpnc.org, iesg@ietf.org, paul@nohats.ca Subject: Re: [dane] [apps-discuss] 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, 02 May 2012 18:53:20 -0000 Ned Freed wrote: > > > Updates: should only be used if the change is supposed to apply not only > > to implementations of the *new* document, but that all new implementors of > > the *old* (=updated) document should ignore certain parts of the old > > document and use the new document instead. > > Which is exactly the sense in which it is being used here. Although > I think it unlikely given how limited DANE is, it is nevertheless > possible that some subsequent use of TLSA will require tweaking of > something in the DANE specification. We're not omnipotent and we > don't always get every detail right. Just the opposite. Quite similar to rfc6125, DANE-protocol assumes that you already have a trustworthy hostname for which to retrieve the certificate association. This way, DANE-protocol can be put into a black block module for the caller and does not need to be updated or changed depending on the usage scenario. It would even be possible to tunnel the TLSA+DNSSEC records for performing DANE-protocol through a TLS extension instead of looking it up in a combined TLS+DANE module in a fashion that is completely opaque to the application caller. What some of the app specs (other than HTTPS) may have to specify _and_ implement, in order to be able to use DANE, is how to securely obtain a hostname&port which can be used as input to an implementation of DANE-protocol or input to rfc6125 matching for PKIX-based matching to DV-validated server certificates. But such an apps-specific spec is _not_ an update to DANE itself, in spite of refering to DANE. It is irrelevant to the DANE software module. New TLS cipher suites usually do not update or change TLS, new crypto algorithms usually do not update or change PKIX, new mime-types ususally do not update HTTP or the internet message format. > > > - retaining full interop with old implementations based on only > > the full spec, and clear distinction of features that were > > added or dropped in the updated parts. > > This, OTOH, is unduly constraining. Not at all. Maybe you're misreading this. It says that anything that claims to update an earlier document must explain where and how it does that, an in particular outline omissions and mark additions as such, so that it will be clear to the reader of the document. Example: http://tools.ietf.org/html/rfc5321#section-1.2 -Martin From marka@isc.org Wed May 2 16:25:33 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19E9121E8053; Wed, 2 May 2012 16:25:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.505 X-Spam-Level: X-Spam-Status: No, score=-2.505 tagged_above=-999 required=5 tests=[AWL=0.094, 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 drOFqVMTMBTf; Wed, 2 May 2012 16:25:32 -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 35E7B21E802B; Wed, 2 May 2012 16:25:32 -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 "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id 0AA905F9943; Wed, 2 May 2012 23:25:18 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:8533:73c:dc1:bdbb]) (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 E5278216C33; Wed, 2 May 2012 23:25:15 +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 0F806205C037; Thu, 3 May 2012 09:25:05 +1000 (EST) To: mrex@sap.com From: Mark Andrews References: <201205021807.q42I7iZW002794@fs4113.wdf.sap.corp> In-reply-to: Your message of "Wed, 02 May 2012 20:07:44 +0200." <201205021807.q42I7iZW002794@fs4113.wdf.sap.corp> Date: Thu, 03 May 2012 09:25:05 +1000 Message-Id: <20120502232506.0F806205C037@drugs.dv.isc.org> Cc: apps-discuss@ietf.org, dane@ietf.org Subject: Re: [dane] [apps-discuss] AppsDir review of X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 02 May 2012 23:25:33 -0000 In message <201205021807.q42I7iZW002794@fs4113.wdf.sap.corp>, Martin Rex writes: > Tony Finch wrote: > > > > Martin Rex wrote: > > > Mark Andrews wrote: > > > > > > > > Should != must. > > > > > > I think that is a misunderstanding. > > > > No, I think Mark is right. RFC 6125 is guidance for protocol designers, > > so the "should" is a recommendation about how to decide which identity is > > authenticated when adding TLS to a protocol. Whether local policy can > > override this decision is something else entirely. > > The idea behind this should is that it completely obviates the need of a > secure directory and secure lookup service and is easier to understand > and configure and therefore easier to operate securely. Indeed, but it is not the only model of usage. Pushing the RFC 6125 model onto MX would just be wrong. Sometimes you do need the secure directory and secure lookup. Having each protcol specify the security model it is using is a good thing. For MX and STARTTLS, DANE can stop downgrade attacks on the MX targets. You can't just intercept port 25 traffic and get away with it in a world where DANE exists like you can with plain PKIX. You have to manipulate the DNS and hope that the client MTA is not checking by using DNSSEC. MTA's can now know whether that should be expecting to see STARTTLS on not in the EHOL response. If they don't they see it then they should abort the connection even if the MX records themselves were not secure. > The idea behind DANE is that it can be implemented and evaluated > as a module, and provides a similar service as a public CA that issues > DV-validated SSL certs. That is part of what DANE provides. It also provides protection from downgrade attacks by indicating that TLS is available. It also provides protection from rogue CA's and rogue states that get global wildcard certs. These are adjucts to PKIX. > If there are apps protocols that would like to perform fancy name > transformations on the that is passed as input to an implementation > of DANE-protocol, then this apps protocol will have to specify > (and implement) the security for any such name transformations > when they are not based on a trusted local source, because the > DANE module does not know about (and therefore does not care about) > any such transformations. > > Any necessity of such name transformations is likely to also cause > problems with obtaining and using "traditional" PKIX certificates > (TLSA usage types 0&1). Apps which currently have such a PKIX-problem > first ought to fix their architecture so that the TLSA usage 0&1 vs 2&3 > becomes a true option for the consumer of the technology, rather > than focus on subverting usage type 2&3 only and leaving the problems > that preclude TLSA usages 0&1 unsolved. Just because you don't like the alternate security model that doesn't make it wrong or require that protocol to be fixed. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From ned.freed@mrochek.com Wed May 2 19:25:13 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44BEE21E801B; Wed, 2 May 2012 19:25:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[AWL=-0.802, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, J_CHICKENPOX_46=0.6, J_CHICKENPOX_84=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 w8HmrgHiYYkk; Wed, 2 May 2012 19:25:12 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 48CC721E8019; Wed, 2 May 2012 19:25:12 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OF0OFIAT6O000YTV@mauve.mrochek.com>; Wed, 2 May 2012 19:25:07 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OENEYWYFI80006TF@mauve.mrochek.com>; Wed, 2 May 2012 19:25:04 -0700 (PDT) Message-id: <01OF0OFG3VOI0006TF@mauve.mrochek.com> Date: Wed, 02 May 2012 19:10:44 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Wed, 02 May 2012 20:53:17 +0200 (MEST)" <201205021853.q42IrHJJ005341@fs4113.wdf.sap.corp> MIME-version: 1.0 Content-type: TEXT/PLAIN References: <01OF07L047040006TF@mauve.mrochek.com> <201205021853.q42IrHJJ005341@fs4113.wdf.sap.corp> To: Martin Rex Cc: ned.freed@mrochek.com, apps-discuss@ietf.org, dane@ietf.org, paul.hoffman@vpnc.org, iesg@ietf.org, paul@nohats.ca Subject: Re: [dane] [apps-discuss] X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 03 May 2012 02:25:13 -0000 > Ned Freed wrote: > > > > > Updates: should only be used if the change is supposed to apply not only > > > to implementations of the *new* document, but that all new implementors of > > > the *old* (=updated) document should ignore certain parts of the old > > > document and use the new document instead. > > > > Which is exactly the sense in which it is being used here. Although > > I think it unlikely given how limited DANE is, it is nevertheless > > possible that some subsequent use of TLSA will require tweaking of > > something in the DANE specification. We're not omnipotent and we > > don't always get every detail right. > Just the opposite. So you're saying that it is flatly impossible that DANE contains some assertion or restriction or whatever that will interfere with some future protocol use of TLSA? Please cite your proof of this, because I'm a wee bit skeptical. Remember, just because we're allowing something to be done doesn't mean it ever will be done. This is known as "covering our bases". Morever, as Mark Andrews has pointed out in another thread, it is also entirely possible that DANE may be used to implement different security models than the one the specification currently describes. > Quite similar to rfc6125, DANE-protocol assumes that you already have a > trustworthy hostname for which to retrieve the certificate association. > This way, DANE-protocol can be put into a black block module for the > caller and does not need to be updated or changed depending on the > usage scenario. It would even be possible to tunnel the TLSA+DNSSEC > records for performing DANE-protocol through a TLS extension instead > of looking it up in a combined TLS+DANE module in a fashion that is > completely opaque to the application caller. I fail to see the slightest relevance. > What some of the app specs (other than HTTPS) may have to specify _and_ > implement, in order to be able to use DANE, is how to securely obtain > a hostname&port which can be used as input to an implementation of > DANE-protocol or input to rfc6125 matching for PKIX-based matching > to DV-validated server certificates. > But such an apps-specific spec is _not_ an update to DANE itself, > in spite of refering to DANE. It is irrelevant to the DANE software module. In other words, by giving a single example where you claim it won't be necessary to update DANE, you have shown that it any possible protocol, including future ones we haven't even thought of, developed in the future won't need to either? > New TLS cipher suites usually do not update or change TLS, new crypto > algorithms usually do not update or change PKIX, new mime-types ususally > do not update HTTP or the internet message format. And by giving examples of things where extensibility was specifically planned into the underlying protocols, you have now proved that a protocol that contains no similar provisions will ... at this point I don't even know how to finish the sentence. This makes no sense whatsoever. > > > > > - retaining full interop with old implementations based on only > > > the full spec, and clear distinction of features that were > > > added or dropped in the updated parts. > > > > This, OTOH, is unduly constraining. > Not at all. Maybe you're misreading this. It says that anything that > claims to update an earlier document must explain where and how it does > that, an in particular outline omissions and mark additions as such, > so that it will be clear to the reader of the document. Misreading? More like miswriting, if it was you intention to say that. You said "retaining full interop with old implementations based on only the full spec", which is what I objected to. Your new paraphrase mentions none of that. > Example: http://tools.ietf.org/html/rfc5321#section-1.2 Both RFC 5321 and RFC 5322 and their predecessors went to considerable trouble to maintain compatibility with RFC 821 and RFC 822, preferring to mark a large number of features as deprecated rather than remove them. But this is not always possible, as was the case when the nested encoding restriction was removed so that message/global could be defined. Anyway, this has now gone well past the point of absurdity. I apologize to everyone who has read all of this for wasting their time on such a silly argument. This will be my final message on the topic. Ned From ondrej.sury@nic.cz Thu May 3 07:34:57 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBE2121F8620 for ; Thu, 3 May 2012 07:34:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.589 X-Spam-Level: X-Spam-Status: No, score=-1.589 tagged_above=-999 required=5 tests=[AWL=0.110, 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 0w-UrjBVXOXg for ; Thu, 3 May 2012 07:34:57 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 0228C21F8610 for ; Thu, 3 May 2012 07:34:56 -0700 (PDT) Received: from kimac-wifi.office.nic.cz (fw.nic.cz [217.31.207.1]) by mail.nic.cz (Postfix) with ESMTPSA id 4606F13F9E9; Thu, 3 May 2012 16:34:55 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1336055695; bh=69zTQAIbcLqbxlAHYc5S7HeHMxRURCBZthrSRN5PEho=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=BwC6/c6ZvakQ+930BL1llf6g9LYunjxuxNzigMRVPeCEwu616MTWv+0uE6pg6QsZ4 Dsunq/K9MRvSlQ46eLWmvPxUXwGPiROzkRu9tnk+517eW22VbaW8Szfo2K7a4Yrm4J ASQ9/7vi73CB81/h1eteMV2pzfA0dD4nESjEF97c= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <4F9F6236.3050303@stpeter.im> Date: Thu, 3 May 2012 16:34:55 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <05746AE2-AAA4-496E-A92D-C6826FD27F18@nic.cz> References: <4F95CA0B.8050202@stpeter.im> <4F9F4DEE.1090309@stpeter.im> <20120501040138.GA25922@odin.ulthar.us> <4F9F6236.3050303@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: dane@ietf.org Subject: [dane] Terminology 'whitespace' (Was: AppsDir review of draft-ietf-dane-protocol-19) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 03 May 2012 14:34:58 -0000 On 1. 5. 2012, at 6:10, Peter Saint-Andre wrote: >>>> 4. In Section 2.2, the term "whitespace" is underspecified. Does=20 >>>> that include, say, any Unicode space separator (Unicode General=20 >>>> Category Zs) or also line separators (Unicode General Category Zl)=20= >>>> or only certain code points in the ASCII range? Further, is the=20 >>>> whitespace significant in the examples from Section 2.3? >>>=20 >>> I see no change in -20 to clarify this matter. >>=20 >> RFC 1035 (normative reference of RFC 4034, which is a normative >> reference of this draft), section 5 defines the format for zone files >> ("Master files" in RFC 1035). That RFC predates Unicode and IDN, and >> doesn't appear to be updated by any RFC spelling out use of Unicode = in >> zone files. >>=20 >> Based on that, I'd say that zone files are still ASCII-only (and a = quick >> web search seems to confirm that that is the case, though I don't see >> any harm in adhering to the robustness principle here). At any rate, >> the definition of the TLSA presentation format and examples in this >> draft seem consistent with RFC 1035 and the definition for other RR >> types. >=20 > Does whitespace include tab, linefeed, etc., or only SP (ASCII 20)? It > really ought to be easy to clarify the matter. Just saying = "whitespace" > is less than clear, IMHO. Unfortunatelly we are again in the field of DNS archaeology, and there = is no clear definition of 'whitespace', but it is widely used everywhere, = see: http://tools.ietf.org/html/rfc4034#section-2.2 The Public Key field MUST be represented as a Base64 encoding of the Public Key. Whitespace is allowed within the Base64 text. For a definition of Base64 encoding, see [RFC3548]. This probably needs fixing (rewriting RFC1034/1035 with more up-to-date RFC language), but definitely not here. O. -- Ond=C5=99ej Sur=C3=BD -- Chief Science Officer ------------------------------------------- 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 Thu May 3 07:35:51 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F298A21F8625; Thu, 3 May 2012 07:35:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[AWL=0.100, 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 A+4jlUNg5UgR; Thu, 3 May 2012 07:35:50 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 6DFFA21F8621; Thu, 3 May 2012 07:35:50 -0700 (PDT) Received: from kimac-wifi.office.nic.cz (fw.nic.cz [217.31.207.1]) by mail.nic.cz (Postfix) with ESMTPSA id C06A513F9E9; Thu, 3 May 2012 16:35:49 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1336055749; bh=BaG9XbwRAGI7E9PuyyzuIUm8kCjXaI1tm8ET27VlB1M=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=TaGmlFLOWsq+h+ctxUxnYp/mdy309ssBuV/dGs7MbzgGOYRX4PHejEB49UXn9KvVA Jp5T3XM39aMAFQT6ELVFckTZbTHZvKG+tdmv7U6eRxSbs6PbiRKyV8W0CgE7J7EVGg xehQ1JLnDKUK8p5KPv0yyt0iNPNo/6Tm/35eu0Uo= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: Date: Thu, 3 May 2012 16:35:49 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7394F7B6-F351-49E8-9728-F732A679DC18@nic.cz> References: <4F95CA0B.8050202@stpeter.im> <4F9F4DEE.1090309@stpeter.im> <4FA031D1.50006@stpeter.im> <3F51E575-D6DC-44B0-A17B-AD8B228CD404@vpnc.org> To: Warren Kumari X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: Paul Hoffman , apps-discuss@ietf.org, dane list Subject: [dane] Client-defined port -> particular port (was: [apps-discuss] AppsDir review of draft-ietf-dane-protocol-19) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 03 May 2012 14:35:51 -0000 On 1. 5. 2012, at 21:26, Warren Kumari wrote: >=20 > [ -IESG] > On May 1, 2012, at 3:18 PM, Paul Hoffman wrote: >=20 >> On May 1, 2012, at 11:56 AM, Peter Saint-Andre wrote: >>=20 >>> On 5/1/12 11:02 AM, Tony Finch wrote: >>>> Peter Saint-Andre wrote: >>>>>=20 >>>>> The change from "client-chosen port" to "client-define port" is >>>>> mystifying to me. Even assuming that "client-defined" was meant, = it's >>>>> not clear to me what a client-defined port is, and I see no = effective >>>>> difference between the old text and the new text. >>>>=20 >>>> I think the mistake is to talk about the client here. The client = begins a >>>> connection to the service's port at that IP address. >>>=20 >>> Usually, yes. Sometimes the client is configured to override the = default >>> port for the given service, as Paul noted. >>>=20 >>> Could we just say "It then begins a connection to a particular port = at >>> that address"? Perhaps the method for determining the port isn't = really >>> relevant in this spec. >>=20 >> Works for me. What do others think? >>=20 >> Current: >> It then begins a connection to a client-defined port at that address, = and sends an initial message there. >> Proposed: >> It then begins a connection to a particular port at that address, and = sends an initial message there. >=20 > LGTM. +1 -- Ond=C5=99ej Sur=C3=BD -- Chief Science Officer ------------------------------------------- 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 Thu May 3 08:03:42 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47E1721F858D; Thu, 3 May 2012 08:03:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.607 X-Spam-Level: X-Spam-Status: No, score=-1.607 tagged_above=-999 required=5 tests=[AWL=0.092, 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 zOgSol47tVyf; Thu, 3 May 2012 08:03:41 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 16C8121F84D1; Thu, 3 May 2012 08:03:41 -0700 (PDT) Received: from kimac-wifi.office.nic.cz (fw.nic.cz [217.31.207.1]) by mail.nic.cz (Postfix) with ESMTPSA id 57D7913F9E9; Thu, 3 May 2012 17:03:34 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1336057415; bh=y4DD9JEMYJPj2hCGMW/85OGQk3mg7VWZ8NgcWUIwIVE=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=pIH9WNpGkZ4trScvWgOC/F0gaPycer7rtn5g5H2NYl1F+tlbhxopCy2Ml9IKKBTTx GOYflkenzPXu/FarprM673FCL9nQ7SnNveNeTLLAgABXbYPM55udowza2+yGk/ZhgB b2+mNKhXasCiNEpG7kQmrPAGmPm+3pskgAfPEHj4= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <4F9F479A.10501@stpeter.im> Date: Thu, 3 May 2012 17:03:33 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3AF93C00-67F1-46EB-880F-2B72F1B72E6C@nic.cz> References: <4F96D157.7020504@isode.com> <21AF6AE7-8BFB-457F-BB2D-39DA16206A8C@vpnc.org> <201204292309.q3TN9BcF027057@new.toad.com> <20120429235801.B8FB32036A98@drugs.dv.isc.org> <21E89A0F-05A8-4EF4-8F44-EA0D58F8F0E3@frobbit.se> <01OEXB2GEMB20006TF@mauve.mrochek.com> <01OEXJW3QF0G0006TF@mauve.mrochek.com> <4F9EFAFB.5050709@cs.tcd.ie> <01OEXMZ1FWDW0006TF@mauve.mrochek.com> <4F9F1039.8000402@cs.tcd.ie> <01OEXO8DBSKY0006TF@mauve.mrochek.com> <4F9F1C31.50602@cs.tcd.ie> <01OEXVCY097U0006TF@mauve.mrochek.com> <4F9F479A.10501@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: Ned Freed , "apps-discuss@ietf.org" , dane@ietf.org, Paul Hoffman , iesg@ietf.org, Paul Wouters Subject: Re: [dane] [apps-discuss] AppsDir review of draft-ietf-dane-protocol-19 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 03 May 2012 15:03:42 -0000 On 1. 5. 2012, at 4:16, Peter Saint-Andre wrote: > On 4/30/12 6:52 PM, Ned Freed wrote: >>=20 >>>> Again, I'm not taking any position on the interaction of TLSA = records and >>>> services that use SRV or SRV-like mechanisms. That said, I think = most of the >>>> comments are essentially saying that not discussing how TLSA = records would >>>> interact with such services at all - even if that discussion is = simply to say >>>> that those services need to specify how they are going to use TLSA = records - >>>> is a mistake. And I have to say that is a pretty compelling = argument. >>=20 >>> Could well be. What changes to the text in 1.3 of -20 do you think >>> are needed if any? >>=20 >>> " Note that this document does not cover how to = associate >>> certificates with domain names for application protocols that = depend >>> on SRV, NAPTR, and similar DNS resource records; it is expected = that >>> later updates to this document might cover methods for making = those >>> associations." >>=20 >> Well, to be blunt, I think that by trying to avoid solving the = problem now >> while not giving up control over future solutions this ends up being >> unacceptable to everyone.=20 >>=20 >> What if a service comes along that uses SRV records and wants to = specify how >> TLSA records are used to secure them? According to this text, it = can't - the >> clear implication here is that this has to be done by revising the = DANE >> specification itself. >>=20 >> And what about existing services like email where it is arguably the = case that >> simply using TLSA records to secure the A/AAAA targets MX records is >> sufficient? A very short "secure email transport" specification could >> be writte that refers to the DANE specification, but this would also = seem >> to forbid that. >>=20 >> I would much rather see a note that simply refers to future = specification work >> being needed, not specifically to a DANE revision being needed. >=20 > I had the same concern but then I realized that "later updates to this > document might cover methods for making those associations" could be > construed as referring to add-on documents that would officially = update > the DANE-RFC-to-be, not as saying that such changes would need to be > made in the single DANEbis document that would cover all possible uses > of the TLSA RR. Hear, hear! (Just remembers how many RFCs which states "Updates: = RFCNNNN" we have...) O. -- Ond=C5=99ej Sur=C3=BD -- Chief Science Officer ------------------------------------------- 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 Thu May 3 08:07:17 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 602F121F856F; Thu, 3 May 2012 08:07:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.614 X-Spam-Level: X-Spam-Status: No, score=-1.614 tagged_above=-999 required=5 tests=[AWL=0.085, 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 7Tn1LltsqI7B; Thu, 3 May 2012 08:07:16 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 0164C21F84B5; Thu, 3 May 2012 08:07:16 -0700 (PDT) Received: from kimac-wifi.office.nic.cz (fw.nic.cz [217.31.207.1]) by mail.nic.cz (Postfix) with ESMTPSA id 4D3C013F9E9; Thu, 3 May 2012 17:07:15 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1336057635; bh=6/NOMAga4vpuBi8ceE0WstqVBrdAYbOsp/QSc0VR6Io=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=d+9rd7ZTjZFWHZWtkNSmePYV3HeYcPn6ig3mfZKDyZRpM4kzrsK8sX5gcg7b40Kcr 2HoaIimLrBBZUikNOf0+4Fw9Qverc9nMODdY+lL07EiO0RHpIQFqvOreZsyk75lV2E /iIugS9TQPAK/mJBmcUyWFucpBxUoXI+jwp0LCsQ= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <9D005ED4-61DE-4CFF-8136-8AD5E30F66DB@kirei.se> Date: Thu, 3 May 2012 17:07:15 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4874649B-01B4-4642-A3C0-F4CDFE87C85B@nic.cz> References: <201204301353.q3UDrb2I007118@fs4113.wdf.sap.corp> <9D005ED4-61DE-4CFF-8136-8AD5E30F66DB@kirei.se> To: Jakob Schlyter X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: apps-discuss@ietf.org, dane@ietf.org, paul.hoffman@vpnc.org, iesg@ietf.org, alexey.melnikov@isode.com, paul@nohats.ca Subject: [dane] MX and DANE (Was: AppsDir review of draft-ietf-dane-protocol-19) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 03 May 2012 15:07:17 -0000 On 1. 5. 2012, at 8:05, Jakob Schlyter wrote: > On 30 apr 2012, at 15:53, Martin Rex wrote: >=20 >> When trying to deliver mail to @toad.com, the only secure >> question to ask is whether the server is authorized to process >> Email for @toad.com. For certificates issued from the traditional >> PKIX world, that would require a "toad.com" DNSName SAN. >=20 > That would require large hosting provider, e.g. Google Apps, to update = their SMTP TLS certificates each and every time they added or removed a = customer. In my book, that would not scale. I believe we should focus on = securing the transport, not building a TLS-based application = authorization system. And I would add this is out of the scope of the DANE protocol... If you want MX fixed, do it. But it is currently broken even just for = TLS. Either there will be some other document which fixes interaction = of SMTP and TLS and throws DANE on top of it, or the MTAs will just cope = ;), but we cannot specify anything which is broken right now. O. -- Ond=C5=99ej Sur=C3=BD -- Chief Science Officer ------------------------------------------- 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 Thu May 3 08:08:29 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02EC521F85FF for ; Thu, 3 May 2012 08:08:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.62 X-Spam-Level: X-Spam-Status: No, score=-1.62 tagged_above=-999 required=5 tests=[AWL=0.079, 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 SmdG3q0Fx+O1 for ; Thu, 3 May 2012 08:08:28 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 5F4B221F85FC for ; Thu, 3 May 2012 08:08:28 -0700 (PDT) Received: from kimac-wifi.office.nic.cz (fw.nic.cz [217.31.207.1]) by mail.nic.cz (Postfix) with ESMTPSA id AC71813F9E9; Thu, 3 May 2012 17:08:27 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1336057707; bh=+CxJULJHgbTKAlRl5F3RDqzrMPmt69f/jEeBkjMdka4=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=GTx7Wz/VwU2pb159C4YT7panK7bwzgBJY0vCL7BLgUw4Gp6+rq1Pln+TtOuMmGZuq JH6Jb6kDba2qLJMZy6fLIxLtBYj32eLtc7lp0dxOrtay/IkZpOYtebp3yEa3RfRzyj 3Vm7h9x7UoGWZSqIavR5WugOhM6eR/12V13j0ltg= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <01OEZB9OC9VW0006TF@mauve.mrochek.com> Date: Thu, 3 May 2012 17:08:27 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <423EB149-C411-4C7E-A6FF-259F7D7F836C@nic.cz> References: <4F96D157.7020504@isode.com> <21AF6AE7-8BFB-457F-BB2D-39DA16206A8C@vpnc.org> <201204292309.q3TN9BcF027057@new.toad.com> <20120429235801.B8FB32036A98@drugs.dv.isc.org> <21E89A0F-05A8-4EF4-8F44-EA0D58F8F0E3@frobbit.se> <01OEXB2GEMB20006TF@mauve.mrochek.com> <01OEXJW3QF0G0006TF@mauve.mrochek.com> <4F9EFAFB.5050709@cs.tcd.ie> <01OEXMZ1FWDW0006TF@mauve.mrochek.com> <4F9F1039.8000402@cs.tcd.ie> <01OEXO8DBSKY0006TF@mauve.mrochek.com> <4F9F1C31.50602@cs.tcd.ie> <01OEXVCY097U0006TF@mauve.mrochek.com> <4F9F479A.10501@stpeter.im> <01OEY4K69WQE0006TF@mauve.mrochek.com> <4F9FA2FC.7050402@cs.tcd.ie> <01OEZB9OC9VW0006TF@mauve.mrochek.com> To: Ned Freed X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: dane list , Paul Hoffman Subject: Re: [dane] [apps-discuss] AppsDir review of draft-ietf-dane-protocol-19 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 03 May 2012 15:08:29 -0000 On 2. 5. 2012, at 4:55, Ned Freed wrote: >> Nevertheless, how about if it said: >=20 >> "Note that this document does not cover how to associate >> certificates with domain names for application protocols that depend >> on SRV, NAPTR, and similar DNS resource records. It is expected that >> future documents will cover methods for making those associations. >> Those documents may or may not need to update this one." >=20 > That's essentially the change I suggested making. >=20 >> As Paul said, I don't think there's any problem if you've a >> better wording for that, so please do suggest some specific text >> if the above doesn't work. >=20 > The wording you suggest is fine with me, and addresses my concern. I am fine with "may or may not". O. -- Ond=C5=99ej Sur=C3=BD -- Chief Science Officer ------------------------------------------- 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 Thu May 3 08:12:27 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76C5621F8603; Thu, 3 May 2012 08:12:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.626 X-Spam-Level: X-Spam-Status: No, score=-1.626 tagged_above=-999 required=5 tests=[AWL=0.073, 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 OmR3OA4S0waW; Thu, 3 May 2012 08:12:26 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id A7B6221F8601; Thu, 3 May 2012 08:12:26 -0700 (PDT) Received: from kimac-wifi.office.nic.cz (fw.nic.cz [217.31.207.1]) by mail.nic.cz (Postfix) with ESMTPSA id 0D42613F9E9; Thu, 3 May 2012 17:12:25 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1336057946; bh=E6gFYoHePVYqL7CxC9ifiRpSPYJL4aMUUFKhrlGJ+Jk=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=rSOi+vGYogs8EjKsLO3AkUjjE2lTWDvb9FRPkFg3BAjXi1MmjHmsd4moCSYjWdHnU iF4KttXs+BMcHKgD/wBjIDPUwyX9Dlk4s0rc/uQLm14G0A3+LGBaunCS4TL+hh1/xN XYESRlR1eO2mJYt685iQFmUGXkaX/GIyNYImmL8s= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <201205021359.q42DxVtm018679@fs4113.wdf.sap.corp> Date: Thu, 3 May 2012 17:12:24 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2861796C-6DBC-4CEF-A1AF-CC9DBF42CE9C@nic.cz> References: <201205021359.q42DxVtm018679@fs4113.wdf.sap.corp> To: mrex@sap.com X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: The IESG , apps-discuss@ietf.org, dane list Subject: Re: [dane] [apps-discuss] AppsDir review of X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 03 May 2012 15:12:27 -0000 Martin and all other, On 2. 5. 2012, at 15:59, Martin Rex wrote: > Mark Andrews wrote: >>=20 >> Tony Finch writes: >>>=20 >>> Ned Freed wrote: >>>>=20 >>>> But even this may not be acceptable for all I know. It may turn out >>>> that using DANE to secure the terminal A/AAAA records (modulo = CNAMEs) >>>> is actually an acceptable default for SRV/MX/NATPR-based services. >>>> I could easily be wrong, but it seems to me that this is what all >>>> this additional discussion is about. >>>=20 >>> I don't think it's as simple as that because RFC 6125 says = certificates >>> should match the SRV owner name not the target name. See also Dave >>> Cridland's comments about XMPP. >>=20 >> Should !=3D must. >=20 > I think that is a misunderstanding. >=20 > The XMPP document may explicitly account for a local policy to = override > the decision to continue communication because of a mismatch and chose > "should" over "must" for that, assuming that MUST is unconditional > and not subject to local policy. >=20 > Some specifications in the security area (and PKIX in particular) > use a different approach, using MUST all over the place, silently > assuming that local policy overrides MUSTS in specs all the time... > (and some of the language in DANE-protocol is the same, generously > sprinkling MUST all over the place, and causing confusion about > when a MUST is really a MUST (i.e. not subject to local policy). >=20 > Personally, I prefer shoulds to musts for situations where local > policy is supposed to apply. Is this still related to review of DANE protocol? It seems to me it's = not. Please change the subject, if you want to discuss this further, and cut = down the Cc list (I don't mind discussing this in the DANE WG list, if it's = clear it's not related to the review, but you talk about XMPP/SRV/etc.) -- Ond=C5=99ej Sur=C3=BD -- Chief Science Officer ------------------------------------------- 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 Thu May 3 08:20:05 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97B2121F8669 for ; Thu, 3 May 2012 08:20:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.63 X-Spam-Level: X-Spam-Status: No, score=-1.63 tagged_above=-999 required=5 tests=[AWL=0.069, 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 s-g-8SKRsmj4 for ; Thu, 3 May 2012 08:20:04 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 6D4EF21F8656 for ; Thu, 3 May 2012 08:20:04 -0700 (PDT) Received: from kimac-wifi.office.nic.cz (fw.nic.cz [217.31.207.1]) by mail.nic.cz (Postfix) with ESMTPSA id BF5E713F9E9; Thu, 3 May 2012 17:20:03 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1336058403; bh=zzBnh05ZTjKoH7GkmC+MuN/i20/UqLmseQhylXbH5mI=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=h4v7cd7JyZIbu4tAHS0rNnEsczxVwrSmE1/1d3jpJFsYB/0xK8o4XcV3LCmB7BhpB TcXEYTGOgTuF4nouAkGa3CDFd4N47okU7NFmDm//eR/Mg6Ta35BvIuZfpMaOqfBB3R jNwkol5YHO7ntXcSYKSIZ/fnMaqFrjBLkB+bMM6o= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <4F982BDA.2040003@KingsMountain.com> Date: Thu, 3 May 2012 17:20:03 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7BFA5ED9-9DB8-49A5-AA6D-AD6146F11123@nic.cz> References: <4F982BDA.2040003@KingsMountain.com> To: =JeffH X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: Paul Hoffman , IETF DANE WG list Subject: Re: [dane] Referring to the DANE protocol and DANE-denoted certificate associations X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 03 May 2012 15:20:05 -0000 Jeff, we believe that your issues: http://www.ietf.org/mail-archive/web/dane/current/msg04695.html http://www.ietf.org/mail-archive/web/dane/current/msg04713.html should be fixed in -20. Could you please confirm? Thank you. Ondrej On 25. 4. 2012, at 18:52, =3DJeffH wrote: > Paul Hoffman replied: > >>> We use the term "usable certificate association" in section 4. For = your > >>> spec, how about: > >>> > >>> trusted certificate association > >>> A certificate association specified in a > >>> TLSA record that is determined to be usable in the TLSA spec. > >>> > >> > >> In that case, I'd be inclined to just use "usable cert association" = rather > >> than redefine it with the qualifier "trusted" (ie, if that's not = what the > >> -dane-protocol spec defines). > >> > >> Also, it would be helpful if the term "usable certificate = association" is > >> explicitly defined in a clearly referenceable manner in = -dane-protocol. > >> > >> This could be done by making that final para of section 4 a titled > >> subsection, e.g.. > >> > >> 4.1 Usable Certificate Association > >> > >> but since I notice that section 4 is entitled "Use of TLSA Records = in TLS" > >> it should perhaps be.. > >> > >> 4.1 Usable TLS Certificate Association > > > > I like the former. >=20 > Actually, in re-reading section 4 of -dane-protocol I wouldn't turn = that last para into a subsection -- because as you note.. >=20 >=20 > > The definition of what is "usable" goes on for many paragraphs.. >=20 >=20 > Rather, I'd be inclined to add something akin to this to "1.4. = Terminology".. >=20 > Usable TLS Certificate Association > A TLS certificate association that has passed all the tests = specified > in Section 4 "Use of TLSA Records in TLS". >=20 >=20 > there's some other terminological issues I'll send in another msg as a = Last Call comment. >=20 > HTH, >=20 > =3DJeffH > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane -- Ond=C5=99ej Sur=C3=BD -- Chief Science Officer ------------------------------------------- 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 rbarnes@bbn.com Thu May 3 08:25:47 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C923521F867A; Thu, 3 May 2012 08:25:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.449 X-Spam-Level: X-Spam-Status: No, score=-106.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 9jZqOrXxFh9a; Thu, 3 May 2012 08:25:47 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 1763621F866D; Thu, 3 May 2012 08:25:46 -0700 (PDT) Received: from dhcp-192-1-255-166.col.bbn.com ([192.1.255.166]:54441) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SPxu8-00088f-GT; Thu, 03 May 2012 11:25:16 -0400 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=utf-8 From: "Richard L. Barnes" In-Reply-To: <4874649B-01B4-4642-A3C0-F4CDFE87C85B@nic.cz> Date: Thu, 3 May 2012 11:25:40 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <9CB47D95-DF49-4B4A-875B-E2EED9E626A7@bbn.com> References: <201204301353.q3UDrb2I007118@fs4113.wdf.sap.corp> <9D005ED4-61DE-4CFF-8136-8AD5E30F66DB@kirei.se> <4874649B-01B4-4642-A3C0-F4CDFE87C85B@nic.cz> To: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= X-Mailer: Apple Mail (2.1257) Cc: apps-discuss@ietf.org, dane@ietf.org, paul.hoffman@vpnc.org, iesg@ietf.org, alexey.melnikov@isode.com, paul@nohats.ca Subject: Re: [dane] MX and DANE (Was: AppsDir review of draft-ietf-dane-protocol-19) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 03 May 2012 15:25:47 -0000 On May 3, 2012, at 11:07 AM, Ond=C5=99ej Sur=C3=BD wrote: > On 1. 5. 2012, at 8:05, Jakob Schlyter wrote: >=20 >> On 30 apr 2012, at 15:53, Martin Rex wrote: >>=20 >>> When trying to deliver mail to @toad.com, the only secure >>> question to ask is whether the server is authorized to process >>> Email for @toad.com. For certificates issued from the traditional >>> PKIX world, that would require a "toad.com" DNSName SAN. >>=20 >> That would require large hosting provider, e.g. Google Apps, to = update their SMTP TLS certificates each and every time they added or = removed a customer. In my book, that would not scale. I believe we = should focus on securing the transport, not building a TLS-based = application authorization system. >=20 >=20 > And I would add this is out of the scope of the DANE protocol... >=20 > If you want MX fixed, do it. But it is currently broken even just for = TLS. Either there will be some other document which fixes interaction = of SMTP and TLS and throws DANE on top of it, or the MTAs will just cope = ;), but we cannot specify anything which is broken right now. Oh, this discussion again. If you want real assurance that an = outsourced mail server is authorized to operate a mail server, then you = need: 1. DNSSEC on the MX record (in which case the hosting provider can use = his own cert) 2. Certificate reissuance whenever the set of customers changes (as = Jakob notes) This was raised earlier, e.g.: I relented on that discussion only because people seemed to think that = the MX world were comfortable with the spoofing risk, and communities = that were worried about spoofing (e.g., XMPP) could write their own = independent specs. =20 --Richard From ondrej.sury@nic.cz Thu May 3 08:28:00 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85E1E21F853C; Thu, 3 May 2012 08:28:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.634 X-Spam-Level: X-Spam-Status: No, score=-1.634 tagged_above=-999 required=5 tests=[AWL=0.065, 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 7BX1dqG1rg+6; Thu, 3 May 2012 08:28:00 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id D047521F8581; Thu, 3 May 2012 08:27:59 -0700 (PDT) Received: from kimac-wifi.office.nic.cz (fw.nic.cz [217.31.207.1]) by mail.nic.cz (Postfix) with ESMTPSA id 2CA6B13F9E9; Thu, 3 May 2012 17:27:59 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1336058879; bh=ACDujBuJItKGpH7EPMG2xiS23L5DWH0D/Gmxx81Qe+M=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=aMsgfNbMEklmFPU8QusjYX6UAwhlE/YvgzNAoV8bSckCMhiT68VqtJFP/Www+Sidd lvDPp4/TZ665oYPQQ97w3rNs+DMNpSK0fBruf8saNGFiwmzd3PDU+wngLfbgJCJS08 3XSKJhXpTNMqdAIqPvH3sxxXciAexHSe+zdu35uI= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <4F96D2AB.6090509@stpeter.im> Date: Thu, 3 May 2012 17:27:58 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F96D157.7020504@isode.com> <4F96D21A.7080006@isode.com> <4F96D2AB.6090509@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: The IESG , apps-discuss@ietf.org, IETF DANE WG list Subject: Re: [dane] [apps-discuss] AppsDir review of draft-ietf-dane-protocol-19 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 03 May 2012 15:28:00 -0000 On 24. 4. 2012, at 18:19, Peter Saint-Andre wrote: > Alexey, overnight I realized that this document doesn't say anything > about internationalized domain names (in fact, it doesn't cite any > documents about the definition of "DNS domain name"). So I think at = the > least it needs to provide a citation, e.g. to Section 2.2 of RFC 6125. Peter, I still don't understand why DANE should be different from any other new DNS RR type out there and specifically reference to IDN. RFC 6125 applies to DANE, as it applies to any other new RRtype which was and will be created. I hope you don't suggest we add a reference to RFC 6125 to every document creating a new RRtype? What value it would add to say: "Standard DNS rules applies including the IDN" in the document? I would say that it's implicit and doesn't need an explicit sentence. Chairs (and authors) share the opinion that the document doesn't need an update for IDN. Ondrej -- Ond=C5=99ej Sur=C3=BD -- Chief Science Officer ------------------------------------------- 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 fanf2@hermes.cam.ac.uk Thu May 3 08:32:12 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A7FD21F84F8; Thu, 3 May 2012 08:32:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.509 X-Spam-Level: X-Spam-Status: No, score=-6.509 tagged_above=-999 required=5 tests=[AWL=0.090, 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 F+35Akn5dDgN; Thu, 3 May 2012 08:32:11 -0700 (PDT) Received: from ppsw-52.csi.cam.ac.uk (ppsw-52.csi.cam.ac.uk [131.111.8.152]) by ietfa.amsl.com (Postfix) with ESMTP id 3900221F8498; Thu, 3 May 2012 08:32:11 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:40250) by ppsw-52.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1SPy0n-0001RH-Do (Exim 4.72) (return-path ); Thu, 03 May 2012 16:32:09 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1SPy0n-0006Eu-8d (Exim 4.67) (return-path ); Thu, 03 May 2012 16:32:09 +0100 Date: Thu, 3 May 2012 16:32:09 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: "Richard L. Barnes" In-Reply-To: <9CB47D95-DF49-4B4A-875B-E2EED9E626A7@bbn.com> Message-ID: References: <201204301353.q3UDrb2I007118@fs4113.wdf.sap.corp> <9D005ED4-61DE-4CFF-8136-8AD5E30F66DB@kirei.se> <4874649B-01B4-4642-A3C0-F4CDFE87C85B@nic.cz> <9CB47D95-DF49-4B4A-875B-E2EED9E626A7@bbn.com> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: apps-discuss@ietf.org, dane@ietf.org Subject: Re: [dane] MX and DANE (Was: AppsDir review of draft-ietf-dane-protocol-19) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 03 May 2012 15:32:12 -0000 Richard L. Barnes wrote: > > Oh, this discussion again. If you want real assurance that an > outsourced mail server is authorized to operate a mail server, then you > need: > 1. DNSSEC on the MX record (in which case the hosting provider can use his own cert) > 2. Certificate reissuance whenever the set of customers changes (as Jakob notes) You don't need both of these. If you do (1) then the server certificate identifies the MX target host name, so (2) is not necessary. (2) is only necessary if you put the mail domain (MX owner) in the cert, but if you do that then DNSSEC for the MX lookup isn't necessary. Tony. -- f.anthony.n.finch http://dotat.at/ Humber: Northeast 4 or 5. Slight. Occasional rain, fog patches. Moderate or good, occasionally very poor. From ondrej.sury@nic.cz Thu May 3 08:40:44 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE98E21F85EF for ; Thu, 3 May 2012 08:40:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.638 X-Spam-Level: X-Spam-Status: No, score=-1.638 tagged_above=-999 required=5 tests=[AWL=0.061, 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 11H3VGapYPln for ; Thu, 3 May 2012 08:40: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 1A8EA21F856F for ; Thu, 3 May 2012 08:40:44 -0700 (PDT) Received: from kimac-wifi.office.nic.cz (fw.nic.cz [217.31.207.1]) by mail.nic.cz (Postfix) with ESMTPSA id 054E313F9E9; Thu, 3 May 2012 17:40:43 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1336059643; bh=UCVgWTDfXwVjbXJxjzclmbjDlYAGO0Yk/7Yyu8BbyS4=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=xQo+N60f3kFhlNU2FmcTl0zvImMrT+g2PK7pCQzsLhUpIgm48qiHHXH3MphjNmR2E JryKycHkX7t/Hlo2d/F/tUcc1bWHQl8A/vwIrwqtdgRaRAH0ZlOToiXAZ4SkSSlII7 Vhv0mkSURrlx2nlZ/yLRvI7iHbHuMZeoqTlBUf2k= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <201204121730.q3CHUZcF021835@new.toad.com> Date: Thu, 3 May 2012 17:40:37 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <622147E9-2D3D-4139-BA7D-7601C1FBAF76@nic.cz> References: <201204121730.q3CHUZcF021835@new.toad.com> To: John Gilmore X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: dane@ietf.org Subject: [dane] Appendix A.1 - Certificate Usage 0 only (Re: draft-ietf-dane-protocol-19.txt typos and minor fixes) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 03 May 2012 15:40:44 -0000 On 12. 4. 2012, at 19:30, John Gilmore wrote: > Appendix A.1 is totally focused on CA-based examples, and provides no > guidance to users who want to deploy non-CA-based DANE. Nor does it > provide any guidance for domain administrators who are not sure > whether they want CA-based DANE or non-CA-based DANE. I had written > and submitted text about this, but none of it made it into the > document. Section A.1 says: When creating TLSA records with certificate usage 0 (CA Certificate) or usage 2 (Trust Anchor), one needs to understand the implications when choosing between selector type 0 (full certificate) and 1 (SubjectPublicKeyInfo). A careful choice is required because different methods for building trust chains are used by different TLS clients. The following outlines the cases that one ought to be aware of and discusses the implications of the choice of selector type. and here comes the important part: Certificate usage 2 is not affected by the different types of chain building when the end entity certificate is the same as the trust anchor certificate. > The appendix is written as if there is not even an option in DANE to > avoid using CAs. So yes, section A.1 is written to help deployment for Certificate usage = 0, because this one is the complicated one. I haven't seen any support from the working group on this topic. If = this isn't case please speak now. And in that case, please accompany your +1 with some text you would like to see in Section A.1. Chairs think the section is fine as is. And final note: > One might reasonably come to the conclusion that > committee members associated with CAs are deliberately slanting the > readers of the document toward their business model. This is not > appropriate in an RFC. Please refrain from flaming here. Ad hominem arguments are not = appropriate and they will not help you make stronger argument. Thank you. Ondrej -- Ond=C5=99ej Sur=C3=BD -- Chief Science Officer ------------------------------------------- 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 Thu May 3 08:47:46 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45B3B21F8630 for ; Thu, 3 May 2012 08:47:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.641 X-Spam-Level: X-Spam-Status: No, score=-1.641 tagged_above=-999 required=5 tests=[AWL=0.058, 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 FGf9Io5sXxbR for ; Thu, 3 May 2012 08:47:45 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id A465921F8623 for ; Thu, 3 May 2012 08:47:44 -0700 (PDT) Received: from kimac-wifi.office.nic.cz (fw.nic.cz [217.31.207.1]) by mail.nic.cz (Postfix) with ESMTPSA id E0F5313F9E9; Thu, 3 May 2012 17:47:43 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1336060064; bh=nPbiYf/xpkHUv847khCwruKtbxDyMuFd+fT1W/ksncY=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=kfs2Qx7lQND2otzph5UeeJdRSGZzrd7dPqYYEio4HdBf0zTGiQuWLO6rSGVqYsiL6 V+cRLWhE8hI6awr4+ikABf+48fHbD6ReP3RCanyef0G9rEHlw5W5O9oynIek7cki1W i0bGSKXj5goKwWATdMhZ81jGOs65McY9TnsyI1XA= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <201204121903.q3CJ3ucF026698@new.toad.com> Date: Thu, 3 May 2012 17:47:43 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9605FDF6-096D-4159-96A6-16549E8371AB@nic.cz> References: <201204121903.q3CJ3ucF026698@new.toad.com> To: John Gilmore X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: dane@ietf.org Subject: Re: [dane] Inappropriate Section 8 of draft-ietf-dane-protocol-19.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2012 15:47:46 -0000 John, you have raised this issue several times and yet I haven't seen a supportive message from other WG members. On the other hand Jim Schaad[1] and me have opposed your view of the issue. 1. https://www.ietf.org/mail-archive/web/dane/current/msg04566.html Chairs think the text is fine as it is. If the other WG members disagree, please speak now. And again I would like to see a modified text if you are going to support the assertion that we favor CAs (Type 0/1). O. P.S.: Also again I would like you to refrain from ad hominem attacks. On 12. 4. 2012, at 21:03, John Gilmore wrote: > The last graf of section 8, and the whole of section 8.1, seem > designed to prop up CA-based businesses, by fragmenting and > disparaging the security of the DANE protocol that the RFC proposes. >=20 > Our job as a committee was to design something that would be MORE > secure than CA-based TLS. If the committee truly believes that it > can't tell whether DANE for TLS will be more secure or less secure > than CA-based TLS (which is what draft-19 now says in brand-new text > inserted in Section 8.1), then IETF should avoid standardizing DANE > for TLS, and disband the committee as incompetent. >=20 > Instead, many on the committee have proposed that DANE for TLS become > a Proposed Standard. That means that we *do* think that it will > produce better security than the status quo. Therefore, we should > remove the sections from the document that inappropriately bash the > security of DANE for TLS. And we should remove the suggestion that > because certain mandatory-to-implement TLSA records don't happen to > support CA-based business models, implementors should provide local > options to reject those TLSA records. >=20 > The newly inserted Section 8.1 needs serious work. It was > inappropriate to insert this inflammatory section into the document > immediately before Last Call, with little mailing list discussion > beforehand. Again, it is an inappropriate attack on non-CA-based > DANE. >=20 > I would be happy to work with the committee on text for this > Internet-Draft (or Proposed Standard RFC) that would contrast the > security of DANE-for-TLS with the security of the status-quo-ante TLS, > either for a single secure website, or for the Internet as a whole, or > both. The text that's in Section 8.1 is not accurate, and is slanted > to inappropriately favor particular market participants. If the > committee is interested in a "quick fix" so we can rush the RFC into > print, I would be happy with removing the entire misleading section > 8.1, and removing the MUST-undermining last paragraph of section 8. >=20 > Now for the details: >=20 > Section 8, last paragraph: >=20 > The last paragraph should be removed, because it is designed to > fragment the market for DANE for TLS by encouraging implementers to > "locally" disable the mandatory-to-implement certificate usage types 2 > and 3. It was inserted without discussion in draft-18 and was > objected to at that point, but has been retained in "last call" > draft-19. >=20 > It is part of the design of DANE that if it is widely implemented > among clients, then TLS servers can rely solely on keys stored in > their DNS zone, avoiding the use of CAs. Section 6 of the draft uses > a MUST to require implementation of DANE's certificate usage types 2 > and 3, which provide non-CA-based key certification, but this > paragraph of small print deliberatly seeks to take away what the large > print grants, undermining that MUST by encouraging a "local policy" of > denying these usage types. (A local policy to "deny the trust" of > these keys is equivalent to not implementing them at all.) >=20 > I claim that this paragraph is not motivated by actual security > concerns, but by competitive business concerns. Certifying > Authority-based businesses want usage types 2 and 3 to become unusable > in some significant percentage of clients, because if that came about, > every TLS server would continue to be required to pay some CA-based > business money every year for a certificate. If usage types 2 and 3 > are as widely implemented as usage types 0 and 1, then TLS servers > would be free to stop paying CAs annually. This paragraph and Section > 8.1 are the CAs' weapons in that market struggle. They are welcome > to compete in the security market, but it is not the job of IETF RFCs > to help them retain their oligopoly in that market. >=20 > I sent an email yesterday about this concern, before draft-19: >=20 > https://www.ietf.org/mail-archive/web/dane/current/msg04609.html >=20 > I raised the details of my objections in -18 in an earlier message = here: >=20 > https://www.ietf.org/mail-archive/web/dane/current/msg04565.html >=20 > Section 8.1, entire section: >=20 > The whole section compares apples to oranges by comparing "a DNSSEC > validator" not with "a certificate-chain constructor and validator" > but with unspecified single CAs. To compare apples to apples, it > would compare an unspecified single CA with an unspecified single > domain administrator. >=20 > It claims to be "Comparing DANE to Public CAs", but it doesn't even > attempt to do that. Instead it cherry-picks the most problematic > parts of DANE security in misleading comparisons. It doesn't even = note > that DANE is designed to increase the security of CA usage for users > who want them, while also offering high security to users who for any > reason want to avoid CAs. >=20 > If the intent of the section is to discuss the effect of DANE on the > security of the whole Internet, then a system-level look at both the > status quo's and DANE's security is required, not a patchwork > comparison of individual elements of that security. If the intent is > merely to discuss the effect of DANE on the security of an individual > service that uses TLS (such as a single secure web site), then a > system-level look at that individual service is required. Section 8.1 > has not provided either one; it makes unsupported assertions about one > element of CA-based TLS, while making other unsupported assertions > about a different element of DANE-based TLS. >=20 > The 1st graf of 8.1 makes little sense to me. It claims that a DANE > client using an external DNSSEC validator is "as vulnerable as" a TLS > client of today. It states a tautology by saying that any client that > relies on any external source of trust can be fooled by relying on an > untrustworthy source. But then it bootstraps that into misleadingly > saying that DANE is "as vulnerable" as current TLS. This is wrong, > because a TLS client of today is vulnerable to compromise from > hundreds of trusted entities, most or all of which the client has no > contractual relationship with, and most or all of which were never > explicitly configured or examined by the user of the client. A DANE > client using an exernal DNSSEC validator is vulnerable to compromise > from a single trusted entity, that validator, plus another small > number of trusted entities which provide domain name service for the > domains that the client accesses. There are no pre-configured > external DNSSEC validators in TLS client software, as there are with > trust anchors, so any exernal DNSSEC validator would have to be > configured manually by the user of the client, requiring explicit > action to configure it insecurely. Also, the client's user probably > has a contract or other close relationship (such as being in the same > corporation) with an entity that provides it with an external DNSSEC > validator, so the user can more easily monitor its trustworthiness. > For example, the user's ISP might provide external DNSSEC validation, > as they today provide recursive DNS service, and most users have a > contract with their ISP. But the whole graf is mostly irrelevant, > because external DNSSEC validators running on other peoples' machines > are only expected to be used by a small fraction of the DANE clients. >=20 > The second graf makes an unsupported assumption ("If it is less likely > that a user will hear about...") to produce a scare quote ("could be > worse off than a current TLS client"). >=20 > Similarly, the 3rd graf seems to be unsupported by facts. It says > "Current public CAs are assumed to have better defenses than current > DNSSEC validators", but I don't think that there are any current > DNSSEC validators to compare current public CAs to. "Better defenses" > is ipso facto a misleading phrase unless it specifies against what > threat model it is defending. Furthermore, some current public CAs > have been proven to have poor defenses, since they have issued invalid > certificates used in mass man-in-the-middle attacks against the > population of entire countries. Since some current public CAs are > known to be untrustworthy, it's hard to support saying that "current > public CAs" in general are assumed to have good defenses. It then > goes on to say that "this perception" can't be proven one way or the > other. Barrooms, not RFCs, are the place for such poorly supported > statements. >=20 > The first two grafs discuss "external DNSSEC validators", but the > third and final graf slyly shifts the ground to "DNSSEC validators" in > general, without making this change obvious. And, again > validators are only a small part of the DANE ecosystem, but this > section doesn't go into any other part, while claiming to compare > the totality of DANE's security. >=20 > I believe that today's "internal" DNSSEC validators are considered as > trustworthy as today's "internal" certificate-chain constructors and > validators as used today in TLS. These are both cryptographic = libraries > that have undergone substantial testing and widespread deployment over > a period of many years. =20 >=20 > I believe that if the RFC is going to make statements about the > relative security DANE and of CA-based TLS, we should clearly state > that many well-qualified security experts and network administrators > have serious concerns about the security of CA-based TLS. I would be > happy to provide citations for some such statements, that the RFC > could reference as informative. We should also state that the only > reason for the continued widespread use of CA-based TLS is that there > is no credible alternative ready for mass market use. (The role of > this committee is to produce such an alternative -- not to undermine > its new alternative.) >=20 > The draft currently states in Section 1.1 that the actual security in > practice of traditional TLS CAs has been demonstrated to vary widely > among different CAs, from completely trustworthy to completely > untrustworthy. We all know that more than a few CAs have had their > trust anchors removed from popular TLS software due to public > breaches. A few other CAs who suffered breaches required specific > software patches in mass market TLS software such as browsers, because > their certificates were too widely used to allow their trust anchors > to be removed due to a single breach that issued a small number of > invalid certificates. We all fervently hope that that CA won't allow > another breach to occur, but such a history does not give us great > confidence. >=20 > I believe it is too early to say anything about the actual security in > practice of TLSA-protected domain names, since there is no operational > history to guide us. We don't even have an RRTYPE for TLSA yet! It > is *designed* to be secure, but so was CA-based TLS designed to be > secure, and yet CA-based TLS has not always been secure. We have > designed DANE to be MORE secure than CA-based TLS, for specified > reasons. Only time will tell. >=20 > The conclusion of section 8.1 "Thus, it is difficult to foresee which > system has a higher risk." is invalid. As Steve Kent pointed out, and > as our document now states, DANE for TLS incorporates the principle of > least privilege, which fixes the largest vulnerability in CA-based > TLS. >=20 > John Gilmore > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane -- Ond=C5=99ej Sur=C3=BD -- Chief Science Officer ------------------------------------------- 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 Thu May 3 08:52:32 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C06121F8653 for ; Thu, 3 May 2012 08:52:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.644 X-Spam-Level: X-Spam-Status: No, score=-1.644 tagged_above=-999 required=5 tests=[AWL=0.055, 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 jdpKxr8swV6A for ; Thu, 3 May 2012 08:52:31 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id A342221F8652 for ; Thu, 3 May 2012 08:52:31 -0700 (PDT) Received: from kimac-wifi.office.nic.cz (fw.nic.cz [217.31.207.1]) by mail.nic.cz (Postfix) with ESMTPSA id CA08413F9E9; Thu, 3 May 2012 17:52:30 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1336060350; bh=gmjcUeRWytXuOEAtn0pye8cNKG62atV6OJ5cnJ0WnoI=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=FIbcTNhp7XThBYYTlLf4xcIXmHDLs6BPdkffcuRSiK513v7O2H8yntzkU0q2NL5eC +t4P/1hF6yLvpBC61dlQsGa26J4EMvYQQ1f7iOWrb5Wir6QgQHww8XLsExyNF3jfaw +cyKFw++V8smuYknpN/Upbhxr6qijgwskUxbMeJ8= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <20120413005804.A93D41FA834E@drugs.dv.isc.org> Date: Thu, 3 May 2012 17:52:30 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0CE0B896-670C-4591-9D74-8039C6DEC038@nic.cz> References: <201204121730.q3CHUZcF021835@new.toad.com> <6.2.5.6.2.20120412104202.09ab2338@resistor.net> <6.2.5.6.2.20120412141224.09b64f08@resistor.net> <20120413004711.8C3EA1FA8165@drugs.dv.isc.org> <20120413005804.A93D41FA834E@drugs.dv.isc.org> To: Mark Andrews X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: dane@ietf.org Subject: Re: [dane] draft-ietf-dane-protocol-19.txt typos and minor fixes X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 03 May 2012 15:52:32 -0000 On 13. 4. 2012, at 2:58, Mark Andrews wrote: > We should recommend that tools that convert certificates to TLSA > records "SHOULD" support emitting the record in RFC 3597 format in > addition to TLSA presentation format. I don't think this is appropriate to say in the RFC. Tools are free to do whatever they want. We could add something like (copied from RFC4034): The Type Covered field is represented as an RR type mnemonic. When the mnemonic is not known, the TYPE representation as described in [RFC3597], Section 5, MUST be used. Ondrej -- Ond=C5=99ej Sur=C3=BD -- Chief Science Officer ------------------------------------------- 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 Thu May 3 08:54:18 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65E8421F865C; Thu, 3 May 2012 08:54:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.902 X-Spam-Level: X-Spam-Status: No, score=-0.902 tagged_above=-999 required=5 tests=[AWL=-0.692, BAYES_05=-1.11, 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 NQARRNz8dmHO; Thu, 3 May 2012 08:54: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 2C0E021F865B; Thu, 3 May 2012 08:54:17 -0700 (PDT) Received: from kimac-wifi.office.nic.cz (fw.nic.cz [217.31.207.1]) by mail.nic.cz (Postfix) with ESMTPSA id 793ED13F9E9; Thu, 3 May 2012 17:54:16 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1336060456; bh=wHXyacjAkR15b7HbfDQaN0ZpwkSWVFdO8vM3UickTZA=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=nmUF0VjLgbAcInhM4jYV+sYxJ9dyRin0YrV/5D7lAhx+pathX5AflpQTfzrUjrE4Y f286AL1Pmq1auHEX7WglTT/fs1WH1sofR1NtBJDwk6pXUF9VQtKeuQgD4Ru0me1OhB Q9SwONC1bNoHH5GR/fyfDTcir+HSfqQvllDd2oD0= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: Date: Thu, 3 May 2012 17:54:16 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <27A5BF91-C082-4FB4-8D6E-B68F725440EC@nic.cz> References: <01OE8FJG30ZM00ZUIL@mauve.mrochek.com> <201204130359.q3D3xlG0007556@fs4113.wdf.sap.corp> <01OE9150IMNI00ZUIL@mauve.mrochek.com> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: ietf@ietf.org, dane@ietf.org Subject: Re: [dane] Last Call: (The DNS-Based X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 03 May 2012 15:54:18 -0000 Phillip, I haven't seen any consensus for the change of the document, thus chairs think the document is fine as it is. Ondrej On 25. 4. 2012, at 15:52, Phillip Hallam-Baker wrote: > I have raised these comments in the WG numerous times, I am raising > them here as I do not believe that anyone is going to implement the > specification as currently described. >=20 > As currently written, the specification attempts to mandate client > behavior when DANE records are encountered in ways that are outside > the scope of interoperability. While the objective of the authors is > to mandate certain behavior they consider necessary for security > reasons, what they end up doing is attempting to substitute their own > judgement for that of the security experts who advise the client > providers. >=20 >=20 > Client providers already ignore significant parts of the PKIX > specification because they do not meet their performance criteria. In > particular virtually all browsers treat inability to obtain OCSP > certificate status as being equivalent to 'good'. This is a terrible > security design, one that every CA would like to see change. But it is > also a fact that we have been trying to get this changed for ten years > without success. >=20 > The browser providers do not hard fail on OCSP because doing so would > require them to wait for the OCSP response within the TLS handshake > and this is considered an unacceptable performance degradation. I do > not like this situation, but I can either play Canute and tell the > tide to turn or I can consider it to be a fact and try to work round > it. >=20 >=20 > DANE attempts to fix PKI with another mandate that is certain to be > ignored. In this case the mandate is to establish a critical > dependency on the DNSSEC trust chain despite the easily observed fact > that less than 97% of DNS resolvers will pass anything other than > A/AAAA and CNAME records. >=20 > Section 4 of the draft mandates a client hardfail if the DNSSEC trust > chain cannot be obtained. This is essential if the client is going to > use DNSSEC to establish certificate constraints just as certificate > revocation is an essential part of the PKIX model. But no browser > provider can expect to succeed with a product that simply stops > working when the user tries to surf the Web from a coffee shop. >=20 > Since the coffee shop problem is not intentional we might imagine that > it will eventually go away. But this puts DANE in a deployment > deadlock bind. Nobody is going to fix their coffee shop routers until > there is a need to and that need won't exist until the coffee shop > routers are fixed. >=20 > It is not just coffee shops that are the problem either. It might seem > really easy to put an SSL cert on a server and keep it up to date but > IETF participants represent the 1% of network admins. We all know from > experience how successful protocols that require two sets of records > to be kept in sync are. A protocol that requires a network admin to > remember to update their DNS with each cert change or suffer a > hardfail is going to have a very high administrative error rate. >=20 >=20 > Rather than mandating hardfail or any particular client behavior, the > specification should simply state that the client MUST conclude that > the DANE status of the certificate is invalid and then leave the > client to decide on what course of action to take. This will depend on > the circumstances of the particular user and the client provider's > assessment of the reliability of the DANE data and might range from do > nothing to send a security policy violation notification somewhere to > hardfail. >=20 >=20 > Contrary to the assumptions of the specification authors, hard fail is > not the best option. It is not even the best option in the case that > the users are dissidents. >=20 > To understand the logic of the dissident case it is important to have > a change of perspective. The objective of the authorities is not to > intimidate a single protester, it is to intimidate a whole country. > Being a protester carries inevitable risks. No security protocol is > going to eliminate those risks for the individual. What is important > is to minimize the risk for the population as a whole. >=20 > The Google cert pinning code did not provide much direct protection to > the Iranian dissidents because it only covered one site. But it proved > critical in exposing the Diginotar situation because it provided the > first evidence of the breach. Had the client been designed slightly > differently the breach might have become evident earlier. >=20 >=20 > The coffee shop issue is unintended but there are also parties that > are going to intentionally sabotage any infrastructure that looks like > DANE. We are not in the 1990s any longer, people in authority no > longer expect OSI to replace the Internet. The result is that it is > much harder to get away with no infrastructure. At present there is no > point in blocking DNSSEC records. But you can be sure that Iran, > Russia and China will be doing so the minute any client started to > make use of DANE. These countries can (and will) make use of a client > hard fail to ensure that people don't use browsers that might be used > for 'information terrorism' or freedom of speech as the rest of us > call it. >=20 > And don't think that out own governments necessarily mean what they > say. In public Thatcher was a stalwart champion of freedom. In private > she was begging Gorbachev to send in the tanks to stop the fall of the > Berlin wall. Her own foundation has materials that report this > exchange: >=20 > http://www.margaretthatcher.org/document/112006 >=20 > The last thing I want to do is to hand the authorities another tool > that can be used to selectively shut down the network at the critical > moment in a crisis. Completely shutting off the Internet is one thing, > it probably worked in our favor in Egypt as the 101st keyboarders lost > their Internet connection and were forced to find out what was going > on in the streets. It was a visceral sign of panic on the part of the > regime. >=20 >=20 > DANE is really a form of security policy information and so far there > is no case where we have succeeded in applying raw security policy > information at the client end. DKIM policies are a success because > they are filtered and interpreted by the anti-spam services. There is > a huge infrastructure in place that is working to apply the data from > the DKIM records intelligently and equally importantly provides > feedback to publishers of inconsistent records. >=20 > DANE is proposed on the basis of a mistaken interpretation of how DKIM > security policies work in practice and the result is a protocol that > is deeply flawed and likely to fail. >=20 > It would be a pity if the lack of success of a group that has > steadfastly worked to ignore and discourage outside advice became a > precedent to avoid future security policy efforts. Security policy is > a very powerful tool, one that we can and must use if we are going to > make the insecure Internet secure. But the DANE approach is too > dogmatic to succeed. > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane -- Ond=C5=99ej Sur=C3=BD -- Chief Science Officer ------------------------------------------- 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 Thu May 3 08:58:55 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB8F221F8601; Thu, 3 May 2012 08:58:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.615 X-Spam-Level: X-Spam-Status: No, score=-1.615 tagged_above=-999 required=5 tests=[AWL=0.084, 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 VOXx6izQdB5P; Thu, 3 May 2012 08:58:55 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id EA53F21F865C; Thu, 3 May 2012 08:58:54 -0700 (PDT) Received: from kimac-wifi.office.nic.cz (fw.nic.cz [217.31.207.1]) by mail.nic.cz (Postfix) with ESMTPSA id 3B58B13F9E9; Thu, 3 May 2012 17:58:54 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1336060734; bh=sDQRpdztgMHNX3XCRWEF5p3+mvLO51Jlo4NjzFwc+Sk=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=GigfEF5qJ+BC+OszH2prmiXR7mjMcyVfC4DTM89euWXVblcA2Z1hkEdKgOblznXaC PzQ3cssFkduD8eBncHIx9r8wT6ZDNWC5VASKSVcnzqXTWDvviSnz/MUZVhM0teMOPh pk/HpKvzN+VvFk0k6L0/bjL87WnZ7mhzRczPxbS4= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <9CB47D95-DF49-4B4A-875B-E2EED9E626A7@bbn.com> Date: Thu, 3 May 2012 17:58:54 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201204301353.q3UDrb2I007118@fs4113.wdf.sap.corp> <9D005ED4-61DE-4CFF-8136-8AD5E30F66DB@kirei.se> <4874649B-01B4-4642-A3C0-F4CDFE87C85B@nic.cz> <9CB47D95-DF49-4B4A-875B-E2EED9E626A7@bbn.com> To: Richard L. Barnes X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: The IESG , apps-discuss@ietf.org, IETF DANE WG list Subject: Re: [dane] MX and DANE (Was: AppsDir review of draft-ietf-dane-protocol-19) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 03 May 2012 15:58:55 -0000 On 3. 5. 2012, at 17:25, Richard L. Barnes wrote: > Oh, this discussion again. No, it's _not_ that discussion again. I wanted to say that we don't _want_ to discuss and fix it in the DANE WG. Somebody fix it elsewhere and come back. O. -- Ond=C5=99ej Sur=C3=BD -- Chief Science Officer ------------------------------------------- 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 Thu May 3 09:11:37 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0C9221F84F0 for ; Thu, 3 May 2012 09:11:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 YHAHtFvqW97z for ; Thu, 3 May 2012 09:11:36 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 47ED221F853E for ; Thu, 3 May 2012 09:11:36 -0700 (PDT) Received: from [IPv6:2001:1488:ac14:1400:610e:830c:6380:2906] (unknown [IPv6:2001:1488:ac14:1400:610e:830c:6380:2906]) by mail.nic.cz (Postfix) with ESMTPSA id 64F1713F9E9; Thu, 3 May 2012 18:11:35 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1336061495; bh=hUiez+FrUoPX3m1TsM1C9NtlLQ8l4eHz0akyZjfBOaQ=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=dAat8k+toL4OuuW7czg1isrBPrMyD5Lja5vGe7wLHIw6M3xl9/JxL5f9Tje4wHumk ptfzJl99JHHe+veBK8FOi4JD4cVth5yx7H1UyXeYztOR3cGu8MM0dkJF8Qq2lUi4IB 403KRW+zoqlVSIzPBXKEX01MfZethJZ/erNPQlOw= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <9605FDF6-096D-4159-96A6-16549E8371AB@nic.cz> Date: Thu, 3 May 2012 18:11:35 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3B0E65FD-86B7-4F7F-991F-0402A6D1B540@nic.cz> References: <201204121903.q3CJ3ucF026698@new.toad.com> <9605FDF6-096D-4159-96A6-16549E8371AB@nic.cz> To: John Gilmore X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: dane@ietf.org Subject: Re: [dane] Inappropriate Section 8 of draft-ietf-dane-protocol-19.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2012 16:11:37 -0000 Just to be explicit, I consider that there was no consensus for a = change. On 3. 5. 2012, at 17:47, Ond=C5=99ej Sur=C3=BD wrote: > John, >=20 > you have raised this issue several times and yet I haven't seen > a supportive message from other WG members. On the other hand > Jim Schaad[1] and me have opposed your view of the issue. >=20 > 1. https://www.ietf.org/mail-archive/web/dane/current/msg04566.html >=20 > Chairs think the text is fine as it is. If the other WG members > disagree, please speak now. And again I would like to see a modified > text if you are going to support the assertion that we favor CAs > (Type 0/1). >=20 > O. > P.S.: Also again I would like you to refrain from ad hominem attacks. >=20 > On 12. 4. 2012, at 21:03, John Gilmore wrote: >=20 >> The last graf of section 8, and the whole of section 8.1, seem >> designed to prop up CA-based businesses, by fragmenting and >> disparaging the security of the DANE protocol that the RFC proposes. >>=20 >> Our job as a committee was to design something that would be MORE >> secure than CA-based TLS. If the committee truly believes that it >> can't tell whether DANE for TLS will be more secure or less secure >> than CA-based TLS (which is what draft-19 now says in brand-new text >> inserted in Section 8.1), then IETF should avoid standardizing DANE >> for TLS, and disband the committee as incompetent. >>=20 >> Instead, many on the committee have proposed that DANE for TLS become >> a Proposed Standard. That means that we *do* think that it will >> produce better security than the status quo. Therefore, we should >> remove the sections from the document that inappropriately bash the >> security of DANE for TLS. And we should remove the suggestion that >> because certain mandatory-to-implement TLSA records don't happen to >> support CA-based business models, implementors should provide local >> options to reject those TLSA records. >>=20 >> The newly inserted Section 8.1 needs serious work. It was >> inappropriate to insert this inflammatory section into the document >> immediately before Last Call, with little mailing list discussion >> beforehand. Again, it is an inappropriate attack on non-CA-based >> DANE. >>=20 >> I would be happy to work with the committee on text for this >> Internet-Draft (or Proposed Standard RFC) that would contrast the >> security of DANE-for-TLS with the security of the status-quo-ante = TLS, >> either for a single secure website, or for the Internet as a whole, = or >> both. The text that's in Section 8.1 is not accurate, and is slanted >> to inappropriately favor particular market participants. If the >> committee is interested in a "quick fix" so we can rush the RFC into >> print, I would be happy with removing the entire misleading section >> 8.1, and removing the MUST-undermining last paragraph of section 8. >>=20 >> Now for the details: >>=20 >> Section 8, last paragraph: >>=20 >> The last paragraph should be removed, because it is designed to >> fragment the market for DANE for TLS by encouraging implementers to >> "locally" disable the mandatory-to-implement certificate usage types = 2 >> and 3. It was inserted without discussion in draft-18 and was >> objected to at that point, but has been retained in "last call" >> draft-19. >>=20 >> It is part of the design of DANE that if it is widely implemented >> among clients, then TLS servers can rely solely on keys stored in >> their DNS zone, avoiding the use of CAs. Section 6 of the draft uses >> a MUST to require implementation of DANE's certificate usage types 2 >> and 3, which provide non-CA-based key certification, but this >> paragraph of small print deliberatly seeks to take away what the = large >> print grants, undermining that MUST by encouraging a "local policy" = of >> denying these usage types. (A local policy to "deny the trust" of >> these keys is equivalent to not implementing them at all.) >>=20 >> I claim that this paragraph is not motivated by actual security >> concerns, but by competitive business concerns. Certifying >> Authority-based businesses want usage types 2 and 3 to become = unusable >> in some significant percentage of clients, because if that came = about, >> every TLS server would continue to be required to pay some CA-based >> business money every year for a certificate. If usage types 2 and 3 >> are as widely implemented as usage types 0 and 1, then TLS servers >> would be free to stop paying CAs annually. This paragraph and = Section >> 8.1 are the CAs' weapons in that market struggle. They are welcome >> to compete in the security market, but it is not the job of IETF RFCs >> to help them retain their oligopoly in that market. >>=20 >> I sent an email yesterday about this concern, before draft-19: >>=20 >> https://www.ietf.org/mail-archive/web/dane/current/msg04609.html >>=20 >> I raised the details of my objections in -18 in an earlier message = here: >>=20 >> https://www.ietf.org/mail-archive/web/dane/current/msg04565.html >>=20 >> Section 8.1, entire section: >>=20 >> The whole section compares apples to oranges by comparing "a DNSSEC >> validator" not with "a certificate-chain constructor and validator" >> but with unspecified single CAs. To compare apples to apples, it >> would compare an unspecified single CA with an unspecified single >> domain administrator. >>=20 >> It claims to be "Comparing DANE to Public CAs", but it doesn't even >> attempt to do that. Instead it cherry-picks the most problematic >> parts of DANE security in misleading comparisons. It doesn't even = note >> that DANE is designed to increase the security of CA usage for users >> who want them, while also offering high security to users who for any >> reason want to avoid CAs. >>=20 >> If the intent of the section is to discuss the effect of DANE on the >> security of the whole Internet, then a system-level look at both the >> status quo's and DANE's security is required, not a patchwork >> comparison of individual elements of that security. If the intent is >> merely to discuss the effect of DANE on the security of an individual >> service that uses TLS (such as a single secure web site), then a >> system-level look at that individual service is required. Section = 8.1 >> has not provided either one; it makes unsupported assertions about = one >> element of CA-based TLS, while making other unsupported assertions >> about a different element of DANE-based TLS. >>=20 >> The 1st graf of 8.1 makes little sense to me. It claims that a DANE >> client using an external DNSSEC validator is "as vulnerable as" a TLS >> client of today. It states a tautology by saying that any client = that >> relies on any external source of trust can be fooled by relying on an >> untrustworthy source. But then it bootstraps that into misleadingly >> saying that DANE is "as vulnerable" as current TLS. This is wrong, >> because a TLS client of today is vulnerable to compromise from >> hundreds of trusted entities, most or all of which the client has no >> contractual relationship with, and most or all of which were never >> explicitly configured or examined by the user of the client. A DANE >> client using an exernal DNSSEC validator is vulnerable to compromise >> from a single trusted entity, that validator, plus another small >> number of trusted entities which provide domain name service for the >> domains that the client accesses. There are no pre-configured >> external DNSSEC validators in TLS client software, as there are with >> trust anchors, so any exernal DNSSEC validator would have to be >> configured manually by the user of the client, requiring explicit >> action to configure it insecurely. Also, the client's user probably >> has a contract or other close relationship (such as being in the same >> corporation) with an entity that provides it with an external DNSSEC >> validator, so the user can more easily monitor its trustworthiness. >> For example, the user's ISP might provide external DNSSEC validation, >> as they today provide recursive DNS service, and most users have a >> contract with their ISP. But the whole graf is mostly irrelevant, >> because external DNSSEC validators running on other peoples' machines >> are only expected to be used by a small fraction of the DANE clients. >>=20 >> The second graf makes an unsupported assumption ("If it is less = likely >> that a user will hear about...") to produce a scare quote ("could be >> worse off than a current TLS client"). >>=20 >> Similarly, the 3rd graf seems to be unsupported by facts. It says >> "Current public CAs are assumed to have better defenses than current >> DNSSEC validators", but I don't think that there are any current >> DNSSEC validators to compare current public CAs to. "Better = defenses" >> is ipso facto a misleading phrase unless it specifies against what >> threat model it is defending. Furthermore, some current public CAs >> have been proven to have poor defenses, since they have issued = invalid >> certificates used in mass man-in-the-middle attacks against the >> population of entire countries. Since some current public CAs are >> known to be untrustworthy, it's hard to support saying that "current >> public CAs" in general are assumed to have good defenses. It then >> goes on to say that "this perception" can't be proven one way or the >> other. Barrooms, not RFCs, are the place for such poorly supported >> statements. >>=20 >> The first two grafs discuss "external DNSSEC validators", but the >> third and final graf slyly shifts the ground to "DNSSEC validators" = in >> general, without making this change obvious. And, again >> validators are only a small part of the DANE ecosystem, but this >> section doesn't go into any other part, while claiming to compare >> the totality of DANE's security. >>=20 >> I believe that today's "internal" DNSSEC validators are considered as >> trustworthy as today's "internal" certificate-chain constructors and >> validators as used today in TLS. These are both cryptographic = libraries >> that have undergone substantial testing and widespread deployment = over >> a period of many years. =20 >>=20 >> I believe that if the RFC is going to make statements about the >> relative security DANE and of CA-based TLS, we should clearly state >> that many well-qualified security experts and network administrators >> have serious concerns about the security of CA-based TLS. I would be >> happy to provide citations for some such statements, that the RFC >> could reference as informative. We should also state that the only >> reason for the continued widespread use of CA-based TLS is that there >> is no credible alternative ready for mass market use. (The role of >> this committee is to produce such an alternative -- not to undermine >> its new alternative.) >>=20 >> The draft currently states in Section 1.1 that the actual security in >> practice of traditional TLS CAs has been demonstrated to vary widely >> among different CAs, from completely trustworthy to completely >> untrustworthy. We all know that more than a few CAs have had their >> trust anchors removed from popular TLS software due to public >> breaches. A few other CAs who suffered breaches required specific >> software patches in mass market TLS software such as browsers, = because >> their certificates were too widely used to allow their trust anchors >> to be removed due to a single breach that issued a small number of >> invalid certificates. We all fervently hope that that CA won't allow >> another breach to occur, but such a history does not give us great >> confidence. >>=20 >> I believe it is too early to say anything about the actual security = in >> practice of TLSA-protected domain names, since there is no = operational >> history to guide us. We don't even have an RRTYPE for TLSA yet! It >> is *designed* to be secure, but so was CA-based TLS designed to be >> secure, and yet CA-based TLS has not always been secure. We have >> designed DANE to be MORE secure than CA-based TLS, for specified >> reasons. Only time will tell. >>=20 >> The conclusion of section 8.1 "Thus, it is difficult to foresee which >> system has a higher risk." is invalid. As Steve Kent pointed out, = and >> as our document now states, DANE for TLS incorporates the principle = of >> least privilege, which fixes the largest vulnerability in CA-based >> TLS. >>=20 >> John Gilmore >> _______________________________________________ >> dane mailing list >> dane@ietf.org >> https://www.ietf.org/mailman/listinfo/dane >=20 > -- > Ond=C5=99ej Sur=C3=BD -- Chief Science Officer > ------------------------------------------- > 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 -- Ond=C5=99ej Sur=C3=BD -- Chief Science Officer ------------------------------------------- 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 Thu May 3 09:12:08 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF44821F859B for ; Thu, 3 May 2012 09:12:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 pRfLVP03B4U1 for ; Thu, 3 May 2012 09:12:08 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 4438E21F863E for ; Thu, 3 May 2012 09:12:07 -0700 (PDT) Received: from [IPv6:2001:1488:ac14:1400:610e:830c:6380:2906] (unknown [IPv6:2001:1488:ac14:1400:610e:830c:6380:2906]) by mail.nic.cz (Postfix) with ESMTPSA id 65D5A13F9E9; Thu, 3 May 2012 18:12:04 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1336061524; bh=lqI5KYvI1BMFJ8ehKjzhkLI/9any25i5b8LTm1oXttU=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=cOUf3JP8vD+PnDdZWZLiM01i0xKQx/OUZCJWWz+F2asIKebGv+RE7lQ4pzTsAOsxF 1UPNBwU3lzkgB1htiYpfHer+JYmgGXzyE9Nq0ilASrvgC88Ul2iUJX8ztmWqymEaLd rA9xWr4B0p2cqRoUbfOClFkhOb1t8mKV2E1N04RY= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <622147E9-2D3D-4139-BA7D-7601C1FBAF76@nic.cz> Date: Thu, 3 May 2012 18:12:04 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3A897078-AB6A-4A86-B66A-F53BE7363A3E@nic.cz> References: <201204121730.q3CHUZcF021835@new.toad.com> <622147E9-2D3D-4139-BA7D-7601C1FBAF76@nic.cz> To: John Gilmore X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: dane@ietf.org Subject: Re: [dane] Appendix A.1 - Certificate Usage 0 only (Re: draft-ietf-dane-protocol-19.txt typos and minor fixes) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 03 May 2012 16:12:09 -0000 Also here: Just to be explicit, I consider that there was no consensus for a = change. O. On 3. 5. 2012, at 17:40, Ond=C5=99ej Sur=C3=BD wrote: >=20 > On 12. 4. 2012, at 19:30, John Gilmore wrote: >> Appendix A.1 is totally focused on CA-based examples, and provides no >> guidance to users who want to deploy non-CA-based DANE. Nor does it >> provide any guidance for domain administrators who are not sure >> whether they want CA-based DANE or non-CA-based DANE. I had written >> and submitted text about this, but none of it made it into the >> document. >=20 > Section A.1 says: >=20 > When creating TLSA records with certificate usage 0 (CA Certificate) > or usage 2 (Trust Anchor), one needs to understand the implications > when choosing between selector type 0 (full certificate) and 1 > (SubjectPublicKeyInfo). A careful choice is required because > different methods for building trust chains are used by different = TLS > clients. The following outlines the cases that one ought to be = aware > of and discusses the implications of the choice of selector type. >=20 > and here comes the important part: >=20 > Certificate usage 2 is not affected by the different types of chain > building when the end entity certificate is the same as the trust > anchor certificate. >=20 >> The appendix is written as if there is not even an option in DANE to >> avoid using CAs. >=20 > So yes, section A.1 is written to help deployment for Certificate = usage 0, > because this one is the complicated one. >=20 > I haven't seen any support from the working group on this topic. If = this > isn't case please speak now. And in that case, please accompany your = +1 > with some text you would like to see in Section A.1. >=20 > Chairs think the section is fine as is. >=20 > And final note: >=20 >> One might reasonably come to the conclusion that >> committee members associated with CAs are deliberately slanting the >> readers of the document toward their business model. This is not >> appropriate in an RFC. >=20 > Please refrain from flaming here. Ad hominem arguments are not = appropriate > and they will not help you make stronger argument. Thank you. >=20 > Ondrej > -- > Ond=C5=99ej Sur=C3=BD -- Chief Science Officer > ------------------------------------------- > 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 -- Ond=C5=99ej Sur=C3=BD -- Chief Science Officer ------------------------------------------- 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 Jeff.Hodges@KingsMountain.com Thu May 3 10:01:37 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FBB521F8593 for ; Thu, 3 May 2012 10:01:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.317 X-Spam-Level: X-Spam-Status: No, score=-99.317 tagged_above=-999 required=5 tests=[AWL=-0.681, BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.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 13ob6573Hg+B for ; Thu, 3 May 2012 10:01:36 -0700 (PDT) Received: from oproxy1-pub.bluehost.com (oproxy1.bluehost.com [IPv6:2605:dc00:100:2::a1]) by ietfa.amsl.com (Postfix) with SMTP id 4F13221F858D for ; Thu, 3 May 2012 10:01:24 -0700 (PDT) Received: (qmail 16134 invoked by uid 0); 3 May 2012 17:01:21 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy1.bluehost.com with SMTP; 3 May 2012 17:01:21 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=2GOh2es39yhroWFXcHC2yCoQWtfh+ediBeoC5ze61yU=; b=OaL4x96kO8/o9qBjVZ8N4Qvu+kFAwhHBFBI9ScGcpzaKB0y6XdUE+2TB5scfVFT8r5Dawu9g9/UpLREZk6ViTi2XZkiAVCzOjhhTz9UIb0WfJEVASKxDrowQSchIfKVB; Received: from [205.248.100.252] (helo=[10.69.6.184]) by box514.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1SPzP5-00006s-Qt for dane@ietf.org; Thu, 03 May 2012 11:01:19 -0600 Message-ID: <4FA2B9D6.6070108@KingsMountain.com> Date: Thu, 03 May 2012 10:01:10 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20 MIME-Version: 1.0 To: IETF DANE WG list Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 205.248.100.252 authed with jeff.hodges+kingsmountain.com} Subject: Re: [dane] Referring to the DANE protocol and DANE-denoted certificate associations X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 03 May 2012 17:01:37 -0000 > we believe that your issues: > > http://www.ietf.org/mail-archive/web/dane/current/msg04695.html > http://www.ietf.org/mail-archive/web/dane/current/msg04713.html > > should be fixed in -20. Could you please confirm? Thank you. thx, I will endeavor to review in next day or two. =JeffH From stpeter@stpeter.im Thu May 3 11:59:14 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B1FA21F8674 for ; Thu, 3 May 2012 11:59:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.453 X-Spam-Level: X-Spam-Status: No, score=-102.453 tagged_above=-999 required=5 tests=[AWL=-0.154, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 5005HfGd1T+z for ; Thu, 3 May 2012 11:59:13 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id CBD5221F866B for ; Thu, 3 May 2012 11:59:13 -0700 (PDT) Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 90E5740058; Thu, 3 May 2012 13:14:15 -0600 (MDT) Message-ID: <4FA2D580.6020700@stpeter.im> Date: Thu, 03 May 2012 12:59:12 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= References: <4F95CA0B.8050202@stpeter.im> <4F9F4DEE.1090309@stpeter.im> <20120501040138.GA25922@odin.ulthar.us> <4F9F6236.3050303@stpeter.im> <05746AE2-AAA4-496E-A92D-C6826FD27F18@nic.cz> In-Reply-To: <05746AE2-AAA4-496E-A92D-C6826FD27F18@nic.cz> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: dane@ietf.org Subject: Re: [dane] Terminology 'whitespace' (Was: AppsDir review of draft-ietf-dane-protocol-19) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 03 May 2012 18:59:14 -0000 On 5/3/12 8:34 AM, Ondřej Surý wrote: > On 1. 5. 2012, at 6:10, Peter Saint-Andre wrote: >>>>> 4. In Section 2.2, the term "whitespace" is underspecified. Does >>>>> that include, say, any Unicode space separator (Unicode General >>>>> Category Zs) or also line separators (Unicode General Category Zl) >>>>> or only certain code points in the ASCII range? Further, is the >>>>> whitespace significant in the examples from Section 2.3? >>>> >>>> I see no change in -20 to clarify this matter. >>> >>> RFC 1035 (normative reference of RFC 4034, which is a normative >>> reference of this draft), section 5 defines the format for zone files >>> ("Master files" in RFC 1035). That RFC predates Unicode and IDN, and >>> doesn't appear to be updated by any RFC spelling out use of Unicode in >>> zone files. >>> >>> Based on that, I'd say that zone files are still ASCII-only (and a quick >>> web search seems to confirm that that is the case, though I don't see >>> any harm in adhering to the robustness principle here). At any rate, >>> the definition of the TLSA presentation format and examples in this >>> draft seem consistent with RFC 1035 and the definition for other RR >>> types. >> >> Does whitespace include tab, linefeed, etc., or only SP (ASCII 20)? It >> really ought to be easy to clarify the matter. Just saying "whitespace" >> is less than clear, IMHO. > > Unfortunatelly we are again in the field of DNS archaeology, and there is > no clear definition of 'whitespace', but it is widely used everywhere, see: > > http://tools.ietf.org/html/rfc4034#section-2.2 > > The Public Key field MUST be represented as a Base64 encoding of the > Public Key. Whitespace is allowed within the Base64 text. For a > definition of Base64 encoding, see [RFC3548]. > > This probably needs fixing (rewriting RFC1034/1035 with more up-to-date > RFC language), but definitely not here. Ahoj Ondřej, I'm not familiar with DNS archeology, but if the implicit definition of 'whitespace' is common knowledge in the DNS community, then I think it's fine to leave it undefined here as well. Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Thu May 3 12:52:22 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35A3821F8615; Thu, 3 May 2012 12:52:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.45 X-Spam-Level: X-Spam-Status: No, score=-102.45 tagged_above=-999 required=5 tests=[AWL=-0.151, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 1hWgnppUO5eZ; Thu, 3 May 2012 12:52:20 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 7973C21F861D; Thu, 3 May 2012 12:52:20 -0700 (PDT) Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id C0D894005B; Thu, 3 May 2012 14:07:21 -0600 (MDT) Message-ID: <4FA2E1F2.6060406@stpeter.im> Date: Thu, 03 May 2012 13:52:18 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= References: <4F96D157.7020504@isode.com> <4F96D21A.7080006@isode.com> <4F96D2AB.6090509@stpeter.im> In-Reply-To: X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: The IESG , apps-discuss@ietf.org, IETF DANE WG list Subject: Re: [dane] [apps-discuss] AppsDir review of draft-ietf-dane-protocol-19 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 03 May 2012 19:52:22 -0000 On 5/3/12 9:27 AM, Ondřej Surý wrote: > On 24. 4. 2012, at 18:19, Peter Saint-Andre wrote: >> Alexey, overnight I realized that this document doesn't say anything >> about internationalized domain names (in fact, it doesn't cite any >> documents about the definition of "DNS domain name"). So I think at the >> least it needs to provide a citation, e.g. to Section 2.2 of RFC 6125. > > > Peter, > > I still don't understand why DANE should be different from any other > new DNS RR type out there and specifically reference to IDN. RFC 6125 > applies to DANE, as it applies to any other new RRtype which was and > will be created. I hope you don't suggest we add a reference to RFC > 6125 to every document creating a new RRtype? > > What value it would add to say: "Standard DNS rules applies including > the IDN" in the document? I would say that it's implicit and doesn't > need an explicit sentence. > > Chairs (and authors) share the opinion that the document doesn't need > an update for IDN. Ahoj Ondřej, Perhaps this is simply a difference between folks who look at things from the DNS perspective and folks who look at things from the apps perspective (as users of DNS). All sorts of application protocols are being updated to support IDNs. Those applications will need to know how to translate their IDNs (which might consist of U-labels) into a form that can be placed into the DNS. To make things perfectly clear, I'm just suggesting that we add a sentence or two warning those who write code for application protocols using DANE that they might need to convert U-labels into A-labels. I'll work to propose specific text today or tomorrow. Peter -- Peter Saint-Andre https://stpeter.im/ From paul.hoffman@vpnc.org Thu May 3 13:34:32 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B73821F86B1; Thu, 3 May 2012 13:34:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.545 X-Spam-Level: X-Spam-Status: No, score=-102.545 tagged_above=-999 required=5 tests=[AWL=0.054, 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 9o4fiIjEcafA; Thu, 3 May 2012 13:34: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 8273621F86B0; Thu, 3 May 2012 13:34:31 -0700 (PDT) Received: from [10.20.30.102] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q43KYTTM077432 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 3 May 2012 13:34:30 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <4FA2E1F2.6060406@stpeter.im> Date: Thu, 3 May 2012 13:34:29 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <2B6494C5-4BB1-4159-967C-483094BDC0C7@vpnc.org> References: <4F96D157.7020504@isode.com> <4F96D21A.7080006@isode.com> <4F96D2AB.6090509@stpeter.im> <4FA2E1F2.6060406@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1257) Cc: The IESG , "apps-discuss@ietf.org Discuss" , IETF DANE WG list Subject: Re: [dane] [apps-discuss] AppsDir review of draft-ietf-dane-protocol-19 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 03 May 2012 20:34:32 -0000 On May 3, 2012, at 12:52 PM, Peter Saint-Andre wrote: > Perhaps this is simply a difference between folks who look at things > from the DNS perspective and folks who look at things from the apps > perspective (as users of DNS). All sorts of application protocols are > being updated to support IDNs. Those applications will need to know = how > to translate their IDNs (which might consist of U-labels) into a form > that can be placed into the DNS. To make things perfectly clear, I'm > just suggesting that we add a sentence or two warning those who write > code for application protocols using DANE that they might need to > convert U-labels into A-labels. I'll work to propose specific text = today > or tomorrow. I'll be interested to see that. I cannot see how anyone reading Section = 3 of RFC 5891 could think that they would *not* need to convert to = A-labels before looking up something in the DNS. If you are saying that = every post-5891 protocol that defines a new RRtype must say "and if you = are going to look up the domain name in the DNS, convert to A-labels = first", that's fine, but it seems kinda late to start saying that. --Paul Hoffman From sm@resistor.net Thu May 3 14:27:34 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AEAA21F85D3; Thu, 3 May 2012 14:27:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.563 X-Spam-Level: X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.036, 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 RF2yJIEPUDc2; Thu, 3 May 2012 14:27:33 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id AD68521F8592; Thu, 3 May 2012 14:27:33 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q43LRPD5003550; Thu, 3 May 2012 14:27:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1336080452; i=@resistor.net; bh=Cp4NzOfkwoiY7Mee3yJKAMy48yr/SxqTz5aF87p5Stc=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=P54whtoL7zNUNwiA1IY+KoUAIgu9B2OuyaiSuJ6/G/yhEUtUGG/taMCMPz//zBDpH qjp7Hn5RbviZOLG+NrDyxAXwyNwRoEpmxMeOQNBWzvI8TQXZDmSPsFPHGnX6bhYN+8 c8cQ1XEUHtP51lTlcFv09f5VMmmE4BbjVvJeTI0E= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1336080452; i=@resistor.net; bh=Cp4NzOfkwoiY7Mee3yJKAMy48yr/SxqTz5aF87p5Stc=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=3DVJNbIFFwq1Yty7KwRrmOYqGTwzPJckfe1CRaVZMX/5k2cXgYF6iqea1zuDsEzUN KaQlkxApOwWEmFyeRV42aC2D+nzt3Sk6N1GJEUJJtyQ7i1ngRLd41KisVFgMedy9aC dQ9WFYGunHRRoFPt7N8VC6u2FfZYTWZzXlJOaazc= Message-Id: <6.2.5.6.2.20120503130631.097d25d8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 03 May 2012 14:26:37 -0700 To: Peter Saint-Andre From: SM In-Reply-To: <4FA0335E.7090306@stpeter.im> References: <4F95CA0B.8050202@stpeter.im> <4F9F4DEE.1090309@stpeter.im> <4FA0335E.7090306@stpeter.im> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: iesg@ietf.org, apps-discuss@ietf.org, dane@ietf.org Subject: Re: [dane] [apps-discuss] AppsDir review of draft-ietf-dane-protocol-19 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 03 May 2012 21:27:34 -0000 Hi Peter, At 12:02 01-05-2012, Peter Saint-Andre wrote: > >> I still think that this document needs to say something about > >> IDNs. Section 3 of draft-ietf-dane-protocol-20 uses "domain name". The reference is likely RFC 1035. The problem with DANE is that it touches application layer protocols by using host names (see the examples). RFC 1123 is applicable then. If you want to support internationalization, you then end up using RFC 5890. Should the question about whether STD 13 supports IDN, everyone knows what the answer will be. :-) The note in Section 1.3 could be extended as a separate paragraph: This document does not cover how to associate certificates with domain names for application protocols that depend on MX, SRV, NAPTR, and similar DNS resource records; it is expected that later updates to this document might cover methods for making those associations. Note that legacy application specifications (e.g., SMTP [RFC5321] and HTTP [RFC2616]) do not permit non-ASCII labels in DNS domain names used with those protocols, i.e., only the A-label form of IDNs is permitted in those contexts. Section 2.2 of RFC 6125 discusses about DNS domain name used by an application service. [sentence borrowed from RFC 5890] Somewhere during the discussion of the AppsDir reviews, Alexey asked an interesting question: what is a "DNS domain name". The question was not fully answered. The "fix", if anyone thinks it is worthwhile, would be to get an answer in the context of Section 3 of the draft and adapt the hand-waving accordingly. Regards, -sm From stpeter@stpeter.im Thu May 3 14:41:45 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B44BA21F86DC; Thu, 3 May 2012 14:41:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[AWL=0.001, 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 rfgFVN0PBRyX; Thu, 3 May 2012 14:41:45 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 1E75A21F86D5; Thu, 3 May 2012 14:41:45 -0700 (PDT) Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id A70C540058; Thu, 3 May 2012 15:56:43 -0600 (MDT) Message-ID: <4FA2FB94.204@stpeter.im> Date: Thu, 03 May 2012 15:41:40 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Paul Hoffman References: <4F96D157.7020504@isode.com> <4F96D21A.7080006@isode.com> <4F96D2AB.6090509@stpeter.im> <4FA2E1F2.6060406@stpeter.im> <2B6494C5-4BB1-4159-967C-483094BDC0C7@vpnc.org> In-Reply-To: <2B6494C5-4BB1-4159-967C-483094BDC0C7@vpnc.org> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: The IESG , "apps-discuss@ietf.org Discuss" , IETF DANE WG list Subject: Re: [dane] [apps-discuss] AppsDir review of draft-ietf-dane-protocol-19 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 03 May 2012 21:41:45 -0000 On 5/3/12 2:34 PM, Paul Hoffman wrote: > On May 3, 2012, at 12:52 PM, Peter Saint-Andre wrote: > >> Perhaps this is simply a difference between folks who look at >> things from the DNS perspective and folks who look at things from >> the apps perspective (as users of DNS). All sorts of application >> protocols are being updated to support IDNs. Those applications >> will need to know how to translate their IDNs (which might consist >> of U-labels) into a form that can be placed into the DNS. To make >> things perfectly clear, I'm just suggesting that we add a sentence >> or two warning those who write code for application protocols using >> DANE that they might need to convert U-labels into A-labels. I'll >> work to propose specific text today or tomorrow. > > > I'll be interested to see that. I cannot see how anyone reading > Section 3 of RFC 5891 could think that they would *not* need to > convert to A-labels before looking up something in the DNS. If you > are saying that every post-5891 protocol that defines a new RRtype > must say "and if you are going to look up the domain name in the DNS, > convert to A-labels first", that's fine, but it seems kinda late to > start saying that. Not everyone is as smart as you are. Peter -- Peter Saint-Andre https://stpeter.im/ From ajs@anvilwalrusden.com Thu May 3 14:47:34 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 621C121F864B; Thu, 3 May 2012 14:47:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.636 X-Spam-Level: X-Spam-Status: No, score=-2.636 tagged_above=-999 required=5 tests=[AWL=-0.037, 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 75kWnH4Txcdx; Thu, 3 May 2012 14:47:34 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id E431321F8643; Thu, 3 May 2012 14:47:33 -0700 (PDT) Received: from mail.yitter.info (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 F07051ECB41C; Thu, 3 May 2012 21:47:32 +0000 (UTC) Date: Thu, 3 May 2012 17:47:23 -0400 From: Andrew Sullivan To: iesg@ietf.org, apps-discuss@ietf.org, dane@ietf.org Message-ID: <20120503214643.GB1804@mail.yitter.info> References: <4F95CA0B.8050202@stpeter.im> <4F9F4DEE.1090309@stpeter.im> <4FA0335E.7090306@stpeter.im> <6.2.5.6.2.20120503130631.097d25d8@resistor.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.2.5.6.2.20120503130631.097d25d8@resistor.net> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] [apps-discuss] AppsDir review of draft-ietf-dane-protocol-19 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 03 May 2012 21:47:34 -0000 On Thu, May 03, 2012 at 02:26:37PM -0700, SM wrote: > Hi Peter, > Section 3 of draft-ietf-dane-protocol-20 uses "domain name". The > reference is likely RFC 1035. The problem with DANE is that it > touches application layer protocols by using host names (see the > examples). RFC 1123 is applicable then. If you want to support > internationalization, you then end up using RFC 5890. Should the > question about whether STD 13 supports IDN, everyone knows what the > answer will be. :-) I don't think that the examples (I presume you mean "in that section", since the examples in Appx C aren't DNS names) are normative, and as nearly as I can tell nothing about section 3 is restricted to the host name syntax. It's true that if you want to use IDNA with DANE then you have to do it using A-labels. I don't really get why any of that needs to go into the protocol document, though. This is a document about how you do stuff in the DNS, and that means you have to do it in a DNS-y way. No? A -- Andrew Sullivan ajs@anvilwalrusden.com From ekr@rtfm.com Thu May 3 14:56:08 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0021521F84DA for ; Thu, 3 May 2012 14:56:07 -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 n3EgRM2kQ5S7 for ; Thu, 3 May 2012 14:56:07 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 49B2E21F84D5 for ; Thu, 3 May 2012 14:56:07 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so1975298vcb.31 for ; Thu, 03 May 2012 14:56:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:from:date:message-id:subject:to :content-type:x-gm-message-state; bh=RcDYMEAriRYQnpQdskGBurx8ePMvnWdKngQFhjwW0ng=; b=gErkLtPa3j2OeclfJn5uBCJBgvgEASCBxwjkNGB5k2pUCAVhqSOUre1wcvK5MrFpKv E14+Gz/ax75IhBj5T0O4VtjNjmb26MxheuLuuqMlhJdBY1NlyB3+B/Eeul2XRXpLx4tz qyK0R4h5EaW27Ke+6lcO//RoIH3VKwXVgIlrB6zpN7xJAtTKRE/T65NncVDGQggAvbQQ Z9IXDzmktRsS8t2LddnO9RzTdtHCuSbUEEOSwM6YQeovkEqv8NfFsTxzwwX3+MtJVTKn 1uULrPN9cgdwkwSrlQambRyJExI02vXi6hdCkz8UX2ZtBJFhrL1Dtb8aj/CZ9Y6oKcpr QCDg== Received: by 10.52.172.194 with SMTP id be2mr1766198vdc.60.1336082166664; Thu, 03 May 2012 14:56:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.19.233 with HTTP; Thu, 3 May 2012 14:55:24 -0700 (PDT) X-Originating-IP: [205.248.100.252] From: Eric Rescorla Date: Thu, 3 May 2012 14:55:24 -0700 Message-ID: To: dane@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnGIJNknOd+uDq/F8cu55CiK0YUz+Y/zlvsvH9KDeTPKEpayrNpCy0eRTEqIl3cB1+MvdKO Subject: [dane] Behavior in the face of no answer? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 03 May 2012 21:56:08 -0000 I've been reading -20 and I'm not sure I understand the behavior that section 4.1 is supposed to say. Consider the following case: I am trying to connect for the first time to https://www.example.com/, which is signed. I go to retrieve the TLSA record, but when I do so, the request times out. What do I do? There seem to be two options: (a) Treat this as a hard failure and abort the connection. (b) Treat this as if I have an empty TLSA response and continue with ordinary TLS. I claim that the right response from a security perspective is clearly (a): hard fail. If you agree with me, then jump to "2. DOCUMENT TEXT" below. If not, keep reading. 1. SECURITY ANALYSIS The basic security setting in which CA constraints and service certificate constraints are useful is one in which: (a) The attacker has a valid certificate for the target domain, but not the same as the certificate issued to the real server. (b) The attacker has enough control of the network to get the victim to connect to his server. Generally, (b) means that the attacker is on-path to the client or the server. What makes DANE work is that it provides an independent cryptographically verifiable check on the server certificate, thus excluding the attacker's certificate. Even if the attacker can force traffic to him, then, the certificate won't be acceptable. If the attacker can force you to ignore the information in DANE, then DANE offers minimal security guarantees. If clients treat TLSA RR requests without responses (i.e., timeouts) as if they were empty TLSA responses and continue with TLS as usual, then any attacker who can block DNS responses (i.e., anyone who is on-path to the victim, at least) can downgrade you to ordinary TLS. So, I think it follows that non-responses (or SERVFAILS or any other resolver error) must be treated as hard failures and cause aborts. Note that the security context for DANE is different from that of many DNS contexts, because in many such contexts, non-response means you just don't resolve so you fail hard anyway. But here, you fail to a weaker security position. 2. DOCUMENT TEXT As I said above, I find the document kind of hard to read on this point. S 4.1 refers to the RFC 4033 definitions and says that Bogus must be hard-failed and that Insecure and Indeterminate must be treated as if there were empty TLSA sets and you continue with TLS. So, the question is whether non-response is Bogus or not. Here's what 4033 says (http://tools.ietf.org/html/rfc4033#section-5) Bogus: The validating resolver has a trust anchor and a secure delegation indicating that subsidiary data is signed, but the response fails to validate for some reason: missing signatures, expired signatures, signatures with unsupported algorithms, data missing that the relevant NSEC RR says should be present, and so forth. But in this case we don't have an invalid response, but instead a non-response, so its not clear to me this falls into Bogus. I'm not steeped in all the DNSSEC lore, so maybe there is a wide agreement that nonresponse == bogus, but I don't get that clearly out of the document. IMO, DANE would benefit from stating this clearly. -Ekr From paul.hoffman@vpnc.org Thu May 3 14:59:29 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 475CE21F86F7; Thu, 3 May 2012 14:59:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.546 X-Spam-Level: X-Spam-Status: No, score=-102.546 tagged_above=-999 required=5 tests=[AWL=0.053, 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 5ej1lKeyDJ5i; Thu, 3 May 2012 14:59:28 -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 AE2E021F86E1; Thu, 3 May 2012 14:59:28 -0700 (PDT) Received: from [10.20.30.102] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q43LxRZt080690 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 3 May 2012 14:59:27 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <4FA2FB94.204@stpeter.im> Date: Thu, 3 May 2012 14:59:26 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <07511DD9-AED9-4E67-B162-6D353C550788@vpnc.org> References: <4F96D157.7020504@isode.com> <4F96D21A.7080006@isode.com> <4F96D2AB.6090509@stpeter.im> <4FA2E1F2.6060406@stpeter.im> <2B6494C5-4BB1-4159-967C-483094BDC0C7@vpnc.org> <4FA2FB94.204@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1257) Cc: The IESG , "apps-discuss@ietf.org Discuss" , IETF DANE WG list Subject: Re: [dane] [apps-discuss] AppsDir review of draft-ietf-dane-protocol-19 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 03 May 2012 21:59:29 -0000 On May 3, 2012, at 2:41 PM, Peter Saint-Andre wrote: > On 5/3/12 2:34 PM, Paul Hoffman wrote: >> On May 3, 2012, at 12:52 PM, Peter Saint-Andre wrote: >>=20 >>> Perhaps this is simply a difference between folks who look at >>> things from the DNS perspective and folks who look at things from >>> the apps perspective (as users of DNS). All sorts of application >>> protocols are being updated to support IDNs. Those applications >>> will need to know how to translate their IDNs (which might consist >>> of U-labels) into a form that can be placed into the DNS. To make >>> things perfectly clear, I'm just suggesting that we add a sentence >>> or two warning those who write code for application protocols using >>> DANE that they might need to convert U-labels into A-labels. I'll >>> work to propose specific text today or tomorrow. >>=20 >>=20 >> I'll be interested to see that. I cannot see how anyone reading >> Section 3 of RFC 5891 could think that they would *not* need to >> convert to A-labels before looking up something in the DNS. If you >> are saying that every post-5891 protocol that defines a new RRtype >> must say "and if you are going to look up the domain name in the DNS, >> convert to A-labels first", that's fine, but it seems kinda late to >> start saying that. >=20 > Not everyone is as smart as you are. If you believe that developers who are using IDNs are not following the = easiest-to-read section of RFC 5891, the issue is much larger than just = DANE. I propose that is not a DANE issue at all. --Paul Hoffman From nweaver@icsi.berkeley.edu Thu May 3 15:03:34 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDFCB21F8652 for ; Thu, 3 May 2012 15:03:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IZcfHmBUcazk for ; Thu, 3 May 2012 15:03:34 -0700 (PDT) Received: from rock.ICSI.Berkeley.EDU (rock.ICSI.Berkeley.EDU [192.150.186.19]) by ietfa.amsl.com (Postfix) with ESMTP id 62AED21F8646 for ; Thu, 3 May 2012 15:03:33 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id E0EAE2C400D; Thu, 3 May 2012 15:03:32 -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 uMVF4VV8BxW4; Thu, 3 May 2012 15:03:32 -0700 (PDT) Received: from gala.icir.org (gala [192.150.187.49]) (Authenticated sender: nweaver) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id A1BBD2C4002; Thu, 3 May 2012 15:03:32 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Nicholas Weaver In-Reply-To: Date: Thu, 3 May 2012 15:03:32 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <39F82CB2-9421-4248-955E-CB29012928B3@icsi.berkeley.edu> References: To: Eric Rescorla X-Mailer: Apple Mail (2.1257) Cc: dane@ietf.org Subject: Re: [dane] Behavior in the face of no answer? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 03 May 2012 22:03:35 -0000 On May 3, 2012, at 2:55 PM, Eric Rescorla wrote: > I've been reading -20 and I'm not sure I understand the behavior that = section > 4.1 is supposed to say. Consider the following case: >=20 > I am trying to connect for the first time to https://www.example.com/, > which is signed. I go to retrieve the TLSA record, but when I do so, > the request times out. What do I do? There seem to be two options: >=20 > (a) Treat this as a hard failure and abort the connection. > (b) Treat this as if I have an empty TLSA response and continue with = ordinary > TLS. >=20 > I claim that the right response from a security perspective is clearly = (a): hard > fail. If you agree with me, then jump to "2. DOCUMENT TEXT" below. If = not, keep > reading. I agree: If A www.example.com resolves but the TLSA record times out = (which is required for it to even reach this state in a benign or = malicious form), Thats Bad (tm). And I agree that the text should probably say "Treat nonresponsive as = Bogus" From sm@resistor.net Thu May 3 15:07:37 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 229E421F8705; Thu, 3 May 2012 15:07:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.563 X-Spam-Level: X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.036, 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 FO2vYTWC+EFv; Thu, 3 May 2012 15:07:35 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C25F21F8702; Thu, 3 May 2012 15:07:35 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q43M7QAQ018787; Thu, 3 May 2012 15:07:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1336082853; i=@resistor.net; bh=zum396/mnt9aW03dpcIu7LrOhxO8VdinVsAdAeojKfc=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=05kXBYc3FvOABWeRBUOwvh7rSJNgHwfAYlfuSJxcpqHC3waMH1lpoAoiFxO5aPNNy XQv+y3nJTSM/i0v0yZBkd5fwHNLEoo1bxhfPUvVH240d34M+IKCgZRgIf6rpS/Dtf7 0QwtOhj8MDoQRpOSL2ye5exXNQ/tMqG3D9x2REkY= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1336082853; i=@resistor.net; bh=zum396/mnt9aW03dpcIu7LrOhxO8VdinVsAdAeojKfc=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=X5dLuOESxYVMHzLXEfeBc2912koAbhvNCHefPzhUvxqqVimOTshG0NTkH4QJDWhpY NBNWNl8/IekSepZirTJdEXgQo83/GpUBuiXXUhT0tsabFW7q7kJL1dfd3oPS4SuSiC NGoRfXvECpA2bKgX+iQDZnNyWRE/s7oLdR91LHXE= Message-Id: <6.2.5.6.2.20120503145303.09a25d30@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 03 May 2012 15:03:58 -0700 To: Andrew Sullivan From: SM In-Reply-To: <20120503214643.GB1804@mail.yitter.info> References: <4F95CA0B.8050202@stpeter.im> <4F9F4DEE.1090309@stpeter.im> <4FA0335E.7090306@stpeter.im> <6.2.5.6.2.20120503130631.097d25d8@resistor.net> <20120503214643.GB1804@mail.yitter.info> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: iesg@ietf.org, apps-discuss@ietf.org, dane@ietf.org Subject: Re: [dane] [apps-discuss] AppsDir review of draft-ietf-dane-protocol-19 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 03 May 2012 22:07:37 -0000 Hi Andrew, At 14:47 03-05-2012, Andrew Sullivan wrote: >I don't think that the examples (I presume you mean "in that section", >since the examples in Appx C aren't DNS names) are normative, and as I understand that. >nearly as I can tell nothing about section 3 is restricted to the host >name syntax. It's true that if you want to use IDNA with DANE then >you have to do it using A-labels. I don't really get why any of that >needs to go into the protocol document, though. This is a document >about how you do stuff in the DNS, and that means you have to do it in >a DNS-y way. No? Peter posted a message at http://www.ietf.org/mail-archive/web/apps-discuss/current/msg05577.html which in my opinion explains the application perspective. If you go by RFC 4398, yes. The problem with the DNS way is that it pushes issues to the application side and the reverse is also valid. Regards, -sm From paul.hoffman@vpnc.org Thu May 3 15:20:49 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4503021F8711 for ; Thu, 3 May 2012 15:20:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.546 X-Spam-Level: X-Spam-Status: No, score=-102.546 tagged_above=-999 required=5 tests=[AWL=0.053, 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 i2kXQOYvZcUE for ; Thu, 3 May 2012 15:20:48 -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 6723721F8705 for ; Thu, 3 May 2012 15:20:48 -0700 (PDT) Received: from [10.20.30.102] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q43MKlQJ081601 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 3 May 2012 15:20:47 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1257) From: Paul Hoffman In-Reply-To: Date: Thu, 3 May 2012 15:20:47 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0526D60A-3F1B-4C55-9796-256BC2556AAB@vpnc.org> References: To: IETF DANE WG list X-Mailer: Apple Mail (2.1257) Subject: Re: [dane] Behavior in the face of no answer? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 03 May 2012 22:20:49 -0000 On May 3, 2012, at 2:55 PM, Eric Rescorla wrote: > I've been reading -20 and I'm not sure I understand the behavior that = section > 4.1 is supposed to say. Consider the following case: >=20 > I am trying to connect for the first time to https://www.example.com/, > which is signed. I go to retrieve the TLSA record, but when I do so, > the request times out. What do I do? There seem to be two options: >=20 > (a) Treat this as a hard failure and abort the connection. > (b) Treat this as if I have an empty TLSA response and continue with = ordinary > TLS. >=20 > I claim that the right response from a security perspective is clearly = (a): hard > fail. If you agree with me, then jump to "2. DOCUMENT TEXT" below. If = not, keep > reading. >=20 >=20 > 1. SECURITY ANALYSIS > The basic security setting in which CA constraints and service = certificate > constraints are useful is one in which: >=20 > (a) The attacker has a valid certificate for the target domain, but = not > the same as the certificate issued to the real server. > (b) The attacker has enough control of the network to get the victim > to connect to his server. >=20 > Generally, (b) means that the attacker is on-path to the client or the > server. >=20 > What makes DANE work is that it provides an independent = cryptographically > verifiable check on the server certificate, thus excluding the = attacker's > certificate. Even if the attacker can force traffic to him, then, the > certificate > won't be acceptable. If the attacker can force you to ignore the > information in DANE, then DANE offers minimal security guarantees. > If clients treat TLSA RR requests without responses (i.e., timeouts) = as > if they were empty TLSA responses and continue with TLS as usual, > then any attacker who can block DNS responses (i.e., anyone who > is on-path to the victim, at least) can downgrade you to ordinary TLS. > So, I think it follows that non-responses (or SERVFAILS or any other > resolver error) must be treated as hard failures and cause aborts. >=20 > Note that the security context for DANE is different from > that of many DNS contexts, because in many such contexts, > non-response means you just don't resolve so you fail hard > anyway. But here, you fail to a weaker security position. >=20 > 2. DOCUMENT TEXT > As I said above, I find the document kind of hard to read on this = point. > S 4.1 refers to the RFC 4033 definitions and says that Bogus must > be hard-failed and that Insecure and Indeterminate must be treated > as if there were empty TLSA sets and you continue with TLS. So, > the question is whether non-response is Bogus or not. Here's > what 4033 says (http://tools.ietf.org/html/rfc4033#section-5) >=20 > Bogus: The validating resolver has a trust anchor and a secure > delegation indicating that subsidiary data is signed, but the > response fails to validate for some reason: missing signatures, > expired signatures, signatures with unsupported algorithms, data > missing that the relevant NSEC RR says should be present, and so > forth. >=20 > But in this case we don't have an invalid response, but instead a > non-response, so its not clear to me this falls into Bogus. >=20 > I'm not steeped in all the DNSSEC lore, so maybe there is a wide > agreement that nonresponse =3D=3D bogus, but I don't get that clearly > out of the document. IMO, DANE would benefit from stating this > clearly. =46rom the earlier thread on this topic, I do not think there is "wide = agreement" on what is and is not bogus. RFC 4033 and 4035 don't even = agree about it. Just because I like actual proposals for text, I believe what ekr is = proposing is changing the current: o If the DNSSEC validation state on the response to the request for the TLSA RRset is bogus, this MUST cause TLS not to be started or, if the TLS negotiation is already in progress, MUST cause the connection to be aborted. to: o If the DNSSEC validation state on the response to the request for the TLSA RRset is bogus, or if a response is not received or the response has no data, this MUST cause TLS not to be started or, if the TLS negotiation is already in progress, MUST cause the connection to be aborted. --Paul Hoffman From Jeff.Hodges@KingsMountain.com Thu May 3 15:28:11 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F62F21F86F5 for ; Thu, 3 May 2012 15:28:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.077 X-Spam-Level: X-Spam-Status: No, score=-100.077 tagged_above=-999 required=5 tests=[AWL=0.418, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.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 IglRFefP5tkK for ; Thu, 3 May 2012 15:28:10 -0700 (PDT) Received: from oproxy6-pub.bluehost.com (oproxy6.bluehost.com [IPv6:2605:dc00:100:2::a6]) by ietfa.amsl.com (Postfix) with SMTP id D90FC21F86D1 for ; Thu, 3 May 2012 15:28:09 -0700 (PDT) Received: (qmail 9926 invoked by uid 0); 3 May 2012 22:28:05 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy3.bluehost.com with SMTP; 3 May 2012 22:28:05 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=UDDCGOp7pQXZgUtIPzdgseiPz9SEHn2p1Qq0DIi1Wks=; b=BuxFgoeDvHg2yuKoba3X0+2olh+79B7k6tpYt4np9CnYsu57tTPmQChr1h+oHw4FOiUmQtWxIm4FYixXe7bnLEpKUswHutqf2FxoR2+rHFZOWecfYZ/a2cz2iQJYZD26; Received: from [205.248.100.252] (helo=[10.69.6.184]) by box514.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1SQ4VI-0002IF-DX; Thu, 03 May 2012 16:28:04 -0600 Message-ID: <4FA3066D.8070101@KingsMountain.com> Date: Thu, 03 May 2012 15:27:57 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20 MIME-Version: 1.0 To: IETF DANE WG list Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 205.248.100.252 authed with jeff.hodges+kingsmountain.com} Cc: Paul Hoffman Subject: Re: [dane] Referring to the DANE protocol and DANE-denoted certificate associations X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 03 May 2012 22:28:11 -0000 > we believe that your issues: > should be fixed in -20. Could you please confirm? Thank you. > http://www.ietf.org/mail-archive/web/dane/current/msg04695.html yes, the above issue is addressed in -20. > http://www.ietf.org/mail-archive/web/dane/current/msg04713.html many items are fixed in -20, including the most important ones it seems. (thx) since there were several items, i've identified below fixed vs not fixed and added some further thoughts on a few. the two marked with [*] i'd be inclined to really fix. however, I'll leave it up to you -- I won't fall on my sword over any of 'em at this point. HTH, =JeffH > Some additional modest last call comments on draft-ietf-dane-protocol-19... > > terminological issues > --------------------- > > The "usage" notion has at least five term/phrase variations used in the > spec. I found this quite confusing. Here's the variations I find.. > > usage = usage type = certificate usage = certificate usage type = TLSA Usages > > > I suggest settling on one or two phrases for most all occurances. I suggest > using "certificate usage type" in (almost) all cases, and "usage type" > perhaps in cases where the bare term "usage" is presently used. To help out, > here's an updated TLSA RDATA Wire Format diagram.. > the above set of issues are fixed. (thanks!) > Separately, the term "TLSA certificate association" is used in a few places, > and should probably be "TLS certificate association" for consistency. [*] the term "TLS certificate association" is now established in the 1st para of S 2, but then "TLSA certificate association" (note the "A" at the end of "TLS") is used throughout the spec. Is that the actual intention or a cut-and-paste mistake? using either phrase is fine by me, i'd just be utterly consistent. > I also found the term "TLSA association" used on pages 22 & 23, which ought > to be "TLS certificate association", yes? the above is not addressed. > Section 8.1 introduces the somewhat ambiguous term "DANE client", which is > contrasted with "common TLS clients" and "current TLS client". Perhaps > "TLSA-aware TLS client" is more appropriate here than "DANE client", > especially if this protocol is referred to as the "TLSA protocol"? "DANE client" is now used only once at beginning of S 8.1. thus this issue is mostly addressed. I think in this section the intended connotation of that term is "TLSA-aware TLS client" ? (that's what I would use) > editorial items > --------------- > > > 1.1. Background of the Problem > > [ I'd entitle this section "Background and Motivation" ] fixed. > > last para: > > > DNS-Based Authentication of Named Entities (DANE) offers the option > > to use the DNSSEC infrastructure to store and sign keys and > > certificates that are used by TLS. > > If in fact the term "DANE" (and its expansion) names a class of Secure > DNS-based cert/key-to-domain-name associations, and protocols for > particular instances will nominally be assigned their own names, where a > case-in-point is the "TLSA Protocol", then.. > > s/TLS/security protocols/ > > ..in the above-quoted sentence. the above is not addressed. > > 1.2 Securing the Association with a Server's Certificate > > which association is this section title referring to? (it's ambiguous) > > Suggested more precise section title: > > "Securing the Association of Domain Name and TLS Server Certificate" fixed. > > Currently, the client must extract the domain name from the > > certificate and must successfully validate the certificate, including > > chaining to a trust anchor. > > I found the above description unnecessarily imprecise, though recognizing > the desire to provide only a brief overview here. A suggested modest > rewrite: > > Currently, the client must extract the domain name from the certificate > and validate it [RFC6125], and must also successfully validate the > certificate, including chaining to a CA's trust anchor [RFC5280]. > However, as explained above in Section 1.1, essentially any CA may > have issued the certificate for the domain name. [*] not fixed. > > 2. The TLSA Resource Record > > > > The TLSA DNS resource record (RR) is used to associate a certificate > > with the domain name where the record is found. > > suggested clarification.. > > The TLSA DNS resource record (RR) is used to associate a TLS server > certificate or public key with the domain name where the record is found, > thus forming a "TLS certificate association". > > Otherwise, "TLS certificate association" is only tacitly defined. fixed. > > 2.1.1. The Certificate Usage Field > > > > > > A one-octet value, called "certificate usage" or just "usage", > > specifies the provided association that will be used to match the > > target certificate from the TLS handshake. > > In the above, as well as two more instances in the paragraphs following the > above, I suggest.. > > s/target certificate/presented certificate/ > > ..to be more consistent with RFC6125. not fixed. > > 2.1.4. The Certificate Association Data Field > > > > > > The "certificate association data" to be matched. This field > > contains the data to be matched. > > The 2nd sentence "This field contains the data to be matched." is redundant. fixed. > > 5. TLSA and DANE Use Cases and Requirements > > . > > . > > . > > Combination -- Multiple TLSA records can be published for a given > > host name, thus enabling the client to construct multiple TLSA > > certificate associations that reflect different DANE assertions. > > No support is provided to combine two TLSA certificate > > associations in a single operation. > > > > Roll-over -- TLSA records are processed in the normal manner within > > the scope of DNS protocol, including the TTL expiration of the > > records. This ensures that clients will not latch onto assertions > > made by expired TLSA records, and will be able to transition from > > using one DANE public key or certificate usage type to another. > > > suggested rewrite eliminating the not-defined-in-RFC6394 terms "DANE > assertion" and "DANE public key"... > > Combination -- Multiple TLSA records can be published for a given > host name, thus enabling the client to construct multiple different > TLS certificate associations. No support is provided to combine two > TLS certificate associations in a single operation. > > Roll-over -- TLSA records are processed in the normal manner within > the scope of DNS protocol, including the TTL expiration of the > records. This ensures that clients will not latch onto assertions > made by expired TLSA records, and will be able to transition from > using one TLSA-asserted public key or certificate usage type to > another. fixed. > > 7.2. TLSA Usages > > > > > > This document creates a new registry, "Certificate Usages for TLSA > > Resource Records". > > suggested modest revision for terminological consistency: > > 7.2. TLSA Certificate Usage Types > > This document creates a new registry, "TLSA Resource Record Certificate > Usage Types" fixed. --- end From stpeter@stpeter.im Thu May 3 15:33:41 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50EA621F8705; Thu, 3 May 2012 15:33:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.53 X-Spam-Level: X-Spam-Status: No, score=-102.53 tagged_above=-999 required=5 tests=[AWL=0.069, 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 3jiiUHF0-PYT; Thu, 3 May 2012 15:33:40 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 672E921F8702; Thu, 3 May 2012 15:33:40 -0700 (PDT) Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 893B340058; Thu, 3 May 2012 16:48:42 -0600 (MDT) Message-ID: <4FA307C2.1090209@stpeter.im> Date: Thu, 03 May 2012 16:33:38 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Paul Hoffman References: <4F96D157.7020504@isode.com> <4F96D21A.7080006@isode.com> <4F96D2AB.6090509@stpeter.im> <4FA2E1F2.6060406@stpeter.im> <2B6494C5-4BB1-4159-967C-483094BDC0C7@vpnc.org> <4FA2FB94.204@stpeter.im> <07511DD9-AED9-4E67-B162-6D353C550788@vpnc.org> In-Reply-To: <07511DD9-AED9-4E67-B162-6D353C550788@vpnc.org> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: The IESG , "apps-discuss@ietf.org Discuss" , IETF DANE WG list Subject: Re: [dane] [apps-discuss] AppsDir review of draft-ietf-dane-protocol-19 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 03 May 2012 22:33:41 -0000 On 5/3/12 3:59 PM, Paul Hoffman wrote: > On May 3, 2012, at 2:41 PM, Peter Saint-Andre wrote: > >> On 5/3/12 2:34 PM, Paul Hoffman wrote: >>> On May 3, 2012, at 12:52 PM, Peter Saint-Andre wrote: >>> >>>> Perhaps this is simply a difference between folks who look at >>>> things from the DNS perspective and folks who look at things >>>> from the apps perspective (as users of DNS). All sorts of >>>> application protocols are being updated to support IDNs. Those >>>> applications will need to know how to translate their IDNs >>>> (which might consist of U-labels) into a form that can be >>>> placed into the DNS. To make things perfectly clear, I'm just >>>> suggesting that we add a sentence or two warning those who >>>> write code for application protocols using DANE that they might >>>> need to convert U-labels into A-labels. I'll work to propose >>>> specific text today or tomorrow. >>> >>> >>> I'll be interested to see that. I cannot see how anyone reading >>> Section 3 of RFC 5891 could think that they would *not* need to >>> convert to A-labels before looking up something in the DNS. If >>> you are saying that every post-5891 protocol that defines a new >>> RRtype must say "and if you are going to look up the domain name >>> in the DNS, convert to A-labels first", that's fine, but it seems >>> kinda late to start saying that. >> >> Not everyone is as smart as you are. > > If you believe that developers who are using IDNs are not following > the easiest-to-read section of RFC 5891, the issue is much larger > than just DANE. I propose that is not a DANE issue at all. I believe nothing -- I'm just saying that I am no longer surprised by what folks do or do not know. I see no harm in including a sentence or two sending folks in the right direction. Peter -- Peter Saint-Andre https://stpeter.im/ From ajs@anvilwalrusden.com Thu May 3 15:37:59 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AED221F86DF for ; Thu, 3 May 2012 15:37:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.635 X-Spam-Level: X-Spam-Status: No, score=-2.635 tagged_above=-999 required=5 tests=[AWL=-0.036, 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 7U5UsvYdtUjJ for ; Thu, 3 May 2012 15:37:58 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 9A66621F86BA for ; Thu, 3 May 2012 15:37:58 -0700 (PDT) Received: from mail.yitter.info (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 B06251ECB41C for ; Thu, 3 May 2012 22:37:51 +0000 (UTC) Date: Thu, 3 May 2012 18:37:49 -0400 From: Andrew Sullivan To: dane@ietf.org Message-ID: <20120503223745.GC1804@mail.yitter.info> References: <0526D60A-3F1B-4C55-9796-256BC2556AAB@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0526D60A-3F1B-4C55-9796-256BC2556AAB@vpnc.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Behavior in the face of no answer? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 03 May 2012 22:37:59 -0000 On Thu, May 03, 2012 at 03:20:47PM -0700, Paul Hoffman wrote: > >From the earlier thread on this topic, I do not think there is "wide agreement" on what is and is not bogus. RFC 4033 and 4035 don't even agree about it. > I'm not sure I agree about this. There is a possible difference in 4033 and 4035 on the meaning of "indeterminate", but I don't know anyone who disagrees about "bogus": you ought to be able to validate it, and for some reason, you can't. Whatever the reason is, it's bogus. In this case, what you're talking about is "didn't get an answer". > o If the DNSSEC validation state on the response to the request for > the TLSA RRset is bogus, or if a response is not received or the > response has no data, this MUST cause TLS not to be started or, > if the TLS negotiation is already in progress, MUST cause the > connection to be aborted. I get the analysis, but I feel rather uncomfortable with it. If you can't get responses from the DNS, surely you have other problems, to begin with? A -- Andrew Sullivan ajs@anvilwalrusden.com From paul@nohats.ca Thu May 3 15:45:14 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07ACE21F873A for ; Thu, 3 May 2012 15:45:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.527 X-Spam-Level: X-Spam-Status: No, score=-0.527 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HOST_MISMATCH_COM=0.311, RDNS_DYNAMIC=0.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 mqF3cmWRWqqs for ; Thu, 3 May 2012 15:45:13 -0700 (PDT) Received: from letoams.cypherpunks.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) by ietfa.amsl.com (Postfix) with ESMTP id 92A7E21F873B for ; Thu, 3 May 2012 15:45:12 -0700 (PDT) Received: by letoams.cypherpunks.ca (Postfix, from userid 500) id 4D7AF855F6; Thu, 3 May 2012 18:45:11 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by letoams.cypherpunks.ca (Postfix) with ESMTP id 322BC803A3; Thu, 3 May 2012 18:45:11 -0400 (EDT) Date: Thu, 3 May 2012 18:45:11 -0400 (EDT) From: Paul Wouters To: Paul Hoffman In-Reply-To: <0526D60A-3F1B-4C55-9796-256BC2556AAB@vpnc.org> Message-ID: References: <0526D60A-3F1B-4C55-9796-256BC2556AAB@vpnc.org> User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: IETF DANE WG list Subject: Re: [dane] Behavior in the face of no answer? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 03 May 2012 22:45:14 -0000 On Thu, 3 May 2012, Paul Hoffman wrote: >> From the earlier thread on this topic, I do not think there is "wide agreement" on what is and is not bogus. RFC 4033 and 4035 don't even agree about it. > > Just because I like actual proposals for text, I believe what ekr is proposing is changing the current: > o If the DNSSEC validation state on the response to the request for > the TLSA RRset is bogus, this MUST cause TLS not to be started or, > if the TLS negotiation is already in progress, MUST cause the > connection to be aborted. > to: > o If the DNSSEC validation state on the response to the request for > the TLSA RRset is bogus, or if a response is not received or the > response has no data, this MUST cause TLS not to be started or, > if the TLS negotiation is already in progress, MUST cause the > connection to be aborted. I'm not sure I understand "has no data" in the context of DNSSEC with a validation path (eg DS at the parent). A response with no data, where there is a DNSSEC chain of trust, is per definition bogus, as your response, even for 'no data' has to come with the signed proof (NSEC/NSEC3) I would just leave out "or the response has no data" Paul From ekr@rtfm.com Thu May 3 15:45:39 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89CBE21F873E for ; Thu, 3 May 2012 15:45:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.845 X-Spam-Level: X-Spam-Status: No, score=-102.845 tagged_above=-999 required=5 tests=[AWL=0.132, 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 EYoBKw7nPnsO for ; Thu, 3 May 2012 15:45:38 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id A1E2221F873C for ; Thu, 3 May 2012 15:45:38 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so2002696vcb.31 for ; Thu, 03 May 2012 15:45:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=r/cb0XV7HSqTr1Ic8I17BN2K06auq5dMQ4V1Es3yVQ8=; b=NAq7/vVjRwG2aD/mVDwulN0FPvlsJDNZHyWUzaI13hh4OXrx+OzMGDucY9N74+sWwc u1dtCRVVlZDUYPlAFfkWrxoCle7X2dI0i9XFyWolYpLmfEUdcV7268GR7opVBC8ysLpL KQ3Vx88blXPnNaaWfDDkk4Z4XIkq9DwZQKOgnGazmk6Bebbeueyo2qkzrAiXYBjV5jrw qfZ04OzLxIQUYrnCukR02T1xBQzvKOhN0V5xGUj34E/+ov4+fm0jGDAuZDp1w9h7zcEM tH9+kKK/dBuhTEFcwxVJPsi9/dRW4uskj/bxn3kxPqCYZPMGcpHfN9jVkRWktwCD00+8 vkSw== Received: by 10.220.141.79 with SMTP id l15mr2363315vcu.48.1336085138106; Thu, 03 May 2012 15:45:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.19.233 with HTTP; Thu, 3 May 2012 15:44:57 -0700 (PDT) X-Originating-IP: [74.95.2.169] In-Reply-To: <20120503223745.GC1804@mail.yitter.info> References: <0526D60A-3F1B-4C55-9796-256BC2556AAB@vpnc.org> <20120503223745.GC1804@mail.yitter.info> From: Eric Rescorla Date: Thu, 3 May 2012 15:44:57 -0700 Message-ID: To: Andrew Sullivan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkeuGOsF8YE67ThDZMV44UgtI93um8kgrgl/dx0+1Ri2Yhebky0xezvvmOamd5N4uWFlSKb Cc: dane@ietf.org Subject: Re: [dane] Behavior in the face of no answer? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 03 May 2012 22:45:39 -0000 On Thu, May 3, 2012 at 3:37 PM, Andrew Sullivan wr= ote: > On Thu, May 03, 2012 at 03:20:47PM -0700, Paul Hoffman wrote: >> >From the earlier thread on this topic, I do not think there is "wide ag= reement" on what is and is not bogus. RFC 4033 and 4035 don't even agree ab= out it. >> > > I'm not sure I agree about this. =A0There is a possible difference in > 4033 and 4035 on the meaning of "indeterminate", but I don't know > anyone who disagrees about "bogus": you ought to be able to validate > it, and for some reason, you can't. =A0Whatever the reason is, it's > bogus. > > In this case, what you're talking about is "didn't get an answer". > >> =A0 =A0o =A0If the DNSSEC validation state on the response to the reques= t for >> =A0 =A0 =A0 the TLSA RRset is bogus, or if a response is not received or= the >> =A0 =A0 =A0 response has no data, this MUST cause TLS not to be started = or, >> =A0 =A0 =A0 if the TLS negotiation is already in progress, MUST cause th= e >> =A0 =A0 =A0 connection to be aborted. > > I get the analysis, but I feel rather uncomfortable with it. =A0If you > can't get responses from the DNS, surely you have other problems, to > begin with? Well, I absolutely have a problem.... I'm under active attack :) However, if you choose option (a) and hard fail, then all the attacker can do is create a failure. However, if you choose option (b) then the attacker is able to cause you to connect to his server even though the domain operator is trying to serve you a DNSSEC-signed DANE record which tells you not to accept that cert (if you could only get that record). -Ekr From ekr@rtfm.com Thu May 3 15:50:04 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA57921F8740 for ; Thu, 3 May 2012 15:50:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.852 X-Spam-Level: X-Spam-Status: No, score=-102.852 tagged_above=-999 required=5 tests=[AWL=0.125, 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 F5jlRm7Qi8cn for ; Thu, 3 May 2012 15:50:04 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0F15621F873E for ; Thu, 3 May 2012 15:49:59 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so2004770vcb.31 for ; Thu, 03 May 2012 15:49:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=45MN0ohGJBlCAlGWEW7k03wJk4+UOpzAoGilzqx8F9M=; b=daj0/wUCSD3ssUnnrr+dH5umueSbhf/4UTSNO5+YnwFoQtPxhFjrqKWPAYmb5kgEl5 8Q9inAALGFPAddpgbDP1DLSOpWCG2qKPQcSEQ6kvMEX6IsFY9oFrx0rJnxLBTLNfIxpR Y/F15+/MKSLzSsntb3+eWurYXZe3gYHa7zI7vM1SkFP4miwLP+cjlPc84Kygs1g89Tdz OhGO7/T/bZcV4/DIpH2y4SOqWn/wVYoZvPg5hzR1US7aoWLHKHUMm75ocsQn7c8n7YRZ 8+20hwpOaUnGQrVxGXAaDrOuAXhoM6dRnibHbpwv7iVmI6wfIemJ7waDp357JC/9087g DrMw== Received: by 10.52.172.194 with SMTP id be2mr1829416vdc.60.1336085399588; Thu, 03 May 2012 15:49:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.19.233 with HTTP; Thu, 3 May 2012 15:49:19 -0700 (PDT) X-Originating-IP: [74.95.2.169] In-Reply-To: References: <0526D60A-3F1B-4C55-9796-256BC2556AAB@vpnc.org> From: Eric Rescorla Date: Thu, 3 May 2012 15:49:19 -0700 Message-ID: To: Paul Wouters Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkxcnQu9792S8oY3dCGNLOm/hj3lgF50aUnbdrqjKTf2sEkvZDCFG5rmqJqJec+J1HW5gzQ Cc: Paul Hoffman , IETF DANE WG list Subject: Re: [dane] Behavior in the face of no answer? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 03 May 2012 22:50:05 -0000 On Thu, May 3, 2012 at 3:45 PM, Paul Wouters wrote: > On Thu, 3 May 2012, Paul Hoffman wrote: > A response with no data, where there is a DNSSEC chain of trust, is > per definition bogus, as your response, even for 'no data' has to come > with the signed proof (NSEC/NSEC3) > > I would just leave out "or the response has no data" I should probably mention that the analysis I am offering applies to any other non-cryptographically verifiable error case, such as ICMP errors, unverifiable SERVFAILs, etc. It's not clear to me if these are all treated as Bogus but in this context I claim they must be. -Ekr From mrex@sap.com Thu May 3 16:03:43 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0ABA11E8080 for ; Thu, 3 May 2012 16:03:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.123 X-Spam-Level: X-Spam-Status: No, score=-10.123 tagged_above=-999 required=5 tests=[AWL=0.126, 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 q2i8yKDNEToY for ; Thu, 3 May 2012 16:03:43 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 0AFEB11E8079 for ; Thu, 3 May 2012 16:03:42 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q43N3aVH025855 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 4 May 2012 01:03:41 +0200 (MEST) From: Martin Rex Message-Id: <201205032303.q43N3ZB7009975@fs4113.wdf.sap.corp> To: ekr@rtfm.com (Eric Rescorla) Date: Fri, 4 May 2012 01:03:35 +0200 (MEST) In-Reply-To: from "Eric Rescorla" at May 3, 12 03:49:19 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: paul@nohats.ca, paul.hoffman@vpnc.org, dane@ietf.org Subject: Re: [dane] Behavior in the face of no answer? 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, 03 May 2012 23:03:43 -0000 Eric Rescorla wrote: > > On Thu, May 3, 2012 at 3:45 PM, Paul Wouters wrote: > > On Thu, 3 May 2012, Paul Hoffman wrote: > > A response with no data, where there is a DNSSEC chain of trust, is > > per definition bogus, as your response, even for 'no data' has to come > > with the signed proof (NSEC/NSEC3) > > > > I would just leave out "or the response has no data" > > I should probably mention that the analysis I am offering applies to any > other non-cryptographically verifiable error case, such as ICMP > errors, unverifiable SERVFAILs, etc. It's not clear to me if these > are all treated as Bogus but in this context I claim they must > be. While I do agree with your analysis, I'm inclined to believe that an unconditional hard-fail is as realistic for DANE as a hard-fail is for OCSP response failures. A non-marginal number of TLS clients (WinXP using MSIE) is IMHO not even attempting OCSP lookups at all. And while I personally use FF 3.6, I have OCSP purposely disabled and Certificate Patrol installed. The difficulty with DNSSEC is that there are many firewalled networks with either private DNS universes as well as NATed networks with DHCP and local, DNSSEC-unaware recurive DNS resolvers, where a DANE hard-fail approach might result in severe usability issues. Is there any reliable data on the availability of 100% correctness of DNSSEC records from places with full&transparent internet connectivity to DNSSEC-capable recursive DNS resolvers? -Martin From paul.hoffman@vpnc.org Thu May 3 16:11:53 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDC3121F8603 for ; Thu, 3 May 2012 16:11:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.547 X-Spam-Level: X-Spam-Status: No, score=-102.547 tagged_above=-999 required=5 tests=[AWL=0.052, 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 L4tYl0p-vLzJ for ; Thu, 3 May 2012 16:11:53 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 1759821F85D2 for ; Thu, 3 May 2012 16:11:53 -0700 (PDT) Received: from [10.20.30.102] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q43NBpNV083065 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 3 May 2012 16:11:52 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Thu, 3 May 2012 16:11:51 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0526D60A-3F1B-4C55-9796-256BC2556AAB@vpnc.org> To: Paul Wouters X-Mailer: Apple Mail (2.1257) Cc: IETF DANE WG list Subject: Re: [dane] Behavior in the face of no answer? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 03 May 2012 23:11:53 -0000 On May 3, 2012, at 3:45 PM, Paul Wouters wrote: > On Thu, 3 May 2012, Paul Hoffman wrote: >=20 >>> =46rom the earlier thread on this topic, I do not think there is = "wide agreement" on what is and is not bogus. RFC 4033 and 4035 don't = even agree about it. >>=20 >> Just because I like actual proposals for text, I believe what ekr is = proposing is changing the current: >> o If the DNSSEC validation state on the response to the request for >> the TLSA RRset is bogus, this MUST cause TLS not to be started = or, >> if the TLS negotiation is already in progress, MUST cause the >> connection to be aborted. >> to: >> o If the DNSSEC validation state on the response to the request for >> the TLSA RRset is bogus, or if a response is not received or the >> response has no data, this MUST cause TLS not to be started or, >> if the TLS negotiation is already in progress, MUST cause the >> connection to be aborted. >=20 > I'm not sure I understand "has no data" in the context of DNSSEC with > a validation path (eg DS at the parent). A response of SERVFAIL is a response, and it has no data in it. > A response with no data, where there is a DNSSEC chain of trust, is > per definition bogus, as your response, even for 'no data' has to come > with the signed proof (NSEC/NSEC3) That is a reasonable interpretation. Can you point to somewhere in = 4033-5 where it says that clearly? > I would just leave out "or the response has no data" I would like to as well, but I think the text above reflects ekr's = problem statement. --Paul Hoffman From marka@isc.org Thu May 3 16:17:29 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DCEF21F86E4 for ; Thu, 3 May 2012 16:17:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.51 X-Spam-Level: X-Spam-Status: No, score=-2.51 tagged_above=-999 required=5 tests=[AWL=0.089, 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 T7oYLP-QdHj3 for ; Thu, 3 May 2012 16:17:28 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id AC0A921F86E2 for ; Thu, 3 May 2012 16:17:28 -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 "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS id 1076DC98B8; Thu, 3 May 2012 23:17:15 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:ada5:f16c:1a15:3716]) (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 9B1B9216C31; Thu, 3 May 2012 23:17:14 +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 1EA8C206345B; Fri, 4 May 2012 09:17:09 +1000 (EST) To: Peter Saint-Andre From: Mark Andrews References: <4F95CA0B.8050202@stpeter.im> <4F9F4DEE.1090309@stpeter.im> <20120501040138.GA25922@odin.ulthar.us> <4F9F6236.3050303@stpeter.im> <05746AE2-AAA4-496E-A92D-C6826FD27F18@nic.cz> <4FA2D580.6020700@stpeter.im> In-reply-to: Your message of "Thu, 03 May 2012 12:59:12 CST." <4FA2D580.6020700@stpeter.im> Date: Fri, 04 May 2012 09:17:08 +1000 Message-Id: <20120503231709.1EA8C206345B@drugs.dv.isc.org> Cc: dane@ietf.org Subject: Re: [dane] Terminology 'whitespace' (Was: AppsDir review of draft-ietf-dane-protocol-19) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 03 May 2012 23:17:29 -0000 In message <4FA2D580.6020700@stpeter.im>, Peter Saint-Andre writes: > On 5/3/12 8:34 AM, Ondřej Surý wrote: > > On 1. 5. 2012, at 6:10, Peter Saint-Andre wrote: > >>>>> 4. In Section 2.2, the term "whitespace" is underspecified. Does > >>>>> that include, say, any Unicode space separator (Unicode General > >>>>> Category Zs) or also line separators (Unicode General Category Zl) > >>>>> or only certain code points in the ASCII range? Further, is the > >>>>> whitespace significant in the examples from Section 2.3? > >>>> > >>>> I see no change in -20 to clarify this matter. > >>> > >>> RFC 1035 (normative reference of RFC 4034, which is a normative > >>> reference of this draft), section 5 defines the format for zone files > >>> ("Master files" in RFC 1035). That RFC predates Unicode and IDN, and > >>> doesn't appear to be updated by any RFC spelling out use of Unicode in > >>> zone files. > >>> > >>> Based on that, I'd say that zone files are still ASCII-only (and a > quick > >>> web search seems to confirm that that is the case, though I don't see > >>> any harm in adhering to the robustness principle here). At any rate, > >>> the definition of the TLSA presentation format and examples in this > >>> draft seem consistent with RFC 1035 and the definition for other RR > >>> types. > >> > >> Does whitespace include tab, linefeed, etc., or only SP (ASCII 20)? It > >> really ought to be easy to clarify the matter. Just saying "whitespace" > >> is less than clear, IMHO. > > > > Unfortunatelly we are again in the field of DNS archaeology, and there > is > > no clear definition of 'whitespace', but it is widely used everywhere, > see: > > > > http://tools.ietf.org/html/rfc4034#section-2.2 > > > > The Public Key field MUST be represented as a Base64 encoding of the > > Public Key. Whitespace is allowed within the Base64 text. For a > > definition of Base64 encoding, see [RFC3548]. > > > > This probably needs fixing (rewriting RFC1034/1035 with more up-to-date > > RFC language), but definitely not here. > > Ahoj Ondřej, > > I'm not familiar with DNS archeology, but if the implicit definition of > 'whitespace' is common knowledge in the DNS community, then I think it's > fine to leave it undefined here as well. > > Peter As a DNS developer, master files are still all ascii. DNS records are line orientated unless you signal that the record is spread over multiple line by using a set of brackets. Whitespace is tab + space and eol if multiline. ";" introduces a comment which goes to end of line. Not all parsers permit brackets anywhere. Good: example.net. 600 SOA ( ns1.example.net. hostmaster.example.net. 2012150500 ; serial 3600 ; refresh 1200 ; retry 1209600 ; expire 1200 ) ; negative ttl example.net. 600 SOA ns1.example.net. hostmaster.example.net. ( 2012150500 ; serial 3600 ; refresh 1200 ; retry 1209600 ; expire 1200 ) ; negative ttl example.net. 600 SOA ns1.example.net. hostmaster.example.net. 2012150500 3600 1200 1209600 1200 ; the soa record example.net. 600 SOA ( ns1.example.net. hostmaster.example.net. 2012150500 3600 1200 1209600 1200 ) ; the soa record Bad (two lines): example.net. 600 SOA ns1.example.net. hostmaster.example.net. 2012150500 3600 1200 1209600 1200 > -- > Peter Saint-Andre > https://stpeter.im/ > > > _______________________________________________ > 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 paul@nohats.ca Thu May 3 16:25:39 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5764221F8711 for ; Thu, 3 May 2012 16:25:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.527 X-Spam-Level: X-Spam-Status: No, score=-0.527 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HOST_MISMATCH_COM=0.311, RDNS_DYNAMIC=0.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 IBiW-neIyHNk for ; Thu, 3 May 2012 16:25:38 -0700 (PDT) Received: from letoams.cypherpunks.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) by ietfa.amsl.com (Postfix) with ESMTP id C408E21F870F for ; Thu, 3 May 2012 16:25:38 -0700 (PDT) Received: by letoams.cypherpunks.ca (Postfix, from userid 500) id A8DC7855F6; Thu, 3 May 2012 19:25:37 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by letoams.cypherpunks.ca (Postfix) with ESMTP id 9EBF7803A3; Thu, 3 May 2012 19:25:37 -0400 (EDT) Date: Thu, 3 May 2012 19:25:37 -0400 (EDT) From: Paul Wouters To: Martin Rex In-Reply-To: <201205032303.q43N3ZB7009975@fs4113.wdf.sap.corp> Message-ID: References: <201205032303.q43N3ZB7009975@fs4113.wdf.sap.corp> User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dane@ietf.org Subject: Re: [dane] Behavior in the face of no answer? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 03 May 2012 23:25:39 -0000 On Fri, 4 May 2012, Martin Rex wrote: > Is there any reliable data on the availability of 100% correctness > of DNSSEC records from places with full&transparent internet > connectivity to DNSSEC-capable recursive DNS resolvers? I've been running my laptop with dnssec-trigger+unbound for a long time now, and it is pretty good. There are some networks where DNS is too broken, but the port 80 or tls443 fallback via unbound to trusted fedoraproject.org resolvers is working remarkably well to even getadnssec data on those networks - though at times the dns over tls is too slow and the website gives an error. However, some more automation and userfriendliness on the hotspot handling is needed. Paul From marka@isc.org Thu May 3 17:02:52 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 918D421F867A; Thu, 3 May 2012 17:02:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.364 X-Spam-Level: X-Spam-Status: No, score=-2.364 tagged_above=-999 required=5 tests=[AWL=-0.065, 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 3YJhGzie+q9j; Thu, 3 May 2012 17:02: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 1A51521F864F; Thu, 3 May 2012 17:02: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 "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id E06955F9A09; Fri, 4 May 2012 00:02:37 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:ada5:f16c:1a15:3716]) (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 2D496216C33; Fri, 4 May 2012 00:02:35 +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 0F9632063979; Fri, 4 May 2012 10:02:20 +1000 (EST) To: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= From: Mark Andrews References: <201204301353.q3UDrb2I007118@fs4113.wdf.sap.corp> <9D005ED4-61DE-4CFF-8136-8AD5E30F66DB@kirei.se> <4874649B-01B4-4642-A3C0-F4CDFE87C85B@nic.cz> <9CB47D95-DF49-4B4A-875B-E2EED9E626A7@bbn.com> In-reply-to: Your message of "Thu, 03 May 2012 17:58:54 +0200." Date: Fri, 04 May 2012 10:02:19 +1000 Message-Id: <20120504000220.0F9632063979@drugs.dv.isc.org> Cc: The IESG , apps-discuss@ietf.org, IETF DANE WG list Subject: Re: [dane] MX and DANE (Was: AppsDir review of draft-ietf-dane-protocol-19) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 04 May 2012 00:02:52 -0000 In message , =?utf-8?Q?Ond=C5=99ej _Sur=C3=BD?= writes: > On 3. 5. 2012, at 17:25, Richard L. Barnes wrote: > > Oh, this discussion again. > > No, it's _not_ that discussion again. I wanted to say that we > don't _want_ to discuss and fix it in the DANE WG. Somebody fix > it elsewhere and come back. While this isn't be a issue for DANE, DANE actually *removes* the last known threat, downgrade by filtering/not offering STARTTLS from the EHLO response, to making MX and STARTTLS work globally as it provides a method to signal that TLS should be available and as a consequence you should see a STARTTLS. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From marka@isc.org Thu May 3 17:20:43 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2B7221F86A8 for ; Thu, 3 May 2012 17:20:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.761 X-Spam-Level: X-Spam-Status: No, score=-0.761 tagged_above=-999 required=5 tests=[AWL=-1.662, BAYES_50=0.001, 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 jE0sO8Li9Tso for ; Thu, 3 May 2012 17:20:43 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 1F8CE21F86A5 for ; Thu, 3 May 2012 17:20:43 -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 "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS id D97CEC97D1; Fri, 4 May 2012 00:20:26 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:ada5:f16c:1a15:3716]) (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 9B837216C3B; Fri, 4 May 2012 00:20:26 +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 70A712063DA5; Fri, 4 May 2012 10:20:19 +1000 (EST) To: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= From: Mark Andrews References: <201204121730.q3CHUZcF021835@new.toad.com> <6.2.5.6.2.20120412104202.09ab2338@resistor.net> <6.2.5.6.2.20120412141224.09b64f08@resistor.net> <20120413004711.8C3EA1FA8165@drugs.dv.isc.org> <20120413005804.A93D41FA834E@drugs.dv.isc.org> <0CE0B896-670C-4591-9D74-8039C6DEC038@nic.cz> In-reply-to: Your message of "Thu, 03 May 2012 17:52:30 +0200." <0CE0B896-670C-4591-9D74-8039C6DEC038@nic.cz> Date: Fri, 04 May 2012 10:20:19 +1000 Message-Id: <20120504002019.70A712063DA5@drugs.dv.isc.org> Cc: dane@ietf.org Subject: Re: [dane] draft-ietf-dane-protocol-19.txt typos and minor fixes X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 04 May 2012 00:20:43 -0000 In message <0CE0B896-670C-4591-9D74-8039C6DEC038@nic.cz>, =?utf-8?Q?Ond=C5=99ej _Sur=C3=BD?= writes: > On 13. 4. 2012, at 2:58, Mark Andrews wrote: > > We should recommend that tools that convert certificates to TLSA > > records "SHOULD" support emitting the record in RFC 3597 format in > > addition to TLSA presentation format. > > > I don't think this is appropriate to say in the RFC. Tools are free > to do whatever they want. If we want interoperability between tool sets it is needed. Not everything is over the wire. Sometimes you are dealing with text files as the data interchange mechanism. Requiring everything to be able to read and emit the LCD format achieves that. It doesn't have to be the default emitted but it MUST be able to be emitted. We would be negligent as software engineers if we don't do that. > We could add something like (copied from RFC4034): > > The Type Covered field is represented as an RR type mnemonic. When > the mnemonic is not known, the TYPE representation as described in > [RFC3597], Section 5, MUST be used. > > Ondrej > -- > Ond=C5=99ej Sur=C3=BD -- Chief Science Officer > ------------------------------------------- > 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 > ------------------------------------------- > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From ned.freed@mrochek.com Thu May 3 18:36:39 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B990D11E8085; Thu, 3 May 2012 18:36:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.489 X-Spam-Level: X-Spam-Status: No, score=-2.489 tagged_above=-999 required=5 tests=[AWL=0.110, 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 IJXi3MJNpiAL; Thu, 3 May 2012 18:36:38 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 4A1FE11E8073; Thu, 3 May 2012 18:36:37 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OF210DXHJK000UL2@mauve.mrochek.com>; Thu, 3 May 2012 18:36:21 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OENEYWYFI80006TF@mauve.mrochek.com>; Thu, 3 May 2012 18:36:18 -0700 (PDT) Message-id: <01OF210BT32G0006TF@mauve.mrochek.com> Date: Thu, 03 May 2012 18:16:39 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Thu, 03 May 2012 14:59:26 -0700" <07511DD9-AED9-4E67-B162-6D353C550788@vpnc.org> MIME-version: 1.0 Content-type: TEXT/PLAIN References: <4F96D157.7020504@isode.com> <4F96D21A.7080006@isode.com> <4F96D2AB.6090509@stpeter.im> <4FA2E1F2.6060406@stpeter.im> <2B6494C5-4BB1-4159-967C-483094BDC0C7@vpnc.org> <4FA2FB94.204@stpeter.im> <07511DD9-AED9-4E67-B162-6D353C550788@vpnc.org> To: Paul Hoffman Cc: "apps-discuss@ietf.org Discuss" , The IESG , IETF DANE WG list Subject: Re: [dane] [apps-discuss] AppsDir review of draft-ietf-dane-protocol-19 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 04 May 2012 01:36:39 -0000 > If you believe that developers who are using IDNs are not following the > easiest-to-read section of RFC 5891, the issue is much larger than just DANE. I > propose that is not a DANE issue at all. I completely agree, but additionally, the model of trying to cover all the possible ancillary material that some developer might possibly be unaware of is simply unsustainable. Were we to attempt it, we'd end up with every specification stuff with huge amounts of "see also" material irrelevant to the specification itself. And it will cause more problems than it solves. No, the question isn't whether someone without clue is going to read this specification and miss something important. That's going to happen no matter what. Rather, the question is whether or not it is at all likely that adding a particular pointer will actually make a significant difference. I don't think this suggestion rises to that level. Consider: TLSA records appear next to A, AAAA, or CNAME records, and have to have the same names as those records (modulo wildcards). Therefore an IDN name in a TLSA record means the A/AAAA/CNAME record also has, and more likely already had, an IDN name. That in turn means that the IDN issue has already been faced/addressed. So there doesn't seem to be much value here. Of course you can come up with scenarios where different people provision the different records, or the provisioning interface has different behavior for different kinds of records, and so on and so forth. But are these scenarios likely? I don't think so. Indeed, I suspect the bigger problem will be the lack of builtin support for TLSA records in deployed nameserver software. So if you want to address the more likely deployment problem for the less than clueful, you should be arguing for a reference to something that explains how to use the arbitrary record support in the more popular nameservers. (Or alternately, we could actually look at, you know, solving the problem. See John Levine's draft.) Ned From ajs@anvilwalrusden.com Thu May 3 19:00:40 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 442EC11E8086 for ; Thu, 3 May 2012 19:00:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.635 X-Spam-Level: X-Spam-Status: No, score=-2.635 tagged_above=-999 required=5 tests=[AWL=-0.036, 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 OlBRdldIh-GR for ; Thu, 3 May 2012 19:00:39 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 572B911E8085 for ; Thu, 3 May 2012 19:00:39 -0700 (PDT) Received: from mail.yitter.info (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 505CC1ECB41C for ; Fri, 4 May 2012 02:00:38 +0000 (UTC) Date: Thu, 3 May 2012 22:00:27 -0400 From: Andrew Sullivan To: dane@ietf.org Message-ID: <20120504020027.GA4560@mail.yitter.info> References: <0526D60A-3F1B-4C55-9796-256BC2556AAB@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Behavior in the face of no answer? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 04 May 2012 02:00:40 -0000 On Thu, May 03, 2012 at 04:11:51PM -0700, Paul Hoffman wrote: > On May 3, 2012, at 3:45 PM, Paul Wouters wrote: > > > > I'm not sure I understand "has no data" in the context of DNSSEC with > > a validation path (eg DS at the parent). > > A response of SERVFAIL is a response, and it has no data in it. Aha. That's not what many people think of when they say "no data". See section 1 of RFC 2308. SERVFAIL is actually an error response. Since SERVFAIL was sort of overloaded in DNSSEC, maybe you want to call that out. But what are you going to do with things like NOTIMP, then? But I think it still may be possible to get a validated NODATA response, if you're a non-validating security-aware stub resolver and your upstream decided not to send you the NSEC or NSEC3 record, but sent you a response with AD=1, and you had a secure connection. I think this would be _stupid_, but I think it's protocol-legal. (I am not aware of any implementation that works this way. Also, I haven't checked this interpretation tonight, and am therefore prepared to be wrong.) > > A response with no data, where there is a DNSSEC chain of trust, is > > per definition bogus, as your response, even for 'no data' has to come > > with the signed proof (NSEC/NSEC3) > > That is a reasonable interpretation. Can you point to somewhere in 4033-5 where it says that clearly? > As I say above, I think it depends on whether you think a response with AD=1 and some assurances about the last hop qualify. If you don't, then Paul W is right. A -- Andrew Sullivan ajs@anvilwalrusden.com From ajs@anvilwalrusden.com Thu May 3 19:10:48 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28CBC11E8089 for ; Thu, 3 May 2012 19:10:48 -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 oKSsGfBWAcbG for ; Thu, 3 May 2012 19:10:47 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 3636911E808D for ; Thu, 3 May 2012 19:10:46 -0700 (PDT) Received: from mail.yitter.info (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 E7DA21ECB41C for ; Fri, 4 May 2012 02:10:45 +0000 (UTC) Date: Thu, 3 May 2012 22:10:44 -0400 From: Andrew Sullivan To: dane@ietf.org Message-ID: <20120504021044.GB4560@mail.yitter.info> References: <0526D60A-3F1B-4C55-9796-256BC2556AAB@vpnc.org> <20120503223745.GC1804@mail.yitter.info> 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] Behavior in the face of no answer? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 04 May 2012 02:10:48 -0000 On Thu, May 03, 2012 at 03:44:57PM -0700, Eric Rescorla wrote: > > Well, I absolutely have a problem.... I'm under active attack :) > > However, if you choose option (a) and hard fail, then all the attacker > can do is create a failure. However, if you choose option (b) then > the attacker is able to cause you to connect to his server even > though the domain operator is trying to serve you a DNSSEC-signed > DANE record which tells you not to accept that cert (if you > could only get that record). No, I think I still don't understand. Under (b), how can the attacker get you to connect to "his server"? The attacker can get you to connect to some server and foil your attempt to use the TLSA-provided credential, but how do you go to the wrong server? You can't get the A or AAAA record if the attacker is fiddling with the DNS, because that RRset will fail DNSSEC validation in the first place. Remember, we're already depending on DNSSEC. If you _can_ get the right address, then the problem is that you use the wrong certificate (i.e. you fall back to the X.509 chain)? Unless the X.509 chain is somehow subverted, though -- but how is that any more of a danger than "compromised key in TLSA"? A -- Andrew Sullivan ajs@anvilwalrusden.com From nweaver@icsi.berkeley.edu Thu May 3 19:13:52 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0C9E11E8089 for ; Thu, 3 May 2012 19:13:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.984 X-Spam-Level: X-Spam-Status: No, score=-1.984 tagged_above=-999 required=5 tests=[AWL=0.615, 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 j0o1eRKilj51 for ; Thu, 3 May 2012 19:13:52 -0700 (PDT) Received: from rock.ICSI.Berkeley.EDU (rock.ICSI.Berkeley.EDU [192.150.186.19]) by ietfa.amsl.com (Postfix) with ESMTP id 271F611E8073 for ; Thu, 3 May 2012 19:13:52 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 035E82C400D; Thu, 3 May 2012 19:13:52 -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 dB3Q6gus+86f; Thu, 3 May 2012 19:13:51 -0700 (PDT) Received: from [10.0.1.7] (c-76-103-162-14.hsd1.ca.comcast.net [76.103.162.14]) (Authenticated sender: nweaver) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 502F42C4002; Thu, 3 May 2012 19:13:51 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Nicholas Weaver In-Reply-To: <20120504021044.GB4560@mail.yitter.info> Date: Thu, 3 May 2012 19:14:33 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0526D60A-3F1B-4C55-9796-256BC2556AAB@vpnc.org> <20120503223745.GC1804@mail.yitter.info> <20120504021044.GB4560@mail.yitter.info> To: Andrew Sullivan X-Mailer: Apple Mail (2.1257) Cc: dane@ietf.org Subject: Re: [dane] Behavior in the face of no answer? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 04 May 2012 02:13:52 -0000 On May 3, 2012, at 7:10 PM, Andrew Sullivan wrote: > On Thu, May 03, 2012 at 03:44:57PM -0700, Eric Rescorla wrote: >>=20 >> Well, I absolutely have a problem.... I'm under active attack :) >>=20 >> However, if you choose option (a) and hard fail, then all the = attacker >> can do is create a failure. However, if you choose option (b) then >> the attacker is able to cause you to connect to his server even >> though the domain operator is trying to serve you a DNSSEC-signed >> DANE record which tells you not to accept that cert (if you >> could only get that record). >=20 > No, I think I still don't understand. Under (b), how can the attacker > get you to connect to "his server"? The attacker can get you to > connect to some server and foil your attempt to use the TLSA-provided > credential, but how do you go to the wrong server? >=20 > You can't get the A or AAAA record if the attacker is fiddling with > the DNS, because that RRset will fail DNSSEC validation in the first > place. Remember, we're already depending on DNSSEC. If you _can_ get > the right address, then the problem is that you use the wrong > certificate (i.e. you fall back to the X.509 chain)? Unless the X.509 > chain is somehow subverted, though -- but how is that any more of a > danger than "compromised key in TLSA"? An IN-path adversary doesn't need to manipulate the A or AAAA records to = get you to connect to their server. Since the adversaries of concern are likely to be in-path, not just = on-path, this is a serious concern and DANE when it can't get the record = it MUST hard fail lest it be useless in the face on an in-path attacker, = which is critical since the goal of all this cryptomagic is to deal with = in-path attackers. From ajs@anvilwalrusden.com Thu May 3 19:36:15 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47E5821F8595 for ; Thu, 3 May 2012 19:36:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[AWL=-0.034, 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 zOjXglY16zBP for ; Thu, 3 May 2012 19:36:14 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 6E5BC21F8594 for ; Thu, 3 May 2012 19:36:14 -0700 (PDT) Received: from mail.yitter.info (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 5A42E1ECB41C for ; Fri, 4 May 2012 02:36:13 +0000 (UTC) Date: Thu, 3 May 2012 22:36:02 -0400 From: Andrew Sullivan To: dane@ietf.org Message-ID: <20120504023602.GA4683@mail.yitter.info> References: <0526D60A-3F1B-4C55-9796-256BC2556AAB@vpnc.org> <20120503223745.GC1804@mail.yitter.info> <20120504021044.GB4560@mail.yitter.info> 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] Behavior in the face of no answer? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 04 May 2012 02:36:15 -0000 On Thu, May 03, 2012 at 07:14:33PM -0700, Nicholas Weaver wrote: > > An IN-path adversary doesn't need to manipulate the A or AAAA records to get you to connect to their server. > Ah, ok, so we're talking about someone who can both intercept and redirect your connection to a target address and block DNS responses from getting to you but who cannot re-engineer DNS responses for you (obviously, because it'd fail at the root trust anchor). Ok, now I get it. > Since the adversaries of concern are likely to be in-path, not just > on-path, this is a serious concern and DANE when it can't get the > record it MUST hard fail lest it be useless in the face on an > in-path attacker, which is critical since the goal of all this > cryptomagic is to deal with in-path attackers. Surely this is a matter of local policy? That is, it's probably a pretty good idea if it fails, and if you know what you are doing you probably want to say "fail if I can't get a TLSA response at all"; but during deployment and roll-out (as someone already argued up-thread) this is simply an unrealistic requirement: people are going to be behind broken devices for some years now, and a protocol-required hard fail requirement will either be ignored or else will delay deployment until we complete upgrading the Internet. I suggest while we are waiting for that, we might want to work on DNS2 and TLS2. If that's not enough, I'm sure we can find some more windmills. Alternatively, we could just let people fall back to the infrastructure we have. Note that there remain _plenty_ of DNS servers deployed in the wild which, if you ask them for an RRTYPE they don't know about, spit up with NOTIMP, SERVFAIL, and all manner of other crappy nonsense. (We were just having a bunfight about that over in SPFBIS a month or two ago.) Turning off TLS for anyone whose client knows about TLSA, but who is trying to go to a service offered by someone employing a broken DNS server like this, is not reasonable. Speaking as an operator, I can tell you that if the protocol says "hard fail if I don't get a TLSA answer", I will tell all my customers not to use TLSA; the alternative is to make my customers mad at me the day someone's connection from some crappy hotel network fails. I'd hate to be put in that position. A -- Andrew Sullivan ajs@anvilwalrusden.com From mrex@sap.com Thu May 3 19:42:19 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A79921F85D8 for ; Thu, 3 May 2012 19:42:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.125 X-Spam-Level: X-Spam-Status: No, score=-10.125 tagged_above=-999 required=5 tests=[AWL=0.124, 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 ft5XV2i2prMB for ; Thu, 3 May 2012 19:42:18 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id DC56021F85D3 for ; Thu, 3 May 2012 19:42:17 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q442gDQS010071 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 4 May 2012 04:42:13 +0200 (MEST) From: Martin Rex Message-Id: <201205040242.q442gDgw023732@fs4113.wdf.sap.corp> To: ajs@anvilwalrusden.com (Andrew Sullivan) Date: Fri, 4 May 2012 04:42:13 +0200 (MEST) In-Reply-To: <20120504023602.GA4683@mail.yitter.info> from "Andrew Sullivan" at May 3, 12 10:36:02 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] Behavior in the face of no answer? 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, 04 May 2012 02:42:19 -0000 Andrew Sullivan wrote: > > Note that there remain _plenty_ of DNS servers deployed in the wild > which, if you ask them for an RRTYPE they don't know about, spit up > with NOTIMP, SERVFAIL, and all manner of other crappy nonsense. You seem to be unaware that returning SERVFAIL and more so NOTIMP to requests for unknown RRTYPES is *PERFECTLY* conformant with rfc1034/rfc1035. So if anything is _broken_, its clients who can not cope with such responses (as can be seen with the IPv6 dualstack in Windows2003). -Martin From i.grok@comcast.net Thu May 3 20:12:28 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 094C121F867E for ; Thu, 3 May 2012 20:12:28 -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 G6u9iWl-8Ags for ; Thu, 3 May 2012 20:12:27 -0700 (PDT) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by ietfa.amsl.com (Postfix) with ESMTP id 0DBC821F867A for ; Thu, 3 May 2012 20:12:26 -0700 (PDT) Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by qmta04.westchester.pa.mail.comcast.net with comcast id 5fC71j0020Fqzac54fCBt8; Fri, 04 May 2012 03:12:11 +0000 Received: from odin.ulthar.us ([68.33.77.0]) by omta08.westchester.pa.mail.comcast.net with comcast id 5fCS1j00W00PQ6U3UfCSiJ; Fri, 04 May 2012 03:12:27 +0000 Received: from odin.ulthar.us (localhost [127.0.0.1]) by odin.ulthar.us (8.14.5/8.14.3) with ESMTP id q443CNVP007112 for ; Thu, 3 May 2012 23:12:23 -0400 Received: (from draco@localhost) by odin.ulthar.us (8.14.5/8.14.5/Submit) id q443CMPE007111 for dane@ietf.org; Thu, 3 May 2012 23:12:22 -0400 Date: Thu, 3 May 2012 23:12:22 -0400 From: Scott Schmit To: dane@ietf.org Message-ID: <20120504031222.GA6541@odin.ulthar.us> Mail-Followup-To: dane@ietf.org References: <201204121903.q3CJ3ucF026698@new.toad.com> <9605FDF6-096D-4159-96A6-16549E8371AB@nic.cz> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="yrj/dFKFPuw6o+aM" Content-Disposition: inline In-Reply-To: <9605FDF6-096D-4159-96A6-16549E8371AB@nic.cz> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Inappropriate Section 8 of draft-ietf-dane-protocol-19.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2012 03:12:28 -0000 --yrj/dFKFPuw6o+aM Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, May 03, 2012 at 05:47:43PM +0200, Ond=C5=99ej Sur=C3=BD wrote: > John, >=20 > you have raised this issue several times and yet I haven't seen > a supportive message from other WG members. On the other hand > Jim Schaad[1] and me have opposed your view of the issue. >=20 > 1. https://www.ietf.org/mail-archive/web/dane/current/msg04566.html >=20 > Chairs think the text is fine as it is. If the other WG members > disagree, please speak now. And again I would like to see a modified > text if you are going to support the assertion that we favor CAs > (Type 0/1). I'll express support for John's technical arguments against section 8.1. I don't have a strong position about the paragraph in section 8, but I think we can improve it by changing this: The client's full trust of a certificate retrieved from a TLSA record with a certificate usage of 2 or 3 may be a matter of local policy. While such trust is limited to the specific domain name for which the TLSA query was made, local policy may deny the trust or further restrict the conditions under which that trust is permitted. to this: Generators of TLSA records should be aware that the client's full trust of a certificate association retrieved from a TLSA record may be a matter of local policy. While such trust is limited to the specific domain name, protocol, and port for which the TLSA query was made, local policy may deny to trust the certificate (e.g., due to weak cryptography), just as with PKIX trust anchors. Rationale behind the changes: * Local policy could disable the TA or an intermediate certificate that is being used for type 0 or 1, too, though I guess you could argue that that's not new to DANE. * I'm not sure how you can meaningfully "further restrict" the conditions of use the conditions of use that isn't already applicable to PKIX. DANE already restricts conditions of use to the name/proto/port tuple. * One of the defenses of the paragraph was that clients can already disable PKIX trust anchors, so I made that comparison explicit. This seems to be more accurate, at the least, and may be more acceptable to John. As for section 8.1, I agree that it's incorrect technically. Martin Rex has also expressed agreement: https://www.ietf.org/mail-archive/web/dane/current/msg04649.html I didn't chime in at the time because I assumed that John and Martin's technical arguments made the case adequately that section 8.1 makes an invalid comparison--but evidentally not, so I'll throw my arguments into the ring: The more-direct parallel to be drawn between CAs and DANE is the DNSSEC signing chain itself -- the DS + KSK DNSKEY records for a domain form the equivalent of a name-constrained PKIX CA certificate, and ZSK DNSKEY records are equivalent to PKIX self-issued certificates. (Where "certificate" is defined as a binding of a name and a key. Obviously, PKIX certificates allow significantly more information to be included into the signed content.) TLSA records are like name-constrained PKIX certificates as well (though bound to a specific protocol/port, which I'm not sure if PKIX can do). Despite this, Section 8.1 compares PKIX CAs to external DNSSEC validators. That's not unlike comparing DNSSEC records to web browser PKIX certificate validation software (though at least web browsers run on the same machine). IIUC, section 8.1 was added to compare the risks of the PKIX CA security model as typically implemented (large trust anchor list) to DANE, but IMHO fails to do so for the reasons stated above. To be charitable, perhaps it was thought that external validation is how DNSSEC is typically implemented today, so it makes for a fair comparison. That said, with DANE, the client can simply eliminate all of the risks of external validation on the DANE side of the comparison by being implemented differently. The same cannot be said, in practice, for PKIX CAs. One could make the comparison to a compromise of .com's DNSKEYs, but section 8.1 doesn't even address that risk. If the above, and the technical arguments from John and Martin remain unconvincing, I'd like you to please explain your position. If you accept the above, the next question is what to replace it with. I think this outline covers the ground: * The risk of compromise * Number of keys that can be compromised to achieve the desired effect * Likelihood of being a target of attack * Security measures in place to prevent attack success (HSM, access to key, authentication of data to be signed) * Qualifications/experience of people securing the keys * ...Other?? * The impact of such a compromise (#s of names affected) * The likelihood of detection * ...Other?? I could propose some text to flesh out the outline (except the "other"s, as I don't know what they are yet :-) ), but before I start, I'd like to know that I wouldn't be wasting my time. --=20 Scott Schmit --yrj/dFKFPuw6o+aM Content-Type: application/x-pkcs7-signature Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIIQJgYJKoZIhvcNAQcCoIIQFzCCEBMCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC DVcwggY0MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAe Fw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0 ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEp pC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9 b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54q zHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX 9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/ 4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8E BTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIw HwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wu Y29tL3Nmc2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIB FiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4IC AQAKgwh9eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8py TUnFsukDFUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMm CeUTyMyikfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIz uQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVm z/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT 5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lAp sbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076 khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8 J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRX un0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCBxswggYDoAMCAQICAwK+HTANBgkqhkiG 9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTExMDcxNzA1 MDQwNFoXDTEyMDcxNzExNDI1OVowYjEgMB4GA1UEDRMXNDY1MjU2LTBnRmI2Sk5ZWW44QnFW bUwxGzAZBgNVBAMMEmkuZ3Jva0Bjb21jYXN0Lm5ldDEhMB8GCSqGSIb3DQEJARYSaS5ncm9r QGNvbWNhc3QubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2AjLOMsBGaqN hv2FcRbfom/QCeKMXu5tUd1JY5oIDZe5y29stnd+se/zUlEkiVeMam4Jgo1c8yGNnwLVYc5/ 9xVi7Qg1Is5b9AB6aJWElJDw/jIdihymNZ2kwkSLT0wl/lzd0mXlwFJPRgQiRkmE6V0ZmjsQ jaVtllVleGBbMvmWPm92e+4Bju9P81kKz7Xr02ijETmaPdVsl+jmOaKPS8Y+2Lat2xus4Ked oJ/7aIWIpz1gRSKjAHSZ1Wmwi2TYUjYhZryChu9e1RWtqk1CycNoeusJ8xdEVN3WSnJ299w/ 3ltK/x/9rpj2j9ShQZVB4NnX6cjQs7pz1lVxvIkjcQIDAQABo4IDrTCCA6kwCQYDVR0TBAIw ADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQW BBQ29j2I0O8sRYi0So9NwwmT1caakDAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhR gjAdBgNVHREEFjAUgRJpLmdyb2tAY29tY2FzdC5uZXQwggIhBgNVHSAEggIYMIICFDCCAhAG CysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20v cG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJt ZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcg dG8gdGhlIENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4g Y29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUF BwICMIGPMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJp bGl0eSBhbmQgd2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFu ZCBMaW1pdGF0aW9ucyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAr oCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUH AQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFz czEvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0 cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQAZ5U0nL/2PQwsVfHgN7MVPbZEGzDzuj4Oy pTgz4XQFwPcCuy6U9sp1Dwmo3DyKX5nKN4xA7pslN+2Pl/kElGamX7zMCAH0xED0RTOLyk+v nDML4s+OUtWaYVnq1bZEp0F8Luq3zIslAYSebleyiz8M0EypZczsL5rOk86R2F9EYw1CBuFJ 5a4x0CmNu5o30fGNDFt+iXRlbJPp/KY25iUgVnBzJ4COT5kQjxn5lgr4t1I+BDCL5HQQ3h/8 2CzwrWVRBNb9Vqh9LL1ZtzYRt8JezoB6HkVvcKVNGlCZ+/MnvfMzPLwfbTDZC8o4d+4RH6aE LeGF2XmAOaenc/YRqm9oMYIClzCCApMCAQEwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQQIDAr4dMAkGBSsOAwIaBQCggdgwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTIwNTA0MDMxMjIyWjAjBgkqhkiG9w0BCQQxFgQU86R3y4DY tBI60Or87onGQTilIZgweQYJKoZIhvcNAQkPMWwwajALBglghkgBZQMEASowCwYJYIZIAWUD BAEWMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAwwjyTJ4O 0RxAqCXnYbyaPZoXheN/n360XL7iIQ/DUbdYcoLPfaLvvf/KIqM/LT6v7NxFfVb6+UNg2nfh g1tXJy1rfHXxc2ji4OJbijbPbMYwUjKfCzo+kLZ5kZOMabeP7P4s1qvrGGw2ThhrwosP1Nfb J3UHUGMFDr3VLlrO/0SCPK45Hp5rXrNPItpWWR40r5eNvunzAVvsy5WA5ov31/mQm/laMYm3 81UW9J687aTPO8nwBtvOlugcd1UkvYbKUCI+J4FEHIhx018+wjcxp+4oeDXzk6n7rhOldsa8 gLmCZCAN2DcNaeBOvK2D9aVTLVhihYjGInNo5UiRlZIxSw== --yrj/dFKFPuw6o+aM-- From ekr@rtfm.com Thu May 3 20:19:25 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3725711E8073 for ; Thu, 3 May 2012 20:19:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.858 X-Spam-Level: X-Spam-Status: No, score=-102.858 tagged_above=-999 required=5 tests=[AWL=0.119, 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 GkocKtTMox9L for ; Thu, 3 May 2012 20:19:24 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 76CB821F867A for ; Thu, 3 May 2012 20:19:24 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so2119293vcb.31 for ; Thu, 03 May 2012 20:19:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=SqKSzJOIahZOAOgLT1S/9FHVdmQL+VjaPlnlG5+O68E=; b=VBtz3qZKfrmLItv6QGLrMw0sNuEe6Un1vLPatckd6SorWgFbOVXHqK03KzZfjJDIn3 v6VbqzCDikBFk7BT8r6Vr0ABvnXomwyRvFiBzfpIOlKW3YjtvJ/z+eNsT6GFm+Z1se// EWUflKi8Hn9Za/TdtcRXq1SQYPXhCaJhSd1v9L5BMm1ScF/K+QgDMNW/lo0LbXZl+rl+ RIJfTeTZI75g+0c99QmBm9TnJoRX08pCym6YoI3GdofRkojGCRYpkihZcSOujpXu3fa9 WfHqGB+pG7FOi/run4z4oGDF7Nv2lVDYg7N8bQoQBZX34kCE3OtwZjW93hEazElHKPPu zcEw== Received: by 10.52.70.209 with SMTP id o17mr258145vdu.11.1336101563986; Thu, 03 May 2012 20:19:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.19.233 with HTTP; Thu, 3 May 2012 20:18:41 -0700 (PDT) X-Originating-IP: [74.95.2.169] In-Reply-To: <20120504023602.GA4683@mail.yitter.info> References: <0526D60A-3F1B-4C55-9796-256BC2556AAB@vpnc.org> <20120503223745.GC1804@mail.yitter.info> <20120504021044.GB4560@mail.yitter.info> <20120504023602.GA4683@mail.yitter.info> From: Eric Rescorla Date: Thu, 3 May 2012 20:18:41 -0700 Message-ID: To: Andrew Sullivan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmffuorQuA2tJBGxRL5Oh/9aLuAWBPuHUcl3V0TsUL8YmKPJgKwlhiB3z+lvecUu4b+9gtR Cc: dane@ietf.org Subject: Re: [dane] Behavior in the face of no answer? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 04 May 2012 03:19:25 -0000 On Thu, May 3, 2012 at 7:36 PM, Andrew Sullivan wr= ote: > On Thu, May 03, 2012 at 07:14:33PM -0700, Nicholas Weaver wrote: >> >> An IN-path adversary doesn't need to manipulate the A or AAAA records to= get you to connect to their server. >> > > Ah, ok, so we're talking about someone who can both intercept and > redirect your connection to a target address and block DNS responses > from getting to you but who cannot re-engineer DNS responses for you > (obviously, because it'd fail at the root trust anchor). =A0Ok, now I > get it. Yes, this seems like the only threat model of real concern here, since if you are dealing with an attacker who cannot do this, then there is no need to authenticate their cryptographic keys at all: you can just use unauthenticated DH (or RSA) key exchange. >> Since the adversaries of concern are likely to be in-path, not just >> on-path, this is a serious concern and DANE when it can't get the >> record it MUST hard fail lest it be useless in the face on an >> in-path attacker, which is critical since the goal of all this >> cryptomagic is to deal with in-path attackers. > > Surely this is a matter of local policy? =A0That is, it's probably a > pretty good idea if it fails, and if you know what you are doing you > probably want to say "fail if I can't get a TLSA response at all"; but > during deployment and roll-out (as someone already argued up-thread) > this is simply an unrealistic requirement: people are going to be > behind broken devices for some years now, and a protocol-required hard > fail requirement will either be ignored or else will delay deployment > until we complete upgrading the Internet. =A0I suggest while we are > waiting for that, we might want to work on DNS2 and TLS2. =A0If that's > not enough, I'm sure we can find some more windmills. =A0Alternatively, > we could just let people fall back to the infrastructure we have. > > Note that there remain _plenty_ of DNS servers deployed in the wild > which, if you ask them for an RRTYPE they don't know about, spit up > with NOTIMP, SERVFAIL, and all manner of other crappy nonsense. =A0(We > were just having a bunfight about that over in SPFBIS a month or two > ago.) =A0Turning off TLS for anyone whose client knows about TLSA, but > who is trying to go to a service offered by someone employing a broken > DNS server like this, is not reasonable. > > Speaking as an operator, I can tell you that if the protocol says > "hard fail if I don't get a TLSA answer", I will tell all my customers > not to use TLSA; the alternative is to make my customers mad at me the > day someone's connection from some crappy hotel network fails. =A0I'd > hate to be put in that position. While I understand that these operational constraints, I'm having trouble understanding what security benefit DANE offers if one behaves as you suggest, since it seems the attacker can simply force you to ignore any records that DANE provides. Perhaps it would be useful to go back to first principles and ask about the threat model. Can you describe a set of capabilities which would allow successful attack on TLS in the current environment but would not allow attack with DANE if TLSA nonresponse for signed domains is treated as if there are verifiably no TLSA records? Thanks, -Ekr From ajs@anvilwalrusden.com Fri May 4 04:20:48 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1409321F871A for ; Fri, 4 May 2012 04:20:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[AWL=-0.034, 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 FAo+hHpHBnSO for ; Fri, 4 May 2012 04:20:47 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 4547E21F86E4 for ; Fri, 4 May 2012 04:20:46 -0700 (PDT) Received: from mail.yitter.info (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 960FF1ECB41C for ; Fri, 4 May 2012 11:20:45 +0000 (UTC) Date: Fri, 4 May 2012 07:20:42 -0400 From: Andrew Sullivan To: dane@ietf.org Message-ID: <20120504112015.GA4929@mail.yitter.info> References: <20120504023602.GA4683@mail.yitter.info> <201205040242.q442gDgw023732@fs4113.wdf.sap.corp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201205040242.q442gDgw023732@fs4113.wdf.sap.corp> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Behavior in the face of no answer? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 04 May 2012 11:20:48 -0000 On Fri, May 04, 2012 at 04:42:13AM +0200, Martin Rex wrote: > Andrew Sullivan wrote: > > > > Note that there remain _plenty_ of DNS servers deployed in the wild > > which, if you ask them for an RRTYPE they don't know about, spit up > > with NOTIMP, SERVFAIL, and all manner of other crappy nonsense. > > You seem to be unaware that returning SERVFAIL and more so NOTIMP > to requests for unknown RRTYPES is *PERFECTLY* conformant with > rfc1034/rfc1035. So if anything is _broken_, its clients who can > not cope with such responses (as can be seen with the IPv6 dualstack > in Windows2003). I'm not unaware of this (although I think there is rather less consensus about the correctness of those RCODE responses than you seem to be suggesting). I just think it's crappy. RFC 3597 was published in 2003. There is no excuse any more for a server of any sort to be incapable of handling unknown RRTYPEs. I get the arguments about provisioning systems, and I think they're real problems. But by now, if your _server_ doesn't handle unknown RRTYPEs it is plainly garbage, and ought to be off the Net. The fundamental problem, of course, is that people who are told to go develop a DNS server in a weekend read RFC 1034 and RFC 1035 -- usually selectively, it appears to me -- and nothing else. I wish I had a good idea about what to do about this. (That's all I'll say about it here, though, because it's plainly off-topic.) Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From ajs@anvilwalrusden.com Fri May 4 04:29:19 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 047A321F871C for ; Fri, 4 May 2012 04:29:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[AWL=-0.033, 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 07TeLeaASUKJ for ; Fri, 4 May 2012 04:29:18 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 6386121F871A for ; Fri, 4 May 2012 04:29:18 -0700 (PDT) Received: from mail.yitter.info (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 512591ECB41C for ; Fri, 4 May 2012 11:29:17 +0000 (UTC) Date: Fri, 4 May 2012 07:29:22 -0400 From: Andrew Sullivan To: dane@ietf.org Message-ID: <20120504112922.GB4929@mail.yitter.info> References: <0526D60A-3F1B-4C55-9796-256BC2556AAB@vpnc.org> <20120503223745.GC1804@mail.yitter.info> <20120504021044.GB4560@mail.yitter.info> <20120504023602.GA4683@mail.yitter.info> 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] Behavior in the face of no answer? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 04 May 2012 11:29:19 -0000 On Thu, May 03, 2012 at 08:18:41PM -0700, Eric Rescorla wrote: > > While I understand that these operational constraints, I'm having > trouble understanding what security benefit DANE offers if one behaves > as you suggest, since it seems the attacker can simply force you to > ignore any records that DANE provides. As a client, you could be making a decision about what is more likely: 1. The attacker is able to undermine some CA. 2. The attacker is actually on-path and going to undermine my connection. In many cases, one might decide that (1) is more likely than (2), and therefore decide that TLSA is a better thing to rely on. During deployment, however, one might be willing to think that (1) is less likely than, "I am in a coffee shop, and these people bought crappy infrastructure." In that case, one might want to be able to fall back to the way we actually do this today. I imagine that, over time, the tolerance for the broken infrastructure will go down, and the fall-back decision will be less and less attractive. But if the protocol says that once a client supports TLSA, any not-fully-modern DNS environment just means "no TLS", then we will be promulgating a standard that cannot be deployed. We might as well not publish it. A -- Andrew Sullivan ajs@anvilwalrusden.com From nweaver@icsi.berkeley.edu Fri May 4 05:12:56 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C8C721F8638 for ; Fri, 4 May 2012 05:12:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.189 X-Spam-Level: X-Spam-Status: No, score=-2.189 tagged_above=-999 required=5 tests=[AWL=0.410, 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 hJEH9Cni1noh for ; Fri, 4 May 2012 05:12:55 -0700 (PDT) Received: from rock.ICSI.Berkeley.EDU (rock.ICSI.Berkeley.EDU [192.150.186.19]) by ietfa.amsl.com (Postfix) with ESMTP id BE79121F8637 for ; Fri, 4 May 2012 05:12:55 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 7F65A2C400E; Fri, 4 May 2012 05:12:55 -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 OycpYu+d3a81; Fri, 4 May 2012 05:12:55 -0700 (PDT) Received: from [10.0.1.7] (c-76-103-162-14.hsd1.ca.comcast.net [76.103.162.14]) (Authenticated sender: nweaver) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 248D12C4002; Fri, 4 May 2012 05:12:55 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Nicholas Weaver In-Reply-To: <20120504112922.GB4929@mail.yitter.info> Date: Fri, 4 May 2012 05:12:54 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <2DDB5448-6A34-4D68-9421-4505CCC71A1A@icsi.berkeley.edu> References: <0526D60A-3F1B-4C55-9796-256BC2556AAB@vpnc.org> <20120503223745.GC1804@mail.yitter.info> <20120504021044.GB4560@mail.yitter.info> <20120504023602.GA4683@mail.yitter.info> <20120504112922.GB4929@mail.yitter.info> To: Andrew Sullivan X-Mailer: Apple Mail (2.1257) Cc: dane@ietf.org Subject: Re: [dane] Behavior in the face of no answer? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 04 May 2012 12:12:56 -0000 On May 4, 2012, at 4:29 AM, Andrew Sullivan wrote: > On Thu, May 03, 2012 at 08:18:41PM -0700, Eric Rescorla wrote: >>=20 >> While I understand that these operational constraints, I'm having >> trouble understanding what security benefit DANE offers if one = behaves >> as you suggest, since it seems the attacker can simply force you to >> ignore any records that DANE provides. >=20 > As a client, you could be making a decision about what is more likely: >=20 > 1. The attacker is able to undermine some CA. >=20 > 2. The attacker is actually on-path and going to undermine my > connection. =20 Since the attacker is often a government, its 1+2. For a CA attack to = be useful, you probably need 1+2, as without 2 you still need to be able = to get the victim to go to your site which, even in the absence of = DNSSEC, requires being an on-path attacker in most circumstances. A CA attack without effectively 2 is useless. This is why browser's have given up on the other solution for the bad CA = problem: Certificate Revocation Lists. Because an attacker can block = the CRL check, and the CRL check is NOT mandatory (they are unreliable = enough that its not treated as a hard fail), CRLs are useless for = blocking attackers. > I imagine that, over time, the tolerance for the broken infrastructure > will go down, and the fall-back decision will be less and less > attractive. But if the protocol says that once a client supports > TLSA, any not-fully-modern DNS environment just means "no TLS", then > we will be promulgating a standard that cannot be deployed. We might > as well not publish it. DNSSEC at all requires client validation, and client validation REQUIRES = that the client be able to bypass the significant-probability-broken = recursive resolver already. DANE doesn't really add to that: If the = client can fetch DNSSEC signed records, TLSA won't be a problem. From ajs@anvilwalrusden.com Fri May 4 06:08:59 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0540921F85B6 for ; Fri, 4 May 2012 06:08:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[AWL=-0.033, 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 93ZY4a7bcqHB for ; Fri, 4 May 2012 06:08:58 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 78D1E21F85A5 for ; Fri, 4 May 2012 06:08:58 -0700 (PDT) Received: from mail.yitter.info (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 5E4E81ECB41C for ; Fri, 4 May 2012 13:08:48 +0000 (UTC) Date: Fri, 4 May 2012 09:08:46 -0400 From: Andrew Sullivan To: dane@ietf.org Message-ID: <20120504130846.GC4929@mail.yitter.info> References: <0526D60A-3F1B-4C55-9796-256BC2556AAB@vpnc.org> <20120503223745.GC1804@mail.yitter.info> <20120504021044.GB4560@mail.yitter.info> <20120504023602.GA4683@mail.yitter.info> <20120504112922.GB4929@mail.yitter.info> <2DDB5448-6A34-4D68-9421-4505CCC71A1A@icsi.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2DDB5448-6A34-4D68-9421-4505CCC71A1A@icsi.berkeley.edu> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Behavior in the face of no answer? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 04 May 2012 13:08:59 -0000 On Fri, May 04, 2012 at 05:12:54AM -0700, Nicholas Weaver wrote: > > DNSSEC at all requires client validation No it does not. You keep insisting that because you have in mind the model of any DNS client in any network, but not every situation is like that. I personally think that end-point validation is the best way to do things, but the protocol is written in such a way that it is not required, and we can't make it so by wishing. > , and client validation > REQUIRES that the client be able to bypass the > significant-probability-broken recursive resolver already. Yes. > DANE > doesn't really add to that: If the client can fetch DNSSEC signed > records, TLSA won't be a problem. But I note that in my DNSSEC Trigger application, I have the ability to turn it off -- and sometimes it disables itself. This tells me that the most-robust end-point validation tool we have already concedes that it isn't perfect. The proposal appears, AFAICT, to make that known-bad path a critical dependency not just for TLSA, but for doing TLS _at all_. The way I read the proposal, if you can't get a TLSA then you fail the TLS connection. In some number of networks, what you're arguing for is "no TLS, ever" for any TLSA-enabled application. Is that really the direction we want to go? Because I predict the result is going to be that everyone turns off TLSA in their systems on the first day of failure, and then the protocol is dead. A -- Andrew Sullivan ajs@anvilwalrusden.com From ekr@rtfm.com Fri May 4 06:49:02 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF00A21F86D3 for ; Fri, 4 May 2012 06:49:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.863 X-Spam-Level: X-Spam-Status: No, score=-102.863 tagged_above=-999 required=5 tests=[AWL=0.114, 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 OMF98E6VOPiI for ; Fri, 4 May 2012 06:49:02 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 01ECC21F8645 for ; Fri, 4 May 2012 06:49:01 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so2437302vbb.31 for ; Fri, 04 May 2012 06:49:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=u6YabKFwUs6c2//7r9dlc6JPq4PztBbZekWiY+B8FPU=; b=TMMVyzCZ+3T/Qe6Fjfn/imJ1mg9IHrY3nessbVS4xFrXd557mhGMBtaF77mBuHpY8x crMX3dd2BYR0F/guhg0/FWIzekLaD3t8LMOyd6mWTtrdPNgva73pwUfIXOcI9zp5LN2N QemDwCHnLTEEnfwZtm6lZqkw/9HBKBHWiUrWeAhRfVD/y8knuWPr79xGRIY22VwcN5yD eUZ9Jo2BZaPQO5FGdCTOZ8jSOLrdQ7QBc0e/SHVar1wZ21pY2MHRRo4Gvpl24V4erna3 xzUteSEfQYPQxVifBjuePCwfpdSjDS95UW7vngjGYJGJMwTeVxh4poemb+Zm48mYVSx2 jB4A== Received: by 10.220.141.79 with SMTP id l15mr3916754vcu.48.1336139341409; Fri, 04 May 2012 06:49:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.19.233 with HTTP; Fri, 4 May 2012 06:48:20 -0700 (PDT) X-Originating-IP: [74.95.2.169] In-Reply-To: <20120504112922.GB4929@mail.yitter.info> References: <0526D60A-3F1B-4C55-9796-256BC2556AAB@vpnc.org> <20120503223745.GC1804@mail.yitter.info> <20120504021044.GB4560@mail.yitter.info> <20120504023602.GA4683@mail.yitter.info> <20120504112922.GB4929@mail.yitter.info> From: Eric Rescorla Date: Fri, 4 May 2012 06:48:20 -0700 Message-ID: To: Andrew Sullivan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkspsfsHI5Fi75qO2BJyqgkyndPgzoVERX0pbJcSQto+ZRhbhI5lwsetLznHH9gHajLqOcA Cc: dane@ietf.org Subject: Re: [dane] Behavior in the face of no answer? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 04 May 2012 13:49:03 -0000 On Fri, May 4, 2012 at 4:29 AM, Andrew Sullivan wr= ote: > On Thu, May 03, 2012 at 08:18:41PM -0700, Eric Rescorla wrote: >> >> While I understand that these operational constraints, I'm having >> trouble understanding what security benefit DANE offers if one behaves >> as you suggest, since it seems the attacker can simply force you to >> ignore any records that DANE provides. > > As a client, you could be making a decision about what is more likely: > > =A0 =A01. =A0The attacker is able to undermine some CA. > > =A0 =A02. =A0The attacker is actually on-path and going to undermine my > =A0 =A0connection. I'm confused by this answer: DANE (for the two constraints modes) only offers security value if *both* of these things are true. If the first is not true, then a PKIX certificate is sufficient to distinguish between valid users and attackers and in the second is not true, then even an attacker with an invalid certificate cannot get your packts. > In many cases, one might decide that (1) is more likely than (2), and > therefore decide that TLSA is a better thing to rely on. =A0During > deployment, however, one might be willing to think that (1) is less > likely than, "I am in a coffee shop, and these people bought crappy > infrastructure." =A0In that case, one might want to be able to fall back > to the way we actually do this today. Again, this is logical, but as far as I can tell it obviates the security provided by DANE. I'd like to repeat the question I asked in my previous message: can you describe a set of attacker capabilities which would be sufficient for an attacker to mount a successful attack on TLS pre-DANE but would not post-DANE, provided that clients react to TLSA non-response by falling back to pre-DANE behavior? Thanks, -Ekr From nweaver@ICSI.Berkeley.EDU Fri May 4 07:42:58 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B6F821F876C for ; Fri, 4 May 2012 07:42:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_18=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 TuXy-H1zO8pn for ; Fri, 4 May 2012 07:42:57 -0700 (PDT) Received: from rock.ICSI.Berkeley.EDU (rock.ICSI.Berkeley.EDU [192.150.186.19]) by ietfa.amsl.com (Postfix) with ESMTP id 64F5621F8744 for ; Fri, 4 May 2012 07:42:57 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 528982C400E; Fri, 4 May 2012 07:42:57 -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 MRmyWQWb54uV; Fri, 4 May 2012 07:42:56 -0700 (PDT) Received: from gala.icir.org (gala [192.150.187.49]) (Authenticated sender: nweaver) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id C7E2C2C4002; Fri, 4 May 2012 07:42:56 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Nicholas Weaver In-Reply-To: <2DDB5448-6A34-4D68-9421-4505CCC71A1A@icsi.berkeley.edu> Date: Fri, 4 May 2012 07:42:56 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0526D60A-3F1B-4C55-9796-256BC2556AAB@vpnc.org> <20120503223745.GC1804@mail.yitter.info> <20120504021044.GB4560@mail.yitter.info> <20120504023602.GA4683@mail.yitter.info> <20120504112922.GB4929@mail.yitter.info> <2DDB5448-6A34-4D68-9421-4505CCC71A1A@icsi.berkeley.edu> To: Andrew Sullivan X-Mailer: Apple Mail (2.1257) Cc: dane@ietf.org Subject: Re: [dane] Behavior in the face of no answer? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 04 May 2012 14:42:58 -0000 On May 4, 2012, at 5:12 AM, Nicholas Weaver wrote: > This is why browser's have given up on the other solution for the bad = CA problem: Certificate Revocation Lists. Because an attacker can block = the CRL check, and the CRL check is NOT mandatory (they are unreliable = enough that its not treated as a hard fail), CRLs are useless for = blocking attackers. For those not familiar with the context for the paragraph above: http://www.imperialviolet.org/2012/02/05/crlsets.html Chrome is abandoning the use of CRL lists for the browser, because of = the "soft fail" nature, which means that CRLs only work when not under = attack. DANE for CA certificates with "fail open" is just the same as a = CRL check. And DANE effectively requires client-side validation. Which means there are three cases: A: Client can't receive ANY DNSSEC at all when communicating directly = with the network [1] B: Client can't receive ANY TLSA signed records... C: Client CAN receive valid DNSSEC and TLSA records but CAN'T get a = TLSA (or NSEC/NSEC3 proof that it won't find one) for the site in = question. C clearly MUST be treated as an attack, and DANE MUST be fail closed in = this case. A and B are different. It COULD be a broken network, or it could be an = attack (And based on Netalyzr, I think B is rare, its mostly A). But = an attacker can always make his attack look like A, so 'fail open' is = clearly wrong. So here's my proposal: Actually check the network for b0rkenness! The browser, on startup, or when the local IP address changes, conducts = the following test: It checks, using three known sites with TLSA records (provided by the = browser vendor, with deliberate redundancy to prevent a TLD outage from = being a problem), to see if it can receive and validate a TLSA record = using DNSSEC for at least one of the three sites. If yes, any failure to fetch the proper TLSA record or NSEC proof = results in immediate 'fail open' when TLSA records are not received, as = it is case C. If no, DANE goes into a "Fail Scary" mode, akin to how browsers treat = self signed certificates: The browser MUST notify the user that the network is broken: its not = allowing the browser to fetch DNS records needed to authenticate = connections. The user MAY override it and disable DANE validation, but = the user is on notice that: 1) The network is not allowing secure communication 2) Its the network's fault, so go blame your network kit From ajs@anvilwalrusden.com Fri May 4 07:44:30 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E176921F87BC for ; Fri, 4 May 2012 07:44:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.631 X-Spam-Level: X-Spam-Status: No, score=-2.631 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 lc4kbxbfMG3r for ; Fri, 4 May 2012 07:44:30 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 2877C21F87B5 for ; Fri, 4 May 2012 07:44:30 -0700 (PDT) Received: from mail.yitter.info (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 354871ECB41C for ; Fri, 4 May 2012 14:44:29 +0000 (UTC) Date: Fri, 4 May 2012 10:44:26 -0400 From: Andrew Sullivan To: dane@ietf.org Message-ID: <20120504144426.GD4929@mail.yitter.info> References: <0526D60A-3F1B-4C55-9796-256BC2556AAB@vpnc.org> <20120503223745.GC1804@mail.yitter.info> <20120504021044.GB4560@mail.yitter.info> <20120504023602.GA4683@mail.yitter.info> <20120504112922.GB4929@mail.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Behavior in the face of no answer? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 04 May 2012 14:44:31 -0000 On Fri, May 04, 2012 at 06:48:20AM -0700, Eric Rescorla wrote: > On Fri, May 4, 2012 at 4:29 AM, Andrew Sullivan wrote: > > > >    1.  The attacker is able to undermine some CA. > > > >    2.  The attacker is actually on-path and going to undermine my > >    connection. > > I'm confused by this answer: DANE (for the two constraints modes) > only offers security value if *both* of these things are true. If the > first is not true, then a PKIX certificate is sufficient to distinguish > between valid users and attackers and in the second is not true, > then even an attacker with an invalid certificate cannot get > your packts. Yes, of course. Your proposal is that, if I have a TLSA-enabled client, I automatically lose TLS support _for anything_ in the event I'm in a network with poor DNS support. I was trying to argue that there is another sensible alternative: I could make a decision to allow TLSA responses not to work in some cases, because I think it is more likely that the network is broken than that (1) and (2) are both true. But I might in general not trust CAs, and think that (1) is more likely that (2) most of the time, and therefore normally want to prefer TLSA. Therefore, I ought to be able to decide to proceed in the face of the failure to get a TLSA record at all. Perhaps one would argue, however, that this amounts to saying, "I need to be able to turn TLSA off." I could live with that. I am still opposed to anything that says we have to treat some reponses that are not DNSSEC-bogus "as bogus", because I think it muddies the DNSSEC evaluation waters even more than they already are. Could we come up with another way of saying this? How about this: In the event that all DNS queries for the TLSA record time out, or return with RCODE 1 or RCODE 4-15, TLS MUST NOT be started or, if the TLS negotiation is already in progress, MUST cause the connection to be aborted. Under these conditions, a user agent MUST disable TLSA queries in order to undertage a TLS connection. Note that this does _not_ cause the connection to fail under the case we usually call "NODATA". The case I mentioned yesterday, where AD is set and the upstream doesn't give you the DNSSEC data and you have a NODATA response is, AFAICT, just a case where there is no TLSA RRset and shouldn't result in TLS failure. FWIW, I think the above is probaby too strong, but as long as we have something expicitly telling people that, if they thing DNS is broken where they are they need to turn of TLSA processing (i.e. a clue to implementers that they need this knob), I can live with it. > Again, this is logical, but as far as I can tell it obviates the security > provided by DANE. I'd like to repeat the question I asked in my > previous message: can you describe a set of attacker capabilities > which would be sufficient for an attacker to mount a successful > attack on TLS pre-DANE but would not post-DANE, provided > that clients react to TLSA non-response by falling back to pre-DANE > behavior? No, and I never thought that was the point of TLSA. I thought the point of TLSA was to enable people to use TLS, provably securely but without the X.509 PKI infrastructure, if they wanted to. Usability enhancements are security improvements too, IMO. A -- Andrew Sullivan ajs@anvilwalrusden.com From ekr@rtfm.com Fri May 4 08:11:22 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5AAA21F85EF for ; Fri, 4 May 2012 08:11:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.868 X-Spam-Level: X-Spam-Status: No, score=-102.868 tagged_above=-999 required=5 tests=[AWL=0.109, 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 PmYf+3mbFtlq for ; Fri, 4 May 2012 08:11:21 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9AC6621F85F0 for ; Fri, 4 May 2012 08:11:21 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so2518131vbb.31 for ; Fri, 04 May 2012 08:11:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=L6qX5YnPXzFMllbVFZrCDyz0AdqNtULa7Z2abwQsEYU=; b=QOaOehcDebpJdJnRAyXvNEdL+tjzij5baFeRppNMxpxB+s+uI4xyBJH0mrY6Xt19hP jzezRu0FUL5vTk2s38ooKr7A3GDjBY4pIkINORUZ7zEr6h3q4nj7GEsDYQEkEKzkWECy qxWA3iYwePg0GIycSZcLX/QXRH+p8bNPrap9zEtGqJKZIFK/5o78CG/N1qFAlVCHW4v+ piuDNR3b/pbKFYHEI07o9is+DU3Sn2f6raWgFQYBDa1eqKFXiO8qquY+kmsuZY/PwV6D VHwKY0gcF62HBuWyXogkJ9iWxvaaN5F4fEtbrtzNZ0iyv4kpjBQHwyeAqm8VnX6jhzK1 StgQ== Received: by 10.52.68.204 with SMTP id y12mr3280502vdt.53.1336144280928; Fri, 04 May 2012 08:11:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.19.233 with HTTP; Fri, 4 May 2012 08:10:40 -0700 (PDT) X-Originating-IP: [74.95.2.173] In-Reply-To: <20120504144426.GD4929@mail.yitter.info> References: <0526D60A-3F1B-4C55-9796-256BC2556AAB@vpnc.org> <20120503223745.GC1804@mail.yitter.info> <20120504021044.GB4560@mail.yitter.info> <20120504023602.GA4683@mail.yitter.info> <20120504112922.GB4929@mail.yitter.info> <20120504144426.GD4929@mail.yitter.info> From: Eric Rescorla Date: Fri, 4 May 2012 08:10:40 -0700 Message-ID: To: Andrew Sullivan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkdZhDAD++1KX7xoiQhkAtDmlnQ/5wRY6KLR8k1P42ByepCU4npeqHzlLUHqDt2tO/+YbzM Cc: dane@ietf.org Subject: Re: [dane] Behavior in the face of no answer? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 04 May 2012 15:11:22 -0000 On Fri, May 4, 2012 at 7:44 AM, Andrew Sullivan wr= ote: > On Fri, May 04, 2012 at 06:48:20AM -0700, Eric Rescorla wrote: >> On Fri, May 4, 2012 at 4:29 AM, Andrew Sullivan = wrote: >> > >> > =A0 =A01. =A0The attacker is able to undermine some CA. >> > >> > =A0 =A02. =A0The attacker is actually on-path and going to undermine m= y >> > =A0 =A0connection. >> >> I'm confused by this answer: DANE (for the two constraints modes) >> only offers security value if *both* of these things are true. If the >> first is not true, then a PKIX certificate is sufficient to distinguish >> between valid users and attackers and in the second is not true, >> then even an attacker with an invalid certificate cannot get >> your packts. > > Yes, of course. > > Your proposal is that, if I have a TLSA-enabled client, I > automatically lose TLS support _for anything_ in the event I'm in a > network with poor DNS support. =A0I was trying to argue that there is > another sensible alternative: I could make a decision to allow TLSA > responses not to work in some cases, because I think it is more likely > that the network is broken than that (1) and (2) are both true. =A0But > I might in general not trust CAs, and think that (1) is more likely > that (2) most of the time, and therefore normally want to prefer > TLSA. =A0Therefore, I ought to be able to decide to proceed in the face > of the failure to get a TLSA record at all. Again, I don't understand your reasoning here. It's not a matter of 1 *versus* 2. If you proceed in the face of no TLSA record, I claim you might as well not do the TLSA check. > Perhaps one would argue, however, that this amounts to saying, "I need > to be able to turn TLSA off." =A0I could live with that. > > I am still opposed to anything that says we have to treat some > reponses that are not DNSSEC-bogus "as bogus", because I think it > muddies the DNSSEC evaluation waters even more than they already are. > Could we come up with another way of saying this? =A0How about this: > > =A0 =A0In the event that all DNS queries for the TLSA record time out, or > =A0 =A0return with RCODE 1 or RCODE 4-15, TLS MUST NOT be started or, > =A0 =A0if the TLS negotiation is already in progress, MUST cause the > =A0 =A0connection to be aborted. =A0Under these conditions, a user agent > =A0 =A0MUST disable TLSA queries in order to undertage a TLS connection. I don't really see how to operationalize this in a client in a useful way. > Note that this does _not_ cause the connection to fail under the case > we usually call "NODATA". =A0The case I mentioned yesterday, where AD is > set and the upstream doesn't give you the DNSSEC data and you have a > NODATA response is, AFAICT, just a case where there is no TLSA RRset > and shouldn't result in TLS failure. But the problem is that this is indistinguishable from the case where there *was* a TLSA RRSET and you have a network attacker. > =A0FWIW, I think the above is > probaby too strong, but as long as we have something expicitly telling > people that, if they thing DNS is broken where they are they need to > turn of TLSA processing (i.e. a clue to implementers that they need > this knob), I can live with it. I'd rather not get bogged down in the exact RFC 2119 language and discussion of what knobs must be provided just yet. But I do think it's useful to think about this from the perspective of the implementor. For convenience, consider the case of the browser. Currently, the browser's algorithm is simple: check the PKIX cert and if it's valid, connect and if not show a scary red dialog. [I'm ignoring cert pinning for now.] And it's generally agreed that one should only proceed past the scary dialog if either (a) you don't care who you are connecting to, like in a captive network portal or (b) you are really sure you are in a secure network environment. Now, consider the perspective of an implementor who adds DANE support for usages 0 and 1. The first arm of the decision, PKIX valid, now becomes three branches. - Verifiably no TLSA records via DNSSEC or Insecure/Indeterminate zone: continue with PKIX validation. - Verifiable TLSA records via DNSSEC: PKIX validation plus the TLSA check - Non-response: ??? Now, the implementor has three choices in this final arm: 1. Proceed with the TLS connection. (soft fail) 2. Show the scary red dialog. (hard fail) 3. Refuse to connect under any conditions (really hard fail, the way you do with pinning). I claim that if you do (1) you might as well not bother with the TLSA check at all, since the attacker can just bypass it. I assume you are saying that one should do (2)? I think that's fine, as long as that's also how you treat other TLSA failures, such as certs which aren't in the TLSA list. If you treat this case preferentially, then attackers will just simulate it. Important note: I am not claiming that route (2) is good. If the infrastructure is indeed as bad as you say, then users will find themselves having to click through all the time and DANE is likely not a useful signal. >> Again, this is logical, but as far as I can tell it obviates the securit= y >> provided by DANE. I'd like to repeat the question I asked in my >> previous message: can you describe a set of attacker capabilities >> which would be sufficient for an attacker to mount a successful >> attack on TLS pre-DANE but would not post-DANE, provided >> that clients react to TLSA non-response by falling back to pre-DANE >> behavior? > > No, and I never thought that was the point of TLSA. =A0I thought the > point of TLSA was to enable people to use TLS, provably securely > but without the X.509 PKI infrastructure, if they wanted to. > Usability enhancements are security improvements too, IMO. TLSA includes two types of records: 1. Records which constrain the set of valid certificates but which still require PKIX validation of the certificate (Usages 0 and 1). 2. Records which allow a client to use keying material which would otherwise not pass PKIX validation (Usages 2 and 3). What we're talking about here is Usages 0 and 1. I agree that the analysis is different for usages 2 and 3. -Ekr From tom@ritter.vg Fri May 4 08:38:14 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BA8C21E8018 for ; Fri, 4 May 2012 08:38:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.612 X-Spam-Level: X-Spam-Status: No, score=-2.612 tagged_above=-999 required=5 tests=[AWL=-0.235, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_18=0.6, 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 C1GYGUDgwucQ for ; Fri, 4 May 2012 08:38:13 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id D58D121E8013 for ; Fri, 4 May 2012 08:38:13 -0700 (PDT) Received: by obbeh20 with SMTP id eh20so4919590obb.31 for ; Fri, 04 May 2012 08:38:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=iJEJ7jiiCthFYkdPIxT+YCV5TcYInf0fCU+2okfDlBw=; b=swH2+Lrq3f84rJmnNAtHbf3w2J7wOdVjzsbKT5uM9JkctHPk5Nbdb3tWL4owyt9PWb GC5cPN8qWZ0UGN4bRALP/ZpR8yzBDAfDvgs9KCerfUBWHP9wre9Ul0IH5+59AqRzqIu3 yEnStQ8fkz0VKYbJ383tKaACVW8kyxk0w3J3Q= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=iJEJ7jiiCthFYkdPIxT+YCV5TcYInf0fCU+2okfDlBw=; b=mqZpJnuJqyQFq/HsoBr3CsY4aM9RPzShQGAg9K3ciGinhldmrmLOBN9KP4LLHzd7qz QiucEMLVbT8MzcmWFDzJotbaKjwu0vyomKjo0liA3ILbnTpGYtEewEanU8eOki7vqU/q y6oSk5xlnySkN7bXH9XsCg+FM/9czurUuLczeHH7LfJVwF20Ynnr0PYryjv0NXrkKPWE Mc35aKHzqmZvCZTMIGbaO3I8pjnwVbVCRnLEo1Q3wgQx5u2OzvFH0NSgT+8mRd9GFBHS eopS9zAfgEHibkapBrH/GgmyR6GgCgXKcT/uTkcOY488Jg/jPYGxTyEpcnGE6fLVBeLq KkYg== Received: by 10.182.111.39 with SMTP id if7mr9038360obb.55.1336145893387; Fri, 04 May 2012 08:38:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.150.41 with HTTP; Fri, 4 May 2012 08:37:53 -0700 (PDT) In-Reply-To: References: <0526D60A-3F1B-4C55-9796-256BC2556AAB@vpnc.org> <20120503223745.GC1804@mail.yitter.info> <20120504021044.GB4560@mail.yitter.info> <20120504023602.GA4683@mail.yitter.info> <20120504112922.GB4929@mail.yitter.info> <2DDB5448-6A34-4D68-9421-4505CCC71A1A@icsi.berkeley.edu> From: Tom Ritter Date: Fri, 4 May 2012 11:37:53 -0400 Message-ID: To: dane@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkmIaFWWAPZLCKrnvneycsVHvI+kLMoDVG5rf657RYAkxkCehdHgdkEVmmJ5z33XdzNM8Rb Cc: Adam Langley Subject: Re: [dane] Behavior in the face of no answer? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 04 May 2012 15:38:14 -0000 On 4 May 2012 10:42, Nicholas Weaver wrote: > So here's my proposal: Actually check the network for b0rkenness! > > The browser, on startup, or when the local IP address changes, conducts t= he following test: > > It checks, using three known sites with TLSA records (provided by the bro= wser vendor, with deliberate redundancy to prevent a TLD outage from being = a problem), to see if it can receive and validate a TLSA record using DNSSE= C for at least one of the three sites. I don't think will actually help anything. The attacker will just block ALL TLSA records, not just for the target site he intends to MITM. Fail-close vs Fail-open when you can't get the TLSA record is OCSP hard-fail vs soft-fail all over again. I'd like Hard fail, but no matter what we say, no browser will implement it. If mandating hard-fail in the spec causes clients to NOT implement DANE (as opposed to just ignoring the recommendation) - I don't think we should do it. HOWEVER! WE HAVE A SOLUTION! Actually, Chrome has a solution, and it already works. http://www.imperialviolet.org/2011/06/16/dnssecchrome.html DNSSEC Stapled Certificates Put the DNSSEC chain *in the TLS certificate*. This won't be blocked by a MITM, and if you receive a self-signed certificate with a valid TLSA chain in it, it's valid. The TLSA chain is signed, so it doesn't matter _how_ you receive it, as long as the signatures all match up. Now this is a solution to the broader problem of delivering the TLSA record to the client for verification, it's not a solution to hard-fail vs soft-fail for TLSA queries. (I already gave my opinion on that.) And it's clear that this solution should not go into this RFC, and that we need to either: - recommend soft-fail (bad) - recommend hard-fail (potentially bad, if it stops adoption) - punt, and let everyone do what they're going to do already: soft-fail But this idea, which I think could turn into a RFC fairly easily, get implemented in browsers in relatively short order, and get implemented in webservers in considerably longer order - can solve the general problem. -tom From warren@kumari.net Fri May 4 08:57:14 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB62F21F8650 for ; Fri, 4 May 2012 08:57:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.548 X-Spam-Level: X-Spam-Status: No, score=-106.548 tagged_above=-999 required=5 tests=[AWL=0.051, 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 NDq6QYif1RUx for ; Fri, 4 May 2012 08:57:14 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id E007C21F8634 for ; Fri, 4 May 2012 08:57:13 -0700 (PDT) Received: from dhcp-172-19-118-235.cbf.corp.google.com (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id 8E7321B4030F; Fri, 4 May 2012 11:57:12 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warren Kumari In-Reply-To: Date: Fri, 4 May 2012 11:57:11 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <3FF36EBA-F8B1-4D66-BA00-E8E36A7E449D@kumari.net> References: <0526D60A-3F1B-4C55-9796-256BC2556AAB@vpnc.org> <20120503223745.GC1804@mail.yitter.info> <20120504021044.GB4560@mail.yitter.info> <20120504023602.GA4683@mail.yitter.info> <20120504112922.GB4929@mail.yitter.info> <20120504144426.GD4929@mail.yitter.info> To: Eric Rescorla X-Mailer: Apple Mail (2.1084) Cc: dane@ietf.org Subject: Re: [dane] Behavior in the face of no answer? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 04 May 2012 15:57:15 -0000 Hi there all, First off, thanks for keeping this civil. This is an important issue = (and one that we've skirted around in the past..), lets try and prevent = it becoming contentions as well :-) So, it seems (to me!) that both Eric and Andrew have perfectly sane and = defendable positions, but diametrically opposed. This is (IMO) something that we are going to have to resolve before this = is published, so I am asking our AD to consider holding off... =20 So, how does the WG feel about a knob that can be turned to choose = behavior? Something that can be set for the less secure manner for now, = and then (the default) changed later?=20 Security conscious / at risk folk would be able to turn the knob now... Worst idea ever? W On May 4, 2012, at 11:10 AM, Eric Rescorla wrote: > On Fri, May 4, 2012 at 7:44 AM, Andrew Sullivan = wrote: >> On Fri, May 04, 2012 at 06:48:20AM -0700, Eric Rescorla wrote: >>> On Fri, May 4, 2012 at 4:29 AM, Andrew Sullivan = wrote: >>>>=20 >>>> 1. The attacker is able to undermine some CA. >>>>=20 >>>> 2. The attacker is actually on-path and going to undermine my >>>> connection. >>>=20 >>> I'm confused by this answer: DANE (for the two constraints modes) >>> only offers security value if *both* of these things are true. If = the >>> first is not true, then a PKIX certificate is sufficient to = distinguish >>> between valid users and attackers and in the second is not true, >>> then even an attacker with an invalid certificate cannot get >>> your packts. >>=20 >> Yes, of course. >>=20 >> Your proposal is that, if I have a TLSA-enabled client, I >> automatically lose TLS support _for anything_ in the event I'm in a >> network with poor DNS support. I was trying to argue that there is >> another sensible alternative: I could make a decision to allow TLSA >> responses not to work in some cases, because I think it is more = likely >> that the network is broken than that (1) and (2) are both true. But >> I might in general not trust CAs, and think that (1) is more likely >> that (2) most of the time, and therefore normally want to prefer >> TLSA. Therefore, I ought to be able to decide to proceed in the face >> of the failure to get a TLSA record at all. >=20 > Again, I don't understand your reasoning here. It's not a matter of 1 > *versus* 2. If you proceed in the face of no TLSA record, I claim you > might as well not do the TLSA check. >=20 >=20 >> Perhaps one would argue, however, that this amounts to saying, "I = need >> to be able to turn TLSA off." I could live with that. >>=20 >> I am still opposed to anything that says we have to treat some >> reponses that are not DNSSEC-bogus "as bogus", because I think it >> muddies the DNSSEC evaluation waters even more than they already are. >> Could we come up with another way of saying this? How about this: >>=20 >> In the event that all DNS queries for the TLSA record time out, or >> return with RCODE 1 or RCODE 4-15, TLS MUST NOT be started or, >> if the TLS negotiation is already in progress, MUST cause the >> connection to be aborted. Under these conditions, a user agent >> MUST disable TLSA queries in order to undertage a TLS connection. >=20 > I don't really see how to operationalize this in a client in a useful = way. >=20 >=20 >> Note that this does _not_ cause the connection to fail under the case >> we usually call "NODATA". The case I mentioned yesterday, where AD = is >> set and the upstream doesn't give you the DNSSEC data and you have a >> NODATA response is, AFAICT, just a case where there is no TLSA RRset >> and shouldn't result in TLS failure. >=20 > But the problem is that this is indistinguishable from the case where = there > *was* a TLSA RRSET and you have a network attacker. >=20 >=20 >> FWIW, I think the above is >> probaby too strong, but as long as we have something expicitly = telling >> people that, if they thing DNS is broken where they are they need to >> turn of TLSA processing (i.e. a clue to implementers that they need >> this knob), I can live with it. >=20 > I'd rather not get bogged down in the exact RFC 2119 language and > discussion of what knobs must be provided just yet. But I do think = it's > useful to think about this from the perspective of the implementor. > For convenience, consider the case of the browser. Currently, the > browser's algorithm is simple: check the PKIX cert and if it's valid, > connect and if not show a scary red dialog. [I'm ignoring cert pinning > for now.] And it's generally agreed that one should only proceed > past the scary dialog if either (a) you don't care who you are > connecting to, like in a captive network portal or (b) you are really > sure you are in a secure network environment. >=20 > Now, consider the perspective of an implementor who adds DANE > support for usages 0 and 1. The first arm of the decision, PKIX valid, > now becomes three branches. >=20 > - Verifiably no TLSA records via DNSSEC or Insecure/Indeterminate = zone: > continue with PKIX validation. > - Verifiable TLSA records via DNSSEC: PKIX validation plus the TLSA = check > - Non-response: ??? >=20 > Now, the implementor has three choices in this final arm: >=20 > 1. Proceed with the TLS connection. (soft fail) > 2. Show the scary red dialog. (hard fail) > 3. Refuse to connect under any conditions (really hard fail, the way = you > do with pinning). >=20 > I claim that if you do (1) you might as well not bother with the TLSA > check at all, since the attacker can just bypass it. I assume you are > saying that one should do (2)? I think that's fine, as long as that's > also how you treat other TLSA failures, such as certs which aren't > in the TLSA list. If you treat this case preferentially, then = attackers > will just simulate it. >=20 > Important note: I am not claiming that route (2) is good. If the > infrastructure is indeed as bad as you say, then users will find > themselves having to click through all the time and DANE is likely > not a useful signal. >=20 >=20 >>> Again, this is logical, but as far as I can tell it obviates the = security >>> provided by DANE. I'd like to repeat the question I asked in my >>> previous message: can you describe a set of attacker capabilities >>> which would be sufficient for an attacker to mount a successful >>> attack on TLS pre-DANE but would not post-DANE, provided >>> that clients react to TLSA non-response by falling back to pre-DANE >>> behavior? >>=20 >> No, and I never thought that was the point of TLSA. I thought the >> point of TLSA was to enable people to use TLS, provably securely >> but without the X.509 PKI infrastructure, if they wanted to. >> Usability enhancements are security improvements too, IMO. >=20 > TLSA includes two types of records: >=20 > 1. Records which constrain the set of valid certificates but which = still > require PKIX validation of the certificate (Usages 0 and 1). > 2. Records which allow a client to use keying material which would > otherwise not pass PKIX validation (Usages 2 and 3). >=20 > What we're talking about here is Usages 0 and 1. I agree that the > analysis is different for usages 2 and 3. >=20 > -Ekr > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane >=20 From ekr@rtfm.com Fri May 4 08:57:21 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 380DC21F86D0 for ; Fri, 4 May 2012 08:57:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.573 X-Spam-Level: X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=-0.196, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_18=0.6, 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 MhJce-gNd9Tu for ; Fri, 4 May 2012 08:57:20 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6EB0621F8680 for ; Fri, 4 May 2012 08:57:20 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so2563902vcb.31 for ; Fri, 04 May 2012 08:57:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=cX/HpHkF6QkuwrbNPhgHoD1O3zUvvj9WLSvNsZD9wbw=; b=TFfhF9dAsgv1zNRBZ6eNKa75ILgzKJjmAJ/T6RjKdYsyhkwjkF0AhoJwCcQX2xYj1r eMFa7hUkVmmL17b7ub6DEzPrG4a1WzRU8DS4FGeF4/2am2lSpe5kbCxW+jyoBj4IAGoU Qa/gQVAxFn9ThtTtD0qtxYH7Rw+gY8Jd4p9vQSwyK5OS0r3jL9FIscsM81vnU/lozDd9 2jrW+Qybhzhvrje6W2FLPLFPfRjf6mGUtSGGAs8ztZk17h7vI4N4+C4Ez3b0F/3XdnG5 Cl5lIu2oZEDqOfP0VdaxvJfibDcI8VYrF4S0Fnvq8CzTTvJOpNiTAeXHSMP0dM/iR++I XZwA== Received: by 10.52.22.148 with SMTP id d20mr2437997vdf.102.1336147039953; Fri, 04 May 2012 08:57:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.19.233 with HTTP; Fri, 4 May 2012 08:56:39 -0700 (PDT) X-Originating-IP: [74.95.2.173] In-Reply-To: References: <0526D60A-3F1B-4C55-9796-256BC2556AAB@vpnc.org> <20120503223745.GC1804@mail.yitter.info> <20120504021044.GB4560@mail.yitter.info> <20120504023602.GA4683@mail.yitter.info> <20120504112922.GB4929@mail.yitter.info> <2DDB5448-6A34-4D68-9421-4505CCC71A1A@icsi.berkeley.edu> From: Eric Rescorla Date: Fri, 4 May 2012 08:56:39 -0700 Message-ID: To: Tom Ritter Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmFlw6BqVR+xedT14BRaIxxnhwyz+p1OgO49Z6s3NWT31gDOQJ+bjeXkGANEp5BIMSyc3Ap Cc: Adam Langley , dane@ietf.org Subject: Re: [dane] Behavior in the face of no answer? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 04 May 2012 15:57:21 -0000 On Fri, May 4, 2012 at 8:37 AM, Tom Ritter wrote: > On 4 May 2012 10:42, Nicholas Weaver wrote: >> So here's my proposal: Actually check the network for b0rkenness! >> >> The browser, on startup, or when the local IP address changes, conducts = the following test: >> >> It checks, using three known sites with TLSA records (provided by the br= owser vendor, with deliberate redundancy to prevent a TLD outage from being= a problem), to see if it can receive and validate a TLSA record using DNSS= EC for at least one of the three sites. > > I don't think will actually help anything. =A0The attacker will just > block ALL TLSA records, not just for the target site he intends to > MITM. > > > > Fail-close vs Fail-open when you can't get the TLSA record is OCSP > hard-fail vs soft-fail all over again. =A0I'd like Hard fail, but no > matter what we say, no browser will implement it. =A0If mandating > hard-fail in the spec causes clients to NOT implement DANE (as opposed > to just ignoring the recommendation) - I don't think we should do it. > But then what is the security value of the restrictive DANE usages? > > HOWEVER! =A0WE HAVE A SOLUTION! =A0Actually, Chrome has a solution, and i= t > already works. http://www.imperialviolet.org/2011/06/16/dnssecchrome.html > DNSSEC Stapled Certificates > > Put the DNSSEC chain *in the TLS certificate*. =A0This won't be blocked > by a MITM, and if you receive a self-signed certificate with a valid > TLSA chain in it, it's valid. =A0The TLSA chain is signed, so it doesn't > matter _how_ you receive it, as long as the signatures all match up. This is only useful for usages 2 and 3 (the additive ones). In the case of usages 0 and 1, the attacker is delivering his own certificate and just won't send any TLSA records. -Ekr From ekr@rtfm.com Fri May 4 09:09:44 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 715FA11E808A for ; Fri, 4 May 2012 09:09:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.865 X-Spam-Level: X-Spam-Status: No, score=-102.865 tagged_above=-999 required=5 tests=[AWL=0.112, 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 GBczT2mDM3P8 for ; Fri, 4 May 2012 09:09:43 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 46C7021F8713 for ; Fri, 4 May 2012 09:09:35 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so2575194vcb.31 for ; Fri, 04 May 2012 09:09:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=IrW3Jq95Wrqk2D+r0uirXXdRuc41B5B/gJvP3JCYwYM=; b=WLQKjpgiyKpWLcZRNgPOqDaZpwWgcYc0DzTn6p3GS8xX8K8dk46DCozwcs8m4pj8ck jf0LRiLysyweW+DZp6OHkRrgKWRkdcWOtHNWLeYhZ1dSbeONVvYptoAUxqpyiJZs6bR8 cljpJs/mqp26yKBmDp5AUyFfLC84RGq8uPqxXiv40S+IaVUQSChdsWKKm+5XG7JQ5VZt T7ZRScR1SSKxVhSWUiEnM3o2SnnbLpimOt83FP/UbrTlgY9R5F3E4dKTwoMrNb7JJQhy 7wm+/iCReEfHw7W4LSAKtm5+V8q8o1TDN2bEvw2Amb5cI2YbHI+Kq5tslQHLQyewabio Pn/Q== Received: by 10.220.141.79 with SMTP id l15mr4204935vcu.48.1336147774778; Fri, 04 May 2012 09:09:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.19.233 with HTTP; Fri, 4 May 2012 09:08:53 -0700 (PDT) X-Originating-IP: [74.95.2.173] In-Reply-To: <3FF36EBA-F8B1-4D66-BA00-E8E36A7E449D@kumari.net> References: <0526D60A-3F1B-4C55-9796-256BC2556AAB@vpnc.org> <20120503223745.GC1804@mail.yitter.info> <20120504021044.GB4560@mail.yitter.info> <20120504023602.GA4683@mail.yitter.info> <20120504112922.GB4929@mail.yitter.info> <20120504144426.GD4929@mail.yitter.info> <3FF36EBA-F8B1-4D66-BA00-E8E36A7E449D@kumari.net> From: Eric Rescorla Date: Fri, 4 May 2012 09:08:53 -0700 Message-ID: To: Warren Kumari Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQny+dkPMmgo7pis8Hd842iJ7E2eaQ8FJucfEcx4zHE5bpwqgPsByGJpmzFpNV7MniYdIX3+ Cc: dane@ietf.org Subject: Re: [dane] Behavior in the face of no answer? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 04 May 2012 16:09:44 -0000 On Fri, May 4, 2012 at 8:57 AM, Warren Kumari wrote: > > > Hi there all, > > First off, thanks for keeping this civil. This is an important issue (and one that we've skirted around in the past..), lets try and prevent it becoming contentions as well :-) > > So, it seems (to me!) that both Eric and Andrew have perfectly sane and defendable positions, but diametrically opposed. > This is (IMO) something that we are going to have to resolve before this is published, so I am asking our AD to consider holding off... > > > > > So, how does the WG feel about a knob that can be turned to choose behavior? Something that can be set for the less secure manner for now, and then (the default) changed later? > Security conscious / at risk folk would be able to turn the knob now... > > Worst idea ever? Before we discuss how to proceed, I think it would be useful to get agreement on the security analysis. I claim that for Usages 0 and 1, treating TLSA non-response as if no TLSA records exist means that DANE adds minmal/no security value for those usages. If people disagree with that, I would like to hear someone describe a threat model under which DANE with this policy would prevent attacks that would otherwise succeed. Until we agree on that, I don't think there's much point in discussing what the document ought to say. -Ekr From alangley@gmail.com Fri May 4 09:18:21 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9B1821E8024 for ; Fri, 4 May 2012 09:18:21 -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 bdDBQWID0SRU for ; Fri, 4 May 2012 09:18:21 -0700 (PDT) Received: from mail-pz0-f52.google.com (mail-pz0-f52.google.com [209.85.210.52]) by ietfa.amsl.com (Postfix) with ESMTP id 1ED4A21E8020 for ; Fri, 4 May 2012 09:18:21 -0700 (PDT) Received: by dadz9 with SMTP id z9so4803089dad.39 for ; Fri, 04 May 2012 09:18:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=XYxT4iIGKQfSh2Q+ddBEEzMB0T+7MOa2Cp0Dlcp+sm0=; b=nvqLMQKHrf4/InKfNJZKxdLFq7ZW1CmeI3ePRsaGCT56FYdC+md6YXwOGCGr9D+Iex oE7o/dPDhdw9Q3ZG2cV54rZmDtrDEaft0QpnMPsZkusVXyavnY33nE9zHStvFIpNIoGT 1FfMmdbhAh4mwpFfS40porfi0cCsmHy/y2oXgfT/9lHnKZbG4gj+K/L5QC76w1sPeeSN u8CSMesx6jsZmGwQRalIH4+bnK18mfH3EQgWhMwMM2WdVGtYspxus49SYDc5qVQMca7E RgqqHOMVlcMG7NRSFiXE4ZU8UoNNAjFssKumByxifVYsF3iMEUSb09k/lHF1MqnJBeVE uB0g== MIME-Version: 1.0 Received: by 10.50.186.168 with SMTP id fl8mr3403171igc.68.1336148300715; Fri, 04 May 2012 09:18:20 -0700 (PDT) Sender: alangley@gmail.com Received: by 10.42.76.7 with HTTP; Fri, 4 May 2012 09:18:20 -0700 (PDT) In-Reply-To: References: <0526D60A-3F1B-4C55-9796-256BC2556AAB@vpnc.org> <20120503223745.GC1804@mail.yitter.info> <20120504021044.GB4560@mail.yitter.info> <20120504023602.GA4683@mail.yitter.info> <20120504112922.GB4929@mail.yitter.info> <20120504144426.GD4929@mail.yitter.info> <3FF36EBA-F8B1-4D66-BA00-E8E36A7E449D@kumari.net> Date: Fri, 4 May 2012 12:18:20 -0400 X-Google-Sender-Auth: LpjljOAj5SMv3i-eF8ujCaZbJpo Message-ID: From: Adam Langley To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Cc: dane@ietf.org Subject: Re: [dane] Behavior in the face of no answer? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 04 May 2012 16:18:21 -0000 On Fri, May 4, 2012 at 12:08 PM, Eric Rescorla wrote: > Before we discuss how to proceed, I think it would be useful to get agreement > on the security analysis. I claim that for Usages 0 and 1, treating > TLSA non-response > as if no TLSA records exist means that DANE adds minmal/no security > value for those > usages. I believe that you're completely correct. Browsers are not going to enable DANE hard fail in the short or medium term because of the fraction of clients that have broken DNS and can't fetch the records. Therefore, browsers are not going to see a security benefit from DANE. The DNSSEC stapled certificates that Tom points to are addressing a very different use case: people who would otherwise use self-signed certificates and who get annoyed that we throw errors for them. However, browsers are not the world. Other clients, which may benefit from a smaller, more controlled, deployment may be able to enforce DANE hard-fail and see security benefits. I would personally suggest that the spec requires hard fail, or at least discusses the fact that, without hard-fail, the security benefits are moot. Implementations frequently ignore requirements in specs, but rarely add to them! Cheers AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org From paul.hoffman@vpnc.org Fri May 4 09:32:34 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3B3921E8045 for ; Fri, 4 May 2012 09:32:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.547 X-Spam-Level: X-Spam-Status: No, score=-102.547 tagged_above=-999 required=5 tests=[AWL=0.052, 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 eKEyS9CRnlTN for ; Fri, 4 May 2012 09:32:34 -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 2347D21E800F for ; Fri, 4 May 2012 09:32:34 -0700 (PDT) Received: from [10.20.30.102] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q44GWW06029206 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 4 May 2012 09:32:33 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1257) From: Paul Hoffman In-Reply-To: Date: Fri, 4 May 2012 09:32:32 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6015A12B-8CA9-426B-9AFF-32CD4211DAB5@vpnc.org> References: <0526D60A-3F1B-4C55-9796-256BC2556AAB@vpnc.org> <20120503223745.GC1804@mail.yitter.info> <20120504021044.GB4560@mail.yitter.info> <20120504023602.GA4683@mail.yitter.info> <20120504112922.GB4929@mail.yitter.info> <20120504144426.GD4929@mail.yitter.info> <3FF36EBA-F8B1-4D66-BA00-E8E36A7E449D@kumari.net> To: IETF DANE WG list X-Mailer: Apple Mail (2.1257) Subject: Re: [dane] Behavior in the face of no answer? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 04 May 2012 16:32:34 -0000 On May 4, 2012, at 9:18 AM, Adam Langley wrote: > On Fri, May 4, 2012 at 12:08 PM, Eric Rescorla wrote: >> Before we discuss how to proceed, I think it would be useful to get = agreement >> on the security analysis. I claim that for Usages 0 and 1, treating >> TLSA non-response >> as if no TLSA records exist means that DANE adds minmal/no security >> value for those >> usages. >=20 > I believe that you're completely correct. >=20 > Browsers are not going to enable DANE hard fail in the short or medium > term because of the fraction of clients that have broken DNS and can't > fetch the records. >=20 > Therefore, browsers are not going to see a security benefit from DANE. > The DNSSEC stapled certificates that Tom points to are addressing a > very different use case: people who would otherwise use self-signed > certificates and who get annoyed that we throw errors for them. >=20 > However, browsers are not the world. Other clients, which may benefit > from a smaller, more controlled, deployment may be able to enforce > DANE hard-fail and see security benefits. >=20 > I would personally suggest that the spec requires hard fail, or at > least discusses the fact that, without hard-fail, the security > benefits are moot. Implementations frequently ignore requirements in > specs, but rarely add to them! My preference is that the spec discuss the issue, propose hard-fail as = an option, and explain that without hard-fail the benefits for usage 0 = and 1 can be circumvented but that the client is no worse off than = without DANE. It's important to emphasize that this is about usage 0 and = 1, and that a different security analysis applies to types 2 and 3 = (well, 3 certainly; I need to think about 2). I would prefer that we not require hard fail while assuming some = implementers will not follow our requirement, since that leads to us = being dishonest about what we expect. If we believe (as Adam says) that = implementations ignore these types of requirements, let's be honest = about that and let the implementer know what it means to ignore the = suggested action. --Paul Hoffman From ajs@anvilwalrusden.com Fri May 4 09:53:27 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39BAA21F8634 for ; Fri, 4 May 2012 09:53:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.631 X-Spam-Level: X-Spam-Status: No, score=-2.631 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 dG7DAMM6KS6r for ; Fri, 4 May 2012 09:53:26 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id B6CBF21F8633 for ; Fri, 4 May 2012 09:53:26 -0700 (PDT) Received: from mail.yitter.info (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 7EFB01ECB41C for ; Fri, 4 May 2012 16:53:25 +0000 (UTC) Date: Fri, 4 May 2012 12:53:15 -0400 From: Andrew Sullivan To: dane@ietf.org Message-ID: <20120504165311.GB7394@mail.yitter.info> References: <20120504023602.GA4683@mail.yitter.info> <20120504112922.GB4929@mail.yitter.info> <20120504144426.GD4929@mail.yitter.info> <3FF36EBA-F8B1-4D66-BA00-E8E36A7E449D@kumari.net> <6015A12B-8CA9-426B-9AFF-32CD4211DAB5@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6015A12B-8CA9-426B-9AFF-32CD4211DAB5@vpnc.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Behavior in the face of no answer? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 04 May 2012 16:53:27 -0000 On Fri, May 04, 2012 at 09:32:32AM -0700, Paul Hoffman wrote: > > My preference is that the spec discuss the issue, propose hard-fail > as an option, and explain that without hard-fail the benefits for > usage 0 and 1 can be circumvented but that the client is no worse > off than without DANE. It's important to emphasize that this is > about usage 0 and 1, and that a different security analysis applies > to types 2 and 3 (well, 3 certainly; I need to think about 2). I agree with this. > I would prefer that we not require hard fail while assuming some > implementers will not follow our requirement, I also strongly agree with this. A -- Andrew Sullivan ajs@anvilwalrusden.com From ajs@anvilwalrusden.com Fri May 4 09:55:16 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD1E621F8648 for ; Fri, 4 May 2012 09:55:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.63 X-Spam-Level: X-Spam-Status: No, score=-2.63 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 h+OhEeW-H26R for ; Fri, 4 May 2012 09:55:15 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id BA3F721F8638 for ; Fri, 4 May 2012 09:55:15 -0700 (PDT) Received: from mail.yitter.info (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 7C0951ECB41C for ; Fri, 4 May 2012 16:55:14 +0000 (UTC) Date: Fri, 4 May 2012 12:55:12 -0400 From: Andrew Sullivan To: dane@ietf.org Message-ID: <20120504165512.GC7394@mail.yitter.info> References: <20120503223745.GC1804@mail.yitter.info> <20120504021044.GB4560@mail.yitter.info> <20120504023602.GA4683@mail.yitter.info> <20120504112922.GB4929@mail.yitter.info> <20120504144426.GD4929@mail.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Behavior in the face of no answer? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 04 May 2012 16:55:16 -0000 On Fri, May 04, 2012 at 08:10:40AM -0700, Eric Rescorla wrote: > > we usually call "NODATA".  The case I mentioned yesterday, where AD is > > set and the upstream doesn't give you the DNSSEC data and you have a > > NODATA response is, AFAICT, just a case where there is no TLSA RRset > > and shouldn't result in TLS failure. > > But the problem is that this is indistinguishable from the case where there > *was* a TLSA RRSET and you have a network attacker. It certainly isn't. If you're depending on your upstream validator, you need to trust it. If you don't trust it, don't depend on the upstream, in which case you're not going to offload validation. A NODATA answer is _not_ just like "no response at all" if the answer passed validation, and if it didn't pass the the specification already covers this case. A -- Andrew Sullivan ajs@anvilwalrusden.com From mrex@sap.com Fri May 4 10:24:45 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D6AA21F8638 for ; Fri, 4 May 2012 10:24:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.126 X-Spam-Level: X-Spam-Status: No, score=-10.126 tagged_above=-999 required=5 tests=[AWL=0.123, 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 U9bFijp7yUwN for ; Fri, 4 May 2012 10:24:44 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id D0B5B21F8637 for ; Fri, 4 May 2012 10:24:41 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q44HObdB017838 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 4 May 2012 19:24:37 +0200 (MEST) From: Martin Rex Message-Id: <201205041724.q44HOars012930@fs4113.wdf.sap.corp> To: ajs@anvilwalrusden.com (Andrew Sullivan) Date: Fri, 4 May 2012 19:24:36 +0200 (MEST) In-Reply-To: <20120504112015.GA4929@mail.yitter.info> from "Andrew Sullivan" at May 4, 12 07:20:42 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] Behavior in the face of no answer? 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, 04 May 2012 17:24:45 -0000 Andrew Sullivan wrote: > > Martin Rex wrote: > > > > Andrew Sullivan wrote: > > > > > > Note that there remain _plenty_ of DNS servers deployed in the wild > > > which, if you ask them for an RRTYPE they don't know about, spit up > > > with NOTIMP, SERVFAIL, and all manner of other crappy nonsense. > > > > You seem to be unaware that returning SERVFAIL and more so NOTIMP > > to requests for unknown RRTYPES is *PERFECTLY* conformant with > > rfc1034/rfc1035. So if anything is _broken_, its clients who can > > not cope with such responses (as can be seen with the IPv6 dualstack > > in Windows2003). > > I'm not unaware of this (although I think there is rather less > consensus about the correctness of those RCODE responses than you seem > to be suggesting). I just think it's crappy. Not at all crappy, it's perfectly valid. If you look at this: http://tools.ietf.org/html/std13 that is an IETF "Full Standard" (and the above does not even mention any updates at all). > > RFC 3597 was published in 2003. So what? That seems to be a totally irrelevant RFC. The document itself is only proposed, so it pales in comparison to STD, but what's the real issue, there is not the slightest sign that it has anything to do with STD13! There is neither meta-data nor any mentioning in the Abstract/Intro that this document is supposed to apply to STD13 (rather than being just another optional and irrelevant extension). > > There is no excuse any more for a server of any sort to be > incapable of handling unknown RRTYPEs. Just the opposite. According to the IETF process, STD13 clearly suggests that NOTIMP is the most reasonable response to a request for an unknown RRTYPE. > > I get the arguments about > provisioning systems, and I think they're real problems. But by now, > if your _server_ doesn't handle unknown RRTYPEs it is plainly garbage, > and ought to be off the Net. I don't know what documents are looking at, but STD13 is pretty clear, your _clients_ are the ones that are broken. > > The fundamental problem, of course, is that people who are told to go > develop a DNS server in a weekend read RFC 1034 and RFC 1035 -- = STD13. That is what standards at maturity level "full standard" were made for. > > usually selectively, it appears to me -- and nothing else. I wish I > had a good idea about what to do about this. (That's all I'll say > about it here, though, because it's plainly off-topic.) Follow the IETF process. So first of all, the same housekeeping that was done with 821 -> 2821 -> 5321 822 -> 2822 -> 5322 will have to be done for DNS, i.e. all real(!!) updates&changes that are relevant to the base DNS standard will have to be merged into a new set of 2-3 documents and "completely replace" STD13. After that is accomplished, it will take 10-15 years for the installed base of STD13 to die of age or get updated. -Martin From paul@cypherpunks.ca Fri May 4 10:39:21 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24AC121E8018 for ; Fri, 4 May 2012 10:39:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.535 X-Spam-Level: X-Spam-Status: No, score=-0.535 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HOST_MISMATCH_COM=0.311, RDNS_DYNAMIC=0.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 kRvznvQun+IM for ; Fri, 4 May 2012 10:39:20 -0700 (PDT) Received: from letoams.cypherpunks.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) by ietfa.amsl.com (Postfix) with ESMTP id A1C2F11E8073 for ; Fri, 4 May 2012 10:39:20 -0700 (PDT) Received: by letoams.cypherpunks.ca (Postfix, from userid 500) id 8C47E855F6; Fri, 4 May 2012 13:39:19 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by letoams.cypherpunks.ca (Postfix) with ESMTP id 7DD11803A3; Fri, 4 May 2012 13:39:19 -0400 (EDT) Date: Fri, 4 May 2012 13:39:19 -0400 (EDT) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: Andrew Sullivan In-Reply-To: <20120504112922.GB4929@mail.yitter.info> Message-ID: References: <0526D60A-3F1B-4C55-9796-256BC2556AAB@vpnc.org> <20120503223745.GC1804@mail.yitter.info> <20120504021044.GB4560@mail.yitter.info> <20120504023602.GA4683@mail.yitter.info> <20120504112922.GB4929@mail.yitter.info> User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: dane@ietf.org Subject: Re: [dane] Behavior in the face of no answer? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 04 May 2012 17:39:21 -0000 On Fri, 4 May 2012, Andrew Sullivan wrote: > As a client, you could be making a decision about what is more likely: > > 1. The attacker is able to undermine some CA. > > 2. The attacker is actually on-path and going to undermine my > connection. > > In many cases, one might decide that (1) is more likely than (2), and > therefore decide that TLSA is a better thing to rely on. During > deployment, however, one might be willing to think that (1) is less > likely than, "I am in a coffee shop, and these people bought crappy > infrastructure." In that case, one might want to be able to fall back > to the way we actually do this today. Where "fall back" in this case means, "click OK to the 10 certificate warnings popping up from my facebook, twitter, encrypted.google.com and other tabs" that just got MITM's to the coffee shop "press ok to continue" portal page on a self signed cert on port 443. That scenario is lost with PKIX as well as TLSA. > I imagine that, over time, the tolerance for the broken infrastructure > will go down, and the fall-back decision will be less and less > attractive. But if the protocol says that once a client supports > TLSA, any not-fully-modern DNS environment just means "no TLS", then > we will be promulgating a standard that cannot be deployed. We might > as well not publish it. >From the protocol point of view, this should be a hard fail. However, I do not believe in the soft vs hard fail distinction in browsers, and those vendors seem to implement things more in a scale from silently ignore to adding more red colour depending on how hard they believe the failure to be. Overriding a protocol hard fail is really the overriding local policy of the application. But in the protocol specification, hard fail should mean hard fail, and it should not take that local policy into account. Paul From paul@cypherpunks.ca Fri May 4 10:41:28 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADAE821F85F6 for ; Fri, 4 May 2012 10:41:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.535 X-Spam-Level: X-Spam-Status: No, score=-0.535 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HOST_MISMATCH_COM=0.311, RDNS_DYNAMIC=0.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 RSZnGF2AQ2HI for ; Fri, 4 May 2012 10:41:28 -0700 (PDT) Received: from letoams.cypherpunks.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) by ietfa.amsl.com (Postfix) with ESMTP id 458E321F858F for ; Fri, 4 May 2012 10:41:28 -0700 (PDT) Received: by letoams.cypherpunks.ca (Postfix, from userid 500) id E5B29855F7; Fri, 4 May 2012 13:41:27 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by letoams.cypherpunks.ca (Postfix) with ESMTP id D7BA3803A3; Fri, 4 May 2012 13:41:27 -0400 (EDT) Date: Fri, 4 May 2012 13:41:27 -0400 (EDT) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: Nicholas Weaver In-Reply-To: <2DDB5448-6A34-4D68-9421-4505CCC71A1A@icsi.berkeley.edu> Message-ID: References: <0526D60A-3F1B-4C55-9796-256BC2556AAB@vpnc.org> <20120503223745.GC1804@mail.yitter.info> <20120504021044.GB4560@mail.yitter.info> <20120504023602.GA4683@mail.yitter.info> <20120504112922.GB4929@mail.yitter.info> <2DDB5448-6A34-4D68-9421-4505CCC71A1A@icsi.berkeley.edu> User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dane@ietf.org Subject: Re: [dane] Behavior in the face of no answer? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 04 May 2012 17:41:28 -0000 On Fri, 4 May 2012, Nicholas Weaver wrote: > This is why browser's have given up on the other solution for the bad CA problem: Certificate Revocation Lists. Because an attacker can block the CRL check, and the CRL check is NOT mandatory (they are unreliable enough that its not treated as a hard fail), CRLs are useless for blocking attackers. But CRLs are cached, so once you got it from a working connection, it does offer some protection once you move into a hostile network and you already have the cached CRL of the cert they try to use on you. > DNSSEC at all requires client validation, and client validation REQUIRES that the client be able to bypass the significant-probability-broken recursive resolver already. DANE doesn't really add to that: If the client can fetch DNSSEC signed records, TLSA won't be a problem. Unless specifically targetted and filtered (or not understood) Paul From paul@cypherpunks.ca Fri May 4 10:43:07 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 146D611E8073 for ; Fri, 4 May 2012 10:43:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.535 X-Spam-Level: X-Spam-Status: No, score=-0.535 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HOST_MISMATCH_COM=0.311, RDNS_DYNAMIC=0.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 ZZof8qBHqrXm for ; Fri, 4 May 2012 10:43:06 -0700 (PDT) Received: from letoams.cypherpunks.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) by ietfa.amsl.com (Postfix) with ESMTP id 53B6A21F85FC for ; Fri, 4 May 2012 10:43:05 -0700 (PDT) Received: by letoams.cypherpunks.ca (Postfix, from userid 500) id 6816A855F7; Fri, 4 May 2012 13:43:05 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by letoams.cypherpunks.ca (Postfix) with ESMTP id 5B2A6803A3; Fri, 4 May 2012 13:43:05 -0400 (EDT) Date: Fri, 4 May 2012 13:43:05 -0400 (EDT) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: Andrew Sullivan In-Reply-To: <20120504130846.GC4929@mail.yitter.info> Message-ID: References: <0526D60A-3F1B-4C55-9796-256BC2556AAB@vpnc.org> <20120503223745.GC1804@mail.yitter.info> <20120504021044.GB4560@mail.yitter.info> <20120504023602.GA4683@mail.yitter.info> <20120504112922.GB4929@mail.yitter.info> <2DDB5448-6A34-4D68-9421-4505CCC71A1A@icsi.berkeley.edu> <20120504130846.GC4929@mail.yitter.info> User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dane@ietf.org Subject: Re: [dane] Behavior in the face of no answer? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 04 May 2012 17:43:07 -0000 On Fri, 4 May 2012, Andrew Sullivan wrote: > But I note that in my DNSSEC Trigger application, I have the ability > to turn it off -- and sometimes it disables itself. It should never disable itself. Please try to reproduce with verbosity turned on full in dnssec-trigger.conf and get us the output. Paul From paul@cypherpunks.ca Fri May 4 10:46:18 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7677121F8567 for ; Fri, 4 May 2012 10:46:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.535 X-Spam-Level: X-Spam-Status: No, score=-0.535 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HOST_MISMATCH_COM=0.311, RDNS_DYNAMIC=0.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 b3BZBXna4AGH for ; Fri, 4 May 2012 10:46:18 -0700 (PDT) Received: from letoams.cypherpunks.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) by ietfa.amsl.com (Postfix) with ESMTP id 0A21D21F8566 for ; Fri, 4 May 2012 10:46:18 -0700 (PDT) Received: by letoams.cypherpunks.ca (Postfix, from userid 500) id AD074855F9; Fri, 4 May 2012 13:46:17 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by letoams.cypherpunks.ca (Postfix) with ESMTP id 9B167855F8; Fri, 4 May 2012 13:46:17 -0400 (EDT) Date: Fri, 4 May 2012 13:46:17 -0400 (EDT) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: Warren Kumari In-Reply-To: <3FF36EBA-F8B1-4D66-BA00-E8E36A7E449D@kumari.net> Message-ID: References: <0526D60A-3F1B-4C55-9796-256BC2556AAB@vpnc.org> <20120503223745.GC1804@mail.yitter.info> <20120504021044.GB4560@mail.yitter.info> <20120504023602.GA4683@mail.yitter.info> <20120504112922.GB4929@mail.yitter.info> <20120504144426.GD4929@mail.yitter.info> <3FF36EBA-F8B1-4D66-BA00-E8E36A7E449D@kumari.net> User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dane@ietf.org Subject: Re: [dane] Behavior in the face of no answer? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 04 May 2012 17:46:18 -0000 On Fri, 4 May 2012, Warren Kumari wrote: > So, how does the WG feel about a knob that can be turned to choose behavior? Something that can be set for the less secure manner for now, and then (the default) changed later? > Security conscious / at risk folk would be able to turn the knob now... The knob is already there and called "local policy override" And we'll have this discussion all over again for HASTLS, if that ever proceeds. Paul From ekr@rtfm.com Fri May 4 12:00:08 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D4F621F8669 for ; Fri, 4 May 2012 12:00:07 -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 8Ixbb-2iq2zT for ; Fri, 4 May 2012 12:00:06 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 34B4C21F865B for ; Fri, 4 May 2012 12:00:06 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so2707742vcb.31 for ; Fri, 04 May 2012 12:00:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=ZegA+U3jCsavBBKIuEWHpvN3A0qj9hmPrxx1dCHHNm8=; b=WCAjTi85IQELfcnB+0ppoj3bN3UnFhBh0dVLw7eCqr9VpAlCsUjVGzVIwnaz/+MKjk 9uwBZgvr7kZj/KRdV0/KnvPkeRE8ZMwP+q/zHC2uM3fgBLu4FyUFB2VqjoEYJTT1l97e SPH1+qWQdz/IfeHHp2JJuDrsj2h3ar9nS4hYvt2FrIYeDps2qs9wwXjPuakzo0mcdqN8 eRxLL8FhmgBQVYkk/qzKCcL90+6wNOulnQG4Yt22po0OJ4BogsDdgtiwWh7awFj6MFAk 0Si4BlvHicCDUiBztV5PxabnSFiIXSx25pynPvPDVUf0VXyNU85OqoKn60nGNdVkn70b NDCQ== Received: by 10.52.74.69 with SMTP id r5mr2672971vdv.110.1336158005741; Fri, 04 May 2012 12:00:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.19.233 with HTTP; Fri, 4 May 2012 11:59:25 -0700 (PDT) X-Originating-IP: [63.245.220.224] In-Reply-To: <20120504165512.GC7394@mail.yitter.info> References: <20120503223745.GC1804@mail.yitter.info> <20120504021044.GB4560@mail.yitter.info> <20120504023602.GA4683@mail.yitter.info> <20120504112922.GB4929@mail.yitter.info> <20120504144426.GD4929@mail.yitter.info> <20120504165512.GC7394@mail.yitter.info> From: Eric Rescorla Date: Fri, 4 May 2012 11:59:25 -0700 Message-ID: To: Andrew Sullivan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkLOXf/yDfQCk1ea/drxNhL1ka97lqDs1w4r50lbtpDlbPik2txNWkKOtNCw2oo1OQtUdGv Cc: dane@ietf.org Subject: Re: [dane] Behavior in the face of no answer? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 04 May 2012 19:00:08 -0000 On Fri, May 4, 2012 at 9:55 AM, Andrew Sullivan wr= ote: > On Fri, May 04, 2012 at 08:10:40AM -0700, Eric Rescorla wrote: >> > we usually call "NODATA". =A0The case I mentioned yesterday, where AD = is >> > set and the upstream doesn't give you the DNSSEC data and you have a >> > NODATA response is, AFAICT, just a case where there is no TLSA RRset >> > and shouldn't result in TLS failure. >> >> But the problem is that this is indistinguishable from the case where th= ere >> *was* a TLSA RRSET and you have a network attacker. > > It certainly isn't. =A0If you're depending on your upstream validator, > you need to trust it. =A0If you don't trust it, don't depend on the > upstream, in which case you're not going to offload validation. > > A NODATA answer is _not_ just like "no response at all" if the answer > passed validation, and if it didn't pass the the specification already > covers this case. I'm sorry, I think we're still talking past each other. If you treat non-response the same way as you treat a validated empty RRSET, then a network attacker can get the same effect (i.e., no DANE checks) by simple suppressing DNS resolution. -Ekr From mrex@sap.com Fri May 4 12:02:25 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A321D21F8438 for ; Fri, 4 May 2012 12:02:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.06 X-Spam-Level: X-Spam-Status: No, score=-10.06 tagged_above=-999 required=5 tests=[AWL=0.189, 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 q+ar3sd6gx+Z for ; Fri, 4 May 2012 12:02:19 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 0F3F721F8421 for ; Fri, 4 May 2012 12:02:18 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q44J2HEa001890 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 4 May 2012 21:02:17 +0200 (MEST) From: Martin Rex Message-Id: <201205041902.q44J2B3F018135@fs4113.wdf.sap.corp> To: ekr@rtfm.com (Eric Rescorla) Date: Fri, 4 May 2012 21:02:11 +0200 (MEST) In-Reply-To: from "Eric Rescorla" at May 4, 12 09:08:53 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] Behavior in the face of no answer? 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, 04 May 2012 19:02:26 -0000 Eric Rescorla wrote: > > Before we discuss how to proceed, I think it would be useful to get > agreement on the security analysis. Analysis (about what the attacker could do) is correct, but ... > > I claim that for Usages 0 and 1, treating TLSA non-response as if no > TLSA records exist means that DANE adds minmal/no security value for > those usages. If people disagree with that, I do not fully agree to the conclusion. With the exact same logic, when comparing DV-certs to EV-certs, you could say that EV-certs add minimal/no security value. I believe it is OK for DANE to be a building block for security, rather than a security silver bullet (something I believe doesn't exist). What value is offered depends entirely on whether you use that extra information of entirely ignore it. If it's ignored, then there is no value, and that should not come as a surprise. Web Browsers provide visual cues to differentiate DV/EV-certs (since very few users look at the certificate details. Another possibility (previously mentioned) would be to get rid of the PKIX-style Alzheimer approach to security and memorize characteristics from previous encounters with peers an reuse those memories on re-encounters, similar to how evolution taught mammals develop trust relationships. Any new IETF protocol that treats smooth migration of the installed base as serious and important as IPv6 does it for users of IPv4, will see a similarly rapid migration&adoption of the technology by consumers that IPv6 has been seeing over the last decade. -Martin From ekr@rtfm.com Fri May 4 12:06:00 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B54F21F8484 for ; Fri, 4 May 2012 12:06:00 -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=[AWL=-0.000, 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 n5CumCl1rVmb for ; Fri, 4 May 2012 12:06:00 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id D116921F847F for ; Fri, 4 May 2012 12:05:59 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so2712155vcb.31 for ; Fri, 04 May 2012 12:05:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=JLSEC3q5U6rPMQUm9yUnxatlCcmQqF/2IyRBZrjCmj8=; b=DcsziQ/W3ZdYAAqcEMgnXbY7peLOhNyU4wj9Jb086K2qGqtbwRUNZlso9t1lyVjNb+ KmaVqBz6aNULdzdTGZktYV7LuxQGKPT08FqXTqXbbX0ibFT6fVmt/TRtm97XQFdTjdXj CzPQIRj76CZqnC33wA6/EiKEZTLHerEDBlAaQd2rYUl+FZTMZaWJYy+qOn3EJW+qMQW0 rIZ61Wx0mMuoRcfF3rBi7J8A5JH53sdqTUnToQraixY9CsPztbXOncnc7/CiF5wArbez JNTr8wpf72I1+DtTge1xNJZ2vkV2EJR41MBAaQK14sSrPz2DyLP1R1kLJ2iz2a65y/om HlDg== Received: by 10.220.38.200 with SMTP id c8mr4625287vce.28.1336158359379; Fri, 04 May 2012 12:05:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.19.233 with HTTP; Fri, 4 May 2012 12:05:19 -0700 (PDT) X-Originating-IP: [63.245.220.224] In-Reply-To: <201205041902.q44J2B3F018135@fs4113.wdf.sap.corp> References: <201205041902.q44J2B3F018135@fs4113.wdf.sap.corp> From: Eric Rescorla Date: Fri, 4 May 2012 12:05:19 -0700 Message-ID: To: mrex@sap.com Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmcfZqVTifr7Qczuqn+bpje7lMwBWAoezU3KezF5X0VQWNkaOeNQdcRqlBRwDg2u4esfN5u Cc: dane@ietf.org Subject: Re: [dane] Behavior in the face of no answer? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 04 May 2012 19:06:00 -0000 On Fri, May 4, 2012 at 12:02 PM, Martin Rex wrote: > Eric Rescorla wrote: >> >> Before we discuss how to proceed, I think it would be useful to get >> agreement on the security analysis. > > Analysis (about what the attacker could do) is correct, but ... > >> >> I claim that for Usages 0 and 1, treating TLSA non-response as if no >> TLSA records exist means that DANE adds minmal/no security value for >> those usages. If people disagree with that, > > I do not fully agree to the conclusion. > With the exact same logic, when comparing DV-certs to EV-certs, you > could say that EV-certs add minimal/no security value. It's precisely for this reason that EV certs add minimal security value. > Web Browsers provide visual cues to differentiate DV/EV-certs (since > very few users look at the certificate details. There's very little evidence that users treat these indicia differently. Adding yet another indicator seems to make the cognitive overload problem even worse. -Ekr From ekr@rtfm.com Fri May 4 12:13:18 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6F6A21F85A0 for ; Fri, 4 May 2012 12:13:18 -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 Bqqlw331fEb8 for ; Fri, 4 May 2012 12:13:18 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id EC67F21F8598 for ; Fri, 4 May 2012 12:13:17 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so2712596vbb.31 for ; Fri, 04 May 2012 12:13:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=Bfros3ab15yRph2JkljgVpgDc1GlBV93p9fEddpxa+k=; b=aiGpHcUmBe925JxnUF0FyT7nFcHou6Ss1g5xGhRFtHEXwh9t7+X7fOXgX8G1QLaoZL 5zlrcn+2VcvQrFD6FBhOCgi+fMwqtN3FFQyL/xIpW5O/8b0xiQx8ZJMx/+dCVBH7nndw KeqZIlUvcerJWpbKwuxyMYQ+BNy0kAcI6QEl0ELaiVyXl7Azy5De5rhqqarDICabfrOf Ov5Smod2Abtk8jCXPJlldFNKN+H37kMDZErBDPeXB+SMDATK9/hbs6I0v8QTuJ8jEYyC sLCv+vfBybCd/+txuEXIS6af+NarYI5oHaFrZtE0kk3tJKHrBvNM1a7o3qcm9pwr3dPH 1w1A== Received: by 10.52.68.204 with SMTP id y12mr3656485vdt.53.1336158797491; Fri, 04 May 2012 12:13:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.19.233 with HTTP; Fri, 4 May 2012 12:12:37 -0700 (PDT) X-Originating-IP: [63.245.220.224] In-Reply-To: References: <201205041902.q44J2B3F018135@fs4113.wdf.sap.corp> From: Eric Rescorla Date: Fri, 4 May 2012 12:12:37 -0700 Message-ID: To: mrex@sap.com Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQl+Cn4HaGrmMA+5auJAthBiUhx0e9Q5aZ80WfWc0NcXnMeFVbc9wiObyc39KQd+7sVrYdCE Cc: dane@ietf.org Subject: Re: [dane] Behavior in the face of no answer? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 04 May 2012 19:13:18 -0000 On Fri, May 4, 2012 at 12:05 PM, Eric Rescorla wrote: > On Fri, May 4, 2012 at 12:02 PM, Martin Rex wrote: >> Eric Rescorla wrote: >>> >>> Before we discuss how to proceed, I think it would be useful to get >>> agreement on the security analysis. >> >> Analysis (about what the attacker could do) is correct, but ... >> >>> >>> I claim that for Usages 0 and 1, treating TLSA non-response as if no >>> TLSA records exist means that DANE adds minmal/no security value for >>> those usages. If people disagree with that, >> >> I do not fully agree to the conclusion. >> With the exact same logic, when comparing DV-certs to EV-certs, you >> could say that EV-certs add minimal/no security value. > > It's precisely for this reason that EV certs add minimal security value. I should mention that there are potentially settings in which they add more security value, e.g., EV-lock. Also, at least in principle they allow a user to have some trust in the organization name as opposed to the DN, which is not something that DANE provides. -Ekr From ietf@augustcellars.com Fri May 4 12:28:41 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB8B121F8637 for ; Fri, 4 May 2012 12:28:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.584 X-Spam-Level: X-Spam-Status: No, score=-3.584 tagged_above=-999 required=5 tests=[AWL=0.015, 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 5AqxIHZ3GVQR for ; Fri, 4 May 2012 12:28:41 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id E158521F8620 for ; Fri, 4 May 2012 12:28:40 -0700 (PDT) Received: from Tobias (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id 72BE72CA75; Fri, 4 May 2012 12:28:40 -0700 (PDT) From: "Jim Schaad" To: "'Scott Schmit'" , References: <201204121903.q3CJ3ucF026698@new.toad.com> <9605FDF6-096D-4159-96A6-16549E8371AB@nic.cz> <20120504031222.GA6541@odin.ulthar.us> In-Reply-To: <20120504031222.GA6541@odin.ulthar.us> Date: Fri, 4 May 2012 12:27:35 -0700 Message-ID: <031501cd2a2b$f8a81de0$e9f859a0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIvktlb52thh8zHwaw81Pgk0daBYQL2WUKRAyVhHUqVxFRX8A== Content-Language: en-us Subject: Re: [dane] Inappropriate Section 8 of draft-ietf-dane-protocol-19.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2012 19:28:41 -0000 The changes to the paragraph in section 8 are fine with me. Jim > -----Original Message----- > From: dane-bounces@ietf.org [mailto:dane-bounces@ietf.org] On Behalf = Of > Scott Schmit > Sent: Thursday, May 03, 2012 8:12 PM > To: dane@ietf.org > Subject: Re: [dane] Inappropriate Section 8 of = draft-ietf-dane-protocol-19.txt >=20 > On Thu, May 03, 2012 at 05:47:43PM +0200, Ondrej Sur wrote: > > John, > > > > you have raised this issue several times and yet I haven't seen a > > supportive message from other WG members. On the other hand Jim > > Schaad[1] and me have opposed your view of the issue. > > > > 1. https://www.ietf.org/mail-archive/web/dane/current/msg04566.html > > > > Chairs think the text is fine as it is. If the other WG members > > disagree, please speak now. And again I would like to see a = modified > > text if you are going to support the assertion that we favor CAs = (Type > > 0/1). >=20 > I'll express support for John's technical arguments against section = 8.1. > I don't have a strong position about the paragraph in section 8, but I = think we > can improve it by changing this: >=20 > The client's full trust of a certificate retrieved from a TLSA = record > with a certificate usage of 2 or 3 may be a matter of local policy. > While such trust is limited to the specific domain name for which = the > TLSA query was made, local policy may deny the trust or further > restrict the conditions under which that trust is permitted. >=20 > to this: >=20 > Generators of TLSA records should be aware that the client's full > trust of a certificate association retrieved from a TLSA record may > be a matter of local policy. While such trust is limited to the > specific domain name, protocol, and port for which the TLSA query = was > made, local policy may deny to trust the certificate (e.g., due to > weak cryptography), just as with PKIX trust anchors. >=20 > Rationale behind the changes: > * Local policy could disable the TA or an intermediate certificate = that > is being used for type 0 or 1, too, though I guess you could argue > that that's not new to DANE. >=20 > * I'm not sure how you can meaningfully "further restrict" the > conditions of use the conditions of use that isn't already = applicable > to PKIX. DANE already restricts conditions of use to the > name/proto/port tuple. >=20 > * One of the defenses of the paragraph was that clients can already > disable PKIX trust anchors, so I made that comparison explicit. >=20 > This seems to be more accurate, at the least, and may be more = acceptable to > John. >=20 >=20 > As for section 8.1, I agree that it's incorrect technically. Martin = Rex has also > expressed agreement: > https://www.ietf.org/mail-archive/web/dane/current/msg04649.html > I didn't chime in at the time because I assumed that John and Martin's > technical arguments made the case adequately that section 8.1 makes an > invalid comparison--but evidentally not, so I'll throw my arguments = into the > ring: >=20 > The more-direct parallel to be drawn between CAs and DANE is the = DNSSEC > signing chain itself -- the DS + KSK DNSKEY records for a domain form = the > equivalent of a name-constrained PKIX CA certificate, and ZSK DNSKEY > records are equivalent to PKIX self-issued certificates. (Where = "certificate" is > defined as a binding of a name and a key. Obviously, PKIX certificates = allow > significantly more information to be included into the signed = content.) TLSA > records are like name-constrained PKIX certificates as well (though = bound to > a specific protocol/port, which I'm not sure if PKIX can do). >=20 > Despite this, Section 8.1 compares PKIX CAs to external DNSSEC = validators. > That's not unlike comparing DNSSEC records to web browser PKIX = certificate > validation software (though at least web browsers run on the same > machine). >=20 > IIUC, section 8.1 was added to compare the risks of the PKIX CA = security > model as typically implemented (large trust anchor list) to DANE, but = IMHO > fails to do so for the reasons stated above. >=20 > To be charitable, perhaps it was thought that external validation is = how > DNSSEC is typically implemented today, so it makes for a fair = comparison. > That said, with DANE, the client can simply eliminate all of the risks = of > external validation on the DANE side of the comparison by being > implemented differently. The same cannot be said, in practice, for = PKIX CAs. > One could make the comparison to a compromise of .com's DNSKEYs, but > section 8.1 doesn't even address that risk. >=20 > If the above, and the technical arguments from John and Martin remain > unconvincing, I'd like you to please explain your position. >=20 > If you accept the above, the next question is what to replace it with. > I think this outline covers the ground: >=20 > * The risk of compromise > * Number of keys that can be compromised to achieve the desired = effect > * Likelihood of being a target of attack > * Security measures in place to prevent attack success (HSM, access = to > key, authentication of data to be signed) > * Qualifications/experience of people securing the keys > * ...Other?? > * The impact of such a compromise (#s of names affected) > * The likelihood of detection > * ...Other?? >=20 > I could propose some text to flesh out the outline (except the = "other"s, as I > don't know what they are yet :-) ), but before I start, I'd like to = know that I > wouldn't be wasting my time. >=20 > -- > Scott Schmit From mrex@sap.com Fri May 4 12:33:44 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BBCE21F8622 for ; Fri, 4 May 2012 12:33:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.062 X-Spam-Level: X-Spam-Status: No, score=-10.062 tagged_above=-999 required=5 tests=[AWL=0.187, 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 Feg-WQ38hewL for ; Fri, 4 May 2012 12:33:44 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id A5A4721F8620 for ; Fri, 4 May 2012 12:33:43 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q44JXfIp024416 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 4 May 2012 21:33:41 +0200 (MEST) From: Martin Rex Message-Id: <201205041933.q44JXfBv019935@fs4113.wdf.sap.corp> To: ekr@rtfm.com (Eric Rescorla) Date: Fri, 4 May 2012 21:33:41 +0200 (MEST) In-Reply-To: from "Eric Rescorla" at May 4, 12 12:05:19 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] Behavior in the face of no answer? 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, 04 May 2012 19:33:44 -0000 Eric Rescorla wrote: > > Martin Rex wrote: > > > > Eric Rescorla wrote: > >> > >> Before we discuss how to proceed, I think it would be useful to get > >> agreement on the security analysis. > > > > Analysis (about what the attacker could do) is correct, but ... > > > >> > >> I claim that for Usages 0 and 1, treating TLSA non-response as if no > >> TLSA records exist means that DANE adds minmal/no security value for > >> those usages. If people disagree with that, > > > > I do not fully agree to the conclusion. > > With the exact same logic, when comparing DV-certs to EV-certs, you > > could say that EV-certs add minimal/no security value. > > It's precisely for this reason that EV certs add minimal security value. > > > > Web Browsers provide visual cues to differentiate DV/EV-certs (since > > very few users look at the certificate details. > > There's very little evidence that users treat these indicia differently. > Adding yet another indicator seems to make the cognitive overload > problem even worse. Browsers memorize megabytes of useless stuff, but seem to have difficulties memorizing a few kilobytes of useful and important stuff. Currently, the value of EV-certs is vitally dependent on cooperation of the human brain of the user at the TLS client to either react to the visual cues or look at & perform plausibility checks on the additionally vetted information, comparing it to the original intent. Browsers (and to some extent TLS clients in general) should be able to perform some of that all by themselves rather than "outsourcing" it to users, since users quickly become bored by such activity and start cheating/ignoring. As long as the majority of Web-sites & their users get to login-pages by clicking a URL on a page received through HTTP rather than HTTPS, the hard-fail instead of a soft-fail DANE discussion does not add value, but instead might turn out to be a coffin nail. -Martin From ajs@anvilwalrusden.com Fri May 4 12:44:39 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06EA521E8042 for ; Fri, 4 May 2012 12:44:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.63 X-Spam-Level: X-Spam-Status: No, score=-2.63 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 do5jYUVmrMvB for ; Fri, 4 May 2012 12:44:38 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id EB1E121E8029 for ; Fri, 4 May 2012 12:44:37 -0700 (PDT) Received: from mail.yitter.info (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 62DD81ECB41C for ; Fri, 4 May 2012 19:44:37 +0000 (UTC) Date: Fri, 4 May 2012 15:44:35 -0400 From: Andrew Sullivan To: dane@ietf.org Message-ID: <20120504194132.GF7394@mail.yitter.info> References: <20120504021044.GB4560@mail.yitter.info> <20120504023602.GA4683@mail.yitter.info> <20120504112922.GB4929@mail.yitter.info> <20120504144426.GD4929@mail.yitter.info> <20120504165512.GC7394@mail.yitter.info> 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] Behavior in the face of no answer? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 04 May 2012 19:44:39 -0000 On Fri, May 04, 2012 at 11:59:25AM -0700, Eric Rescorla wrote: > I'm sorry, I think we're still talking past each other. If you treat > non-response > the same way as you treat a validated empty RRSET, then a network > attacker can get the same effect (i.e., no DANE checks) by simple > suppressing DNS resolution. I likely wasn't clear enough. I was not advocating treating non-response that way. I was saying that "non-response" and "an empty answer" (i.e. an empty answer section in the DNS response) are not to be treated the same; somewhere else in the discussion it seemed that they were being collapsed. I believe it is possible to get a useful response that has nothing in the Answer, Authority, and Additional sections only if you trust your upstream, you trust the connection somehow, you set CD=0, and you get AD=1 on the response. In that case, I believe it is a legitimate NODATA response (though I don't know of any implementation that works this way), and it is validated. It means there is no TLSA record at that owner name, just like if you used CD=1 and got back an answer with (say) an NSEC3 record in the Authority. If I sound tentative, it's because I haven't in the last 48 hours walked through the relevant RFCs in order to be perfectly sure that this is what a NODATA response looks like for a non-validated security-aware stub relying on upstream validation. But I think this is right. In any case, if all of those necessary conditions aren't satisfied, then the answer is either bogus or indeterminate and you should react accordingly. This is already covered in the existing draft. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From ekr@rtfm.com Fri May 4 12:48:56 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E249A21E805A for ; Fri, 4 May 2012 12:48:56 -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 x-28wLCXeVzd for ; Fri, 4 May 2012 12:48:56 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 45C0121E8056 for ; Fri, 4 May 2012 12:48:56 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so2738621vbb.31 for ; Fri, 04 May 2012 12:48:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=ee81fCm49VdGnf1VI8n0sxoR76YLSSvciaFeGLmoN5U=; b=FLDwJFhARAp45x9f1doP02FpXMsKT+cweA40herbM03VDbeC9qIkQ2fyBInfhNCrPW kNClIDEtot6bZSBuHmzxnd77fhwpYwYgh7Opqd3yC9V2oAqu69wbevp2zS2J48bTlEwh a9asPVuYtK4WN8A35dVkFXX9Cy8tTNf1iWxH1seEoTaxzE/2Xpi9DT9IVAjTBMGJYhfp WxXD49zQztssg2vlGxSTl6Kyxk8cCxv4kTWAqjb+ffXG9S/xtASxR6qa4uHQAk4d91+S 8q+YNgEIBFBttylYFT+744hpZFaRbUGKnIEofY5lP0tOfaHdMryYnX+p+8HEjvizu8FS TB+A== Received: by 10.52.70.209 with SMTP id o17mr1703269vdu.11.1336160935586; Fri, 04 May 2012 12:48:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.19.233 with HTTP; Fri, 4 May 2012 12:48:15 -0700 (PDT) X-Originating-IP: [63.245.220.224] In-Reply-To: <20120504194132.GF7394@mail.yitter.info> References: <20120504021044.GB4560@mail.yitter.info> <20120504023602.GA4683@mail.yitter.info> <20120504112922.GB4929@mail.yitter.info> <20120504144426.GD4929@mail.yitter.info> <20120504165512.GC7394@mail.yitter.info> <20120504194132.GF7394@mail.yitter.info> From: Eric Rescorla Date: Fri, 4 May 2012 12:48:15 -0700 Message-ID: To: Andrew Sullivan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlg68dq9qvJobZu+PTkpWJHAdgLFcPec841+yFvG99drgQcKmsIAIKXZ1cs5oCgEJduxjKs Cc: dane@ietf.org Subject: Re: [dane] Behavior in the face of no answer? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 04 May 2012 19:48:57 -0000 On Fri, May 4, 2012 at 12:44 PM, Andrew Sullivan w= rote: > On Fri, May 04, 2012 at 11:59:25AM -0700, Eric Rescorla wrote: > >> I'm sorry, I think we're still talking past each other. If you treat >> non-response >> the same way as you treat a validated empty RRSET, then a network >> attacker can get the same effect (i.e., no DANE checks) by simple >> suppressing DNS resolution. > > I likely wasn't clear enough. =A0I was not advocating treating > non-response that way. =A0 I was saying that "non-response" and "an > empty answer" (i.e. an empty answer section in the DNS response) > are not to be treated the same; somewhere else in the discussion it > seemed that they were being collapsed. > > I believe it is possible to get a useful response that has nothing in > the Answer, Authority, and Additional sections only if you trust your > upstream, you trust the connection somehow, you set CD=3D0, and you get > AD=3D1 on the response. =A0In that case, I believe it is a legitimate > NODATA response (though I don't know of any implementation that works > this way), and it is validated. =A0It means there is no TLSA record at > that owner name, just like if you used CD=3D1 and got back an answer > with (say) an NSEC3 record in the Authority. =A0If I sound tentative, > it's because I haven't in the last 48 hours walked through the > relevant RFCs in order to be perfectly sure that this is what a NODATA > response looks like for a non-validated security-aware stub relying on > upstream validation. =A0But I think this is right. > > In any case, if all of those necessary conditions aren't satisfied, > then the answer is either bogus or indeterminate and you should react > accordingly. =A0This is already covered in the existing draft. Now I'm really confused. What do you think the draft says about "no respons= e" -Ekr From paul@nohats.ca Fri May 4 13:03:56 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D91F621E8039 for ; Fri, 4 May 2012 13:03:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.528 X-Spam-Level: X-Spam-Status: No, score=-0.528 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HOST_MISMATCH_COM=0.311, RDNS_DYNAMIC=0.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 EuWVWkdeUGzQ for ; Fri, 4 May 2012 13:03:56 -0700 (PDT) Received: from letoams.cypherpunks.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) by ietfa.amsl.com (Postfix) with ESMTP id 5D35D21E8012 for ; Fri, 4 May 2012 13:03:55 -0700 (PDT) Received: by letoams.cypherpunks.ca (Postfix, from userid 500) id E9A1D855F9; Fri, 4 May 2012 16:03:54 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by letoams.cypherpunks.ca (Postfix) with ESMTP id DA8B5855F8; Fri, 4 May 2012 16:03:54 -0400 (EDT) Date: Fri, 4 May 2012 16:03:54 -0400 (EDT) From: Paul Wouters To: Andrew Sullivan In-Reply-To: <20120504194132.GF7394@mail.yitter.info> Message-ID: References: <20120504021044.GB4560@mail.yitter.info> <20120504023602.GA4683@mail.yitter.info> <20120504112922.GB4929@mail.yitter.info> <20120504144426.GD4929@mail.yitter.info> <20120504165512.GC7394@mail.yitter.info> <20120504194132.GF7394@mail.yitter.info> User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dane@ietf.org Subject: Re: [dane] Behavior in the face of no answer? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 04 May 2012 20:03:57 -0000 On Fri, 4 May 2012, Andrew Sullivan wrote: > I believe it is possible to get a useful response that has nothing in > the Answer, Authority, and Additional sections only if you trust your > upstream, you trust the connection somehow, you set CD=0, and you get > AD=1 on the response. In that case, I believe it is a legitimate > NODATA response (though I don't know of any implementation that works > this way), and it is validated. How many months until Rogers (or OpenDNS, or...) starts spitting out AD=1 on their DNS rewriting schemes? >From RFC3655: The AD bit SHOULD be used by the local resolver if and only if it has been explicitly configured to trust the remote resolver. The AD bit SHOULD be ignored when the recursive name server is not trusted. So your scenario really only happens when you bring up a VPN and connect back to a trusted network. At that point, you can trust the AD bit, but you also no longer have DNS breakage/filtering happening, so the point is moot. The other scenario is an application talking to the local resolver that returns the AD bit, which just moves the DNS connectivity problem from the application to the local resolver, but runs into the same hard/soft fail issue, except the browser knows even less about the reasons for the failure or success, and can give less feedback to the user to make an educated guess as to the severity of the failure to be hard or soft. Regardless, all of this is not DANE specific, and IMHO does not belong in the DANE document. Paul From ajs@anvilwalrusden.com Fri May 4 13:10:47 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75A9B21E803D for ; Fri, 4 May 2012 13:10:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.629 X-Spam-Level: X-Spam-Status: No, score=-2.629 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 QJPicbG+XF1C for ; Fri, 4 May 2012 13:10:47 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id CF7D621E803C for ; Fri, 4 May 2012 13:10:46 -0700 (PDT) Received: from mail.yitter.info (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 B9A031ECB41C for ; Fri, 4 May 2012 20:10:36 +0000 (UTC) Date: Fri, 4 May 2012 16:10:35 -0400 From: Andrew Sullivan To: dane@ietf.org Message-ID: <20120504201030.GH7394@mail.yitter.info> References: <20120504023602.GA4683@mail.yitter.info> <20120504112922.GB4929@mail.yitter.info> <20120504144426.GD4929@mail.yitter.info> <20120504165512.GC7394@mail.yitter.info> <20120504194132.GF7394@mail.yitter.info> 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] Behavior in the face of no answer? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 04 May 2012 20:10:47 -0000 On Fri, May 04, 2012 at 12:48:15PM -0700, Eric Rescorla wrote: > > Now I'm really confused. What do you think the draft says about "no response" Nothing, at the moment. You've made this point quite clear. I thought that's what we were discussing. The draft currently _does_ have something to say about no _answer_ -- i.e. a NODATA DNS response. What that means is that there isn't a TLSA RR at that owner name, so you should use something else (probably traditional TLS processing). Best, a -- Andrew Sullivan ajs@anvilwalrusden.com From nweaver@icsi.berkeley.edu Fri May 4 13:12:13 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 853F421F8531 for ; Fri, 4 May 2012 13:12:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 gjf+I0-phyzq for ; Fri, 4 May 2012 13:12:13 -0700 (PDT) Received: from rock.ICSI.Berkeley.EDU (rock.ICSI.Berkeley.EDU [192.150.186.19]) by ietfa.amsl.com (Postfix) with ESMTP id 1999421F84FF for ; Fri, 4 May 2012 13:12:13 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 033922C4039; Fri, 4 May 2012 13:12:13 -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 DERbDHnyBU-K; Fri, 4 May 2012 13:12:12 -0700 (PDT) Received: from gala.icir.org (gala [192.150.187.49]) (Authenticated sender: nweaver) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id B9FE72C4002; Fri, 4 May 2012 13:12:12 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Nicholas Weaver In-Reply-To: Date: Fri, 4 May 2012 13:12:12 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: <20120504021044.GB4560@mail.yitter.info> <20120504023602.GA4683@mail.yitter.info> <20120504112922.GB4929@mail.yitter.info> <20120504144426.GD4929@mail.yitter.info> <20120504165512.GC7394@mail.yitter.info> <20120504194132.GF7394@mail.yitter.info> To: Paul Wouters X-Mailer: Apple Mail (2.1257) Cc: dane@ietf.org Subject: Re: [dane] Behavior in the face of no answer? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 04 May 2012 20:12:13 -0000 On May 4, 2012, at 1:03 PM, Paul Wouters wrote: > On Fri, 4 May 2012, Andrew Sullivan wrote: > >> I believe it is possible to get a useful response that has nothing in >> the Answer, Authority, and Additional sections only if you trust your >> upstream, you trust the connection somehow, you set CD=0, and you get >> AD=1 on the response. In that case, I believe it is a legitimate >> NODATA response (though I don't know of any implementation that works >> this way), and it is validated. > > How many months until Rogers (or OpenDNS, or...) starts spitting out AD=1 > on their DNS rewriting schemes? Xerocole already says "Just do it"... From ajs@anvilwalrusden.com Fri May 4 13:21:31 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F91D21F8539 for ; Fri, 4 May 2012 13:21:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.629 X-Spam-Level: X-Spam-Status: No, score=-2.629 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 N33bbSqurmBg for ; Fri, 4 May 2012 13:21:30 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 5287921F856A for ; Fri, 4 May 2012 13:21:30 -0700 (PDT) Received: from mail.yitter.info (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 54C281ECB41C for ; Fri, 4 May 2012 20:21:29 +0000 (UTC) Date: Fri, 4 May 2012 16:21:27 -0400 From: Andrew Sullivan To: dane@ietf.org Message-ID: <20120504202121.GJ7394@mail.yitter.info> References: <20120504023602.GA4683@mail.yitter.info> <20120504112922.GB4929@mail.yitter.info> <20120504144426.GD4929@mail.yitter.info> <20120504165512.GC7394@mail.yitter.info> <20120504194132.GF7394@mail.yitter.info> 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] Behavior in the face of no answer? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 04 May 2012 20:21:31 -0000 On Fri, May 04, 2012 at 04:03:54PM -0400, Paul Wouters wrote: > > How many months until Rogers (or OpenDNS, or...) starts spitting out AD=1 > on their DNS rewriting schemes? I wasn't arguing that you should trust it, or that this is a good state of affairs. But we can't write the specification such that it is incompatible with DNSSEC as specified, however little I personally like the AD bit. > So your scenario really only happens when you bring up a VPN and connect > back to a trusted network. At that point, you can trust the AD bit, but > you also no longer have DNS breakage/filtering happening, so the point > is moot. As Martin Rex argues elsewhere in this thread, a NOTIMP response to an RR you don't know is not obviously inconsistent with RFCs 1034 and 1035. Ekr's position would cause a system that depended on intermediate-resolver validation, the AD bit, and a resolver that can't handle unknown RRTYPEs, to cause all TLS negotiation to fail for TLSA-aware clients. This isn't "will cause TLSA not to work", it's "can't use TLS at all on that system". I have no idea whether there are such configurations in the wild, but they're pefectly acceptable under the standards we have. It seems to me, therefore, that one needs to be able to turn off TLSA use under such circumstances, if we're going to say that such failures must "fail hard". > The other scenario is an application talking to the local resolver that > returns the AD bit, which just moves the DNS connectivity problem from the > application to the local resolver, but runs into the same hard/soft > fail issue, except the browser knows even less about the reasons for > the failure or success, and can give less feedback to the user to make > an educated guess as to the severity of the failure to be hard or soft. Yes. A -- Andrew Sullivan ajs@anvilwalrusden.com From ynir@checkpoint.com Fri May 4 13:40:58 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB55821F8464 for ; Fri, 4 May 2012 13:40:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.346 X-Spam-Level: X-Spam-Status: No, score=-10.346 tagged_above=-999 required=5 tests=[AWL=0.253, BAYES_00=-2.599, 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 rckNcCz6Eg2D for ; Fri, 4 May 2012 13:40:58 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 8F27421F85D0 for ; Fri, 4 May 2012 13:40:57 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id q44KesFB025890; Fri, 4 May 2012 23:40:54 +0300 X-CheckPoint: {4FA44C92-0-1B221DC2-2FFFF} Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 4 May 2012 23:40:54 +0300 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Fri, 4 May 2012 23:40:52 +0300 From: Yoav Nir To: Eric Rescorla Date: Fri, 4 May 2012 23:40:56 +0300 Thread-Topic: [dane] Behavior in the face of no answer? Thread-Index: Ac0qNjIdkbPgRswGTAySxIRgt0qMUg== Message-ID: References: <201205041902.q44J2B3F018135@fs4113.wdf.sap.corp> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean x-cpdlp: 1167c1a607a90c806a8fd7d893b4307a2add4847ab Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-KSE-AntiSpam-Interceptor-Info: protection disabled X-KSE-Antivirus-Interceptor-Info: scan successful X-KSE-Antivirus-Info: Clean Cc: "dane@ietf.org" Subject: Re: [dane] Behavior in the face of no answer? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 04 May 2012 20:40:58 -0000 On May 4, 2012, at 10:05 PM, Eric Rescorla wrote: > On Fri, May 4, 2012 at 12:02 PM, Martin Rex wrote: >> Web Browsers provide visual cues to differentiate DV/EV-certs (since >> very few users look at the certificate details. >=20 > There's very little evidence that users treat these indicia differently. > Adding yet another indicator seems to make the cognitive overload > problem even worse. An informal, non-scientific survey of some of my coworkers revealed that ab= out half hadn't noticed green indicators, some had, but had no idea what th= ese were, and a few noticed that the company name was indicated. None knew = that the CA was actually vouching for the company name being correct. These= are people who work at a security vendor. I think you'd do worse in the ge= neral population. Yoav= From paul@cypherpunks.ca Fri May 4 13:52:57 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0038A21F854E for ; Fri, 4 May 2012 13:52:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.535 X-Spam-Level: X-Spam-Status: No, score=-0.535 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HOST_MISMATCH_COM=0.311, RDNS_DYNAMIC=0.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 WCxO469BwfVG for ; Fri, 4 May 2012 13:52:56 -0700 (PDT) Received: from letoams.cypherpunks.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) by ietfa.amsl.com (Postfix) with ESMTP id 20F7A21F854D for ; Fri, 4 May 2012 13:52:55 -0700 (PDT) Received: by letoams.cypherpunks.ca (Postfix, from userid 500) id 6AEE8855F9; Fri, 4 May 2012 16:52:55 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by letoams.cypherpunks.ca (Postfix) with ESMTP id 5555A855F8; Fri, 4 May 2012 16:52:55 -0400 (EDT) Date: Fri, 4 May 2012 16:52:55 -0400 (EDT) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: Andrew Sullivan In-Reply-To: <20120504202121.GJ7394@mail.yitter.info> Message-ID: References: <20120504023602.GA4683@mail.yitter.info> <20120504112922.GB4929@mail.yitter.info> <20120504144426.GD4929@mail.yitter.info> <20120504165512.GC7394@mail.yitter.info> <20120504194132.GF7394@mail.yitter.info> <20120504202121.GJ7394@mail.yitter.info> User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: dane@ietf.org Subject: Re: [dane] Behavior in the face of no answer? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 04 May 2012 20:52:57 -0000 On Fri, 4 May 2012, Andrew Sullivan wrote: > This isn't "will cause TLSA not to work", it's > "can't use TLS at all on that system". But you cannot tell the difference between maliciously "not supporting" and "pretending to not support so you will not request TLSA". > I have no idea whether there > are such configurations in the wild, but they're pefectly acceptable > under the standards we have. It seems to me, therefore, that one > needs to be able to turn off TLSA use under such circumstances, if > we're going to say that such failures must "fail hard". These can certainly happen. But an application or device can then use its own validating resolver. This only becomes a problem when there is both a broken old DNS deployment, AND additional firewalling preventing one from bypassing that old DNS deployment. I'm willing to call those networks "broken by design", and I'm fine with hard failing. But I don't have to man a support desk. This does assume that if an application that wants to support TLSA would have to have a validating resolver built in to fall back to, along with a root key. Alternatively, the local policy could be that if generic DNSSEC is failing (eg a query to the a root server for a root zone record fails to come back with proper RRSIG/NSEC* records) that no attempts to use TLSA are done. But that is a local policy decision, one that I would override to hard fail (but my father probably would be ok with) Paul From stpeter@stpeter.im Fri May 4 13:58:55 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDB6611E8083; Fri, 4 May 2012 13:58:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.534 X-Spam-Level: X-Spam-Status: No, score=-102.534 tagged_above=-999 required=5 tests=[AWL=0.065, 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 ReVGOWyo7pJh; Fri, 4 May 2012 13:58:55 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 137E711E8072; Fri, 4 May 2012 13:58:55 -0700 (PDT) Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id E686440058; Fri, 4 May 2012 15:13:59 -0600 (MDT) Message-ID: <4FA4430D.3090902@stpeter.im> Date: Fri, 04 May 2012 14:58:53 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Paul Hoffman References: <4F96D157.7020504@isode.com> <4F96D21A.7080006@isode.com> <4F96D2AB.6090509@stpeter.im> <4FA2E1F2.6060406@stpeter.im> <2B6494C5-4BB1-4159-967C-483094BDC0C7@vpnc.org> <4FA2FB94.204@stpeter.im> <07511DD9-AED9-4E67-B162-6D353C550788@vpnc.org> In-Reply-To: <07511DD9-AED9-4E67-B162-6D353C550788@vpnc.org> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: The IESG , "apps-discuss@ietf.org Discuss" , IETF DANE WG list Subject: Re: [dane] [apps-discuss] AppsDir review of draft-ietf-dane-protocol-19 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 04 May 2012 20:58:55 -0000 On 5/3/12 3:59 PM, Paul Hoffman wrote: > On May 3, 2012, at 2:41 PM, Peter Saint-Andre wrote: > >> On 5/3/12 2:34 PM, Paul Hoffman wrote: >>> On May 3, 2012, at 12:52 PM, Peter Saint-Andre wrote: >>> >>>> Perhaps this is simply a difference between folks who look at >>>> things from the DNS perspective and folks who look at things from >>>> the apps perspective (as users of DNS). All sorts of application >>>> protocols are being updated to support IDNs. Those applications >>>> will need to know how to translate their IDNs (which might consist >>>> of U-labels) into a form that can be placed into the DNS. To make >>>> things perfectly clear, I'm just suggesting that we add a sentence >>>> or two warning those who write code for application protocols using >>>> DANE that they might need to convert U-labels into A-labels. I'll >>>> work to propose specific text today or tomorrow. >>> >>> >>> I'll be interested to see that. I cannot see how anyone reading >>> Section 3 of RFC 5891 could think that they would *not* need to >>> convert to A-labels before looking up something in the DNS. If you >>> are saying that every post-5891 protocol that defines a new RRtype >>> must say "and if you are going to look up the domain name in the DNS, >>> convert to A-labels first", that's fine, but it seems kinda late to >>> start saying that. >> >> Not everyone is as smart as you are. > > If you believe that developers who are using IDNs are not following the easiest-to-read section of RFC 5891, the issue is much larger than just DANE. I propose that is not a DANE issue at all. Maybe, maybe not. I leave that up to the working group. Borrowing a bit from RFC 6066 (thanks to Martin Rex for the pointer), I suggest that we could add the following parenthetical statement to point 3 in Section 3... OLD 3. The domain name is appended to the result of step 2 to complete the prepared domain name. NEW 3. The domain name is appended to the result of step 2 to complete the prepared domain name. (The domain name is the fully qualified DNS domain name [RFC1035] of the TLS server and is represented as a byte string using ASCII encoding without a trailing dot; this enables support for internationalized domain names through the use of A-labels as defined in [RFC5890].) Peter -- Peter Saint-Andre https://stpeter.im/ From ynir@checkpoint.com Fri May 4 14:02:51 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 615E121F847E for ; Fri, 4 May 2012 14:02:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.352 X-Spam-Level: X-Spam-Status: No, score=-10.352 tagged_above=-999 required=5 tests=[AWL=0.247, BAYES_00=-2.599, 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 rcfPdxpv8rxc for ; Fri, 4 May 2012 14:02:50 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 7189121F847C for ; Fri, 4 May 2012 14:02:50 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id q44L2Vsi029148; Sat, 5 May 2012 00:02:44 +0300 X-CheckPoint: {4FA451A2-8-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Sat, 5 May 2012 00:02:30 +0300 From: Yoav Nir To: Adam Langley Date: Sat, 5 May 2012 00:02:33 +0300 Thread-Topic: [dane] Behavior in the face of no answer? Thread-Index: Ac0qOTes5LQJh05ATY6/rGA7ycvepw== Message-ID: <13B3A487-2C93-4958-8FE6-63132742181E@checkpoint.com> References: <0526D60A-3F1B-4C55-9796-256BC2556AAB@vpnc.org> <20120503223745.GC1804@mail.yitter.info> <20120504021044.GB4560@mail.yitter.info> <20120504023602.GA4683@mail.yitter.info> <20120504112922.GB4929@mail.yitter.info> <20120504144426.GD4929@mail.yitter.info> <3FF36EBA-F8B1-4D66-BA00-E8E36A7E449D@kumari.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean x-cpdlp: 11ae4d7cc4d232b4b8f4e7dae71f168237c961ba9b Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dane@ietf.org" Subject: Re: [dane] Behavior in the face of no answer? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 04 May 2012 21:02:51 -0000 On May 4, 2012, at 7:18 PM, Adam Langley wrote: > On Fri, May 4, 2012 at 12:08 PM, Eric Rescorla wrote: >> Before we discuss how to proceed, I think it would be useful to get agre= ement >> on the security analysis. I claim that for Usages 0 and 1, treating >> TLSA non-response >> as if no TLSA records exist means that DANE adds minmal/no security >> value for those >> usages. >=20 > I believe that you're completely correct. >=20 > Browsers are not going to enable DANE hard fail in the short or medium > term because of the fraction of clients that have broken DNS and can't > fetch the records. > However, browsers are not the world. Other clients, which may benefit > from a smaller, more controlled, deployment may be able to enforce > DANE hard-fail and see security benefits. >=20 > I would personally suggest that the spec requires hard fail, or at > least discusses the fact that, without hard-fail, the security > benefits are moot. Implementations frequently ignore requirements in > specs, but rarely add to them! I disagree. I would hate for this group to publish a spec with a MUST level= requirement that we fully expect all browsers to ignore. At best this shou= ld be a SHOULD with an explanation that not doing this eliminates usages 0 = and 1.=20 I can think of a heuristic for this. Suppose we have to domain names, one w= ith a valid TLSA record, the other without. The browser could query the DNS= for a TLSA record for both of these, and if both answers are received, the= n TLSA works. In that case, a timeout can rightfully become a hard fail. If= no response is received to either query, then either the DNS is broken or = the attack is already going on. In that case the user should be warned with= the likelier of the two - that the DNS seems to be broken, and certain kin= ds of attack are possible. Yoav= From paul.hoffman@vpnc.org Fri May 4 14:10:57 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9542021F8532; Fri, 4 May 2012 14:10:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.548 X-Spam-Level: X-Spam-Status: No, score=-102.548 tagged_above=-999 required=5 tests=[AWL=0.051, 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 H-et4MvXiMQ0; Fri, 4 May 2012 14:10:57 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 0229821F84B2; Fri, 4 May 2012 14:10:56 -0700 (PDT) Received: from [10.20.30.102] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q44LAtCb056796 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 4 May 2012 14:10:56 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <4FA4430D.3090902@stpeter.im> Date: Fri, 4 May 2012 14:10:55 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4C883441-D7DD-4BE8-80C4-61C276CC8840@vpnc.org> References: <4F96D157.7020504@isode.com> <4F96D21A.7080006@isode.com> <4F96D2AB.6090509@stpeter.im> <4FA2E1F2.6060406@stpeter.im> <2B6494C5-4BB1-4159-967C-483094BDC0C7@vpnc.org> <4FA2FB94.204@stpeter.im> <07511DD9-AED9-4E67-B162-6D353C550788@vpnc.org> <4FA4430D.3090902@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1257) Cc: "apps-discuss@ietf.org Discuss" , IETF DANE WG list Subject: Re: [dane] [apps-discuss] AppsDir review of draft-ietf-dane-protocol-19 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 04 May 2012 21:10:57 -0000 On May 4, 2012, at 1:58 PM, Peter Saint-Andre wrote: > Borrowing a bit from RFC 6066 (thanks to Martin Rex for the pointer), = I > suggest that we could add the following parenthetical statement to = point > 3 in Section 3... >=20 > OLD > 3. The domain name is appended to the result of step 2 to complete > the prepared domain name. >=20 > NEW >=20 > 3. The domain name is appended to the result of step 2 to complete > the prepared domain name. (The domain name is the fully > qualified DNS domain name [RFC1035] of the TLS server and is > represented as a byte string using ASCII encoding without a > trailing dot; this enables support for internationalized > domain names through the use of A-labels as defined in > [RFC5890].) Thank you for finally suggesting text. :-) This seems fine to me, doesn't change anything technically, appears in = the right place, and doesn't feel gratuitous. --Paul Hoffman From ajs@crankycanuck.ca Fri May 4 15:07:21 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 545B621F855A; Fri, 4 May 2012 15:07:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.543 X-Spam-Level: X-Spam-Status: No, score=-2.543 tagged_above=-999 required=5 tests=[AWL=0.056, 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 BHOUJjBozJnv; Fri, 4 May 2012 15:07:20 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id CBC4121F8559; Fri, 4 May 2012 15:07:20 -0700 (PDT) Received: from crankycanuck.ca (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 8D9D21ECB41C; Fri, 4 May 2012 22:07:19 +0000 (UTC) Date: Fri, 4 May 2012 18:07:17 -0400 From: Andrew Sullivan To: Peter Saint-Andre Message-ID: <20120504220713.GR7394@crankycanuck.ca> References: <4F96D157.7020504@isode.com> <4F96D21A.7080006@isode.com> <4F96D2AB.6090509@stpeter.im> <4FA2E1F2.6060406@stpeter.im> <2B6494C5-4BB1-4159-967C-483094BDC0C7@vpnc.org> <4FA2FB94.204@stpeter.im> <07511DD9-AED9-4E67-B162-6D353C550788@vpnc.org> <4FA4430D.3090902@stpeter.im> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4FA4430D.3090902@stpeter.im> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: IETF DANE WG list , Paul Hoffman , "apps-discuss@ietf.org Discuss" , The IESG Subject: Re: [dane] [apps-discuss] AppsDir review of draft-ietf-dane-protocol-19 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 04 May 2012 22:07:21 -0000 Hi, On Fri, May 04, 2012 at 02:58:53PM -0600, Peter Saint-Andre wrote: > 3. The domain name is appended to the result of step 2 to complete > the prepared domain name. (The domain name is the fully > qualified DNS domain name [RFC1035] of the TLS server and is > represented as a byte string using ASCII encoding without a > trailing dot; this enables support for internationalized > domain names through the use of A-labels as defined in > [RFC5890].) I don't understand that definition of "the domain name". What we appear to be discussing here is how you prepare the presentation format for the domain name; "represented as a byte string using ASCII encoding" doesn't make a lot of sense to me in this context. In particular, you don't need any of the text starting with "represented" and ending with the semicolon, because what you're describing there isn't properly speaking a domain name at all. It's a relative domain name, which happens to be relative to the root. It's also in presentation format, which is irrelevant for DNS query purposes, because we don't send queries in presentation format. It sounds like the key point you want to make is that IDNA2008 labels MUST be in A-label format before transformation. Is that it? A -- Andrew Sullivan ajs@crankycanuck.ca From mrex@sap.com Fri May 4 15:24:59 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D9EF21F84D8; Fri, 4 May 2012 15:24:59 -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 wowv-UxmRu-v; Fri, 4 May 2012 15:24:58 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 4E57721F84D0; Fri, 4 May 2012 15:24:58 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q44MOpx2011769 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 5 May 2012 00:24:51 +0200 (MEST) From: Martin Rex Message-Id: <201205042224.q44MOo03029933@fs4113.wdf.sap.corp> To: ajs@crankycanuck.ca (Andrew Sullivan) Date: Sat, 5 May 2012 00:24:50 +0200 (MEST) In-Reply-To: <20120504220713.GR7394@crankycanuck.ca> from "Andrew Sullivan" at May 4, 12 06:07:17 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: iesg@ietf.org, apps-discuss@ietf.org, paul.hoffman@vpnc.org, dane@ietf.org Subject: Re: [dane] [apps-discuss] AppsDir review of 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, 04 May 2012 22:24:59 -0000 Andrew Sullivan wrote: > > On Fri, May 04, 2012 at 02:58:53PM -0600, Peter Saint-Andre wrote: > > 3. The domain name is appended to the result of step 2 to complete > > the prepared domain name. (The domain name is the fully > > qualified DNS domain name [RFC1035] of the TLS server and is > > represented as a byte string using ASCII encoding without a > > trailing dot; this enables support for internationalized > > domain names through the use of A-labels as defined in > > [RFC5890].) > > I don't understand that definition of "the domain name". What we > appear to be discussing here is how you prepare the presentation > format for the domain name; "represented as a byte string using ASCII > encoding" doesn't make a lot of sense to me in this context. > > In particular, you don't need any of the text starting with > "represented" and ending with the semicolon, because what you're > describing there isn't properly speaking a domain name at all. It's a > relative domain name, which happens to be relative to the root. It's > also in presentation format, which is irrelevant for DNS query > purposes, because we don't send queries in presentation format. > > It sounds like the key point you want to make is that IDNA2008 labels > MUST be in A-label format before transformation. Is that it? We added similar text like the above to rfc6066 (TLS extensions) for the description of the extension "Server name indication" here: http://tools.ietf.org/html/rfc6066#page-7 3rd paragraph on page 7 Could you point to an existing document that contains a suitable 1-paragraph desciption that you believe fits better here? I don't think that we should be inventing a new description for ever new document, but preferably re-use what is already there. -Martin From ajs@anvilwalrusden.com Fri May 4 15:33:22 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17A2C21E8015; Fri, 4 May 2012 15:33:22 -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 s8iKDUjn2cJd; Fri, 4 May 2012 15:33:21 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 8F9E921E8012; Fri, 4 May 2012 15:33:21 -0700 (PDT) Received: from crankycanuck.ca (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 BEF9E1ECB41C; Fri, 4 May 2012 22:33:20 +0000 (UTC) Date: Fri, 4 May 2012 18:33:19 -0400 From: Andrew Sullivan Sender: dane-bounces@ietf.org To: Peter Saint-Andre Message-ID: <20120504223314.GU7394@crankycanuck.ca> References: <4F96D157.7020504@isode.com> <4F96D21A.7080006@isode.com> <4F96D2AB.6090509@stpeter.im> <4FA2E1F2.6060406@stpeter.im> <2B6494C5-4BB1-4159-967C-483094BDC0C7@vpnc.org> <4FA2FB94.204@stpeter.im> <07511DD9-AED9-4E67-B162-6D353C550788@vpnc.org> <4FA4430D.3090902@stpeter.im> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4FA4430D.3090902@stpeter.im> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: The IESG , "apps-discuss@ietf.org Discuss" , IETF DANE WG list Subject: Re: [dane] [apps-discuss] AppsDir review of draft-ietf-dane-protocol-19 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 04 May 2012 22:33:22 -0000 [resending from an actually subscribed address. Apologies] Hi, On Fri, May 04, 2012 at 02:58:53PM -0600, Peter Saint-Andre wrote: > 3. The domain name is appended to the result of step 2 to complete > the prepared domain name. (The domain name is the fully > qualified DNS domain name [RFC1035] of the TLS server and is > represented as a byte string using ASCII encoding without a > trailing dot; this enables support for internationalized > domain names through the use of A-labels as defined in > [RFC5890].) I don't understand that definition of "the domain name". What we appear to be discussing here is how you prepare the presentation format for the domain name; "represented as a byte string using ASCII encoding" doesn't make a lot of sense to me in this context. In particular, you don't need any of the text starting with "represented" and ending with the semicolon, because what you're describing there isn't properly speaking a domain name at all. It's a relative domain name, which happens to be relative to the root. It's also in presentation format, which is irrelevant for DNS query purposes, because we don't send queries in presentation format. It sounds like the key point you want to make is that IDNA2008 labels MUST be in A-label format before transformation. Is that it? A -- Andrew Sullivan ajs@anvilwalrusden.com From mrex@sap.com Fri May 4 15:37:50 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 513A321F84F8; Fri, 4 May 2012 15:37:50 -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 q3m-tok2M3VV; Fri, 4 May 2012 15:37:49 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 73E2321F84F0; Fri, 4 May 2012 15:37:49 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q44MbknI013307 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 5 May 2012 00:37:46 +0200 (MEST) From: Martin Rex Message-Id: <201205042237.q44Mbj23000744@fs4113.wdf.sap.corp> To: mrex@sap.com Date: Sat, 5 May 2012 00:37:45 +0200 (MEST) In-Reply-To: <201205042224.q44MOo03029933@fs4113.wdf.sap.corp> from "Martin Rex" at May 5, 12 00:24:50 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: ajs@crankycanuck.ca, dane@ietf.org, iesg@ietf.org, apps-discuss@ietf.org, paul.hoffman@vpnc.org Subject: Re: [dane] [apps-discuss] AppsDir review of 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, 04 May 2012 22:37:50 -0000 Martin Rex wrote: > > Andrew Sullivan wrote: > > > > On Fri, May 04, 2012 at 02:58:53PM -0600, Peter Saint-Andre wrote: > > > 3. The domain name is appended to the result of step 2 to complete > > > the prepared domain name. (The domain name is the fully > > > qualified DNS domain name [RFC1035] of the TLS server and is > > > represented as a byte string using ASCII encoding without a > > > trailing dot; this enables support for internationalized > > > domain names through the use of A-labels as defined in > > > [RFC5890].) > > > > I don't understand that definition of "the domain name". What we > > appear to be discussing here is how you prepare the presentation > > format for the domain name; "represented as a byte string using ASCII > > encoding" doesn't make a lot of sense to me in this context. > > > > In particular, you don't need any of the text starting with > > "represented" and ending with the semicolon, because what you're > > describing there isn't properly speaking a domain name at all. It's a > > relative domain name, which happens to be relative to the root. It's > > also in presentation format, which is irrelevant for DNS query > > purposes, because we don't send queries in presentation format. > > > > It sounds like the key point you want to make is that IDNA2008 labels > > MUST be in A-label format before transformation. Is that it? > > > We added similar text like the above to rfc6066 (TLS extensions) > for the description of the extension "Server name indication" here: > > http://tools.ietf.org/html/rfc6066#page-7 > > 3rd paragraph on page 7 > > Could you point to an existing document that contains a suitable > 1-paragraph desciption that you believe fits better here? > I don't think that we should be inventing a new description > for ever new document, but preferably re-use what is already there. That "we added to rfc6066" refers to this disussion in the TLS WG: https://www.ietf.org/mail-archive/web/tls/current/msg07233.html Re-reading that paragraph, I realize that the description "fully qualified DNS hostname of the server" is factually incorrect for rfc6066 (I don't know about DANE, though). When used by HTTP-over-TLS, it ought to be the name as used by the client for performing server endpoint identification (rfc2818 or rf6125), and that _can_ be a hostname without domain from a URL!! -Martin From ajs@anvilwalrusden.com Fri May 4 15:38:32 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A313721F84F8; Fri, 4 May 2012 15:38:32 -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 tjafVrGjEyqA; Fri, 4 May 2012 15:38:32 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 2550221F84F0; Fri, 4 May 2012 15:38:32 -0700 (PDT) Received: from crankycanuck.ca (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 CFDAB1ECB41C; Fri, 4 May 2012 22:38:21 +0000 (UTC) Date: Fri, 4 May 2012 18:38:20 -0400 From: Andrew Sullivan To: Martin Rex Message-ID: <20120504223816.GV7394@crankycanuck.ca> References: <20120504220713.GR7394@crankycanuck.ca> <201205042224.q44MOo03029933@fs4113.wdf.sap.corp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201205042224.q44MOo03029933@fs4113.wdf.sap.corp> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: dane@ietf.org, iesg@ietf.org, apps-discuss@ietf.org, paul.hoffman@vpnc.org Subject: Re: [dane] [apps-discuss] AppsDir review of X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 04 May 2012 22:38:33 -0000 On Sat, May 05, 2012 at 12:24:50AM +0200, Martin Rex wrote: > > We added similar text like the above to rfc6066 (TLS extensions) > for the description of the extension "Server name indication" here: The problem in this case, however, is that what the TLSA document is doing is building a QNAME for use in the DNS. None of the description from RFC 6066 is a domain name. Remember, the dot-separated labels are the presentation form, but _not_ what you send on the wire. Dots aren't part of the DNS on the wire. What we want to do for this case is get the QNAME for the DNS. So we take the two labels that come out of steps 1 and 2 in the draft, and put them on the front of the DNS name that we're trying to look up, creating an absolute, fully qualified name that gets sent in the QNAME of the DNS operation. At least I think that's what the section is trying to do. I'm also uncomfortable with the "ASCII" stuff, because DNS labels aren't in ASCII. They're octets. However, ASCII is treated specially in the DNS. (This is one of the sharp edges about the DNS that we'd all like to go back and fix if we could.) A -- Andrew Sullivan ajs@anvilwalrusden.com From sm@resistor.net Fri May 4 15:51:04 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9099021F848A; Fri, 4 May 2012 15:51:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, 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 MOo+QsB8Ajm8; Fri, 4 May 2012 15:51:03 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id D840421F8484; Fri, 4 May 2012 15:51:02 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q44MosIQ028878; Fri, 4 May 2012 15:50:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1336171862; i=@resistor.net; bh=dCK3Jg/dzB8UsGA/Kes7ELu7lJOaB3hllpIZf9kZjYE=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=j2cPhLFpwDleX40wWq6yXwJ47yDfopVIISdVUTk4bRgtYXcI0AG4js4uX/UXcuTpT D4d0xQwioIzm7BPZcvrjct5Umkc0qrC1rFic1eRwl3G96RhZS770LOVy8yakL/UyzP TbqyVuqv/hfK7dzw0ceB2ugtdWv7br3B1BSfHBEE= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1336171862; i=@resistor.net; bh=dCK3Jg/dzB8UsGA/Kes7ELu7lJOaB3hllpIZf9kZjYE=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=xW8Pjb3zz/bOxeA0wwqN+aMlRA2rCzWQQBTi+IUfnydmqrdV+7LdTKpI0q9xU+XKe oqZ5aLtXCypVagoinuO/xAs/PaYRY6fl++eBSEWu1GqC7cMoa7eyNFcEG03mk7/h7H qDBgui4uRTxYcLwO9zmd+X9+6cvnNJmg4AzduiZ4= Message-Id: <6.2.5.6.2.20120504152947.0ab53640@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 04 May 2012 15:50:49 -0700 To: mrex@sap.com From: SM In-Reply-To: <201205042224.q44MOo03029933@fs4113.wdf.sap.corp> References: <20120504220713.GR7394@crankycanuck.ca> <201205042224.q44MOo03029933@fs4113.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: dane@ietf.org, iesg@ietf.org, apps-discuss@ietf.org, paul.hoffman@vpnc.org Subject: Re: [dane] [apps-discuss] AppsDir review of X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 04 May 2012 22:51:04 -0000 Hi Martin, At 15:24 04-05-2012, Martin Rex wrote: >We added similar text like the above to rfc6066 (TLS extensions) >for the description of the extension "Server name indication" here: > > http://tools.ietf.org/html/rfc6066#page-7 > >3rd paragraph on page 7 > >Could you point to an existing document that contains a suitable >1-paragraph desciption that you believe fits better here? I'll skip the tricky question. :-) >I don't think that we should be inventing a new description >for ever new document, but preferably re-use what is already there. The text from that section of RFC 6066 is about FQDNs. RFC 6394 mentions that 'the process of obtaining this "source" domain is application specific [RFC6125]'. It seems like the better choice to keep things easy. It also matches what's in Section 4 of the draft. Regards, -sm From mrex@sap.com Fri May 4 18:43:31 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5A1A21E8018; Fri, 4 May 2012 18:43:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.775 X-Spam-Level: X-Spam-Status: No, score=-9.775 tagged_above=-999 required=5 tests=[AWL=-0.126, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_31=0.6, 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 dxQlSX2FXY9z; Fri, 4 May 2012 18:43: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 C2DFF21F84EE; Fri, 4 May 2012 18:43:30 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q451hRgw017094 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 5 May 2012 03:43:27 +0200 (MEST) From: Martin Rex Message-Id: <201205050143.q451hQnW011408@fs4113.wdf.sap.corp> To: marka@isc.org (Mark Andrews) Date: Sat, 5 May 2012 03:43:26 +0200 (MEST) In-Reply-To: <20120504000220.0F9632063979@drugs.dv.isc.org> from "Mark Andrews" at May 4, 12 10:02:19 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: iesg@ietf.org, apps-discuss@ietf.org, dane@ietf.org Subject: Re: [dane] MX and DANE (Was: AppsDir review of 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, 05 May 2012 01:43:31 -0000 Mark Andrews wrote: > > O. writes: > > > > On 3. 5. 2012, at 17:25, Richard L. Barnes wrote: > > > Oh, this discussion again. > > > > No, it's _not_ that discussion again. I wanted to say that we > > don't _want_ to discuss and fix it in the DANE WG. Somebody fix > > it elsewhere and come back. 100 ack. > > While this isn't be a issue for DANE, DANE actually *removes* the > last known threat, downgrade by filtering/not offering STARTTLS > from the EHLO response, to making MX and STARTTLS work globally as > it provides a method to signal that TLS should be available and as > a consequence you should see a STARTTLS. Please do not confuse DANE with DNSSEC. example: foo.x. IN MX 10 mx.bar.y. mx.bar.y. IN CNAME tweety.baz.z. tweety.baz.z. IN A 0.1.2.3 plus: foo.x. is a DNS-Zone with DNSSEC enabled bar.y. is a DNS-Zone without DNSSEC baz.z. is a DNS-Zone with DNSSEC enabled The DNS software module does not know about MX records and will not look at any of the above. To _me_ this looks like opening a can of worms, not like closing one, and the apps protocols that want such scenarios secured by DNSSEC, will have to design and discuss their desired security architecture, how to perform&implement the various lookups and possible indirections, how to compute the desired result/outcome from the various possibilities leveraged by the DNS magic machinery and describe: - to implementers of the apps protocol how to implement this - to admins of the machines how to configure the various possible scenarios and provide a security considerations about all the potential and non-obvious pitfalls. Btw. in the example above, "mx.bar.y. IN CNAME tweety.baz.z." could have been a DNS reply spoofed by an attacker. I have significant doubts, that DANE is the right forum to discuss any of these very apps-specific characteristics and requirements. And DANE-protocol LC is definitely the wrong time for it (IIRC, the DANE WG tabled this discussion before it got deeply ratholed over it). *I* really do not want to discuss this any further. -Martin From mrex@sap.com Fri May 4 21:38:20 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D139021F845A; Fri, 4 May 2012 21:38:19 -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 Y4GOw9ONtAqh; Fri, 4 May 2012 21:38:18 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 126A521F844E; Fri, 4 May 2012 21:38:17 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q454cDSR002960 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 5 May 2012 06:38:13 +0200 (MEST) From: Martin Rex Message-Id: <201205050438.q454cC0K021676@fs4113.wdf.sap.corp> To: ajs@anvilwalrusden.com (Andrew Sullivan) Date: Sat, 5 May 2012 06:38:12 +0200 (MEST) In-Reply-To: <20120504223816.GV7394@crankycanuck.ca> from "Andrew Sullivan" at May 4, 12 06:38:20 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: dane@ietf.org, iesg@ietf.org, apps-discuss@ietf.org, paul.hoffman@vpnc.org Subject: Re: [dane] [apps-discuss] AppsDir review of 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, 05 May 2012 04:38:20 -0000 Andrew Sullivan wrote: > > On Sat, May 05, 2012 at 12:24:50AM +0200, Martin Rex wrote: > > > > We added similar text like the above to rfc6066 (TLS extensions) > > for the description of the extension "Server name indication" here: > > The problem in this case, however, is that what the TLSA document is > doing is building a QNAME for use in the DNS. None of the description > from RFC 6066 is a domain name. > > Remember, the dot-separated labels are the presentation form, but > _not_ what you send on the wire. Dots aren't part of the DNS on the > wire. > > What we want to do for this case is get the QNAME for the DNS. So we > take the two labels that come out of steps 1 and 2 in the draft, and > put them on the front of the DNS name that we're trying to look up, > creating an absolute, fully qualified name that gets sent in the QNAME > of the DNS operation. > > At least I think that's what the section is trying to do. > > I'm also uncomfortable with the "ASCII" stuff, because DNS labels > aren't in ASCII. They're octets. However, ASCII is treated specially > in the DNS. (This is one of the sharp edges about the DNS that we'd > all like to go back and fix if we could.) Thanks for pointing out the details. I have been an occasional caller of gethostbyname(), and not used libresolv function() like res_query(). Do we expect the target audience (folks implementing DANE protocol) to use an API like that of libresolv's res_query(), where the representation appears to be still a single string rather than individual DNS labels, or that they're caller of even lower APIs? The name that gets prefixed by protocol and port should probably represent an absolute, fully qualified name as is, and be used with res_query? The default behaviour of gethostbyname(), trying completion of a name that doesn't end with a dot/period with (default) domain or entries from a (domain) searchlist (res_search?) would likely risk unpleasant consequences. -Martin From paul.hoffman@vpnc.org Sat May 5 07:22:00 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A307F21F854F; Sat, 5 May 2012 07:22:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.55 X-Spam-Level: X-Spam-Status: No, score=-102.55 tagged_above=-999 required=5 tests=[AWL=0.049, 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 izD-imIIjxhU; Sat, 5 May 2012 07:22:00 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 5C08321F8548; Sat, 5 May 2012 07:21:55 -0700 (PDT) Received: from [10.20.30.102] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q45ELpKW060046 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 5 May 2012 07:21:52 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <20120504223816.GV7394@crankycanuck.ca> Date: Sat, 5 May 2012 07:21:51 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1EF0ACEE-52ED-4BDE-BF34-C995F117783D@vpnc.org> References: <20120504220713.GR7394@crankycanuck.ca> <201205042224.q44MOo03029933@fs4113.wdf.sap.corp> <20120504223816.GV7394@crankycanuck.ca> To: Andrew Sullivan X-Mailer: Apple Mail (2.1257) Cc: The IESG , "apps-discuss@ietf.org Discuss" , IETF DANE WG list Subject: Re: [dane] [apps-discuss] AppsDir review of X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 05 May 2012 14:22:00 -0000 On May 4, 2012, at 3:38 PM, Andrew Sullivan wrote: > On Sat, May 05, 2012 at 12:24:50AM +0200, Martin Rex wrote: >>=20 >> We added similar text like the above to rfc6066 (TLS extensions) >> for the description of the extension "Server name indication" here: >=20 > The problem in this case, however, is that what the TLSA document is > doing is building a QNAME for use in the DNS. None of the description > from RFC 6066 is a domain name. >=20 > Remember, the dot-separated labels are the presentation form, but > _not_ what you send on the wire. Dots aren't part of the DNS on the > wire. =20 >=20 > What we want to do for this case is get the QNAME for the DNS. So we > take the two labels that come out of steps 1 and 2 in the draft, and > put them on the front of the DNS name that we're trying to look up, > creating an absolute, fully qualified name that gets sent in the QNAME > of the DNS operation. =20 >=20 > At least I think that's what the section is trying to do. It is indeed what the section is trying to do. > I'm also uncomfortable with the "ASCII" stuff, because DNS labels > aren't in ASCII. They're octets. However, ASCII is treated specially > in the DNS. (This is one of the sharp edges about the DNS that we'd > all like to go back and fix if we could.) Note that the document explicitly states in the last paragraph of = section 1.2 that "This document only relates to securely associating = certificates for TLS and DTLS with host names". We are not talking just = "domain names" (which are made up of labels of octets) but "host names" = which are made up of labels of ASCII. We were told (wisely) not to try = to reopen this can of worms, so we didn't. As you pointed out, Peter's proposed wording had an issue by mentioning = the "dots". That can easily be fixed. I now propose: OLD 3. The domain name is appended to the result of step 2 to complete the prepared domain name. NEW 3. The domain name is appended to the result of step 2 to complete the prepared domain name. (The domain name is the fully qualified DNS domain name [RFC1035] of the TLS server and is represented as a byte string where each label is encoded using ASCII; this enables support for internationalized domain names through the use of A-labels as defined in [RFC5890].) --Paul Hoffman From ondrej.mikle@nic.cz Sat May 5 18:18:51 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A859421F84EB for ; Sat, 5 May 2012 18:18:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 XhV3SSNxkhNu for ; Sat, 5 May 2012 18:18:51 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id D8EDC21F84D8 for ; Sat, 5 May 2012 18:18:50 -0700 (PDT) Received: from [192.168.0.100] (ip-94-113-0-21.net.upcbroadband.cz [94.113.0.21]) by mail.nic.cz (Postfix) with ESMTPSA id CF3DE13F7B7 for ; Sun, 6 May 2012 03:18:48 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1336267128; bh=s3SkJXjz7OOJyuflYW8cVY/LLSzIkbkjgdjlE6SiW84=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=ZT5j4AWOojj5ZpJqx5txd4EV41cqg1IVD8eRQCq6CQrvZNqv+FiHdJtmcv0xdJmwY rJPJIplf54CoYgukCkdpIAUZBB2aW7Fq0rwkW5deCrls2oJEV2mXwb0tMtqP6b5MHy oZurrl9gdRzoo3exPXHy6ftjKoZ40becjMftSsQg= Message-ID: <4FA5D178.8030405@nic.cz> Date: Sun, 06 May 2012 03:18:48 +0200 From: Ondrej Mikle User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: dane@ietf.org References: <20120504023602.GA4683@mail.yitter.info> <20120504112922.GB4929@mail.yitter.info> <20120504144426.GD4929@mail.yitter.info> <3FF36EBA-F8B1-4D66-BA00-E8E36A7E449D@kumari.net> <6015A12B-8CA9-426B-9AFF-32CD4211DAB5@vpnc.org> <20120504165311.GB7394@mail.yitter.info> In-Reply-To: <20120504165311.GB7394@mail.yitter.info> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Subject: Re: [dane] Behavior in the face of no answer? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 06 May 2012 01:18:51 -0000 On 05/04/2012 06:53 PM, Andrew Sullivan wrote: > On Fri, May 04, 2012 at 09:32:32AM -0700, Paul Hoffman wrote: >> >> My preference is that the spec discuss the issue, propose hard-fail >> as an option, and explain that without hard-fail the benefits for >> usage 0 and 1 can be circumvented but that the client is no worse >> off than without DANE. It's important to emphasize that this is >> about usage 0 and 1, and that a different security analysis applies >> to types 2 and 3 (well, 3 certainly; I need to think about 2). > > I agree with this. > >> I would prefer that we not require hard fail while assuming some >> implementers will not follow our requirement, > > I also strongly agree with this. I also agree with the above points. I'll chime in with some data: we've been collecting data (with Ralph Holz) on behavior of various authoritative NS (about 15 RR types for each domain, with DNSSEC enabled). >From the ongoing scan, out of 70M currently finished .com domains, SERVFAILs appeared for ~8.6M distinct domains. My interpretation of such high percentage is that those are forgotten/unmaintained domains (for comparison, percentage for .cz TLD is < 1%). We'll cross-check the failing answers against lists such as Alexa top 1M (to see how "relevant" they are) and do a rescan of the failures. >From the preliminary data it follows that no vendor of a TLS client would honor hard-fail if it was a "MUST" (though I don't like the possible downgrade attacks). Another goal of the scan is to find statistics on average/maximum size of DNSSEC-stapled structure (as Jim Schaad asked - https://www.ietf.org/mail-archive/web/dane/current/msg04694.html), which is heavily influenced by number of zones traversed by CNAMEs/DNAMEs (ask away if you're interested in other stats). Ondrej Mikle From stpeter@stpeter.im Sun May 6 18:07:33 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08F8821F853D; Sun, 6 May 2012 18:07:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.544 X-Spam-Level: X-Spam-Status: No, score=-102.544 tagged_above=-999 required=5 tests=[AWL=0.055, 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 UaGpl+WuXKvD; Sun, 6 May 2012 18:07:32 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 7D00721F852B; Sun, 6 May 2012 18:07:32 -0700 (PDT) Received: from [192.168.0.3] (unknown [216.17.175.160]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 96E674005B; Sun, 6 May 2012 19:22:44 -0600 (MDT) Message-ID: <4FA72053.6000704@stpeter.im> Date: Sun, 06 May 2012 19:07:31 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Paul Hoffman References: <20120504220713.GR7394@crankycanuck.ca> <201205042224.q44MOo03029933@fs4113.wdf.sap.corp> <20120504223816.GV7394@crankycanuck.ca> <1EF0ACEE-52ED-4BDE-BF34-C995F117783D@vpnc.org> In-Reply-To: <1EF0ACEE-52ED-4BDE-BF34-C995F117783D@vpnc.org> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "apps-discuss@ietf.org Discuss" , The IESG , IETF DANE WG list Subject: Re: [dane] [apps-discuss] AppsDir review of X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 07 May 2012 01:07:33 -0000 On 5/5/12 8:21 AM, Paul Hoffman wrote: > On May 4, 2012, at 3:38 PM, Andrew Sullivan wrote: > >> On Sat, May 05, 2012 at 12:24:50AM +0200, Martin Rex wrote: >>> >>> We added similar text like the above to rfc6066 (TLS extensions) >>> for the description of the extension "Server name indication" here: >> >> The problem in this case, however, is that what the TLSA document is >> doing is building a QNAME for use in the DNS. None of the description >> from RFC 6066 is a domain name. >> >> Remember, the dot-separated labels are the presentation form, but >> _not_ what you send on the wire. Dots aren't part of the DNS on the >> wire. >> >> What we want to do for this case is get the QNAME for the DNS. So we >> take the two labels that come out of steps 1 and 2 in the draft, and >> put them on the front of the DNS name that we're trying to look up, >> creating an absolute, fully qualified name that gets sent in the QNAME >> of the DNS operation. >> >> At least I think that's what the section is trying to do. > > It is indeed what the section is trying to do. > >> I'm also uncomfortable with the "ASCII" stuff, because DNS labels >> aren't in ASCII. They're octets. However, ASCII is treated specially >> in the DNS. (This is one of the sharp edges about the DNS that we'd >> all like to go back and fix if we could.) > > Note that the document explicitly states in the last paragraph of section 1.2 that "This document only relates to securely associating certificates for TLS and DTLS with host names". We are not talking just "domain names" (which are made up of labels of octets) but "host names" which are made up of labels of ASCII. We were told (wisely) not to try to reopen this can of worms, so we didn't. > > As you pointed out, Peter's proposed wording had an issue by mentioning the "dots". That can easily be fixed. I now propose: > > OLD > 3. The domain name is appended to the result of step 2 to complete > the prepared domain name. > > NEW > > 3. The domain name is appended to the result of step 2 to complete > the prepared domain name. (The domain name is the fully > qualified DNS domain name [RFC1035] of the TLS server and is > represented as a byte string where each label is encoded > using ASCII; this enables support for internationalized > domain names through the use of A-labels as defined in > [RFC5890].) Works for me. Peter From hallam@gmail.com Mon May 7 05:52:22 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A97621F8567; Mon, 7 May 2012 05:52:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.122 X-Spam-Level: X-Spam-Status: No, score=-3.122 tagged_above=-999 required=5 tests=[AWL=-0.423, 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 Fnpym6T7f4gb; Mon, 7 May 2012 05:52:20 -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 8EDD021F84FD; Mon, 7 May 2012 05:52:19 -0700 (PDT) Received: by yenq13 with SMTP id q13so382280yen.31 for ; Mon, 07 May 2012 05:52:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=h/POpsZdxhIPWhmrROjywBhd64y2YyR/oG/A3ofh5ZE=; b=jBoqT71dN6WKZo03CaqvQX3JCP6VqKV/u1h5te6lQOWGreHdoOfrGfAMGwYdbFREE0 /QypZg8cOre/GWUm7U/LUvzNQ1SSDzeJFjedQZx9Oobz1H93hEs7XLxEAOaL0hpvE06E 7PHpyuJ+XmLQ9z9Pr6Iewp1gMTxmZN9ZM6NKtC5LpRkeFuxeZhveFaI/nA0Gkrdygztm MIc64VkrEq3a0yw38JfqwDJPM+UGZk5aVF83T9abLiAU0roXiCKGO6Ass4V4XVqlcgE1 Jr6zXrazLwnNnXPIQXQB5p0tm8REdzoPBlNXtP7MD5JE1G6jvs15t9jolB8wak3JaP/w TGtw== MIME-Version: 1.0 Received: by 10.60.32.204 with SMTP id l12mr15424776oei.47.1336395138962; Mon, 07 May 2012 05:52:18 -0700 (PDT) Received: by 10.182.41.165 with HTTP; Mon, 7 May 2012 05:52:18 -0700 (PDT) In-Reply-To: <27A5BF91-C082-4FB4-8D6E-B68F725440EC@nic.cz> References: <01OE8FJG30ZM00ZUIL@mauve.mrochek.com> <201204130359.q3D3xlG0007556@fs4113.wdf.sap.corp> <01OE9150IMNI00ZUIL@mauve.mrochek.com> <27A5BF91-C082-4FB4-8D6E-B68F725440EC@nic.cz> Date: Mon, 7 May 2012 08:52:18 -0400 Message-ID: From: Phillip Hallam-Baker To: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable Cc: ietf@ietf.org, dane@ietf.org Subject: Re: [dane] Last Call: (The DNS-Based X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 07 May 2012 12:52:22 -0000 So far I don't see any interest in production deployment other than our own plans so I don't think your working group consensus has relevance. The point I am making applies to all forms of security policy, not just DANE. If the party enforcing a security policy is not the same as the party asserting it, the party enforcing that policy can and will treat it as advice. The big problem with all security policy mechanisms is that the policy records have to be maintained separately from the system being administered. That will inevitably lead to incompatibilities between the policy and the practice. Attempting to rely on raw, uncurated security policy records is a certain recipe for failure. You can try to order the policy enforcement point around in the Request For Comments, but here the comment is going to be 'we don't want to do that'. On Thu, May 3, 2012 at 11:54 AM, Ond=F8ej Sur=FD wrote= : > Phillip, > > I haven't seen any consensus for the change of the document, thus > chairs think the document is fine as it is. > > Ondrej > > On 25. 4. 2012, at 15:52, Phillip Hallam-Baker wrote: > >> I have raised these comments in the WG numerous times, I am raising >> them here as I do not believe that anyone is going to implement the >> specification as currently described. >> >> As currently written, the specification attempts to mandate client >> behavior when DANE records are encountered in ways that are outside >> the scope of interoperability. While the objective of the authors is >> to mandate certain behavior they consider necessary for security >> reasons, what they end up doing is attempting to substitute their own >> judgement for that of the security experts who advise the client >> providers. >> >> >> Client providers already ignore significant parts of the PKIX >> specification because they do not meet their performance criteria. In >> particular virtually all browsers treat inability to obtain OCSP >> certificate status as being equivalent to 'good'. This is a terrible >> security design, one that every CA would like to see change. But it is >> also a fact that we have been trying to get this changed for ten years >> without success. >> >> The browser providers do not hard fail on OCSP because doing so would >> require them to wait for the OCSP response within the TLS handshake >> and this is considered an unacceptable performance degradation. I do >> not like this situation, but I can either play Canute and tell the >> tide to turn or I can consider it to be a fact and try to work round >> it. >> >> >> DANE attempts to fix PKI with another mandate that is certain to be >> ignored. In this case the mandate is to establish a critical >> dependency on the DNSSEC trust chain despite the easily observed fact >> that less than 97% of DNS resolvers will pass anything other than >> A/AAAA and CNAME records. >> >> Section 4 of the draft mandates a client hardfail if the DNSSEC trust >> chain cannot be obtained. This is essential if the client is going to >> use DNSSEC to establish certificate constraints just as certificate >> revocation is an essential part of the PKIX model. But no browser >> provider can expect to succeed with a product that simply stops >> working when the user tries to surf the Web from a coffee shop. >> >> Since the coffee shop problem is not intentional we might imagine that >> it will eventually go away. But this puts DANE in a deployment >> deadlock bind. Nobody is going to fix their coffee shop routers until >> there is a need to and that need won't exist until the coffee shop >> routers are fixed. >> >> It is not just coffee shops that are the problem either. It might seem >> really easy to put an SSL cert on a server and keep it up to date but >> IETF participants represent the 1% of network admins. We all know from >> experience how successful protocols that require two sets of records >> to be kept in sync are. A protocol that requires a network admin to >> remember to update their DNS with each cert change or suffer a >> hardfail is going to have a very high administrative error rate. >> >> >> Rather than mandating hardfail or any particular client behavior, the >> specification should simply state that the client MUST conclude that >> the DANE status of the certificate is invalid and then leave the >> client to decide on what course of action to take. This will depend on >> the circumstances of the particular user and the client provider's >> assessment of the reliability of the DANE data and might range from do >> nothing to send a security policy violation notification somewhere to >> hardfail. >> >> >> Contrary to the assumptions of the specification authors, hard fail is >> not the best option. It is not even the best option in the case that >> the users are dissidents. >> >> To understand the logic of the dissident case it is important to have >> a change of perspective. The objective of the authorities is not to >> intimidate a single protester, it is to intimidate a whole country. >> Being a protester carries inevitable risks. No security protocol is >> going to eliminate those risks for the individual. What is important >> is to minimize the risk for the population as a whole. >> >> The Google cert pinning code did not provide much direct protection to >> the Iranian dissidents because it only covered one site. But it proved >> critical in exposing the Diginotar situation because it provided the >> first evidence of the breach. Had the client been designed slightly >> differently the breach might have become evident earlier. >> >> >> The coffee shop issue is unintended but there are also parties that >> are going to intentionally sabotage any infrastructure that looks like >> DANE. We are not in the 1990s any longer, people in authority no >> longer expect OSI to replace the Internet. The result is that it is >> much harder to get away with no infrastructure. At present there is no >> point in blocking DNSSEC records. But you can be sure that Iran, >> Russia and China will be doing so the minute any client started to >> make use of DANE. These countries can (and will) make use of a client >> hard fail to ensure that people don't use browsers that might be used >> for 'information terrorism' or freedom of speech as the rest of us >> call it. >> >> And don't think that out own governments necessarily mean what they >> say. In public Thatcher was a stalwart champion of freedom. In private >> she was begging Gorbachev to send in the tanks to stop the fall of the >> Berlin wall. Her own foundation has materials that report this >> exchange: >> >> http://www.margaretthatcher.org/document/112006 >> >> The last thing I want to do is to hand the authorities another tool >> that can be used to selectively shut down the network at the critical >> moment in a crisis. Completely shutting off the Internet is one thing, >> it probably worked in our favor in Egypt as the 101st keyboarders lost >> their Internet connection and were forced to find out what was going >> on in the streets. It was a visceral sign of panic on the part of the >> regime. >> >> >> DANE is really a form of security policy information and so far there >> is no case where we have succeeded in applying raw security policy >> information at the client end. DKIM policies are a success because >> they are filtered and interpreted by the anti-spam services. There is >> a huge infrastructure in place that is working to apply the data from >> the DKIM records intelligently and equally importantly provides >> feedback to publishers of inconsistent records. >> >> DANE is proposed on the basis of a mistaken interpretation of how DKIM >> security policies work in practice and the result is a protocol that >> is deeply flawed and likely to fail. >> >> It would be a pity if the lack of success of a group that has >> steadfastly worked to ignore and discourage outside advice became a >> precedent to avoid future security policy efforts. Security policy is >> a very powerful tool, one that we can and must use if we are going to >> make the insecure Internet secure. But the DANE approach is too >> dogmatic to succeed. >> _______________________________________________ >> dane mailing list >> dane@ietf.org >> https://www.ietf.org/mailman/listinfo/dane > > -- > =A0Ond=F8ej Sur=FD -- Chief Science Officer > =A0------------------------------------------- > =A0CZ.NIC, z.s.p.o. =A0 =A0-- =A0 =A0Laborato=F8e CZ.NIC > =A0Americka 23, 120 00 Praha 2, Czech Republic > =A0mailto:ondrej.sury@nic.cz =A0 =A0http://nic.cz/ > =A0tel:+420.222745110 =A0 =A0 =A0 fax:+420.222745112 > =A0------------------------------------------- > --=20 Website: http://hallambaker.com/ From cloos@jhcloos.com Mon May 7 06:10:19 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 824BE21F85FF for ; Mon, 7 May 2012 06:10:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[AWL=-0.267, BAYES_05=-1.11] 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 QziBSPy8LQri for ; Mon, 7 May 2012 06:10:18 -0700 (PDT) Received: from eagle.jhcloos.com (eagle.jhcloos.com [207.210.242.212]) by ietfa.amsl.com (Postfix) with ESMTP id D06EA21F85FD for ; Mon, 7 May 2012 06:10:18 -0700 (PDT) Received: by eagle.jhcloos.com (Postfix, from userid 10) id 24C6040337; Mon, 7 May 2012 13:09:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=eagle; t=1336396217; bh=BXf5ylRVTdePQlaTmjaT4rslc5Vvcv2/9AruPeYZPEc=; h=From:To:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=XFPjGYWhqIh3zewZ2odiT44w1VL0wril9ydp4SyoJ4+lzWt1r6trPDe8SmWSRx4fN TEj0p8JJHlNflCbP1f13/ANM33y3hv6HwLRTT9poeJgARgxa2J3nGuvdaEl/iwWyah /puSTDYG9MTOtlHzo5sDBTPtyuPvV/GPzFN9JFBE= Received: by carbon.jhcloos.org (Postfix, from userid 500) id 902E636004C; Mon, 7 May 2012 13:05:37 +0000 (UTC) From: James Cloos To: dane@ietf.org In-Reply-To: <20120504031222.GA6541@odin.ulthar.us> (Scott Schmit's message of "Thu, 3 May 2012 23:12:22 -0400") References: <201204121903.q3CJ3ucF026698@new.toad.com> <9605FDF6-096D-4159-96A6-16549E8371AB@nic.cz> <20120504031222.GA6541@odin.ulthar.us> User-Agent: Gnus/5.130004 (Ma Gnus v0.4) Emacs/24.1.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2012 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: Mon, 07 May 2012 09:05:37 -0400 Message-ID: Lines: 21 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:120507:dane@ietf.org::pF03N++uxIWI5xJz:000ToFa5 Subject: Re: [dane] Inappropriate Section 8 of draft-ietf-dane-protocol-19.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2012 13:10:19 -0000 >>>>> "SS" == Scott Schmit writes: SS> I'll express support for John's technical arguments against section 8.1. SS> I don't have a strong position about the paragraph in section 8, but I SS> think we can improve it by changing this: ... SS> As for section 8.1, I agree that it's incorrect technically. Martin SS> Rex has also expressed agreement: ... I didn't chime in at the time SS> because I assumed that John and Martin's technical arguments made SS> the case adequately that section 8.1 makes an invalid comparison-- SS> but evidentally not, so I'll throw my arguments into the ring: I also fell into that trap. Since no one objected at the time, it didn't seem like there were any need further to . Scott's analysis is well though and his suggested revisions look reasonable. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From warren@kumari.net Mon May 7 07:46:33 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E802321F851B for ; Mon, 7 May 2012 07:46:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.552 X-Spam-Level: X-Spam-Status: No, score=-106.552 tagged_above=-999 required=5 tests=[AWL=0.048, 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 Lm6Z3myH4+oB for ; Mon, 7 May 2012 07:46:31 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id B6A9021F84DF for ; Mon, 7 May 2012 07:46:31 -0700 (PDT) Received: from dhcp-172-19-118-235.cbf.corp.google.com (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id 7792C1B401ED; Mon, 7 May 2012 10:46:30 -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, 7 May 2012 10:46:28 -0400 Content-Transfer-Encoding: 7bit Message-Id: References: <20120504021044.GB4560@mail.yitter.info> <20120504023602.GA4683@mail.yitter.info> <20120504112922.GB4929@mail.yitter.info> <20120504144426.GD4929@mail.yitter.info> <20120504165512.GC7394@mail.yitter.info> <20120504194132.GF7394@mail.yitter.info> To: Nicholas Weaver X-Mailer: Apple Mail (2.1084) Cc: Paul Wouters , dane@ietf.org Subject: Re: [dane] Behavior in the face of no answer? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 07 May 2012 14:46:33 -0000 On May 4, 2012, at 4:12 PM, Nicholas Weaver wrote: > > On May 4, 2012, at 1:03 PM, Paul Wouters wrote: > >> On Fri, 4 May 2012, Andrew Sullivan wrote: >> >>> I believe it is possible to get a useful response that has nothing in >>> the Answer, Authority, and Additional sections only if you trust your >>> upstream, you trust the connection somehow, you set CD=0, and you get >>> AD=1 on the response. In that case, I believe it is a legitimate >>> NODATA response (though I don't know of any implementation that works >>> this way), and it is validated. >> >> How many months until Rogers (or OpenDNS, or...) starts spitting out AD=1 >> on their DNS rewriting schemes? > > Xerocole already says "Just do it"... Win! W > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > From nweaver@ICSI.Berkeley.EDU Mon May 7 07:54:49 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5572421F8613 for ; Mon, 7 May 2012 07:54:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 76agEdJzTs7x for ; Mon, 7 May 2012 07:54:48 -0700 (PDT) Received: from rock.ICSI.Berkeley.EDU (rock.ICSI.Berkeley.EDU [192.150.186.19]) by ietfa.amsl.com (Postfix) with ESMTP id C8EFD21F85FF for ; Mon, 7 May 2012 07:54:48 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 7803B2C400B; Mon, 7 May 2012 07:54:48 -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 jPlq9SldLuMJ; Mon, 7 May 2012 07:54:48 -0700 (PDT) Received: from gala.icir.org (gala [192.150.187.49]) (Authenticated sender: nweaver) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 269242C4004; Mon, 7 May 2012 07:54:48 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Nicholas Weaver In-Reply-To: Date: Mon, 7 May 2012 07:54:48 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120504021044.GB4560@mail.yitter.info> <20120504023602.GA4683@mail.yitter.info> <20120504112922.GB4929@mail.yitter.info> <20120504144426.GD4929@mail.yitter.info> <20120504165512.GC7394@mail.yitter.info> <20120504194132.GF7394@mail.yitter.info> To: Warren Kumari X-Mailer: Apple Mail (2.1257) Cc: Paul Wouters , dane@ietf.org Subject: Re: [dane] Behavior in the face of no answer? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 07 May 2012 14:54:49 -0000 On May 7, 2012, at 7:46 AM, Warren Kumari wrote: >>> How many months until Rogers (or OpenDNS, or...) starts spitting out = AD=3D1 >>> on their DNS rewriting schemes? >>=20 >> Xerocole already says "Just do it"... >=20 > Win! For those overall interested in the business of DNS NXDOMAIN and other = modifications, the outsourced companies, the ISPs, the profitability = claims ($1-3 per customer per year), etc, our paper from last year = covers this space. I think I posted a note to other DNS groups last = year, but I don't think I posted it here: http://www.icir.org/christian/publications/2011-foci-dns.pdf "Redirecting DNS For Ads and Profit" This is also why I am so cynical about recursive resolver validation, = rather than end-host validation, and assert that the recursive resolver = should be considered an adversary. From paul.hoffman@vpnc.org Mon May 7 08:02:03 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94E2B21F85B7 for ; Mon, 7 May 2012 08:02:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.552 X-Spam-Level: X-Spam-Status: No, score=-102.552 tagged_above=-999 required=5 tests=[AWL=0.047, 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 V9OXib8lWEJ2 for ; Mon, 7 May 2012 08:02:03 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 14A8121F85B6 for ; Mon, 7 May 2012 08:02:03 -0700 (PDT) Received: from [10.20.30.102] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q47F1umU057203 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 7 May 2012 08:01:56 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Mon, 7 May 2012 08:01:56 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120504021044.GB4560@mail.yitter.info> <20120504023602.GA4683@mail.yitter.info> <20120504112922.GB4929@mail.yitter.info> <20120504144426.GD4929@mail.yitter.info> <20120504165512.GC7394@mail.yitter.info> <20120504194132.GF7394@mail.yitter.info> To: Nicholas Weaver X-Mailer: Apple Mail (2.1257) Cc: IETF DANE WG list Subject: Re: [dane] Behavior in the face of no answer? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 07 May 2012 15:02:03 -0000 On May 7, 2012, at 7:54 AM, Nicholas Weaver wrote: > This is also why I am so cynical about recursive resolver validation, = rather than end-host validation, and assert that the recursive resolver = should be considered an adversary. The current DANE spec explicitly allows both models. It would be great = in the future for there to be more work done on end-host validation, but = the lack of that work should not hinder people who can get benefit from = DANE now. --Paul Hoffman From ajs@anvilwalrusden.com Mon May 7 08:13:06 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75CD021F85E7; Mon, 7 May 2012 08:13:06 -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 sMzt1lhfmFh6; Mon, 7 May 2012 08:13:05 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 01B8A21F85D6; Mon, 7 May 2012 08:13:03 -0700 (PDT) Received: from mail.yitter.info (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 238181ECB41D; Mon, 7 May 2012 15:13:03 +0000 (UTC) Date: Mon, 7 May 2012 11:13:01 -0400 From: Andrew Sullivan To: Paul Hoffman Message-ID: <20120507151257.GH8963@mail.yitter.info> References: <20120504220713.GR7394@crankycanuck.ca> <201205042224.q44MOo03029933@fs4113.wdf.sap.corp> <20120504223816.GV7394@crankycanuck.ca> <1EF0ACEE-52ED-4BDE-BF34-C995F117783D@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1EF0ACEE-52ED-4BDE-BF34-C995F117783D@vpnc.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: The IESG , "apps-discuss@ietf.org Discuss" , IETF DANE WG list Subject: Re: [dane] [apps-discuss] AppsDir review of X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 07 May 2012 15:13:06 -0000 On Sat, May 05, 2012 at 07:21:51AM -0700, Paul Hoffman wrote: > > Note that the document explicitly states in the last paragraph of > section 1.2 that "This document only relates to securely associating > certificates for TLS and DTLS with host names". We are not talking > just "domain names" (which are made up of labels of octets) but > "host names" which are made up of labels of ASCII. We were told > (wisely) not to try to reopen this can of worms, so we didn't. Aha, good point. I guess this needs a normative reference to RFC 952, then? That's actually the most recent RFC that establishes the host rules. > OLD > 3. The domain name is appended to the result of step 2 to complete > the prepared domain name. > > NEW > > 3. The domain name is appended to the result of step 2 to complete > the prepared domain name. (The domain name is the fully > qualified DNS domain name [RFC1035] of the TLS server and is > represented as a byte string where each label is encoded > using ASCII; this enables support for internationalized > domain names through the use of A-labels as defined in > [RFC5890].) I'm still uncomfortable with this, because it's not technically accurate. When you send the QNAME, it's not a "byte string" and the labels aren't encoded. They're octets, not strings. How about 3. The base domain name is appended to the result of step 2 to complete the prepared domain name. The base domain name is the fully-qualified DNS domain name [RFC1035] of the TLS server, with the additional restriction that every label must meet the rules of [RFC952]. The latter restriction means that, if the query is for an internationalized domain name, it must use the A-label form as defined in [RFC5890]. ? I added the modifier "base" to this to make it clear that we're not defining what domain names are, although I don't myself feel too strongly about that addition. A -- Andrew Sullivan ajs@anvilwalrusden.com From ajs@anvilwalrusden.com Mon May 7 08:14:40 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 403C621F85F1; Mon, 7 May 2012 08:14:40 -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 P1IarkI-ekLg; Mon, 7 May 2012 08:14:39 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id C07FF21F85ED; Mon, 7 May 2012 08:14:39 -0700 (PDT) Received: from mail.yitter.info (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 EBC611ECB41D; Mon, 7 May 2012 15:14:38 +0000 (UTC) Date: Mon, 7 May 2012 11:14:37 -0400 From: Andrew Sullivan To: Martin Rex Message-ID: <20120507151437.GI8963@mail.yitter.info> References: <20120504223816.GV7394@crankycanuck.ca> <201205050438.q454cC0K021676@fs4113.wdf.sap.corp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201205050438.q454cC0K021676@fs4113.wdf.sap.corp> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: dane@ietf.org, iesg@ietf.org, apps-discuss@ietf.org, paul.hoffman@vpnc.org Subject: Re: [dane] [apps-discuss] AppsDir review of X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 07 May 2012 15:14:40 -0000 On Sat, May 05, 2012 at 06:38:12AM +0200, Martin Rex wrote: > Do we expect the target audience (folks implementing DANE protocol) > to use an API like that of libresolv's res_query(), where the representation > appears to be still a single string rather than individual DNS labels, > or that they're caller of even lower APIs? They'll certainly need to call something other than getaddrinfo(), because they need to know whether validation succeeded and you can't find it out that way. > res_query? The default behaviour of gethostbyname(), trying completion > of a name that doesn't end with a dot/period with (default) domain or > entries from a (domain) searchlist (res_search?) would likely > risk unpleasant consequences. Indeed. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From nweaver@ICSI.Berkeley.EDU Mon May 7 08:23:07 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8237D21F862A for ; Mon, 7 May 2012 08:23:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 TCt7G-XN3Cjt for ; Mon, 7 May 2012 08:23:06 -0700 (PDT) Received: from rock.ICSI.Berkeley.EDU (rock.ICSI.Berkeley.EDU [192.150.186.19]) by ietfa.amsl.com (Postfix) with ESMTP id DF2B821F84DD for ; Mon, 7 May 2012 08:23:06 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id D56892C4005; Mon, 7 May 2012 08:23:06 -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 kn01iF-rXbVW; Mon, 7 May 2012 08:23:06 -0700 (PDT) Received: from gala.icir.org (gala [192.150.187.49]) (Authenticated sender: nweaver) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 906A22C4002; Mon, 7 May 2012 08:23:06 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Nicholas Weaver In-Reply-To: Date: Mon, 7 May 2012 08:23:06 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120504021044.GB4560@mail.yitter.info> <20120504023602.GA4683@mail.yitter.info> <20120504112922.GB4929@mail.yitter.info> <20120504144426.GD4929@mail.yitter.info> <20120504165512.GC7394@mail.yitter.info> <20120504194132.GF7394@mail.yitter.info> To: Paul Hoffman X-Mailer: Apple Mail (2.1257) Cc: IETF DANE WG list Subject: Re: [dane] Behavior in the face of no answer? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 07 May 2012 15:23:07 -0000 On May 7, 2012, at 8:01 AM, Paul Hoffman wrote: > On May 7, 2012, at 7:54 AM, Nicholas Weaver wrote: >=20 >> This is also why I am so cynical about recursive resolver validation, = rather than end-host validation, and assert that the recursive resolver = should be considered an adversary. >=20 >=20 > The current DANE spec explicitly allows both models. It would be great = in the future for there to be more work done on end-host validation, but = the lack of that work should not hinder people who can get benefit from = DANE now. The cynic in me observes that without end-host validation, DANE is just = a connectionless version of the existing browser Certificate Revocation = List protocol: A seatbelt which fails when you actually need it, but = only works when you don't. The only advantage is cacheability and a = 1RTT interface when its cached. In general there is very little benefit from storing cryptographic = material in DNS without client-side validation. I will argue absence = client-side validation, the DNSSEC protection of such data, DANE = included, is almost useless. DNSSEC validation on the recursive resolver in lieu of end-host = validation for cryptographic material is only useful under the following = conditions: A) The adversary is only between the recursive resolver and the = Internet, but can never be between the victim and the recursive = resolver. B) The recursive resolver validates and is a system that can actually be = considered trustworthy. C) The protocol is "fail hard" on SERVFAIL or other 'unable to get the = key material in a DNS fetch'. Since A is a questionable assumption, B is ALMOST nonexistent if you = aren't a Comcast customer, and it seems that the DANE community doesn't = believe in C despite a host of evidence as to why they should, that DANE = even considers recursive resolver validation a deployment model is = downright silly to me. From stephen.farrell@cs.tcd.ie Mon May 7 08:31:39 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04EA521F85EA for ; Mon, 7 May 2012 08:31:39 -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 mzP2bV2+Efy5 for ; Mon, 7 May 2012 08:31:38 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id E22EA21F85E5 for ; Mon, 7 May 2012 08:31:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 58603157D22; Mon, 7 May 2012 16:31:37 +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=1336404697; bh=ppse08ezLvFBzH Xe6WWhdnGiyZYMQXMXkpeyfGZlTok=; b=A48toaiBTX20VJi7DoBD64qjxCOpBp iDnxX9NvyAu/6cEiYsPEnhlccmQoyREWflh0Y8ZWiAdYsWatYaMNV8pI8JHuVxjJ H8bh9/obgk/9gYsTSOIUJU0aYpkw56V/qqDztRfTpW1UJ6SSmNPJxgB1FyqhGIiR CEOSMy6wdEsYMke7aD3Zve+Tpa4fcdsE1ia7qyj3yhPPB3fJg/1Eu3xfQp5kbzil rIKG6YDs1XRXe8WtCu5Rf30tyHce1SdhgNEjtsqAyUDg0eSuNommxXVT70zw0SSV SQwfb6nKDar3lnM3EeeWmFoDpABuTu+dAGBu8F2O2RF/g7JCVaqWVF/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 PDrhmLXwvqBg; Mon, 7 May 2012 16:31:37 +0100 (IST) Received: from [10.87.48.9] (unknown [86.46.17.170]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id EB63E157B14; Mon, 7 May 2012 16:31:35 +0100 (IST) Message-ID: <4FA7EAD7.5070704@cs.tcd.ie> Date: Mon, 07 May 2012 16:31:35 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: James Cloos References: <201204121903.q3CJ3ucF026698@new.toad.com> <9605FDF6-096D-4159-96A6-16549E8371AB@nic.cz> <20120504031222.GA6541@odin.ulthar.us> In-Reply-To: X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dane@ietf.org Subject: Re: [dane] Inappropriate Section 8 of draft-ietf-dane-protocol-19.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2012 15:31:39 -0000 On 05/07/2012 02:05 PM, James Cloos wrote: >>>>>> "SS" == Scott Schmit writes: > > SS> I'll express support for John's technical arguments against section 8.1. > SS> I don't have a strong position about the paragraph in section 8, but I > SS> think we can improve it by changing this: > ... > SS> As for section 8.1, I agree that it's incorrect technically. Martin > SS> Rex has also expressed agreement: ... I didn't chime in at the time > SS> because I assumed that John and Martin's technical arguments made > SS> the case adequately that section 8.1 makes an invalid comparison-- > SS> but evidentally not, so I'll throw my arguments into the ring: > > I also fell into that trap. Since no one objected at the time, it > didn't seem like there were any need further to . > > Scott's analysis is well though and his suggested revisions look > reasonable. I'd like to see the resulting text if possible - I do think that its valid to make some comparisons here and while that may or may not suit different folks' positions, the technical points remain valid - if you use an external validator for DNSSEC then that puts the TLS client back into a place with only subtle differences compared to the current TLS client depending on the current X.509 PKI and public CAs. Since those subtitles might not be obvious to implementers I think they deserve a mention. As AD, I'll not try hold up progress regardless of what the WG do with this, so long as what's done has rough WG consensus according to the chairs (so no news there then:-) S. > > -JimC From paul.hoffman@vpnc.org Mon May 7 08:43:13 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5CAF21F8616 for ; Mon, 7 May 2012 08:43:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.552 X-Spam-Level: X-Spam-Status: No, score=-102.552 tagged_above=-999 required=5 tests=[AWL=0.047, 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 uivaG0+M+tGR for ; Mon, 7 May 2012 08:43:13 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 49EFF21F85FD for ; Mon, 7 May 2012 08:43:13 -0700 (PDT) Received: from [10.20.30.102] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q47FhBdB060465 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 7 May 2012 08:43:12 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Mon, 7 May 2012 08:43:11 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120504021044.GB4560@mail.yitter.info> <20120504023602.GA4683@mail.yitter.info> <20120504112922.GB4929@mail.yitter.info> <20120504144426.GD4929@mail.yitter.info> <20120504165512.GC7394@mail.yitter.info> <20120504194132.GF7394@mail.yitter.info> To: Nicholas Weaver X-Mailer: Apple Mail (2.1257) Cc: IETF DANE WG list Subject: Re: [dane] Behavior in the face of no answer? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 07 May 2012 15:43:14 -0000 If you believe that we should only standardize the perfect, not the = good, that's fine. Others seek to standardize the good which can be = upgraded to the perfect with no flag days, which is what is proposed = here. --Paul Hoffman From alangley@gmail.com Mon May 7 08:45:40 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 870FB21F862A for ; Mon, 7 May 2012 08:45:39 -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 GM8vxz8PxXko for ; Mon, 7 May 2012 08:45:38 -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 6650B21F8620 for ; Mon, 7 May 2012 08:45:38 -0700 (PDT) Received: by yenq13 with SMTP id q13so601986yen.31 for ; Mon, 07 May 2012 08:45:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=D8UBdu+6wd1gLVvh8LVtFZ7NmN8yBqfVahuJjnj+eCo=; b=aE7e00VRKVoxrxAUlmUGMsIxD3uFGt/Loj2F3dlkhMgFqu6Xpe3Rn+wfluPVre0x1E dLa4o/N+FHucvvAWZzX0dAohVEwZOLkkikiyzZrCIcFpCM5wn44Cr9ZUSK8eGjXNFxWQ 6fsVH4r1FeX9R/T83FZF/waubytYOImeXtn1Hf/NClzRaD8pcsI6qu00DEKd+ut5MQpC XJiI1MfSPtruznN8fnooubdlDDq5UDFGDvisyPiR6OMxeMlotR+K95lBvqFb/l/D9rFd Sye2NFIaNcADlEOsU31cSzWI9kulNDdpeMzXDti9YuFvTVvaZGiGK1LK0ONNlB1+YVLE L7Yw== MIME-Version: 1.0 Received: by 10.50.154.169 with SMTP id vp9mr8242289igb.71.1336402020754; Mon, 07 May 2012 07:47:00 -0700 (PDT) Sender: alangley@gmail.com Received: by 10.42.144.66 with HTTP; Mon, 7 May 2012 07:47:00 -0700 (PDT) In-Reply-To: <4FA5D178.8030405@nic.cz> References: <20120504023602.GA4683@mail.yitter.info> <20120504112922.GB4929@mail.yitter.info> <20120504144426.GD4929@mail.yitter.info> <3FF36EBA-F8B1-4D66-BA00-E8E36A7E449D@kumari.net> <6015A12B-8CA9-426B-9AFF-32CD4211DAB5@vpnc.org> <20120504165311.GB7394@mail.yitter.info> <4FA5D178.8030405@nic.cz> Date: Mon, 7 May 2012 10:47:00 -0400 X-Google-Sender-Auth: MPnIcLlg1oEwszXr24Ezrpw9nSc Message-ID: From: Adam Langley To: Ondrej Mikle Content-Type: text/plain; charset=UTF-8 Cc: dane@ietf.org Subject: Re: [dane] Behavior in the face of no answer? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 07 May 2012 15:45:40 -0000 On Sat, May 5, 2012 at 9:18 PM, Ondrej Mikle wrote: > Another goal of the scan is to find statistics on average/maximum size of > DNSSEC-stapled structure (as Jim Schaad asked - > https://www.ietf.org/mail-archive/web/dane/current/msg04694.html), which is > heavily influenced by number of zones traversed by CNAMEs/DNAMEs (ask away if > you're interested in other stats). My (very rough) rule of thumb is that it's ~2.5KB. Getting from . to a TLD is ~600 bytes. The TLDs tend to have a two key structure (I assume because updating DS records at the root is very hard?), and that's about another ~1200 bytes. Most of the time I assume that the record is sitting one zone above the TLD and that the zone only has a single key. So that ends up being about 2000-2500 bytes in total. Cheers AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org From nweaver@ICSI.Berkeley.EDU Mon May 7 08:56:28 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40C6921F85D1 for ; Mon, 7 May 2012 08:56:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 BfQMzgs7-aFj for ; Mon, 7 May 2012 08:56:27 -0700 (PDT) Received: from rock.ICSI.Berkeley.EDU (rock.ICSI.Berkeley.EDU [192.150.186.19]) by ietfa.amsl.com (Postfix) with ESMTP id C867C21F849D for ; Mon, 7 May 2012 08:56:27 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 9E2AD2C400B; Mon, 7 May 2012 08:56:27 -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 IRf2xJWbQMea; Mon, 7 May 2012 08:56:27 -0700 (PDT) Received: from gala.icir.org (gala [192.150.187.49]) (Authenticated sender: nweaver) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 5D31B2C4002; Mon, 7 May 2012 08:56:27 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Nicholas Weaver In-Reply-To: Date: Mon, 7 May 2012 08:56:27 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120504021044.GB4560@mail.yitter.info> <20120504023602.GA4683@mail.yitter.info> <20120504112922.GB4929@mail.yitter.info> <20120504144426.GD4929@mail.yitter.info> <20120504165512.GC7394@mail.yitter.info> <20120504194132.GF7394@mail.yitter.info> To: Paul Hoffman X-Mailer: Apple Mail (2.1257) Cc: IETF DANE WG list Subject: Re: [dane] Behavior in the face of no answer? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 07 May 2012 15:56:28 -0000 On May 7, 2012, at 8:43 AM, Paul Hoffman wrote: > If you believe that we should only standardize the perfect, not the = good, that's fine. Others seek to standardize the good which can be = upgraded to the perfect with no flag days, which is what is proposed = here. No, I believe we should standardize the good. If you wish to standardize the almost useless but can be upgraded to = good with no flag day, but which upgrading to good requires replacing or = bypassing a significant amount of brokenness on the Internet, say so. Because DANE without nearly-hard-fail [1] on no data, not just BOGUS = data, AND client-side validation, is no different that browser CRLs in = terms of protection to the users in the face of an actual attack. [1] namely, allow the user to bypass but scream bloody murder about = it... From ajs@anvilwalrusden.com Mon May 7 09:08:27 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1053F21F8642 for ; Mon, 7 May 2012 09:08:27 -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 7woTI59WHIHS for ; Mon, 7 May 2012 09:08:26 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 68C3F21F8616 for ; Mon, 7 May 2012 09:08:26 -0700 (PDT) Received: from mail.yitter.info (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 BFC981ECB41D for ; Mon, 7 May 2012 16:08:25 +0000 (UTC) Date: Mon, 7 May 2012 12:08:24 -0400 From: Andrew Sullivan To: dane@ietf.org Message-ID: <20120507160824.GK8963@mail.yitter.info> References: <20120504165512.GC7394@mail.yitter.info> <20120504194132.GF7394@mail.yitter.info> 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] Behavior in the face of no answer? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 07 May 2012 16:08:27 -0000 On Mon, May 07, 2012 at 08:23:06AM -0700, Nicholas Weaver wrote: > > The cynic in me observes that without end-host validation, DANE is > just a connectionless version of the existing browser Certificate > Revocation List protocol: Not every browser is in a home or public network with an ISP's corrupted resolver upstream. Just because that is the main network model you test doesn't make it the Internet, as I already pointed out in this thread. MSFT's main DNSSEC offering depends on IPSec and doing validation in the central resolver. That approach -- which I personally happen not to like -- is enabled by the DNSSEC specifications. Their stuff isn't unusual in enterprise deployments. We don't get to pooh-pooh that for DANE just because we don't like it. If we think that model is broken, then we need to deprecate it. If we're not going to deprecate it -- and I wish you luck -- then DANE needs to work for that DNSSEC deployment, too. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From paul.hoffman@vpnc.org Mon May 7 09:11:14 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BD8621F8599 for ; Mon, 7 May 2012 09:11:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.553 X-Spam-Level: X-Spam-Status: No, score=-102.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qfKWzuvVMsOs for ; Mon, 7 May 2012 09:11:13 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id BDD3521F8598 for ; Mon, 7 May 2012 09:11:13 -0700 (PDT) Received: from [10.20.30.102] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q47GBBXY062721 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 7 May 2012 09:11:12 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Mon, 7 May 2012 09:11:11 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120504021044.GB4560@mail.yitter.info> <20120504023602.GA4683@mail.yitter.info> <20120504112922.GB4929@mail.yitter.info> <20120504144426.GD4929@mail.yitter.info> <20120504165512.GC7394@mail.yitter.info> <20120504194132.GF7394@mail.yitter.info> To: Nicholas Weaver X-Mailer: Apple Mail (2.1257) Cc: IETF DANE WG list Subject: Re: [dane] Behavior in the face of no answer? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 07 May 2012 16:11:14 -0000 On May 7, 2012, at 8:56 AM, Nicholas Weaver wrote: > On May 7, 2012, at 8:43 AM, Paul Hoffman wrote: >=20 >> If you believe that we should only standardize the perfect, not the = good, that's fine. Others seek to standardize the good which can be = upgraded to the perfect with no flag days, which is what is proposed = here. >=20 > No, I believe we should standardize the good. Good! > If you wish to standardize the almost useless but can be upgraded to = good with no flag day, but which upgrading to good requires replacing or = bypassing a significant amount of brokenness on the Internet, say so. I didn't say so because I don't consider the current proposal "almost = useless". I hear that you do. > Because DANE without nearly-hard-fail [1] on no data, not just BOGUS = data, AND client-side validation, is no different that browser CRLs in = terms of protection to the users in the face of an actual attack. It is very different, but I hear that you don't believe that. Many of us = believe that there can be integrity-protected communication with = recursive resolvers that do DNSSEC, even if that is not common today. --Paul Hoffman From nweaver@ICSI.Berkeley.EDU Mon May 7 09:30:20 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 703A921F860B for ; Mon, 7 May 2012 09:30:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, 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 g6zViLHkko5J for ; Mon, 7 May 2012 09:30: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 7FD9E21F860D for ; Mon, 7 May 2012 09:30:16 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 648C42C401E; Mon, 7 May 2012 09:30:16 -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 jB5ncde1bg3U; Mon, 7 May 2012 09:30:16 -0700 (PDT) Received: from gala.icir.org (gala [192.150.187.49]) (Authenticated sender: nweaver) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 233A32C4002; Mon, 7 May 2012 09:30:16 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Nicholas Weaver In-Reply-To: Date: Mon, 7 May 2012 09:30:16 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120504021044.GB4560@mail.yitter.info> <20120504023602.GA4683@mail.yitter.info> <20120504112922.GB4929@mail.yitter.info> <20120504144426.GD4929@mail.yitter.info> <20120504165512.GC7394@mail.yitter.info> <20120504194132.GF7394@mail.yitter.info> To: Paul Hoffman X-Mailer: Apple Mail (2.1257) Cc: IETF DANE WG list Subject: Re: [dane] Behavior in the face of no answer? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 07 May 2012 16:30:20 -0000 On May 7, 2012, at 9:11 AM, Paul Hoffman wrote: >> Because DANE without nearly-hard-fail [1] on no data, not just BOGUS = data, AND client-side validation, is no different that browser CRLs in = terms of protection to the users in the face of an actual attack. >=20 > It is very different, but I hear that you don't believe that. Many of = us believe that there can be integrity-protected communication with = recursive resolvers that do DNSSEC, even if that is not common today. This requires=20 a) Changing the on the wire protocol to the recursive resolver. = Changes to both the recursive resolver and the clients. And changes to = how clients are configured to use DNS servers in order to establish this = secure channel. (sDHCP anyone?) b) If on port 53, the same problem with borken middleboxes as doing = DNSSEC on the client. Even on different ports over an IPsec tunnel you = may have middlebox issues. c) Can only be used in environments where the recursive resolver can = legitimately be placed within the trusted base for communication. And if thats your argument, then DANE should have the following caveats: In the absence of client validation, recursive resolver validation only = provides a meaningful security benefit for DANE records if: 1) The recursive resolver is trustworthy as defined by local network = policy. ISP-provided and third party public recursive resolvers MUST = NOT be considered trustworthy. 2) Client to recursive resolver communication is over a secure channel. = Establishing and securing such a channel is outside the scope of this = document. From gnu@toad.com Mon May 7 16:08:18 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C7E621F8665 for ; Mon, 7 May 2012 16:08:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.366 X-Spam-Level: X-Spam-Status: No, score=0.366 tagged_above=-999 required=5 tests=[AWL=0.269, BAYES_00=-2.599, RCVD_IN_NJABL_RELAY=2.696] 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 VmSzRs6dso-9 for ; Mon, 7 May 2012 16:08:17 -0700 (PDT) Received: from new.toad.com (new.toad.com [209.237.225.253]) by ietfa.amsl.com (Postfix) with ESMTP id BF0DF21F866A for ; Mon, 7 May 2012 16:08:17 -0700 (PDT) Received: from new.toad.com (localhost.localdomain [127.0.0.1]) by new.toad.com (8.12.9/8.12.9) with ESMTP id q47N8CcF012916; Mon, 7 May 2012 16:08:12 -0700 Message-Id: <201205072308.q47N8CcF012916@new.toad.com> To: Stephen Farrell In-reply-to: <4FA7EAD7.5070704@cs.tcd.ie> References: <201204121903.q3CJ3ucF026698@new.toad.com> <9605FDF6-096D-4159-96A6-16549E8371AB@nic.cz> <20120504031222.GA6541@odin.ulthar.us> <4FA7EAD7.5070704@cs.tcd.ie> Comments: In-reply-to Stephen Farrell message dated "Mon, 07 May 2012 16:31:35 +0100." Date: Mon, 07 May 2012 16:08:12 -0700 From: John Gilmore Cc: dane@ietf.org Subject: Re: [dane] Inappropriate Section 8 of draft-ietf-dane-protocol-19.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2012 23:08:18 -0000 > if you use an external validator for DNSSEC then that > puts the TLS client back into a place with only subtle differences I hope I'll have time to draft some wording later this week. But as y'all think about this section, I want to emphasize that my biggest problem in the current text is that its title is "Comparing DANE to Public CAs" but then it only addresses DANE-with-an-external-validator. I expect external validators to be a relatively niche scenario (requiring a whole separate secured channel in order to even be possible). Having a validator that runs on the same machine as the browser, or directly inside the browser, will be much simpler to administer, plus more secure and with fewer moving parts. Once one guy writes a reliable internal one in portable free software, it will work everywhere without needing system administration, and is thus very likely to become the norm. Section 8.1 doesn't even address the security of that "norm" scenario at all, which is why I originally viewed that text as a CA scare tactic. But actually it was a response to a specific question, which just got a too-broad and thus misleading title. It's fixable if we put in the work. John From gnu@toad.com Mon May 7 16:16:38 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3F8C21F84B3 for ; Mon, 7 May 2012 16:16:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.35 X-Spam-Level: X-Spam-Status: No, score=0.35 tagged_above=-999 required=5 tests=[AWL=0.253, BAYES_00=-2.599, RCVD_IN_NJABL_RELAY=2.696] 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 khWww8iiEVb5 for ; Mon, 7 May 2012 16:16:38 -0700 (PDT) Received: from new.toad.com (new.toad.com [209.237.225.253]) by ietfa.amsl.com (Postfix) with ESMTP id 26E5021F84B5 for ; Mon, 7 May 2012 16:16:38 -0700 (PDT) Received: from new.toad.com (localhost.localdomain [127.0.0.1]) by new.toad.com (8.12.9/8.12.9) with ESMTP id q47NGbcF013098; Mon, 7 May 2012 16:16:37 -0700 Message-Id: <201205072316.q47NGbcF013098@new.toad.com> To: Nicholas Weaver In-reply-to: References: <20120504021044.GB4560@mail.yitter.info> <20120504023602.GA4683@mail.yitter.info> <20120504112922.GB4929@mail.yitter.info> <20120504144426.GD4929@mail.yitter.info> <20120504165512.GC7394@mail.yitter.info> <20120504194132.GF7394@mail.yitter.info> Comments: In-reply-to Nicholas Weaver message dated "Mon, 07 May 2012 08:23:06 -0700." Date: Mon, 07 May 2012 16:16:37 -0700 From: John Gilmore Cc: Paul Hoffman , IETF DANE WG list Subject: Re: [dane] Behavior in the face of no answer? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 07 May 2012 23:16:38 -0000 I think that if the DANE TLS implementation can't get either a dnssec-validated TLSA rrset, or a dnssec-validated absence of a TLSA rrset, then to meet its security responsibilities, it has to fail to connect. Where the document is imprecise about that (or requires too many indirections through obscure corners of the DNSSEC RFCs to understand the implications) then I think we should say that more straightforwardly in our RFC. In browsers there will likely be a switch to "Use DANE TLS" just like today there's a preference checkbox in Firefox for "Use SSL 3.0" and "Use TLS 1.0". When behind a broken coffeeshop gateway, the human may need to manually turn off that switch. But trying to operate in a place that makes secure communication impossible should make enough trouble for the user that they'll also complain to the coffeeshop owner to fix their $*(@#@ gateway - or pick a different coffee shop next time. John From ynir@checkpoint.com Mon May 7 22:04:51 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A5B621F855F for ; Mon, 7 May 2012 22:04:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.391 X-Spam-Level: X-Spam-Status: No, score=-10.391 tagged_above=-999 required=5 tests=[AWL=0.208, BAYES_00=-2.599, 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 Gc-dWTT0ZCUR for ; Mon, 7 May 2012 22:04:49 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id ADF9B21F84A6 for ; Mon, 7 May 2012 22:04:43 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id q4854SL6027367; Tue, 8 May 2012 08:04:30 +0300 X-CheckPoint: {4FA8B6E9-4-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Tue, 8 May 2012 08:04:25 +0300 From: Yoav Nir To: John Gilmore Date: Tue, 8 May 2012 08:04:23 +0300 Thread-Topic: [dane] Behavior in the face of no answer? Thread-Index: Ac0s2AmAipg6l+r7Q2mdoffGrXbDwA== Message-ID: References: <20120504021044.GB4560@mail.yitter.info> <20120504023602.GA4683@mail.yitter.info> <20120504112922.GB4929@mail.yitter.info> <20120504144426.GD4929@mail.yitter.info> <20120504165512.GC7394@mail.yitter.info> <20120504194132.GF7394@mail.yitter.info> <201205072316.q47NGbcF013098@new.toad.com> In-Reply-To: <201205072316.q47NGbcF013098@new.toad.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Paul Hoffman , IETF DANE WG list Subject: Re: [dane] Behavior in the face of no answer? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 08 May 2012 05:04:51 -0000 On May 8, 2012, at 2:16 AM, John Gilmore wrote: > I think that if the DANE TLS implementation can't get either a > dnssec-validated TLSA rrset, or a dnssec-validated absence of a TLSA > rrset, then to meet its security responsibilities, it has to fail to > connect. >=20 > Where the document is imprecise about that (or requires too many > indirections through obscure corners of the DNSSEC RFCs to understand > the implications) then I think we should say that more > straightforwardly in our RFC. >=20 > In browsers there will likely be a switch to "Use DANE TLS" just like > today there's a preference checkbox in Firefox for "Use SSL 3.0" and > "Use TLS 1.0". When behind a broken coffeeshop gateway, the human may > need to manually turn off that switch. But trying to operate in a > place that makes secure communication impossible should make enough > trouble for the user that they'll also complain to the coffeeshop > owner to fix their $*(@#@ gateway - or pick a different coffee shop > next time. I agree. However, I'm wondering how many of the Firefox users who click "I understan= d the risks" actually understand the risks. Also a likely scenario is that the user unchecks the "use DANE TLS", compla= ins to the owner, and leaves the box unchecked forever. The fact that there's quite a few places where you'll have to uncheck the b= ox, and users are unlikely to find it by themselves, Firefox and the other = browsers are not likely to have this box checked out of the box. To work se= curely, the UI has to pop up a warning that this place has insecure DNS, an= d you can disable the check for this session if you "understand the risks",= and it turns back on automatically when you go somewhere else. Even that is unlikely to be implemented, as browsers are moving in the dire= ction of bothering the user with geek-speak less. Yoav= From fanf2@hermes.cam.ac.uk Tue May 8 04:51:19 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98C3C21F84FF; Tue, 8 May 2012 04:51:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.513 X-Spam-Level: X-Spam-Status: No, score=-6.513 tagged_above=-999 required=5 tests=[AWL=0.086, 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 Z9kvF-m21a9I; Tue, 8 May 2012 04:51:17 -0700 (PDT) Received: from ppsw-51.csi.cam.ac.uk (ppsw-51.csi.cam.ac.uk [131.111.8.151]) by ietfa.amsl.com (Postfix) with ESMTP id D11A521F84F8; Tue, 8 May 2012 04:51:16 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:44718) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:fanf2) id 1SRiwj-0001gx-Wj (Exim 4.72) (return-path ); Tue, 08 May 2012 12:51:13 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1SRiwj-0007fs-4H (Exim 4.67) (return-path ); Tue, 08 May 2012 12:51:13 +0100 Date: Tue, 8 May 2012 12:51:13 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Andrew Sullivan In-Reply-To: <20120507151257.GH8963@mail.yitter.info> Message-ID: References: <20120504220713.GR7394@crankycanuck.ca> <201205042224.q44MOo03029933@fs4113.wdf.sap.corp> <20120504223816.GV7394@crankycanuck.ca> <1EF0ACEE-52ED-4BDE-BF34-C995F117783D@vpnc.org> <20120507151257.GH8963@mail.yitter.info> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: IETF DANE WG list , Paul Hoffman , "apps-discuss@ietf.org Discuss" , The IESG Subject: Re: [dane] [apps-discuss] AppsDir review of X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 08 May 2012 11:51:19 -0000 Andrew Sullivan wrote: > > 3. The base domain name is appended to the result of step 2 to > complete the prepared domain name. The base domain name is the > fully-qualified DNS domain name [RFC1035] of the TLS server, > with the additional restriction that every label must meet the > rules of [RFC952]. The latter restriction means that, if the > query is for an internationalized domain name, it must use the > A-label form as defined in [RFC5890]. I like this. Tony. -- f.anthony.n.finch http://dotat.at/ Sole: Variable 4 in east at first, otherwise northeasterly 5 to 7. Moderate or rough. Occasional rain. Moderate or good. From stpeter@stpeter.im Tue May 8 05:39:02 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C525821F8549; Tue, 8 May 2012 05:39:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.55 X-Spam-Level: X-Spam-Status: No, score=-102.55 tagged_above=-999 required=5 tests=[AWL=0.049, 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 kwgyzJfYaD-8; Tue, 8 May 2012 05:39:02 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 0D52321F84C5; Tue, 8 May 2012 05:39:01 -0700 (PDT) Received: from [192.168.0.9] (unknown [216.17.175.160]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 5CA2B40058; Tue, 8 May 2012 06:54:18 -0600 (MDT) Message-ID: <4FA913E2.6050302@stpeter.im> Date: Tue, 08 May 2012 06:38:58 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Tony Finch References: <20120504220713.GR7394@crankycanuck.ca> <201205042224.q44MOo03029933@fs4113.wdf.sap.corp> <20120504223816.GV7394@crankycanuck.ca> <1EF0ACEE-52ED-4BDE-BF34-C995F117783D@vpnc.org> <20120507151257.GH8963@mail.yitter.info> In-Reply-To: X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: The IESG , "apps-discuss@ietf.org Discuss" , Paul Hoffman , IETF DANE WG list Subject: Re: [dane] [apps-discuss] AppsDir review of X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 08 May 2012 12:39:03 -0000 On 5/8/12 5:51 AM, Tony Finch wrote: > Andrew Sullivan wrote: >> >> 3. The base domain name is appended to the result of step 2 to >> complete the prepared domain name. The base domain name is the >> fully-qualified DNS domain name [RFC1035] of the TLS server, >> with the additional restriction that every label must meet the >> rules of [RFC952]. The latter restriction means that, if the >> query is for an internationalized domain name, it must use the >> A-label form as defined in [RFC5890]. > > I like this. WFM. Peter -- Peter Saint-Andre https://stpeter.im/ From marc.lampo@eurid.eu Tue May 8 06:52:39 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DC9C21F85B8 for ; Tue, 8 May 2012 06:52:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.89 X-Spam-Level: X-Spam-Status: No, score=-0.89 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] 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 SFG28r+czFuE for ; Tue, 8 May 2012 06:52:38 -0700 (PDT) Received: from barra.eurid.eu (barra.eurid.eu [78.41.71.12]) by ietfa.amsl.com (Postfix) with ESMTP id 855FC21F85B4 for ; Tue, 8 May 2012 06:52:38 -0700 (PDT) X-ASG-Debug-ID: 1336485156-0369496fa61dd00001-pGO8SV Received: from zimbra.eurid.eu (zcs-master.vt.eurid.eu [10.19.100.121]) by barra.eurid.eu with ESMTP id sLLrbZprD0uiKCtM; Tue, 08 May 2012 15:52:36 +0200 (CEST) X-Barracuda-Envelope-From: marc.lampo@eurid.eu X-ASG-Whitelist: Client Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.eurid.eu (Postfix) with ESMTP id B73A6E4072; Tue, 8 May 2012 15:52:36 +0200 (CEST) X-Virus-Scanned: amavisd-new at techmail.eurid.eu Received: from zimbra.eurid.eu ([127.0.0.1]) by localhost (zimbra.eurid.eu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s7uU0btFHlEd; Tue, 8 May 2012 15:52:36 +0200 (CEST) Received: from zimbra.eurid.eu (zimbra.eurid.eu [10.19.100.120]) by zimbra.eurid.eu (Postfix) with ESMTP id A51D6E4050; Tue, 8 May 2012 15:52:36 +0200 (CEST) From: "Marc Lampo" To: "'Stephen Farrell'" , "'dane'" References: <4F9FA90B.9090607@cs.tcd.ie> In-Reply-To: <4F9FA90B.9090607@cs.tcd.ie> Date: Tue, 8 May 2012 15:52:36 +0200 (CEST) X-ASG-Orig-Subj: RE: [dane] DANE IETF LC state of play Message-ID: <014701cd2d21$d32a0710$797e1530$@lampo@eurid.eu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 X-Mailer: Zimbra 6.0.14_GA_2928 (ZimbraConnectorForOutlook/5.0.3064.18) Thread-Index: Ac0nepCnW0RyZjLAQs+7TCfbMYXkMwFpSuVw Content-Language: en-za x-antivirus-status: Clean x-antivirus: avast! X-Originating-IP: [172.20.1.66] X-Barracuda-Connect: zcs-master.vt.eurid.eu[10.19.100.121] X-Barracuda-Start-Time: 1336485156 X-Barracuda-URL: http://10.19.10.12:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at eurid.eu Subject: Re: [dane] DANE IETF LC state of play X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 08 May 2012 13:52:39 -0000 Hello, (sorry for late jump in) http://www.ietf.org/mail-archive/web/dane/current/msg04702.html There is a remark about section 8 and SSL proxies. My feeling is the topic condition were SSL proxy is present is not yet treated with sufficient depth. 1) I'd see the (conventional) proxy as a DANE-unaware client, in which case fall back scenario is described. Or proxy implementers may enhance the implementation by supporting DANE. In which case some error messages may have to be defined reflecting abnormalities in the DANE protocol, experienced by the proxy. 2) The proposed draft for DANE states, in that section 8, on SSL proxy. "In such environments, using TLSA records will prevent the SSL proxy from functioning as expected because the TLS client will get a certificate association from the DNS that will not match the certificate that the SSL proxy uses with the client." --> I think what is actually meant is the connection between TLS client on end-user equipment (browser) and the proxy. The "connection" could work fine between proxy and TLS service (either because TLSA is ignored - "unknown" - or because DANE is supported) !! --> the text assumes that the end-user equipment does indeed get the TLSA RR from the external service. In proxy setups, this might not be true ! Since internal clients don't need Internet resolving, there access to public DNS might be limited for good reason ! (think "internal root servers") Overall, my feeling is that end-user clients that access TLS services via a proxy, should make exceptions to how they handle DANE. (like : knowing how the proxy handles DANE) Please don't mistake me : I generally like what DANE offers as extra ! But my feeling is only that the case of SSL proxy needs more elaboration. Kind regards, Marc Lampo -----Original Message----- From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] Sent: 01 May 2012 11:13 AM To: dane Subject: [dane] DANE IETF LC state of play Hi all, Well that's been a busy IETF LC. I think that shows that this is an important spec and the editors and chairs have done a great job so far on handling IETF LC comments, but I think there is a bit more work to do to be sure we're done and we may as well get that done now before the IESG are let loose on it:-) I went through the DANE WG archive of all the IETF LC comments and found the following ones where its not crystal clear from the archive that they're sorted. Notes: a) they might be just fine, e.g. if just one person comments and nobody else thought it important, then doing nothing is probably right. these just weren't clear from the archive so I wanna check; b) I only had time to scan the WG archive, if there are mails that were only to ietf@ietf.org or apps-discsuss that resolved these then I missed them, so just tell me about that, so I'll forward this to the other lists to check as well. So here's the list: 1) Jeff Hodges http://www.ietf.org/mail-archive/web/dane/current/msg04695.html http://www.ietf.org/mail-archive/web/dane/current/msg04713.html I mailed Jeff to see if -20 is ok. Silence can be taken to mean yes I think but since he had a bunch of things its hard to be sure. 2) PSA http://www.ietf.org/mail-archive/web/dane/current/msg04702.html http://www.ietf.org/mail-archive/web/dane/current/msg04790.html There are a few more small things still open in the last mail from earlier today. 3) Dave Cridland http://www.ietf.org/mail-archive/web/dane/current/msg04624.html I think there are still some occurrences of "certificate type" in section 8, (e.g. 3rd para, p18) so those weren't all fixed. I think that's the only remaining thing from Dave's review. 4) John Gilmore, http://www.ietf.org/mail-archive/web/dane/current/msg04635.html A.1 only has CA examples, what about non CA uses? I didn't see any reaction to that and it seems like a fair comment. 5) John Gilmore http://www.ietf.org/mail-archive/web/dane/current/msg04637.html John thinks there's a bias in sections 8/8.1, but I didn't see any reaction to that (other than mine, which just said "please do the right thing, whatever that is") 6) Mark Andrews http://www.ietf.org/mail-archive/web/dane/current/msg04657.html Again, not sure if there was follow-up. 7) PHB http://www.ietf.org/mail-archive/web/dane/current/msg04709.html Don't mandate client security policy (hardfail). I didn't see an obvious conclusion reached to make a change or not make a change. 8) Various on SRV http://www.ietf.org/mail-archive/web/dane/current/msg04793.html I think this might need a tweak to the SRV language in 1.3 (and just suggested one). Cheers, Stephen. From mrex@sap.com Tue May 8 08:04:52 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6381011E8080 for ; Tue, 8 May 2012 08:04:52 -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 pU2azMAfhZHL for ; Tue, 8 May 2012 08:04: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 98CC511E807F for ; Tue, 8 May 2012 08:04:51 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q48F4lKJ026677 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 8 May 2012 17:04:47 +0200 (MEST) From: Martin Rex Message-Id: <201205081504.q48F4kOU008128@fs4113.wdf.sap.corp> To: gnu@toad.com (John Gilmore) Date: Tue, 8 May 2012 17:04:46 +0200 (MEST) In-Reply-To: <201205072316.q47NGbcF013098@new.toad.com> from "John Gilmore" at May 7, 12 04:16:37 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] Behavior in the face of no answer? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 15:04:52 -0000 John Gilmore wrote: > > In browsers there will likely be a switch to "Use DANE TLS" just like > today there's a preference checkbox in Firefox for "Use SSL 3.0" and > "Use TLS 1.0". When behind a broken coffeeshop gateway, the human may > need to manually turn off that switch. But trying to operate in a > place that makes secure communication impossible should make enough > trouble for the user that they'll also complain to the coffeeshop > owner to fix their $*(@#@ gateway - or pick a different coffee shop > next time. Some of the users may simply continue using a browser version that still works in their coffeshop, i.e. downgrade and disable browser updates. -Martin From ajs@anvilwalrusden.com Tue May 8 08:53:05 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15F4621F863B for ; Tue, 8 May 2012 08:53:05 -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 nwoZ7qkbzOmy for ; Tue, 8 May 2012 08:53:04 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 6237B21F8628 for ; Tue, 8 May 2012 08:53:04 -0700 (PDT) Received: from mail.yitter.info (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 BF32F1ECB41D for ; Tue, 8 May 2012 15:53:03 +0000 (UTC) Date: Tue, 8 May 2012 11:53:00 -0400 From: Andrew Sullivan To: dane@ietf.org Message-ID: <20120508155300.GJ10226@mail.yitter.info> References: <20120504165512.GC7394@mail.yitter.info> <20120504194132.GF7394@mail.yitter.info> <201205072316.q47NGbcF013098@new.toad.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201205072316.q47NGbcF013098@new.toad.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Behavior in the face of no answer? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 08 May 2012 15:53:05 -0000 On Mon, May 07, 2012 at 04:16:37PM -0700, John Gilmore wrote: > I think that if the DANE TLS implementation can't get either a > dnssec-validated TLSA rrset, or a dnssec-validated absence of a TLSA > rrset, then to meet its security responsibilities, it has to fail to > connect. This is a strong statement, and is perhaps what ekr was asking for too. It's that "fail to connect" that bugs me. For it means that, if a client is TLSA-aware and it happens to find itself in some sort of environment in which TLSA records don't work, or DNSSEC records don't work, or both, there is exactly one thing it can do: foil all TLS connection attempts. > In browsers there will likely be a switch to "Use DANE TLS" just like > today there's a preference checkbox in Firefox for "Use SSL 3.0" and > "Use TLS 1.0". When behind a broken coffeeshop gateway, the human may > need to manually turn off that switch. Just to be clear, what that does it cause the user to turn the browser into a TLSA-unaware client. If I had to bet, I'd bet that it will persist and that it will itself become a barrier to operation. It feels to me like this discussion lies right on the barrier of "protocol" and "local policy", and that may be the reason it appears to be intractable. On the one hand, I can't believe anyone wants a requirement that actually increases the chances people will make connections without TLS, by making TLS impossible in some networks where it sort of works today. On the other hand, I understand (and agree with) the analysis pointing out the attack available if a complete non-response causes fall-through to traditional TLS processing. I'm wondering whether implementation or deployment advice (perhaps in another document) is something that's not just nice to have, but needed. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From fanf2@hermes.cam.ac.uk Tue May 8 12:41:53 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A66FE21F8569 for ; Tue, 8 May 2012 12:41:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.516 X-Spam-Level: X-Spam-Status: No, score=-6.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4uAPnRL5NDFR for ; Tue, 8 May 2012 12:41:52 -0700 (PDT) Received: from ppsw-41.csi.cam.ac.uk (ppsw-41.csi.cam.ac.uk [131.111.8.141]) by ietfa.amsl.com (Postfix) with ESMTP id 84A4821F855F for ; Tue, 8 May 2012 12:41:52 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:53523) by ppsw-41.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:fanf2) id 1SRqI8-0000hx-RD (Exim 4.72) (return-path ); Tue, 08 May 2012 20:41:48 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1SRqI8-0006p4-DQ (Exim 4.67) (return-path ); Tue, 08 May 2012 20:41:48 +0100 Date: Tue, 8 May 2012 20:41:48 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Yoav Nir In-Reply-To: <13B3A487-2C93-4958-8FE6-63132742181E@checkpoint.com> Message-ID: References: <0526D60A-3F1B-4C55-9796-256BC2556AAB@vpnc.org> <20120503223745.GC1804@mail.yitter.info> <20120504021044.GB4560@mail.yitter.info> <20120504023602.GA4683@mail.yitter.info> <20120504112922.GB4929@mail.yitter.info> <20120504144426.GD4929@mail.yitter.info> <3FF36EBA-F8B1-4D66-BA00-E8E36A7E449D@kumari.net> <13B3A487-2C93-4958-8FE6-63132742181E@checkpoint.com> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: Adam Langley , "dane@ietf.org" Subject: Re: [dane] Behavior in the face of no answer? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 08 May 2012 19:41:53 -0000 Yoav Nir wrote: > > I can think of a heuristic for this. Suppose we have to domain names, > one with a valid TLSA record, the other without. The browser could query > the DNS for a TLSA record for both of these, and if both answers are > received, then TLSA works. In that case, a timeout can rightfully become > a hard fail. If no response is received to either query, then either the > DNS is broken or the attack is already going on. In that case the user > should be warned with the likelier of the two - that the DNS seems to be > broken, and certain kinds of attack are possible. I think the "DNSSEC works but TLSA doesn't" heuristic may also be useful. Tony. -- f.anthony.n.finch http://dotat.at/ Lundy, Fastnet, Irish Sea: Variable 3 or 4 becoming northeast 4 or 5, occasionally 6 later. Slight or moderate. Rain or showers. Good, occasionally poor. From fanf2@hermes.cam.ac.uk Tue May 8 12:46:31 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E26211E8079 for ; Tue, 8 May 2012 12:46:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.519 X-Spam-Level: X-Spam-Status: No, score=-6.519 tagged_above=-999 required=5 tests=[AWL=0.080, 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 CZxSDBxihgFe for ; Tue, 8 May 2012 12:46:30 -0700 (PDT) Received: from ppsw-51.csi.cam.ac.uk (ppsw-51.csi.cam.ac.uk [131.111.8.151]) by ietfa.amsl.com (Postfix) with ESMTP id 680D49E8002 for ; Tue, 8 May 2012 12:46:30 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:33051) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:fanf2) id 1SRqMe-0003So-Ye (Exim 4.72) (return-path ); Tue, 08 May 2012 20:46:28 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1SRqMe-0007XI-NM (Exim 4.67) (return-path ); Tue, 08 May 2012 20:46:28 +0100 Date: Tue, 8 May 2012 20:46:28 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Ondrej Mikle In-Reply-To: <4FA5D178.8030405@nic.cz> Message-ID: References: <20120504023602.GA4683@mail.yitter.info> <20120504112922.GB4929@mail.yitter.info> <20120504144426.GD4929@mail.yitter.info> <3FF36EBA-F8B1-4D66-BA00-E8E36A7E449D@kumari.net> <6015A12B-8CA9-426B-9AFF-32CD4211DAB5@vpnc.org> <20120504165311.GB7394@mail.yitter.info> <4FA5D178.8030405@nic.cz> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: dane@ietf.org Subject: Re: [dane] Behavior in the face of no answer? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 08 May 2012 19:46:31 -0000 Ondrej Mikle wrote: > > From the ongoing scan, out of 70M currently finished .com domains, > SERVFAILs appeared for ~8.6M distinct domains. We're running validating resolvers and we haven't noticed that level of failure. What proportion of authoritative servers with working DNSSEC return SERVFAIL for what QTYPEs? Tony. -- f.anthony.n.finch http://dotat.at/ Faeroes, South-east Iceland: Northeasterly backing northwesterly 5 or 6, occasionally 7 in Faeroes. Moderate, occasionally rough in Faeroes. Wintry showers. Moderate or good. From paul@cypherpunks.ca Tue May 8 12:47:12 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B52A9E8007 for ; Tue, 8 May 2012 12:47:12 -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 anXzOGbYnZY0 for ; Tue, 8 May 2012 12:47:11 -0700 (PDT) Received: from letoams.cypherpunks.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id BEBE29E8006 for ; Tue, 8 May 2012 12:47:11 -0700 (PDT) Received: by letoams.cypherpunks.ca (Postfix, from userid 500) id 8432F853FC; Tue, 8 May 2012 15:47:10 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by letoams.cypherpunks.ca (Postfix) with ESMTP id 793898032E; Tue, 8 May 2012 15:47:10 -0400 (EDT) Date: Tue, 8 May 2012 15:47:10 -0400 (EDT) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: Andrew Sullivan In-Reply-To: <20120508155300.GJ10226@mail.yitter.info> Message-ID: References: <20120504165512.GC7394@mail.yitter.info> <20120504194132.GF7394@mail.yitter.info> <201205072316.q47NGbcF013098@new.toad.com> <20120508155300.GJ10226@mail.yitter.info> User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dane@ietf.org Subject: Re: [dane] Behavior in the face of no answer? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 08 May 2012 19:47:12 -0000 On Tue, 8 May 2012, Andrew Sullivan wrote: > On Mon, May 07, 2012 at 04:16:37PM -0700, John Gilmore wrote: >> I think that if the DANE TLS implementation can't get either a >> dnssec-validated TLSA rrset, or a dnssec-validated absence of a TLSA >> rrset, then to meet its security responsibilities, it has to fail to >> connect. > > This is a strong statement, and is perhaps what ekr was asking for > too. It's that "fail to connect" that bugs me. For it means that, if > a client is TLSA-aware and it happens to find itself in some sort of > environment in which TLSA records don't work, or DNSSEC records don't > work, or both, there is exactly one thing it can do: foil all TLS > connection attempts. We really have no other choice. Your mother did not tell you when you were young "Always lock the door if you are the last one leaving the house, except when you think someone else might arrive home first, in which case put the key under the door mat". She just said "always lock the door" and you left the key under the mat sometimes anyway. > Just to be clear, what that does it cause the user to turn the browser > into a TLSA-unaware client. If I had to bet, I'd bet that it will > persist and that it will itself become a barrier to operation. > > It feels to me like this discussion lies right on the barrier of > "protocol" and "local policy", and that may be the reason it appears > to be intractable. On the one hand, I can't believe anyone wants a > requirement that actually increases the chances people will make > connections without TLS, by making TLS impossible in some networks > where it sort of works today. On the other hand, I understand (and > agree with) the analysis pointing out the attack available if a > complete non-response causes fall-through to traditional TLS > processing. I'm wondering whether implementation or deployment advice > (perhaps in another document) is something that's not just nice to > have, but needed. Let's leave those decisions to the browser vendors. They've gone through this before and will go through this again. Ultimately, the biggest real use-case is the hotspot case, and currently, it is mostly the browser that detects this first. That has to change, and once the OS detects this first, it can provide hints to the browser, and ultimately, even have the browser start a sandboxed sign-on window to authenticate and allow contained spoofed DNS before opening up the entire machine to DNS and port HTTP(S). If networks are still DNSSEC broken after authentication, and they are blocking port 53 and they are blocking fall back resolvers over port 80 and/or 443, then really, what else is there to do then hard fail? Paul From paul@cypherpunks.ca Tue May 8 12:49:30 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C29D321F849D for ; Tue, 8 May 2012 12:49:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gToG+w61aeDH for ; Tue, 8 May 2012 12:49:30 -0700 (PDT) Received: from letoams.cypherpunks.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 5585F21F848F for ; Tue, 8 May 2012 12:49:30 -0700 (PDT) Received: by letoams.cypherpunks.ca (Postfix, from userid 500) id F1ADB853FD; Tue, 8 May 2012 15:49:29 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by letoams.cypherpunks.ca (Postfix) with ESMTP id E42978032E; Tue, 8 May 2012 15:49:29 -0400 (EDT) Date: Tue, 8 May 2012 15:49:29 -0400 (EDT) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: Tony Finch In-Reply-To: Message-ID: References: <0526D60A-3F1B-4C55-9796-256BC2556AAB@vpnc.org> <20120503223745.GC1804@mail.yitter.info> <20120504021044.GB4560@mail.yitter.info> <20120504023602.GA4683@mail.yitter.info> <20120504112922.GB4929@mail.yitter.info> <20120504144426.GD4929@mail.yitter.info> <3FF36EBA-F8B1-4D66-BA00-E8E36A7E449D@kumari.net> <13B3A487-2C93-4958-8FE6-63132742181E@checkpoint.com> User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Adam Langley , "dane@ietf.org" Subject: Re: [dane] Behavior in the face of no answer? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 08 May 2012 19:49:30 -0000 On Tue, 8 May 2012, Tony Finch wrote: > I think the "DNSSEC works but TLSA doesn't" heuristic may also be useful. I don't think you can use that at all. You will still run into DNS implementations that cannot do TLSA or generic records that are not malicious, and I don't really know how you would distinguish those from malicious TLSA breakage, so you cannot really draw any conclusion from such state. Paul From fanf2@hermes.cam.ac.uk Tue May 8 13:14:31 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 145689E8006 for ; Tue, 8 May 2012 13:14:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.522 X-Spam-Level: X-Spam-Status: No, score=-6.522 tagged_above=-999 required=5 tests=[AWL=0.077, 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 CNDGL8h8nokA for ; Tue, 8 May 2012 13:14:29 -0700 (PDT) Received: from ppsw-41.csi.cam.ac.uk (ppsw-41.csi.cam.ac.uk [131.111.8.141]) by ietfa.amsl.com (Postfix) with ESMTP id DDFDA21F8459 for ; Tue, 8 May 2012 13:14:27 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:57844) by ppsw-41.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:fanf2) id 1SRqnd-0004zs-SH (Exim 4.72) (return-path ); Tue, 08 May 2012 21:14:22 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1SRqnd-0002vp-N8 (Exim 4.67) (return-path ); Tue, 08 May 2012 21:14:21 +0100 Date: Tue, 8 May 2012 21:14:21 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Paul Wouters In-Reply-To: Message-ID: References: <20120503223745.GC1804@mail.yitter.info> <20120504021044.GB4560@mail.yitter.info> <20120504023602.GA4683@mail.yitter.info> <20120504112922.GB4929@mail.yitter.info> <20120504144426.GD4929@mail.yitter.info> <3FF36EBA-F8B1-4D66-BA00-E8E36A7E449D@kumari.net> <13B3A487-2C93-4958-8FE6-63132742181E@checkpoint.com> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: Adam Langley , "dane@ietf.org" Subject: Re: [dane] Behavior in the face of no answer? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 08 May 2012 20:14:31 -0000 Paul Wouters wrote: > On Tue, 8 May 2012, Tony Finch wrote: > > > I think the "DNSSEC works but TLSA doesn't" heuristic may also be useful. > > I don't think you can use that at all. > > You will still run into DNS implementations that cannot do TLSA or generic > records that are not malicious, and I don't really know how you would > distinguish those from malicious TLSA breakage, so you cannot really > draw any conclusion from such state. What is the overlap between servers that support DNSSEC but not RFC 3597? Tony. -- f.anthony.n.finch http://dotat.at/ Forth, Tyne, Dogger: South 4 or 5, becoming variable 3 or 4. Slight, occasionally moderate at first. Showers. Moderate or good. From i.grok@comcast.net Tue May 8 17:50:14 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8326B9E801A for ; Tue, 8 May 2012 17:50:14 -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 RRda+tlnvtjQ for ; Tue, 8 May 2012 17:50:14 -0700 (PDT) Received: from qmta05.emeryville.ca.mail.comcast.net (qmta05.emeryville.ca.mail.comcast.net [76.96.30.48]) by ietfa.amsl.com (Postfix) with ESMTP id 10B1D9E8019 for ; Tue, 8 May 2012 17:50:11 -0700 (PDT) Received: from omta09.emeryville.ca.mail.comcast.net ([76.96.30.20]) by qmta05.emeryville.ca.mail.comcast.net with comcast id 7coo1j0010S2fkCA5cqA6q; Wed, 09 May 2012 00:50:10 +0000 Received: from odin.ulthar.us ([68.33.77.0]) by omta09.emeryville.ca.mail.comcast.net with comcast id 7cq81j01400PQ6U8VcqARE; Wed, 09 May 2012 00:50:10 +0000 Received: from odin.ulthar.us (localhost [127.0.0.1]) by odin.ulthar.us (8.14.5/8.14.3) with ESMTP id q490o6eo016964 for ; Tue, 8 May 2012 20:50:06 -0400 Received: (from draco@localhost) by odin.ulthar.us (8.14.5/8.14.5/Submit) id q490o6QO016963 for dane@ietf.org; Tue, 8 May 2012 20:50:06 -0400 Date: Tue, 8 May 2012 20:50:06 -0400 From: Scott Schmit To: dane@ietf.org Message-ID: <20120509005006.GA15139@odin.ulthar.us> Mail-Followup-To: dane@ietf.org References: <20120504144426.GD4929@mail.yitter.info> <3FF36EBA-F8B1-4D66-BA00-E8E36A7E449D@kumari.net> <13B3A487-2C93-4958-8FE6-63132742181E@checkpoint.com> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="IJpNTDwzlM2Ie8A6" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Behavior in the face of no answer? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 09 May 2012 00:50:14 -0000 --IJpNTDwzlM2Ie8A6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, May 08, 2012 at 09:14:21PM +0100, Tony Finch wrote: > Paul Wouters wrote: > > On Tue, 8 May 2012, Tony Finch wrote: > > > > > I think the "DNSSEC works but TLSA doesn't" heuristic may also be use= ful. > > > > I don't think you can use that at all. > > > > You will still run into DNS implementations that cannot do TLSA or gene= ric > > records that are not malicious, and I don't really know how you would > > distinguish those from malicious TLSA breakage, so you cannot really > > draw any conclusion from such state. >=20 > What is the overlap between servers that support DNSSEC but not RFC 3597? RFC 4034 requires use of RFC 3597 for unknown types, so the overlap is supposed to be an empty set. --=20 Scott Schmit --IJpNTDwzlM2Ie8A6 Content-Type: application/x-pkcs7-signature Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIIQJgYJKoZIhvcNAQcCoIIQFzCCEBMCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC DVcwggY0MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAe Fw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0 ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEp pC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9 b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54q zHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX 9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/ 4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8E BTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIw HwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wu Y29tL3Nmc2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIB FiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4IC AQAKgwh9eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8py TUnFsukDFUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMm CeUTyMyikfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIz uQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVm z/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT 5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lAp sbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076 khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8 J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRX un0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCBxswggYDoAMCAQICAwK+HTANBgkqhkiG 9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTExMDcxNzA1 MDQwNFoXDTEyMDcxNzExNDI1OVowYjEgMB4GA1UEDRMXNDY1MjU2LTBnRmI2Sk5ZWW44QnFW bUwxGzAZBgNVBAMMEmkuZ3Jva0Bjb21jYXN0Lm5ldDEhMB8GCSqGSIb3DQEJARYSaS5ncm9r QGNvbWNhc3QubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2AjLOMsBGaqN hv2FcRbfom/QCeKMXu5tUd1JY5oIDZe5y29stnd+se/zUlEkiVeMam4Jgo1c8yGNnwLVYc5/ 9xVi7Qg1Is5b9AB6aJWElJDw/jIdihymNZ2kwkSLT0wl/lzd0mXlwFJPRgQiRkmE6V0ZmjsQ jaVtllVleGBbMvmWPm92e+4Bju9P81kKz7Xr02ijETmaPdVsl+jmOaKPS8Y+2Lat2xus4Ked oJ/7aIWIpz1gRSKjAHSZ1Wmwi2TYUjYhZryChu9e1RWtqk1CycNoeusJ8xdEVN3WSnJ299w/ 3ltK/x/9rpj2j9ShQZVB4NnX6cjQs7pz1lVxvIkjcQIDAQABo4IDrTCCA6kwCQYDVR0TBAIw ADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQW BBQ29j2I0O8sRYi0So9NwwmT1caakDAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhR gjAdBgNVHREEFjAUgRJpLmdyb2tAY29tY2FzdC5uZXQwggIhBgNVHSAEggIYMIICFDCCAhAG CysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20v cG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJt ZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcg dG8gdGhlIENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4g Y29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUF BwICMIGPMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJp bGl0eSBhbmQgd2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFu ZCBMaW1pdGF0aW9ucyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAr oCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUH AQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFz czEvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0 cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQAZ5U0nL/2PQwsVfHgN7MVPbZEGzDzuj4Oy pTgz4XQFwPcCuy6U9sp1Dwmo3DyKX5nKN4xA7pslN+2Pl/kElGamX7zMCAH0xED0RTOLyk+v nDML4s+OUtWaYVnq1bZEp0F8Luq3zIslAYSebleyiz8M0EypZczsL5rOk86R2F9EYw1CBuFJ 5a4x0CmNu5o30fGNDFt+iXRlbJPp/KY25iUgVnBzJ4COT5kQjxn5lgr4t1I+BDCL5HQQ3h/8 2CzwrWVRBNb9Vqh9LL1ZtzYRt8JezoB6HkVvcKVNGlCZ+/MnvfMzPLwfbTDZC8o4d+4RH6aE LeGF2XmAOaenc/YRqm9oMYIClzCCApMCAQEwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQQIDAr4dMAkGBSsOAwIaBQCggdgwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTIwNTA5MDA1MDA2WjAjBgkqhkiG9w0BCQQxFgQUbfLKiueJ vLLb3JhCT2A4ZhKAj5UweQYJKoZIhvcNAQkPMWwwajALBglghkgBZQMEASowCwYJYIZIAWUD BAEWMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAHnsrRPOv W9ckOnVw70oaBW2NP5FfWOP8ViVcorHbKUEgXsDGFl2Pv2hVHN1reDg8XRCJlmt6wu8dbnKQ O7c+14E8ne35F9Lyk0mq2qHHsTstBUqLRoxL88wnKORGDLV/ZqxsLpYXdTcb8fQY7/MvsLb4 607LqQsXzNf3DYmjePm5aS2I7ByMLSNeSryQ28OFfzuAKzOidNY5V7draL73VxzWNgwaTTM5 7oAp5jVCotjSdjf3c6+ZpDVAxkPQNeeRgrWddAFYFFiUVwsQrJWJWUgUF+2YiFcmD7IaP4Hp e1GhrGd8B8lQfnfUS/q675TUAWpeJvzk8nhOYKpMSwt5kQ== --IJpNTDwzlM2Ie8A6-- From paul@cypherpunks.ca Tue May 8 18:00:10 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AB839E8015 for ; Tue, 8 May 2012 18:00:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JXRquV6VhjCF for ; Tue, 8 May 2012 18:00:10 -0700 (PDT) Received: from letoams.cypherpunks.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id E24E29E800E for ; Tue, 8 May 2012 18:00:09 -0700 (PDT) Received: by letoams.cypherpunks.ca (Postfix, from userid 500) id B8430853FC; Tue, 8 May 2012 21:00:08 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by letoams.cypherpunks.ca (Postfix) with ESMTP id AD430803A3; Tue, 8 May 2012 21:00:08 -0400 (EDT) Date: Tue, 8 May 2012 21:00:08 -0400 (EDT) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: Scott Schmit In-Reply-To: <20120509005006.GA15139@odin.ulthar.us> Message-ID: References: <20120504144426.GD4929@mail.yitter.info> <3FF36EBA-F8B1-4D66-BA00-E8E36A7E449D@kumari.net> <13B3A487-2C93-4958-8FE6-63132742181E@checkpoint.com> <20120509005006.GA15139@odin.ulthar.us> User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dane@ietf.org Subject: Re: [dane] Behavior in the face of no answer? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 09 May 2012 01:00:10 -0000 On Tue, 8 May 2012, Scott Schmit wrote: >> What is the overlap between servers that support DNSSEC but not RFC 3597? > > RFC 4034 requires use of RFC 3597 for unknown types, so the overlap is > supposed to be an empty set. But we all know there are many embedded devices with badly written DNS proxy software that do things like comparing packets to known byte streams without actual understanding of bit values. Paul From marc.lampo@eurid.eu Wed May 9 00:26:34 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6805421F846F for ; Wed, 9 May 2012 00:26:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.933 X-Spam-Level: X-Spam-Status: No, score=-0.933 tagged_above=-999 required=5 tests=[AWL=0.216, BAYES_00=-2.599, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1.449] 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 vA7u2A8atQTO for ; Wed, 9 May 2012 00:26:33 -0700 (PDT) Received: from barra.eurid.eu (barra.eurid.eu [78.41.71.12]) by ietfa.amsl.com (Postfix) with ESMTP id 0F4D521F851C for ; Wed, 9 May 2012 00:26:32 -0700 (PDT) X-ASG-Debug-ID: 1336548386-0369496fa71f090001-pGO8SV Received: from zimbra.eurid.eu (zcs-master.vt.eurid.eu [10.19.100.121]) by barra.eurid.eu with ESMTP id SdZNPuMrVX9x9D4D; Wed, 09 May 2012 09:26:26 +0200 (CEST) X-Barracuda-Envelope-From: marc.lampo@eurid.eu X-ASG-Whitelist: Client Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.eurid.eu (Postfix) with ESMTP id 0FF1CE408C; Wed, 9 May 2012 09:26:26 +0200 (CEST) X-Virus-Scanned: amavisd-new at techmail.eurid.eu Received: from zimbra.eurid.eu ([127.0.0.1]) by localhost (zimbra.eurid.eu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fe8DvQu8bzts; Wed, 9 May 2012 09:26:25 +0200 (CEST) Received: from zimbra.eurid.eu (zimbra.eurid.eu [10.19.100.120]) by zimbra.eurid.eu (Postfix) with ESMTP id E2719E407A; Wed, 9 May 2012 09:26:25 +0200 (CEST) From: "Marc Lampo" To: "'dane'" , "'Stephen Farrell'" Date: Wed, 9 May 2012 09:26:25 +0200 (CEST) X-ASG-Orig-Subj: RE: [dane] DANE IETF LC state of play Message-ID: <006c01cd2db5$0ad341c0$2079c540$@lampo@eurid.eu> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_006D_01CD2DC5.CE5C11C0" X-Mailer: Microsoft Office Outlook 12.0 X-Mailer: Zimbra 6.0.14_GA_2928 (ZimbraConnectorForOutlook/5.0.3064.18) Thread-Index: Ac0ttQp/zXk6BDX2RcqG57zZ4E8L4g== Content-Language: en-za x-antivirus-status: Clean x-antivirus: avast! X-Originating-IP: [172.20.1.66] X-Barracuda-Connect: zcs-master.vt.eurid.eu[10.19.100.121] X-Barracuda-Start-Time: 1336548386 X-Barracuda-URL: http://10.19.10.12:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at eurid.eu Subject: Re: [dane] DANE IETF LC state of play X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 09 May 2012 07:26:34 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_006D_01CD2DC5.CE5C11C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello, (sorry for late jump in) http://www.ietf.org/mail-archive/web/dane/current/msg04702.html There is a remark about section 8 and SSL proxies. My feeling is the topic condition were SSL proxy is present is not yet treated with sufficient depth. 1) I'd see the (conventional) proxy as a DANE-unaware client, in which case fall back scenario is described. Or proxy implementers may enhance the implementation by supporting DANE. In which case some error messages may have to be defined reflecting abnormalities in the DANE protocol, experienced by the proxy. 2) The proposed draft for DANE states, in that section 8, on SSL proxy. "In such environments, using TLSA records will prevent the SSL proxy from functioning as expected because the TLS client will get a certificate association from the DNS that will not match the certificate that the SSL proxy uses with the client." --> I think what is actually meant is the connection between TLS client on end-user equipment (browser) and the proxy. The "connection" could work fine between proxy and TLS service (either because TLSA is ignored - "unknown" - or because DANE is supported) !! --> the text assumes that the end-user equipment does indeed get the TLSA RR from the external service. In proxy setups, this might not be true ! Since internal clients don't need Internet resolving, there access to public DNS might be limited for good reason ! (think "internal root servers") Overall, my feeling is that end-user clients that access TLS services via a proxy, should make exceptions to how they handle DANE. (like : knowing how the proxy handles DANE) Please don't mistake me : I generally like what DANE offers as extra ! But my feeling is only that the case of SSL proxy needs more elaboration. Kind regards, Marc Lampo -----Original Message----- From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] Sent: 01 May 2012 11:13 AM To: dane Subject: [dane] DANE IETF LC state of play Hi all, Well that's been a busy IETF LC. I think that shows that this is an important spec and the editors and chairs have done a great job so far on handling IETF LC comments, but I think there is a bit more work to do to be sure we're done and we may as well get that done now before the IESG are let loose on it:-) I went through the DANE WG archive of all the IETF LC comments and found the following ones where its not crystal clear from the archive that they're sorted. Notes: a) they might be just fine, e.g. if just one person comments and nobody else thought it important, then doing nothing is probably right. these just weren't clear from the archive so I wanna check; b) I only had time to scan the WG archive, if there are mails that were only to ietf@ietf.org or apps-discsuss that resolved these then I missed them, so just tell me about that, so I'll forward this to the other lists to check as well. So here's the list: 1) Jeff Hodges http://www.ietf.org/mail-archive/web/dane/current/msg04695.html http://www.ietf.org/mail-archive/web/dane/current/msg04713.html I mailed Jeff to see if -20 is ok. Silence can be taken to mean yes I think but since he had a bunch of things its hard to be sure. 2) PSA http://www.ietf.org/mail-archive/web/dane/current/msg04702.html http://www.ietf.org/mail-archive/web/dane/current/msg04790.html There are a few more small things still open in the last mail from earlier today. 3) Dave Cridland http://www.ietf.org/mail-archive/web/dane/current/msg04624.html I think there are still some occurrences of "certificate type" in section 8, (e.g. 3rd para, p18) so those weren't all fixed. I think that's the only remaining thing from Dave's review. 4) John Gilmore, http://www.ietf.org/mail-archive/web/dane/current/msg04635.html A.1 only has CA examples, what about non CA uses? I didn't see any reaction to that and it seems like a fair comment. 5) John Gilmore http://www.ietf.org/mail-archive/web/dane/current/msg04637.html John thinks there's a bias in sections 8/8.1, but I didn't see any reaction to that (other than mine, which just said "please do the right thing, whatever that is") 6) Mark Andrews http://www.ietf.org/mail-archive/web/dane/current/msg04657.html Again, not sure if there was follow-up. 7) PHB http://www.ietf.org/mail-archive/web/dane/current/msg04709.html Don't mandate client security policy (hardfail). I didn't see an obvious conclusion reached to make a change or not make a change. 8) Various on SRV http://www.ietf.org/mail-archive/web/dane/current/msg04793.html I think this might need a tweak to the SRV language in 1.3 (and just suggested one). Cheers, Stephen. ------=_NextPart_000_006D_01CD2DC5.CE5C11C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

(sorry = for late jump in)

 

= http://www.ietf.org/mail-archive/web/dane/current/msg04702.html<= /o:p>

 

There is a remark about section 8 and SSL = proxies.

 

My feeling is the topic condition were SSL proxy is = present is not yet treated with sufficient depth.

 

1) I'd = see the (conventional) proxy as a DANE-unaware client,

    in which case fall back scenario = is described.

 

   Or proxy implementers may enhance the = implementation by supporting DANE.

    In which case some error = messages may have to be defined

    reflecting abnormalities in the = DANE protocol, experienced by the proxy.

 

2) The = proposed draft for DANE states, in that section 8, on SSL = proxy.

    "In = such environments, using TLSA records will prevent the SSL = proxy

     = from functioning as expected because the TLS client will get = a

     = certificate association from the DNS that will not match = the

     = certificate that the SSL proxy uses with the = client."

 

   --> I think what is actually meant = is the connection between

       TLS client on = end-user equipment (browser) and the proxy.

       The = "connection" could work fine between proxy and TLS = service

        (either = because TLSA is ignored - "unknown" -

         or = because DANE is supported)

!! = --> the text assumes that the end-user equipment does indeed = get

        the TLSA = RR from the external service.

        In proxy = setups, this might not be true !

        Since = internal clients don't need Internet resolving,

         there = access to public DNS might be limited for good reason !

         = (think "internal root servers")

 

    Overall, my feeling is that = end-user clients that access TLS

     services via a proxy, = should make exceptions to how they handle DANE.

     (like : knowing how the = proxy handles DANE)

 

Please = don't mistake me :

I generally = like what DANE offers as extra !

= But my feeling is only that the case of SSL proxy needs more = elaboration.

 

 

Kind = regards,

 

Marc Lampo

 

 

 

 

-----Original Message-----

From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.i= e]

Sent: 01 May 2012 11:13 = AM

To: dane

Subject: [dane] DANE IETF LC state of = play

 

 

Hi = all,

 

Well that's been a busy IETF LC. I think that shows = that this is an important spec and the editors and chairs have done a = great job so far on handling IETF LC comments, but I think there is a = bit more work to do to be sure we're done and we may as well get that = done now before the IESG are let loose on it:-)

 

I went = through the DANE WG archive of all the IETF LC comments and found the = following ones where its not crystal clear from the archive that they're = sorted.

 

Notes: a) they might be just fine, e.g. if just one = person comments and nobody else thought it important, then doing nothing = is probably right. these just weren't clear from the archive so I wanna = check;

b) I only had time to scan = the WG archive, if there are mails that were only to ietf@ietf.org or apps-discsuss that = resolved these then I missed them, so just tell me about that, so I'll = forward this to the other lists to check as well.

 

So = here's the list:

 

1) = Jeff Hodges

= http://www.ietf.org/mail-archive/web/dane/current/msg04695.html<= /o:p>

= http://www.ietf.org/mail-archive/web/dane/current/msg04713.html<= /o:p>

 

I mailed Jeff to see if -20 is ok. Silence can be = taken to mean yes I think but since he had a bunch of things its hard to = be sure.

 

2) PSA

= http://www.ietf.org/mail-archive/web/dane/current/msg04702.html<= /o:p>

= http://www.ietf.org/mail-archive/web/dane/current/msg04790.html<= /o:p>

 

There are a few more small things still open in the = last mail from earlier today.

 

3) = Dave Cridland

= http://www.ietf.org/mail-archive/web/dane/current/msg04624.html<= /o:p>

 

I think there are still some occurrences of = "certificate type"

in = section 8, (e.g. 3rd para, p18) so those weren't all = fixed.

I think that's the only = remaining thing from Dave's review.

 

4) = John Gilmore,

= http://www.ietf.org/mail-archive/web/dane/current/msg04635.html<= /o:p>

 

A.1 only has CA examples, what about non CA uses? I = didn't see any reaction to that and it seems like a fair = comment.

 

5) John Gilmore

= http://www.ietf.org/mail-archive/web/dane/current/msg04637.html<= /o:p>

 

John thinks there's a bias in sections 8/8.1, but I = didn't see any reaction to that (other than mine, which just said = "please do the right thing, whatever that = is")

 

6) Mark = Andrews

= http://www.ietf.org/mail-archive/web/dane/current/msg04657.html=

 

Again, not sure if there was = follow-up.

 

7) PHB

= http://www.ietf.org/mail-archive/web/dane/current/msg04709.html<= /o:p>

 

Don't mandate client security policy (hardfail). I = didn't see an obvious conclusion reached to make a change or not make a = change.

 

8) Various on SRV

= http://www.ietf.org/mail-archive/web/dane/current/msg04793.html<= /o:p>

 

I think this might need a tweak to the SRV language = in 1.3 (and just suggested one).

 

Cheers,

Stephen.

 

------=_NextPart_000_006D_01CD2DC5.CE5C11C0-- From ondrej.sury@nic.cz Wed May 9 04:27:34 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AB3321F850B for ; Wed, 9 May 2012 04:27:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 VMqNVckxf+0y for ; Wed, 9 May 2012 04:27:33 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 2805F21F8499 for ; Wed, 9 May 2012 04:27:32 -0700 (PDT) Received: from [IPv6:2001:1488:ac14:1400:349a:c335:ba4b:eb06] (unknown [IPv6:2001:1488:ac14:1400:349a:c335:ba4b:eb06]) by mail.nic.cz (Postfix) with ESMTPSA id 0866813F69B; Wed, 9 May 2012 13:27:31 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1336562851; bh=dCFxVGAq8HrZIfqZvWhA3CfoYtS9diT4yYtkh4+rZfY=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=NiE/xIiiZz02DrJB1vW6fxr4zCFUceTeI6D/7ysMd/F9U1MXUWp/sDPTbaraUrs2b tfRjpa4AqRBJ5UAx0+8bwO+t9wGmJksCzqefx9gg0ZC5mid6DFw3EOmRcGcr/WoB9p lb7afEPdug6fHuFlfN/kdZOAggu2udDjxdfwFoxE= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <20120504031222.GA6541@odin.ulthar.us> Date: Wed, 9 May 2012 13:27:29 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2354EF03-D8D0-49AD-BD99-BA6AD2616FE6@nic.cz> References: <201204121903.q3CJ3ucF026698@new.toad.com> <9605FDF6-096D-4159-96A6-16549E8371AB@nic.cz> <20120504031222.GA6541@odin.ulthar.us> To: Scott Schmit X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: dane@ietf.org Subject: Re: [dane] Inappropriate Section 8 of draft-ietf-dane-protocol-19.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 11:27:34 -0000 On 4. 5. 2012, at 5:12, Scott Schmit wrote: > On Thu, May 03, 2012 at 05:47:43PM +0200, Ond=C5=99ej Sur=C3=BD wrote: >> John, >>=20 >> you have raised this issue several times and yet I haven't seen >> a supportive message from other WG members. On the other hand >> Jim Schaad[1] and me have opposed your view of the issue. >>=20 >> 1. https://www.ietf.org/mail-archive/web/dane/current/msg04566.html >>=20 >> Chairs think the text is fine as it is. If the other WG members >> disagree, please speak now. And again I would like to see a modified >> text if you are going to support the assertion that we favor CAs >> (Type 0/1). >=20 > I'll express support for John's technical arguments against section = 8.1. > I don't have a strong position about the paragraph in section 8, but I > think we can improve it by changing this: >=20 > The client's full trust of a certificate retrieved from a TLSA = record > with a certificate usage of 2 or 3 may be a matter of local policy. > While such trust is limited to the specific domain name for which = the > TLSA query was made, local policy may deny the trust or further > restrict the conditions under which that trust is permitted. >=20 > to this: >=20 > Generators of TLSA records should be aware that the client's full > trust of a certificate association retrieved from a TLSA record may > be a matter of local policy. While such trust is limited to the > specific domain name, protocol, and port for which the TLSA query = was > made, local policy may deny to trust the certificate (e.g., due to > weak cryptography), just as with PKIX trust anchors. LGTM > If you accept the above, the next question is what to replace it with. > I think this outline covers the ground: >=20 > * The risk of compromise > * Number of keys that can be compromised to achieve the desired = effect > * Likelihood of being a target of attack > * Security measures in place to prevent attack success (HSM, access = to > key, authentication of data to be signed) > * Qualifications/experience of people securing the keys > * ...Other?? > * The impact of such a compromise (#s of names affected) > * The likelihood of detection > * ...Other?? >=20 > I could propose some text to flesh out the outline (except the = "other"s, > as I don't know what they are yet :-) ), but before I start, I'd like = to > know that I wouldn't be wasting my time. I would certainly accept a better text. I share the position with = Stephen, that we need some text, so if we have one which is better and = technically more correct, I would be very happy. O. -- Ond=C5=99ej Sur=C3=BD -- Chief Science Officer ------------------------------------------- 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 Wed May 9 04:35:30 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 746DA21F854B for ; Wed, 9 May 2012 04:35:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 mdKrUdEwfiXy for ; Wed, 9 May 2012 04:35:29 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 66DAF21F853C for ; Wed, 9 May 2012 04:35:29 -0700 (PDT) Received: from [IPv6:2001:1488:ac14:1400:349a:c335:ba4b:eb06] (unknown [IPv6:2001:1488:ac14:1400:349a:c335:ba4b:eb06]) by mail.nic.cz (Postfix) with ESMTPSA id 7468813F69B; Wed, 9 May 2012 13:35:28 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1336563328; bh=2gCQZdV94Jl6o0ZsKYmmDjRScXnhvmXDB80DsZ4TWWI=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=wm1tmKRJerV+jHNYy3YsccHZ2gFUS6tvW3nXkXhv4XcuPZA88bu8PfGDjsBG/1z6R bz7Iex83zu/JtKiOenr5KBYT9Eo0hiiX6zCeLeFprKc5QbuTW3lgv+URIT0oQST6oe /U2ZYSkDoa4wCxZcNeIQpVILGAblhvZU/FxomWa0= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <014701cd2d21$d32a0710$797e1530$@lampo@eurid.eu> Date: Wed, 9 May 2012 13:35:28 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F9FA90B.9090607@cs.tcd.ie> <014701cd2d21$d32a0710$797e1530$@lampo@eurid.eu> To: Marc Lampo X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: 'dane' Subject: Re: [dane] DANE IETF LC state of play X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 09 May 2012 11:35:30 -0000 On 8. 5. 2012, at 15:52, Marc Lampo wrote: > Hello, >=20 > (sorry for late jump in) >=20 > http://www.ietf.org/mail-archive/web/dane/current/msg04702.html >=20 > There is a remark about section 8 and SSL proxies. >=20 > My feeling is the topic condition were SSL proxy is present > is not yet treated with sufficient depth. The questions is whether it does have to be treated in depth? > 1) I'd see the (conventional) proxy as a DANE-unaware client, > in which case fall back scenario is described. >=20 > Or proxy implementers may enhance the implementation by supporting > DANE. > In which case some error messages may have to be defined > reflecting abnormalities in the DANE protocol, experienced by the > proxy. >=20 > 2) The proposed draft for DANE states, in that section 8, on SSL = proxy. > "In such environments, using TLSA records will prevent the SSL = proxy > from functioning as expected because the TLS client will get a > certificate association from the DNS that will not match the > certificate that the SSL proxy uses with the client." Would it help to replace: "the TLS client" with "the DANE-aware TLS = client"? If not, could you please provide proposed text to fix that? I am not = feeling that we have to cover all possible cases here, I think that we can = safely assume that the "client" here is compliant with the document protocol. > --> I think what is actually meant is the connection between > TLS client on end-user equipment (browser) and the proxy. > The "connection" could work fine between proxy and TLS service > (either because TLSA is ignored - "unknown" - > or because DANE is supported) > !! --> the text assumes that the end-user equipment does indeed get > the TLSA RR from the external service. > In proxy setups, this might not be true ! > Since internal clients don't need Internet resolving, > there access to public DNS might be limited for good reason ! > (think "internal root servers") >=20 > Overall, my feeling is that end-user clients that access TLS > services via a proxy, should make exceptions to how they handle = DANE. > (like : knowing how the proxy handles DANE) >=20 > Please don't mistake me : > I generally like what DANE offers as extra ! > But my feeling is only that the case of SSL proxy needs more = elaboration. >=20 >=20 > Kind regards, >=20 > Marc Lampo >=20 >=20 >=20 >=20 > -----Original Message----- > From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie]=20 > Sent: 01 May 2012 11:13 AM > To: dane > Subject: [dane] DANE IETF LC state of play >=20 >=20 > Hi all, >=20 > Well that's been a busy IETF LC. I think that shows that this is an > important spec and the editors and chairs have done a great job so far = on > handling IETF LC comments, but I think there is a bit more work to do = to > be sure we're done and we may as well get that done now before the = IESG > are let loose on it:-) >=20 > I went through the DANE WG archive of all the IETF LC comments and = found > the following ones where its not crystal clear from the archive that > they're sorted. >=20 > Notes: a) they might be just fine, e.g. if just one person comments = and > nobody else thought it important, then doing nothing is probably = right. > these just weren't clear from the archive so I wanna check; > b) I only had time to scan the WG archive, if there are mails that = were > only to ietf@ietf.org or apps-discsuss that resolved these then I = missed > them, so just tell me about that, so I'll forward this to the other = lists > to check as well. >=20 > So here's the list: >=20 > 1) Jeff Hodges > http://www.ietf.org/mail-archive/web/dane/current/msg04695.html > http://www.ietf.org/mail-archive/web/dane/current/msg04713.html >=20 > I mailed Jeff to see if -20 is ok. Silence can be taken to mean yes I > think but since he had a bunch of things its hard to be sure. >=20 > 2) PSA > http://www.ietf.org/mail-archive/web/dane/current/msg04702.html > http://www.ietf.org/mail-archive/web/dane/current/msg04790.html >=20 > There are a few more small things still open in the last mail from = earlier > today. >=20 > 3) Dave Cridland > http://www.ietf.org/mail-archive/web/dane/current/msg04624.html >=20 > I think there are still some occurrences of "certificate type" > in section 8, (e.g. 3rd para, p18) so those weren't all fixed. > I think that's the only remaining thing from Dave's review. >=20 > 4) John Gilmore, > http://www.ietf.org/mail-archive/web/dane/current/msg04635.html >=20 > A.1 only has CA examples, what about non CA uses? I didn't see any > reaction to that and it seems like a fair comment. >=20 > 5) John Gilmore > http://www.ietf.org/mail-archive/web/dane/current/msg04637.html >=20 > John thinks there's a bias in sections 8/8.1, but I didn't see any > reaction to that (other than mine, which just said "please do the = right > thing, whatever that is") >=20 > 6) Mark Andrews > http://www.ietf.org/mail-archive/web/dane/current/msg04657.html >=20 > Again, not sure if there was follow-up. >=20 > 7) PHB > http://www.ietf.org/mail-archive/web/dane/current/msg04709.html >=20 > Don't mandate client security policy (hardfail). I didn't see an = obvious > conclusion reached to make a change or not make a change. >=20 > 8) Various on SRV > http://www.ietf.org/mail-archive/web/dane/current/msg04793.html >=20 > I think this might need a tweak to the SRV language in 1.3 (and just > suggested one). >=20 > Cheers, > Stephen. >=20 >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane -- Ond=C5=99ej Sur=C3=BD -- Chief Science Officer ------------------------------------------- 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 Wed May 9 04:47:50 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0FF421F8552; Wed, 9 May 2012 04:47:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 B+NgM-+eDU8V; Wed, 9 May 2012 04:47:50 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 1E6CC21F8551; Wed, 9 May 2012 04:47:50 -0700 (PDT) Received: from [IPv6:2001:1488:ac14:1400:349a:c335:ba4b:eb06] (unknown [IPv6:2001:1488:ac14:1400:349a:c335:ba4b:eb06]) by mail.nic.cz (Postfix) with ESMTPSA id 6E6B3140431; Wed, 9 May 2012 13:47:49 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1336564069; bh=d1yakrkQEVatpHG78FPs7zqBYPoGIPTRNsVqxZ6dfBg=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=p8iic0tbI/Fe/hWSenk6ve6xO0vv25OYNagTx/BrKjivx7FPEuqD5CLP7pjYTGOnz +Rp+gU8pTGxZxF7Cs6lROsbog3cYaz77FMGdae9sect2Sdhk3+wwPOlDToqNuSD+7r HnFc+ETKA0OlaerWPOYptuv+aVFPQRAgxwm5N4Do= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <4C883441-D7DD-4BE8-80C4-61C276CC8840@vpnc.org> Date: Wed, 9 May 2012 13:47:48 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2FDBECD0-43B9-4A49-B148-FF4AFEB48F87@nic.cz> References: <4F96D157.7020504@isode.com> <4F96D21A.7080006@isode.com> <4F96D2AB.6090509@stpeter.im> <4FA2E1F2.6060406@stpeter.im> <2B6494C5-4BB1-4159-967C-483094BDC0C7@vpnc.org> <4FA2FB94.204@stpeter.im> <07511DD9-AED9-4E67-B162-6D353C550788@vpnc.org> <4FA4430D.3090902@stpeter.im> <4C883441-D7DD-4BE8-80C4-61C276CC8840@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: "apps-discuss@ietf.org Discuss" , IETF DANE WG list Subject: Re: [dane] [apps-discuss] AppsDir review of draft-ietf-dane-protocol-19 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 09 May 2012 11:47:50 -0000 On 4. 5. 2012, at 23:10, Paul Hoffman wrote: > On May 4, 2012, at 1:58 PM, Peter Saint-Andre wrote: >=20 >> Borrowing a bit from RFC 6066 (thanks to Martin Rex for the pointer), = I >> suggest that we could add the following parenthetical statement to = point >> 3 in Section 3... >>=20 >> OLD >> 3. The domain name is appended to the result of step 2 to complete >> the prepared domain name. >>=20 >> NEW >>=20 >> 3. The domain name is appended to the result of step 2 to complete >> the prepared domain name. (The domain name is the fully >> qualified DNS domain name [RFC1035] of the TLS server and is >> represented as a byte string using ASCII encoding without a >> trailing dot; this enables support for internationalized >> domain names through the use of A-labels as defined in >> [RFC5890].) >=20 >=20 > Thank you for finally suggesting text. :-) >=20 > This seems fine to me, doesn't change anything technically, appears in = the right place, and doesn't feel gratuitous. ACK > --Paul Hoffman >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane -- Ond=C5=99ej Sur=C3=BD -- Chief Science Officer ------------------------------------------- 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 Wed May 9 04:52:29 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1FD821F8569; Wed, 9 May 2012 04:52:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 NAVZsD9ydM4f; Wed, 9 May 2012 04:52:29 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 19E9321F8513; Wed, 9 May 2012 04:52:29 -0700 (PDT) Received: from [IPv6:2001:1488:ac14:1400:349a:c335:ba4b:eb06] (unknown [IPv6:2001:1488:ac14:1400:349a:c335:ba4b:eb06]) by mail.nic.cz (Postfix) with ESMTPSA id 682E9140431; Wed, 9 May 2012 13:52:28 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1336564348; bh=1IAqY/FC1G26jqzA8/iKGYJqARCSu41YPOsQDIA8/L4=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=aLBuBxXWa1F8H5AoxssPWjyLC2elIjkgbEu790cYpM6BWDeGy1IK60+veCL7HexfB i1XAbXrmuHZmlBjrBCPi1xfTkl3OZG3kKYkZG5f5AWDY6GKXeoxDDistheoRREHuB6 X+9wMDCmC29a2hqdtZs2v6zL2rdRHwW7Yk9cEijI= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <20120507151257.GH8963@mail.yitter.info> Date: Wed, 9 May 2012 13:52:27 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120504220713.GR7394@crankycanuck.ca> <201205042224.q44MOo03029933@fs4113.wdf.sap.corp> <20120504223816.GV7394@crankycanuck.ca> <1EF0ACEE-52ED-4BDE-BF34-C995F117783D@vpnc.org> <20120507151257.GH8963@mail.yitter.info> To: Andrew Sullivan X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: IETF DANE WG list , Paul Hoffman , "apps-discuss@ietf.org Discuss" , The IESG Subject: Re: [dane] [apps-discuss] AppsDir review of X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 09 May 2012 11:52:29 -0000 On 7. 5. 2012, at 17:13, Andrew Sullivan wrote: > 3. The base domain name is appended to the result of step 2 to > complete the prepared domain name. The base domain name is the=20= > fully-qualified DNS domain name [RFC1035] of the TLS server, > with the additional restriction that every label must meet the > rules of [RFC952]. The latter restriction means that, if the > query is for an internationalized domain name, it must use the > A-label form as defined in [RFC5890]. This also works for me. Unless I hear any objections from WG, I think = we can use this text and close the issue. O. -- Ond=C5=99ej Sur=C3=BD -- Chief Science Officer ------------------------------------------- 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 i.grok@comcast.net Wed May 9 04:56:29 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E83A121F85AF for ; Wed, 9 May 2012 04:56:29 -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 83Q5L59rH3Q7 for ; Wed, 9 May 2012 04:56:29 -0700 (PDT) Received: from qmta13.emeryville.ca.mail.comcast.net (qmta13.emeryville.ca.mail.comcast.net [76.96.27.243]) by ietfa.amsl.com (Postfix) with ESMTP id 77EC121F847C for ; Wed, 9 May 2012 04:56:29 -0700 (PDT) Received: from omta03.emeryville.ca.mail.comcast.net ([76.96.30.27]) by qmta13.emeryville.ca.mail.comcast.net with comcast id 7nvo1j0070b6N64ADnwV4B; Wed, 09 May 2012 11:56:29 +0000 Received: from odin.ulthar.us ([68.33.77.0]) by omta03.emeryville.ca.mail.comcast.net with comcast id 7nwT1j00X00PQ6U8PnwUy3; Wed, 09 May 2012 11:56:29 +0000 Received: from odin.ulthar.us (localhost [127.0.0.1]) by odin.ulthar.us (8.14.5/8.14.3) with ESMTP id q49BuQxQ018096 for ; Wed, 9 May 2012 07:56:26 -0400 Received: (from draco@localhost) by odin.ulthar.us (8.14.5/8.14.5/Submit) id q49BuQFT018095 for dane@ietf.org; Wed, 9 May 2012 07:56:26 -0400 Date: Wed, 9 May 2012 07:56:26 -0400 From: Scott Schmit To: dane@ietf.org Message-ID: <20120509115626.GA31105@odin.ulthar.us> Mail-Followup-To: dane@ietf.org References: <201204121903.q3CJ3ucF026698@new.toad.com> <9605FDF6-096D-4159-96A6-16549E8371AB@nic.cz> <20120504031222.GA6541@odin.ulthar.us> <2354EF03-D8D0-49AD-BD99-BA6AD2616FE6@nic.cz> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="mYCpIKhGyMATD0i+" Content-Disposition: inline In-Reply-To: <2354EF03-D8D0-49AD-BD99-BA6AD2616FE6@nic.cz> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Inappropriate Section 8 of draft-ietf-dane-protocol-19.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 11:56:30 -0000 --mYCpIKhGyMATD0i+ Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, May 09, 2012 at 01:27:29PM +0200, Ond=C5=99ej Sur=C3=BD wrote: > On 4. 5. 2012, at 5:12, Scott Schmit wrote: > > On Thu, May 03, 2012 at 05:47:43PM +0200, Ond=C5=99ej Sur=C3=BD wrote: > > I think this outline covers the ground: > >=20 > > * The risk of compromise > > * Number of keys that can be compromised to achieve the desired effect > > * Likelihood of being a target of attack > > * Security measures in place to prevent attack success (HSM, access to > > key, authentication of data to be signed) > > * Qualifications/experience of people securing the keys > > * ...Other?? > > * The impact of such a compromise (#s of names affected) > > * The likelihood of detection > > * ...Other?? > >=20 > > I could propose some text to flesh out the outline (except the "other"s, > > as I don't know what they are yet :-) ), but before I start, I'd like to > > know that I wouldn't be wasting my time. >=20 > I would certainly accept a better text. I share the position with Stephe= n, > that we need some text, so if we have one which is better and technically > more correct, I would be very happy. Ok, I'll work on writing this up --=20 Scott Schmit --mYCpIKhGyMATD0i+ Content-Type: application/x-pkcs7-signature Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIIQJgYJKoZIhvcNAQcCoIIQFzCCEBMCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC DVcwggY0MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAe Fw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0 ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEp pC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9 b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54q zHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX 9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/ 4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8E BTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIw HwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wu Y29tL3Nmc2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIB FiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4IC AQAKgwh9eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8py TUnFsukDFUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMm CeUTyMyikfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIz uQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVm z/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT 5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lAp sbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076 khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8 J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRX un0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCBxswggYDoAMCAQICAwK+HTANBgkqhkiG 9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTExMDcxNzA1 MDQwNFoXDTEyMDcxNzExNDI1OVowYjEgMB4GA1UEDRMXNDY1MjU2LTBnRmI2Sk5ZWW44QnFW bUwxGzAZBgNVBAMMEmkuZ3Jva0Bjb21jYXN0Lm5ldDEhMB8GCSqGSIb3DQEJARYSaS5ncm9r QGNvbWNhc3QubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2AjLOMsBGaqN hv2FcRbfom/QCeKMXu5tUd1JY5oIDZe5y29stnd+se/zUlEkiVeMam4Jgo1c8yGNnwLVYc5/ 9xVi7Qg1Is5b9AB6aJWElJDw/jIdihymNZ2kwkSLT0wl/lzd0mXlwFJPRgQiRkmE6V0ZmjsQ jaVtllVleGBbMvmWPm92e+4Bju9P81kKz7Xr02ijETmaPdVsl+jmOaKPS8Y+2Lat2xus4Ked oJ/7aIWIpz1gRSKjAHSZ1Wmwi2TYUjYhZryChu9e1RWtqk1CycNoeusJ8xdEVN3WSnJ299w/ 3ltK/x/9rpj2j9ShQZVB4NnX6cjQs7pz1lVxvIkjcQIDAQABo4IDrTCCA6kwCQYDVR0TBAIw ADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQW BBQ29j2I0O8sRYi0So9NwwmT1caakDAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhR gjAdBgNVHREEFjAUgRJpLmdyb2tAY29tY2FzdC5uZXQwggIhBgNVHSAEggIYMIICFDCCAhAG CysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20v cG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJt ZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcg dG8gdGhlIENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4g Y29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUF BwICMIGPMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJp bGl0eSBhbmQgd2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFu ZCBMaW1pdGF0aW9ucyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAr oCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUH AQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFz czEvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0 cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQAZ5U0nL/2PQwsVfHgN7MVPbZEGzDzuj4Oy pTgz4XQFwPcCuy6U9sp1Dwmo3DyKX5nKN4xA7pslN+2Pl/kElGamX7zMCAH0xED0RTOLyk+v nDML4s+OUtWaYVnq1bZEp0F8Luq3zIslAYSebleyiz8M0EypZczsL5rOk86R2F9EYw1CBuFJ 5a4x0CmNu5o30fGNDFt+iXRlbJPp/KY25iUgVnBzJ4COT5kQjxn5lgr4t1I+BDCL5HQQ3h/8 2CzwrWVRBNb9Vqh9LL1ZtzYRt8JezoB6HkVvcKVNGlCZ+/MnvfMzPLwfbTDZC8o4d+4RH6aE LeGF2XmAOaenc/YRqm9oMYIClzCCApMCAQEwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQQIDAr4dMAkGBSsOAwIaBQCggdgwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTIwNTA5MTE1NjI2WjAjBgkqhkiG9w0BCQQxFgQU1szYd/yo c6vGyegwZdlwWYDVUFEweQYJKoZIhvcNAQkPMWwwajALBglghkgBZQMEASowCwYJYIZIAWUD BAEWMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAKv84pdHa wcgKClB/Birfr8i/s3dp9WlxE+b0HjA5E6RPKRczoGNiVdHSyUqy9SNWrywVvF1/Fpqn5/gJ TgrZ3t0895yCcjZn0RaT9bPtwpxQQ/yiZehu0B+u/j+nOrO0xQDxS1TtiXq3osREsO1GcPaC CwU/WIBIjREa+T34jPdBHmoICCxmgTtkMGzzW2OmwuzzGIKP/bfXbL8UJju/PekufAMF4vaX V9nb8L6stqmoMmHhbsRUMS/q3XLryszldrui3Pj67v+y1riqM8OnoMXB0zov/KTSJYBqrsmE YbESEL8HO7vXTchCfue6O+PV8AKWh4VbuD/WQz3iny2HYw== --mYCpIKhGyMATD0i+-- From marc.lampo@eurid.eu Wed May 9 05:58:48 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4FC021F85C7 for ; Wed, 9 May 2012 05:58:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.514 X-Spam-Level: X-Spam-Status: No, score=-0.514 tagged_above=-999 required=5 tests=[AWL=-0.264, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, MSGID_MULTIPLE_AT=1.449] 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 037hseKnFIoN for ; Wed, 9 May 2012 05:58:47 -0700 (PDT) Received: from barra.eurid.eu (barra.eurid.eu [78.41.71.12]) by ietfa.amsl.com (Postfix) with ESMTP id 9B4DB21F8474 for ; Wed, 9 May 2012 05:58:47 -0700 (PDT) X-ASG-Debug-ID: 1336568325-0369496fa71fcf0001-pGO8SV Received: from zimbra.eurid.eu (zcs-master.vt.eurid.eu [10.19.100.121]) by barra.eurid.eu with ESMTP id J5Okc4vBUFwGLsiU; Wed, 09 May 2012 14:58:45 +0200 (CEST) X-Barracuda-Envelope-From: marc.lampo@eurid.eu X-ASG-Whitelist: Client Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.eurid.eu (Postfix) with ESMTP id 9FC3DE4069; Wed, 9 May 2012 14:58:45 +0200 (CEST) X-Virus-Scanned: amavisd-new at techmail.eurid.eu Received: from zimbra.eurid.eu ([127.0.0.1]) by localhost (zimbra.eurid.eu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f+B8NMCXruNp; Wed, 9 May 2012 14:58:45 +0200 (CEST) Received: from zimbra.eurid.eu (zimbra.eurid.eu [10.19.100.120]) by zimbra.eurid.eu (Postfix) with ESMTP id 8B96EE4054; Wed, 9 May 2012 14:58:45 +0200 (CEST) From: "Marc Lampo" To: =?utf-8?Q?'Ond=C5=99ej_Sur=C3=BD'?= References: <4F9FA90B.9090607@cs.tcd.ie> <014701cd2d21$d32a0710$797e1530$@lampo@eurid.eu> In-Reply-To: Date: Wed, 9 May 2012 14:58:45 +0200 (CEST) X-ASG-Orig-Subj: RE: [dane] DANE IETF LC state of play Message-ID: <001f01cd2de3$77be78d0$673b6a70$@lampo@eurid.eu> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Mailer: Microsoft Office Outlook 12.0 X-Mailer: Zimbra 6.0.14_GA_2928 (ZimbraConnectorForOutlook/5.0.3064.18) Thread-Index: Ac0t1+jEi4G4hqhlTH6q/KxqA9w8igAB1CLA Content-Language: en-za x-antivirus-status: Clean x-antivirus: avast! X-Originating-IP: [172.20.5.49] X-Barracuda-Connect: zcs-master.vt.eurid.eu[10.19.100.121] X-Barracuda-Start-Time: 1336568325 X-Barracuda-URL: http://10.19.10.12:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at eurid.eu Cc: 'dane' Subject: Re: [dane] DANE IETF LC state of play X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 09 May 2012 12:58:48 -0000 Hello, In my opinion the "client" side should not be ignored ! The present text implicitly assumes the browser - has direct access to the server - has unlimited access to public DNS data (obviously, since it must be able to query for IP address of the server) Only in that section 8, the existence of "SSL Proxy" is mentioned. And the phrasing is such that it mostly suggest : "DANE won't work". Why not insert a section between present 6. and 7. that addresses this "client" side ? I see four cases : X.1. Unlimited access to DANE service and to public DNS Explain that this is the initial assumption. X.2. Client accesses DANE service via explicit SSL proxy, and has unlimited access to public DNS. In this condition the client is aware of the existence of that SSL proxy, and it is aware of the service TLSA RR. X.3. Client accesses DANE service via implicit SSL proxy, and has unlimited access to public DNS. In this condition the client is not aware of the existence of that SSL proxy, and it is aware of the service TLSA RR. X.4. Client accesses DANE service via explicit SSL proxy, and does not have access to public DNS. In this condition the client is aware of the existence of that SSL proxy, and it is not aware of the service TLSA RR. I think the document would benefit from explicit statements about those conditions. To benefit as much as possible from DANE, I think the authors can propose how to cope with situation X.2 - explicit proxy + full access to public DNS -, in such a way that the end-user is not punished by the existence of the SSL proxy --> allow for exceptions when not to insist on DANE validation. As well as with situation X.4 - explicit proxy + no access to public DNS - : since the browser client sees no TSLA RR (even "worse" : NXDOMAIN) this situation could be permitted (no DANE validation by browser). Situation X.3 - implicit proxy, with full access to public DNS - is problematic (as far as I can see - yet another reason to avoid implicit proxy) I do think it is out of scope of "this" document to describe possible "extensions" that allow full benefit of DANE to clients behind explicit proxies. That would be some kind of "dialogue" between the explicit, DANE aware, proxy and the browser. (in a first impulse : like adding a TLSA record on the proxy's (internal) DNS data that - confirms this proxy is a client supporting DANE - acknowledges the certificate of this explicit proxy (like : certificate usage field value of value #4 which is comparable to #3 - domain issued certificate - but that implies the certificate is of the proxy not the DANE service.) ((please don't shoot me for this suggestion, I am by no means a specialist in DANE)) Please forgive that I do not attempt to provide directly useable text; I have by no means the in depth insight in DANE to do so. Kind regards, Marc Lampo -----Original Message----- From: OndÅ™ej Surý [mailto:ondrej.sury@nic.cz] Sent: 09 May 2012 01:35 PM To: Marc Lampo Cc: 'Stephen Farrell'; 'dane' Subject: Re: [dane] DANE IETF LC state of play On 8. 5. 2012, at 15:52, Marc Lampo wrote: > Hello, > > (sorry for late jump in) > > http://www.ietf.org/mail-archive/web/dane/current/msg04702.html > > There is a remark about section 8 and SSL proxies. > > My feeling is the topic condition were SSL proxy is present is not yet > treated with sufficient depth. The questions is whether it does have to be treated in depth? > 1) I'd see the (conventional) proxy as a DANE-unaware client, > in which case fall back scenario is described. > > Or proxy implementers may enhance the implementation by supporting > DANE. > In which case some error messages may have to be defined > reflecting abnormalities in the DANE protocol, experienced by the > proxy. > > 2) The proposed draft for DANE states, in that section 8, on SSL proxy. > "In such environments, using TLSA records will prevent the SSL proxy > from functioning as expected because the TLS client will get a > certificate association from the DNS that will not match the > certificate that the SSL proxy uses with the client." Would it help to replace: "the TLS client" with "the DANE-aware TLS client"? If not, could you please provide proposed text to fix that? I am not feeling that we have to cover all possible cases here, I think that we can safely assume that the "client" here is compliant with the document protocol. > --> I think what is actually meant is the connection between > TLS client on end-user equipment (browser) and the proxy. > The "connection" could work fine between proxy and TLS service > (either because TLSA is ignored - "unknown" - > or because DANE is supported) > !! --> the text assumes that the end-user equipment does indeed get > the TLSA RR from the external service. > In proxy setups, this might not be true ! > Since internal clients don't need Internet resolving, > there access to public DNS might be limited for good reason ! > (think "internal root servers") > > Overall, my feeling is that end-user clients that access TLS > services via a proxy, should make exceptions to how they handle DANE. > (like : knowing how the proxy handles DANE) > > Please don't mistake me : > I generally like what DANE offers as extra ! > But my feeling is only that the case of SSL proxy needs more elaboration. > > > Kind regards, > > Marc Lampo > > > > > -----Original Message----- > From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] > Sent: 01 May 2012 11:13 AM > To: dane > Subject: [dane] DANE IETF LC state of play > > > Hi all, > > Well that's been a busy IETF LC. I think that shows that this is an > important spec and the editors and chairs have done a great job so far > on handling IETF LC comments, but I think there is a bit more work to > do to be sure we're done and we may as well get that done now before > the IESG are let loose on it:-) > > I went through the DANE WG archive of all the IETF LC comments and > found the following ones where its not crystal clear from the archive > that they're sorted. > > Notes: a) they might be just fine, e.g. if just one person comments > and nobody else thought it important, then doing nothing is probably > right. > these just weren't clear from the archive so I wanna check; > b) I only had time to scan the WG archive, if there are mails that > were only to ietf@ietf.org or apps-discsuss that resolved these then I > missed them, so just tell me about that, so I'll forward this to the > other lists to check as well. > > So here's the list: > > 1) Jeff Hodges > http://www.ietf.org/mail-archive/web/dane/current/msg04695.html > http://www.ietf.org/mail-archive/web/dane/current/msg04713.html > > I mailed Jeff to see if -20 is ok. Silence can be taken to mean yes I > think but since he had a bunch of things its hard to be sure. > > 2) PSA > http://www.ietf.org/mail-archive/web/dane/current/msg04702.html > http://www.ietf.org/mail-archive/web/dane/current/msg04790.html > > There are a few more small things still open in the last mail from > earlier today. > > 3) Dave Cridland > http://www.ietf.org/mail-archive/web/dane/current/msg04624.html > > I think there are still some occurrences of "certificate type" > in section 8, (e.g. 3rd para, p18) so those weren't all fixed. > I think that's the only remaining thing from Dave's review. > > 4) John Gilmore, > http://www.ietf.org/mail-archive/web/dane/current/msg04635.html > > A.1 only has CA examples, what about non CA uses? I didn't see any > reaction to that and it seems like a fair comment. > > 5) John Gilmore > http://www.ietf.org/mail-archive/web/dane/current/msg04637.html > > John thinks there's a bias in sections 8/8.1, but I didn't see any > reaction to that (other than mine, which just said "please do the > right thing, whatever that is") > > 6) Mark Andrews > http://www.ietf.org/mail-archive/web/dane/current/msg04657.html > > Again, not sure if there was follow-up. > > 7) PHB > http://www.ietf.org/mail-archive/web/dane/current/msg04709.html > > Don't mandate client security policy (hardfail). I didn't see an > obvious conclusion reached to make a change or not make a change. > > 8) Various on SRV > http://www.ietf.org/mail-archive/web/dane/current/msg04793.html > > I think this might need a tweak to the SRV language in 1.3 (and just > suggested one). > > Cheers, > Stephen. > > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane -- OndÅ™ej Surý -- Chief Science Officer ------------------------------------------- CZ.NIC, z.s.p.o. -- LaboratoÅ™e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- From paul@cypherpunks.ca Wed May 9 06:39:29 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F139021F848E for ; Wed, 9 May 2012 06:39:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=-0.150, 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 DvTcMznyBt5T for ; Wed, 9 May 2012 06:39:28 -0700 (PDT) Received: from letoams.cypherpunks.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 84C9C21F8484 for ; Wed, 9 May 2012 06:39:28 -0700 (PDT) Received: by letoams.cypherpunks.ca (Postfix, from userid 500) id CBA5A853FC; Wed, 9 May 2012 09:39:25 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by letoams.cypherpunks.ca (Postfix) with ESMTP id C291F853FB; Wed, 9 May 2012 09:39:25 -0400 (EDT) Date: Wed, 9 May 2012 09:39:25 -0400 (EDT) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: =?ISO-8859-2?Q?Ond=F8ej_Sur=FD?= In-Reply-To: Message-ID: References: <4F9FA90B.9090607@cs.tcd.ie> <014701cd2d21$d32a0710$797e1530$@lampo@eurid.eu> User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=ISO-8859-2 Content-Transfer-Encoding: 8BIT Cc: Marc Lampo , 'dane' Subject: Re: [dane] DANE IETF LC state of play X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 09 May 2012 13:39:29 -0000 On Wed, 9 May 2012, Ondøej Surý wrote: >> http://www.ietf.org/mail-archive/web/dane/current/msg04702.html >> >> There is a remark about section 8 and SSL proxies. >> >> My feeling is the topic condition were SSL proxy is present >> is not yet treated with sufficient depth. > > The questions is whether it does have to be treated in depth? We could do more then just state "you have a problem". How about: When a TLS client supporting TLSA records is configured to use an SSL proxy, it should have one or more of the following features: o Disable all DNS lookups when using an SSL proxy (eg SOCKS proxy) o Disable or allow to disable TLSA validation when using an SSL proxy o Treat the SSL certificate of the configured SSL proxy as a valid override for information obtained from TLSA records. o Prominently warn if the SSL proxy certificate does not validate to a configured PKIX trust anchor. TLS clients configured to use an SSL proxy should clearly display the certificate owner name of the SSL proxy at locations where normally the remote TLS certificate information is displayed to prevent the malicious configuration of an SSL proxy without the user's consent. One thing I'm not sure about is what to do with TLSA-based SSL proxy certificates. It might be nice to configure those for trust, but could also lead to rogue configurations of SSL proxy that validate their certificate to a random TLSA record on a remote malicious site. Paul From ondrej.sury@nic.cz Wed May 9 06:44:08 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A804621F85F9 for ; Wed, 9 May 2012 06:44:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.619 X-Spam-Level: X-Spam-Status: No, score=-1.619 tagged_above=-999 required=5 tests=[AWL=0.080, 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 MXTO8Tttg647 for ; Wed, 9 May 2012 06:44:07 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id BF2B821F854E for ; Wed, 9 May 2012 06:44:07 -0700 (PDT) Received: from kimac.office.nic.cz (fw.nic.cz [217.31.207.1]) by mail.nic.cz (Postfix) with ESMTPSA id 1945213FA60; Wed, 9 May 2012 15:44:07 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1336571047; bh=0kewZppMU8aqx8oxsoSLXYiDHYbXNs6w8sh2CrNStFo=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=HqS/g7OTzXlixcsQGzTAETDLset7MC436KQxYqEWKWUbtq/VKOE2ehC9soawrblMu 4QkQl3Hovy0Q8CWS8y5o+LqTM2HsvYLbke/mR2D6szXSe7BF/DIMPFL5Z4cK+8Khxh GeXcUClwzoYrG8TviECUleUM/DV0ohgx02I6hdZ4= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-2 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: Date: Wed, 9 May 2012 15:44:06 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8869B0AB-5F9B-47C1-B576-184E61A97564@nic.cz> References: <4F9FA90B.9090607@cs.tcd.ie> <014701cd2d21$d32a0710$797e1530$@lampo@eurid.eu> To: Paul Wouters X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: Marc Lampo , 'dane' Subject: Re: [dane] DANE IETF LC state of play X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 09 May 2012 13:44:08 -0000 On 9. 5. 2012, at 15:39, Paul Wouters wrote: > On Wed, 9 May 2012, Ond=F8ej Sur=FD wrote: >=20 >>> http://www.ietf.org/mail-archive/web/dane/current/msg04702.html >>>=20 >>> There is a remark about section 8 and SSL proxies. >>>=20 >>> My feeling is the topic condition were SSL proxy is present >>> is not yet treated with sufficient depth. >>=20 >> The questions is whether it does have to be treated in depth? >=20 > We could do more then just state "you have a problem". How about: >=20 >=20 > When a TLS client supporting TLSA records is configured to use an = SSL > proxy, it should have one or more of the following features: >=20 > o Disable all DNS lookups when using an SSL proxy (eg SOCKS proxy) > o Disable or allow to disable TLSA validation when using an SSL = proxy > o Treat the SSL certificate of the configured SSL proxy as a valid = override > for information obtained from TLSA records. > o Prominently warn if the SSL proxy certificate does not validate to > a configured PKIX trust anchor. >=20 > TLS clients configured to use an SSL proxy should clearly display = the > certificate owner name of the SSL proxy at locations where normally = the > remote TLS certificate information is displayed to prevent the = malicious > configuration of an SSL proxy without the user's consent. This is a very bad idea to do in the "protocol" document. We don't want to have a kitchensink protocol document which includes all. Personally I am just fine with 'you have a problem' statement and let = the people solve it elsewhere if they care. O. -- Ond=F8ej Sur=FD -- Chief Science Officer ------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=F8e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- From warren@kumari.net Wed May 9 10:15:25 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 600C411E80A3 for ; Wed, 9 May 2012 10:15:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.482 X-Spam-Level: X-Spam-Status: No, score=-105.482 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, 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 vX+If2Vh+bwe for ; Wed, 9 May 2012 10:15:24 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id DB67111E8079 for ; Wed, 9 May 2012 10:15:23 -0700 (PDT) Received: from dhcp-172-19-118-235.cbf.corp.google.com (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id DEB291B40180; Wed, 9 May 2012 13:15:22 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-2 From: Warren Kumari In-Reply-To: <8869B0AB-5F9B-47C1-B576-184E61A97564@nic.cz> Date: Wed, 9 May 2012 13:15:21 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <327691CB-19FF-4465-83BB-51A5825ACCE0@kumari.net> References: <4F9FA90B.9090607@cs.tcd.ie> <014701cd2d21$d32a0710$797e1530$@lampo@eurid.eu> <8869B0AB-5F9B-47C1-B576-184E61A97564@nic.cz> To: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= X-Mailer: Apple Mail (2.1084) Cc: Marc Lampo , 'dane' Subject: Re: [dane] DANE IETF LC state of play X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 09 May 2012 17:15:25 -0000 On May 9, 2012, at 9:44 AM, Ond=F8ej Sur=FD wrote: >=20 > On 9. 5. 2012, at 15:39, Paul Wouters wrote: >=20 >> On Wed, 9 May 2012, Ond=F8ej Sur=FD wrote: >>=20 >>>> http://www.ietf.org/mail-archive/web/dane/current/msg04702.html >>>>=20 >>>> There is a remark about section 8 and SSL proxies. >>>>=20 >>>> My feeling is the topic condition were SSL proxy is present >>>> is not yet treated with sufficient depth. >>>=20 >>> The questions is whether it does have to be treated in depth? >>=20 >> We could do more then just state "you have a problem". How about: >>=20 >>=20 >> When a TLS client supporting TLSA records is configured to use an = SSL >> proxy, it should have one or more of the following features: >>=20 >> o Disable all DNS lookups when using an SSL proxy (eg SOCKS proxy) >> o Disable or allow to disable TLSA validation when using an SSL = proxy >> o Treat the SSL certificate of the configured SSL proxy as a valid = override >> for information obtained from TLSA records. >> o Prominently warn if the SSL proxy certificate does not validate to >> a configured PKIX trust anchor. >>=20 >> TLS clients configured to use an SSL proxy should clearly display = the >> certificate owner name of the SSL proxy at locations where normally = the >> remote TLS certificate information is displayed to prevent the = malicious >> configuration of an SSL proxy without the user's consent. >=20 > This is a very bad idea to do in the "protocol" document. We don't = want > to have a kitchensink protocol document which includes all. >=20 > Personally I am just fine with 'you have a problem' statement and let = the > people solve it elsewhere if they care. Me too! Hmmm, this sounds like a really nice idea for a follow on = document -- "How to do DANE like things in the presence of proxies" or = something... Submissions considered... W >=20 > O. > -- > Ond=F8ej Sur=FD -- Chief Science Officer > ------------------------------------------- > CZ.NIC, z.s.p.o. -- Laborato=F8e CZ.NIC > Americka 23, 120 00 Praha 2, Czech Republic > mailto:ondrej.sury@nic.cz http://nic.cz/ > tel:+420.222745110 fax:+420.222745112 > ------------------------------------------- >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane >=20 From ondrej.mikle@nic.cz Wed May 9 23:51:51 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11D3E21F85D1 for ; Wed, 9 May 2012 23:51:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 KjzEWUPpJbGY for ; Wed, 9 May 2012 23:51:50 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 41EF721F85BB for ; Wed, 9 May 2012 23:51:49 -0700 (PDT) Received: from [192.168.0.100] (ip-94-113-0-21.net.upcbroadband.cz [94.113.0.21]) by mail.nic.cz (Postfix) with ESMTPSA id 763A913F868; Thu, 10 May 2012 08:51:48 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1336632708; bh=xWuukibK1BT3kK5dxL23J/Ryu5jZUn4xLqqK9+s/7C0=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=aTDp3g1B3vt4hL+YwH+7+WsNYTyfk5S8N0gLT1KqRW+fKRoHvMmmqc3MhIa6OP3w9 LKbMhOXWmCgahLJfkHs73sAtbK+1fQ1v9GUBW3G5jI3f8AV0Yz0hE0HNfIhpk8Qa2P ywZ2z5RM7BKVZMotWC0u/cpW05YaCUfa7nUSTwOI= Message-ID: <4FAB6583.7080903@nic.cz> Date: Thu, 10 May 2012 08:51:47 +0200 From: Ondrej Mikle User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Tony Finch References: <20120504023602.GA4683@mail.yitter.info> <20120504112922.GB4929@mail.yitter.info> <20120504144426.GD4929@mail.yitter.info> <3FF36EBA-F8B1-4D66-BA00-E8E36A7E449D@kumari.net> <6015A12B-8CA9-426B-9AFF-32CD4211DAB5@vpnc.org> <20120504165311.GB7394@mail.yitter.info> <4FA5D178.8030405@nic.cz> In-Reply-To: X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: dane@ietf.org Subject: Re: [dane] Behavior in the face of no answer? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 10 May 2012 06:51:51 -0000 On 05/08/2012 09:46 PM, Tony Finch wrote: > Ondrej Mikle wrote: >> >> From the ongoing scan, out of 70M currently finished .com domains, >> SERVFAILs appeared for ~8.6M distinct domains. > > We're running validating resolvers and we haven't noticed that level of > failure. What proportion of authoritative servers with working DNSSEC > return SERVFAIL for what QTYPEs? The scans finished, here is a breakdown of what those SERVFAILs represented. Short summary: As I expected, most of the domains are most likely parked/unmaintained/speculative (by some whois queries, still SERVFAIL etc.) Thus no reason for admin to care about them - that also means users won't ask for them either. Total amount of .com domains scanned: ~102M 1. SERVFAILS due to NS fetch failed and other RRs failed (disjunct) 10114651 - NS fetch failed - the scanner skips the domain altogether 2373284 - unique count of domains with SERVFAIL for at least one other RR 12487935 total 2. NS fails on FQDNs contained in Alexa/Quantcast TOP 1M 19574 alexa 26087 quantcast 3. Unique domain count with at least one SERVFAIL for non-NS RR present in Alexa/Quantcast TOP 1M 18977 alexa 6017 quantcast The errors from "valuable/important" domains seemed transient (just bad time to ask, probably). We'll still redo the SERVFAILs once/twice more. Other (maybe interesting) common "weird pattern" is using 127.0.0.1 or 0.0.0.0 for A targets. I'm guessing those are domains used for development (so that it connects to developer's machine). Can anyone think of other reason? Apart from the above, there is definitely more brokenness. Mostly various corner cases not explicitly/exhaustively covered by RFCs (tough rare in numbers). Ondrej Mikle From fanf2@hermes.cam.ac.uk Thu May 10 02:41:37 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ACD921F8620 for ; Thu, 10 May 2012 02:41:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.525 X-Spam-Level: X-Spam-Status: No, score=-6.525 tagged_above=-999 required=5 tests=[AWL=0.074, 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 ULALzDpa7j3o for ; Thu, 10 May 2012 02:41:36 -0700 (PDT) Received: from ppsw-52.csi.cam.ac.uk (ppsw-52.csi.cam.ac.uk [131.111.8.152]) by ietfa.amsl.com (Postfix) with ESMTP id 4CA1E21F8562 for ; Thu, 10 May 2012 02:41:36 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:53549) by ppsw-52.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1SSPsL-000346-Fo (Exim 4.72) (return-path ); Thu, 10 May 2012 10:41:34 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1SSPsL-0004Pe-Sj (Exim 4.67) (return-path ); Thu, 10 May 2012 10:41:33 +0100 Date: Thu, 10 May 2012 10:41:33 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Ondrej Mikle In-Reply-To: <4FAB6583.7080903@nic.cz> Message-ID: References: <20120504023602.GA4683@mail.yitter.info> <20120504112922.GB4929@mail.yitter.info> <20120504144426.GD4929@mail.yitter.info> <3FF36EBA-F8B1-4D66-BA00-E8E36A7E449D@kumari.net> <6015A12B-8CA9-426B-9AFF-32CD4211DAB5@vpnc.org> <20120504165311.GB7394@mail.yitter.info> <4FA5D178.8030405@nic.cz> <4FAB6583.7080903@nic.cz> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: dane@ietf.org Subject: Re: [dane] Behavior in the face of no answer? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 10 May 2012 09:41:37 -0000 Ondrej Mikle wrote: > On 05/08/2012 09:46 PM, Tony Finch wrote: > > Ondrej Mikle wrote: > >> > >> From the ongoing scan, out of 70M currently finished .com domains, > >> SERVFAILs appeared for ~8.6M distinct domains. > > > > We're running validating resolvers and we haven't noticed that level of > > failure. What proportion of authoritative servers with working DNSSEC > > return SERVFAIL for what QTYPEs? > > The scans finished, here is a breakdown of what those SERVFAILs represented. > Short summary: As I expected, most of the domains are most likely > parked/unmaintained/speculative (by some whois queries, still SERVFAIL etc.) > Thus no reason for admin to care about them - that also means users won't ask > for them either. For our purposes we need a breakdown of the "other RR" cases. The fact that 10% of domains have broken delegations is sad but it isn't going to confuse a DANE implementation into thinking there is an attack. Tony. -- f.anthony.n.finch http://dotat.at/ Faeroes: Northerly 4 or 5, occasionally 6 later in east. Moderate, becoming rough later in far east. Wintry showers. Good. From ondrej.mikle@nic.cz Thu May 10 06:25:49 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4C4C21F866A for ; Thu, 10 May 2012 06:25:49 -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 Abp3Ov9udlhy for ; Thu, 10 May 2012 06:25:48 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 50AC321F8666 for ; Thu, 10 May 2012 06:25:48 -0700 (PDT) Received: from [IPv6:2001:1488:ac14:1400:221:ccff:fe72:8878] (unknown [IPv6:2001:1488:ac14:1400:221:ccff:fe72:8878]) by mail.nic.cz (Postfix) with ESMTPSA id 9BB3C13F868; Thu, 10 May 2012 15:25:47 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1336656347; bh=sU3DFg3uztGfaa1M4HSohSNo0ZSUsMPBAujZooxsj3M=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=iDxIIPWUtTokJ1M++AoUCAAx+f0ZDFF5WfSF1C7Tp5g4Nw5NnP2GMk4KyOboRqjFE kGl/rhFnXFbbo1w/LBUMVIbuZRifhPvFD5qXWHJWV1LnHvejYR/rN9p3SZrIFex5sG 2/b/zPcLvAoW//t12WHqbUP85JSWmzywmyfpWe5k= Message-ID: <4FABC1DB.6010505@nic.cz> Date: Thu, 10 May 2012 15:25:47 +0200 From: Ondrej Mikle User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Tony Finch References: <20120504023602.GA4683@mail.yitter.info> <20120504112922.GB4929@mail.yitter.info> <20120504144426.GD4929@mail.yitter.info> <3FF36EBA-F8B1-4D66-BA00-E8E36A7E449D@kumari.net> <6015A12B-8CA9-426B-9AFF-32CD4211DAB5@vpnc.org> <20120504165311.GB7394@mail.yitter.info> <4FA5D178.8030405@nic.cz> <4FAB6583.7080903@nic.cz> In-Reply-To: X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: dane@ietf.org Subject: Re: [dane] Behavior in the face of no answer? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 10 May 2012 13:25:50 -0000 On 05/10/2012 11:41 AM, Tony Finch wrote: > Ondrej Mikle wrote: >> On 05/08/2012 09:46 PM, Tony Finch wrote: >>> Ondrej Mikle wrote: >>>> >>>> From the ongoing scan, out of 70M currently finished .com domains, >>>> SERVFAILs appeared for ~8.6M distinct domains. >>> >>> We're running validating resolvers and we haven't noticed that level of >>> failure. What proportion of authoritative servers with working DNSSEC >>> return SERVFAIL for what QTYPEs? >> >> The scans finished, here is a breakdown of what those SERVFAILs represented. >> Short summary: As I expected, most of the domains are most likely >> parked/unmaintained/speculative (by some whois queries, still SERVFAIL etc.) >> Thus no reason for admin to care about them - that also means users won't ask >> for them either. > > For our purposes we need a breakdown of the "other RR" cases. The fact > that 10% of domains have broken delegations is sad but it isn't going to > confuse a DANE implementation into thinking there is an attack. Sorry for the confusion, turns out the idea of posting the numbers before everything is polished was not that great. Don't get me wrong, I want to get DANE working as soon as possible. I even think having some brokeness is not that bad (SW vendors may likely disagree). Many of the scenarios described in this thread cause DoS with hard-fail, otherwise cause downgrade attacks. But what about asking "how much" brokeness is there and "how much" brokeness due to forcing hard-fail is "tolerable"? (so that we don't have to make binary DoS-xor-downgrade-attack choice). Simple proposal complementary to probing authNSs: TLSA will be implemented as soft-fail at first, followed by a "TLSA day" (analogy of IPv6 day) where for instance Google will place a small piece of code to test users' resolvers (Google has unique position of having interest in TLSA and capability to do the measurement of clients' resolvers). The above paragraph is an engineering solution, not suitable as text for RFC, but I fail to see any better alternative to binary option hard-fail/downgrade-attack. It's been the same with CRL and OCSP (hard fail - possible DoS, otherwise no effect). In every client that supports it, I set OCSP to be required. Errors are rather rare. Unfixable exceptions which I'd just mark "problem of somebody else - we don't care": - captive portals - central idea of being built on MitM is broken on so many levels (why not just 802.1x? - I had always less problems with that) - broken DNS resolver implementations - I've always seen them exclusively with captive portals, but there few other "plastic home router boxes" for sure If we keep piling up workarounds/special-code-branches for thoroughly broken infrastructure pieces instead of showing error, things will get even more messy and exploitable. Take "transvalid" certificates as an example - TLS server doesn't send complete chain, works for admin, works for most users, but not users with clean browser profile. Hard to debug even for seasoned admins (who may be not experts in PKIX implementation quirks). Too permissive protocol handling has track record of leading towards vulnerabilities (OID decoder permitting leading 0x80 bug for instance). Solution (big maybe): software should _point_fingers_ with as end-user-readable-messages-as-possible at whoever is responsible - resolver fail at ISP/captive portal, CA for OCSP responder, etc. There have been couple of attempts to detect such broken-by-design elements like captive portals (e.g. ooni-probe). Brokeness should be pushed away, not worked around - maybe some "You-misunderstood-Jon-Postel"-protocol-fascists action is in order :-) (like the campaign against IE6) Ondrej Mikle From gnu@toad.com Fri May 11 09:46:28 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7D6421F86C2 for ; Fri, 11 May 2012 09:46:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.081 X-Spam-Level: * X-Spam-Status: No, score=1.081 tagged_above=-999 required=5 tests=[AWL=-0.505, BAYES_05=-1.11, RCVD_IN_NJABL_RELAY=2.696] 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 XmGK2bpoHJIA for ; Fri, 11 May 2012 09:46:28 -0700 (PDT) Received: from new.toad.com (new.toad.com [209.237.225.253]) by ietfa.amsl.com (Postfix) with ESMTP id 42B9421F86C1 for ; Fri, 11 May 2012 09:46:27 -0700 (PDT) Received: from new.toad.com (localhost.localdomain [127.0.0.1]) by new.toad.com (8.12.9/8.12.9) with ESMTP id q4BGkNcF008939; Fri, 11 May 2012 09:46:23 -0700 Message-Id: <201205111646.q4BGkNcF008939@new.toad.com> To: Paul Wouters In-reply-to: Date: Fri, 11 May 2012 09:46:23 -0700 From: John Gilmore Cc: dane@ietf.org Subject: Re: [dane] Behavior in the face of no answer? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 11 May 2012 16:46:28 -0000 Paul Wouters said: > But we all know there are many embedded devices with badly written DNS > proxy software that do things like comparing packets to known byte > streams without actual understanding of bit values. I don't personally know this. If we're going to design a protocol around such devices, let's at least get some details instead of vague generalizations that "we all know". Can you provide some actual names of such devices, preferably with links to people complaining about their badly written DNS proxies? What is the practical effect of the limitations in their DNS proxies? How widely deployed are they, and where? Are these endpoint devices or routers? Has the mfr released updated firmware for them? Etc. Are these proxies only in the data stream while the box is trying to interpose itself into "your first web access" to force you to log in? Or are the proxies permanently affecting every end user's ability (on that network) to send and receive arbitrary packets on port 53? John From nweaver@icsi.berkeley.edu Fri May 11 10:04:27 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAA8B21F8678 for ; Fri, 11 May 2012 10:04:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.521 X-Spam-Level: X-Spam-Status: No, score=-1.521 tagged_above=-999 required=5 tests=[AWL=-1.011, BAYES_05=-1.11, J_CHICKENPOX_14=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 yrLbKKaJWSIK for ; Fri, 11 May 2012 10:04:26 -0700 (PDT) Received: from rock.ICSI.Berkeley.EDU (rock.ICSI.Berkeley.EDU [192.150.186.19]) by ietfa.amsl.com (Postfix) with ESMTP id 0C02321F8604 for ; Fri, 11 May 2012 10:04:26 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id B0A0D2C4016; Fri, 11 May 2012 10:04:16 -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 tm8zQ+uskRBI; Fri, 11 May 2012 10:04:16 -0700 (PDT) Received: from gala.icir.org (gala [192.150.187.49]) (Authenticated sender: nweaver) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 58CA82C4014; Fri, 11 May 2012 10:04:16 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Nicholas Weaver In-Reply-To: <201205111646.q4BGkNcF008939@new.toad.com> Date: Fri, 11 May 2012 10:04:16 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201205111646.q4BGkNcF008939@new.toad.com> To: John Gilmore X-Mailer: Apple Mail (2.1257) Cc: dane@ietf.org Subject: Re: [dane] Behavior in the face of no answer? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 11 May 2012 17:04:27 -0000 On May 11, 2012, at 9:46 AM, John Gilmore wrote: > Paul Wouters said: >> But we all know there are many embedded devices with badly written = DNS >> proxy software that do things like comparing packets to known byte >> streams without actual understanding of bit values. >=20 > I don't personally know this. If we're going to design a protocol > around such devices, let's at least get some details instead of vague > generalizations that "we all know". >=20 > Can you provide some actual names of such devices, preferably with > links to people complaining about their badly written DNS proxies? > What is the practical effect of the limitations in their DNS proxies? > How widely deployed are they, and where? Are these endpoint devices > or routers? Has the mfr released updated firmware for them? Etc. Its very ubiquitous, and the biggest problem is the CPE (Customer = Premesis Equipment, aka the @#)(@*#)$ NAT!). www.icir.org/christian/publications/2011-satin-netalyzr.pdf See section IV A good 9%+ can't handle unknown RTYPES, TXT records, or requests with = EDNS0. Almost all NATS have DNS proxies that they return as the address of the = DNS server always, so they can give an IP address even when they aren't = connected. A good 10% of clients are behind a firewall that attempts to enforce DNS = semantics when trying to directly contact a remote authority server. =20 A good 4% of clients can't fetch >512B DNS but unfragmented with EDNS0, = an unknown RTYPE, and/or TXT records when DIRECTLY querying the remote = server (bypassing b0rken recursive resolvers, see above) We don't know what fraction of these are correct in terms of DNSSEC, but = its on the todo list. We don't know what fraction can use TCP DNS unmolested, but again, its = on the todo list. Also, not reported yet (we haven't analyzed the data fully), but updates = in CPE frankly don't occur. Only Apple even sort of tries (you still = need to open the AirPort utility tho for updates to happen), and SOME = cable operator provided NAT/cable modems are maintained by the cable = operator. Otherwise, its very often "the crud that shipped is the crud = that runs" E.G, we see nearly 800 sessions (a good fraction of a percent of the = tests which are executed) where the configured resolver is runing = dnsmasq-1.18, which was released in 2003-2004!=20 We're now also fetching UPnP strings these days and we see a distressing = variety of unupdated kit. > Are these proxies only in the data stream while the box is trying to > interpose itself into "your first web access" to force you to log in? > Or are the proxies permanently affecting every end user's ability (on > that network) to send and receive arbitrary packets on port 53? The latter. From paul@cypherpunks.ca Fri May 11 11:37:56 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1448121F8705 for ; Fri, 11 May 2012 11:37:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, 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 MVZBpsUmTOq4 for ; Fri, 11 May 2012 11:37:55 -0700 (PDT) Received: from letoams.cypherpunks.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 2707321F8495 for ; Fri, 11 May 2012 11:37:54 -0700 (PDT) Received: by letoams.cypherpunks.ca (Postfix, from userid 500) id 196BB853FE; Fri, 11 May 2012 14:37:52 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by letoams.cypherpunks.ca (Postfix) with ESMTP id 0553881948; Fri, 11 May 2012 14:37:52 -0400 (EDT) Date: Fri, 11 May 2012 14:37:51 -0400 (EDT) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: Nicholas Weaver In-Reply-To: Message-ID: References: <201205111646.q4BGkNcF008939@new.toad.com> User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dane@ietf.org Subject: Re: [dane] Behavior in the face of no answer? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 11 May 2012 18:37:56 -0000 On Fri, 11 May 2012, Nicholas Weaver wrote: >> Can you provide some actual names of such devices, preferably with >> links to people complaining about their badly written DNS proxies? >> What is the practical effect of the limitations in their DNS proxies? >> How widely deployed are they, and where? Are these endpoint devices >> or routers? Has the mfr released updated firmware for them? Etc. > > Its very ubiquitous, and the biggest problem is the CPE (Customer Premesis Equipment, aka the @#)(@*#)$ NAT!). > > www.icir.org/christian/publications/2011-satin-netalyzr.pdf There is also: www.icann.org/en/groups/ssac/documents/sac-035-en.pdf https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/Studies/DNSSEC/DNSSEC_Support_by_Home_Routers.pdf http://ripe60.ripe.net/presentations/Dietrich-DNSSEC_Support_by_Home_Routers_in_Germany.pdf https://www.iis.se/docs/Health-Status-DNS-and-DNSSEC-20120321.pdf etc. etc. There are a lot of failure modes. One important one used to be the dnsmasq software shipped with many commercial vendors, though that one has now been fixed, though no one installs firmware updates so it takes years for these kind of brokenness to disappear. The Atlas probe project at RIPE will hopefully be able to tell us a lot more in the near future as well. Regardless, to get back on the topic, there will be devices that can do DNSSEC but that do not handle the Generic record format. Paul From i.grok@comcast.net Sun May 13 10:58:47 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E85521F854B for ; Sun, 13 May 2012 10:58:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.669 X-Spam-Level: X-Spam-Status: No, score=-101.669 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74, 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 S9w5hKD0MIfR for ; Sun, 13 May 2012 10:58:46 -0700 (PDT) Received: from qmta13.emeryville.ca.mail.comcast.net (qmta13.emeryville.ca.mail.comcast.net [76.96.27.243]) by ietfa.amsl.com (Postfix) with ESMTP id 36F3021F8546 for ; Sun, 13 May 2012 10:58:46 -0700 (PDT) Received: from omta16.emeryville.ca.mail.comcast.net ([76.96.30.72]) by qmta13.emeryville.ca.mail.comcast.net with comcast id 9Vyh1j0011ZMdJ4ADVyl9u; Sun, 13 May 2012 17:58:45 +0000 Received: from odin.ulthar.us ([68.33.77.0]) by omta16.emeryville.ca.mail.comcast.net with comcast id 9Vyj1j01000PQ6U8cVyl7f; Sun, 13 May 2012 17:58:45 +0000 Received: from odin.ulthar.us (localhost [127.0.0.1]) by odin.ulthar.us (8.14.5/8.14.3) with ESMTP id q4DHwdtu008390 for ; Sun, 13 May 2012 13:58:39 -0400 Received: (from draco@localhost) by odin.ulthar.us (8.14.5/8.14.5/Submit) id q4DHwd5m008389 for dane@ietf.org; Sun, 13 May 2012 13:58:39 -0400 Date: Sun, 13 May 2012 13:58:39 -0400 From: Scott Schmit To: dane@ietf.org Message-ID: <20120513175839.GA8350@odin.ulthar.us> Mail-Followup-To: dane@ietf.org References: <201204121903.q3CJ3ucF026698@new.toad.com> <9605FDF6-096D-4159-96A6-16549E8371AB@nic.cz> <20120504031222.GA6541@odin.ulthar.us> <2354EF03-D8D0-49AD-BD99-BA6AD2616FE6@nic.cz> <20120509115626.GA31105@odin.ulthar.us> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="/04w6evG8XlLl3ft" Content-Disposition: inline In-Reply-To: <20120509115626.GA31105@odin.ulthar.us> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Inappropriate Section 8 of draft-ietf-dane-protocol-19.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 May 2012 17:58:47 -0000 --/04w6evG8XlLl3ft Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, May 09, 2012 at 07:56:26AM -0400, Scott Schmit wrote: > On Wed, May 09, 2012 at 01:27:29PM +0200, Ond=C5=99ej Sur=C3=BD wrote: > > I would certainly accept a better text. I share the position with Step= hen, > > that we need some text, so if we have one which is better and technical= ly > > more correct, I would be very happy. >=20 > Ok, I'll work on writing this up This is intended to replace the -20 section 8.1: 8.1. Comparing DANE to Public CAs The security of the DNS RRtype described in this document relies on the security of DNSSEC to verify that the TLSA record has not been altered. [The above paragraph is moved from section 8, as it seems to fit here better.] DNSSEC forms certificates (the binding of an identity to a key) by combining a DNSKEY, DS, or DLV RR with an associated RRSIG record. These records then form a signing chain extending from the client's trust anchors to the RR of interest. Though the DNSSEC protocol doesn't enforce it, DNSKEYs are often marked with a SEP flag indicating whether the key is a Zone Signing Key (ZSK) or a Key Signing Key (KSK). ZSKs protect records in the zone (including DS and DLV records), and KSKs protect ZSK DNSKEY records. This allows KSKs to be stored offline. The TLSA RRtype allows keys from the DNSSEC PKI hierarchy to authenticate keys wrapped in PKIX certificates for a particular host name, protocol, and port. With the exception of the DLV RRtype, all of these certificates constrain the keys they identify to names that are within the zone signing the certificate [RFC 4033]. For a domain's DLV RRs to be honored, it must be configured as a DLV domain, and the domain's DNSKEYs must be configured as trust anchors or be authentic [RFC 5074]. The mapping between DNSSEC RRtypes and the analogous PKIX certificate type is shown in the following table: +----------------+------------------+---------------+ | DNSSEC RRtype | Analogous PKIX | Name- | | + RRSIG | Certificate | Constrained? | +----------------+------------------+---------------+ | DNSKEY (KSK) | CA Certificate | Yes | +----------------+------------------+---------------+ | DNSKEY (ZSK) | CA Certificate | Yes | | | (w/ DS/DLV RRs) | | | +------------------+---------------+ | | EE Certificate | Yes | | | (w/o DS/DLV RRs) | | +----------------+------------------+---------------+ | DS | CA Certificate | Yes | +----------------+------------------+---------------+ | DLV | CA Certificate | No | +----------------+------------------+---------------+ | TLSA | CA Certificate | Yes | +----------------+------------------+---------------+ 8.1.1. Risk of Key Compromise The risk that a given certificate is fake despite having a valid signing chain is related to the number of keys that can contribute to the validation of the certificate, the quality of protection each key receives, the value of each key to an attacker, and the value of falsifying the certificate. DNSSEC allows any set of domains to be configured as trust anchors and/or DLVs, but most clients are likely to use the root zone as its only trust anchor. Also, because a given DNSKEY can only sign RRs for that zone, the number of keys capable of compromising a given TLSA RR is limited to the number of zones between the TLSA RR and the nearest trust anchor, plus any configured DLV domains. Typically, this will be six keys--half of which will be KSKs. PKIX only describes how to validate a certificate based on a client-chosen set of trust anchors, but says nothing about how many trust anchors to use, how many, or how they are constrained. That said, as currently deployed, PKIX clients typically use a large number of trust anchors provided with the client or operating system software. These trust anchors are selected carefully, but with a desire for broad interoperability. The trust anchors and CA certificates for public CAs rarely have name constraints applied. Recent efforts to determine how many keys are trusted by a typical client estimate the number to be around 1482. [SSLObs] [SSLObs =3D https://www.eff.org/files/DefconSSLiverse.pdf ] A combination of technical protections, process controls, and personnel experience contribute to the quality of security that keys receive. The security surrounding DNSSEC DNSKEYs varies significantly. The KSK/ZSK split allows the KSK to be stored offline and protected more carefully than the ZSK, but not all domains will do so. The security applied to a zone's DNSKEYs will be proportional to the value of the domain. For example, the root DNSKEY has protections and controls comparable to or exceeding that of public CAs [Root-DPS]. On the other end of the spectrum, small domains might provide no more protection to their keys than they do to their other data. [Root-DPS =3D https://www.iana.org/dnssec/icann-dps.txt] The security surrounding public CAs also varies. However, due to financial incentives and standards imposed by clients for acceptance into their trust anchor stores, CAs generally employ security experts and protect their keys carefully, though compromises are not unheard of. 8.1.2. Impact of Key Compromise The impact of a key compromise differs significantly between the two models. Public CAs are not typically constrained in what names they can sign, and therefore a compromise of even one CA allows the attacker to generate a certificate for any name in the DNS. A domain holder can get a certificate from any CA, or even multiple CAs simultaneously, making it impossible for a client to determine whether the certificate it is validating is legitimate or fraudulent. DNSKEYs are inherently limited in what they can sign, so a compromise of the DNSKEY for example.com provides no avenue of attack against example.org. Even the impact of a compromise of .com's DNSKEY, while considerable, would be limited to .com domains. Only the compromise of the root DNSKEY would have the equivalent impact of an unconstrained public CA. Because a TLS certificate association is constrained to its associated name, protocol, and port, the PKIX certificate is similarly constrained, even if its public CAs signing the certificate (if any) are not. 8.1.3. Detection of Key Compromise If a key is compromised, rapid and reliable detection is important in order to limit the impact of the compromise. In this regard, neither model prevents an attacker from near-invisibly attacking their victim, provided that the necessary keys are compromised. If a public CA is compromised, only the victim will see the fraudulent certificate, as there is typically no publically-accessible directory of all the certificates issued by a CA that can be inspected. DNS RRs are typically published publically. However, the attacker could also allow the uncompromised records to be published to the Internet as usual but provide a compromised DNS view to the victim to achieve the same effect. 8.1.4. Spoofing Hostnames Some CAs implement technical controls to ensure that certificates are not issued to domains that with names similar to popular & prone-to-attack domains. Of course, an attacker can attempt to circumvent this restriction by finding a CA willing to issue the certificate anyway. However, by using DNSSEC and TLSA, the attacker can circumvent this check completely. 8.2. External DNSSEC Validators Due to a lack of DNSSEC support in the most commonly-deployed stub resolvers today, a number of ISPs have begun checking DNSSEC in the recursive resolvers they provide to their customers, setting the AD flag as appropriate. DNSSEC-aware clients could use that data, ignoring the fact that the DNSSEC data has been validated externally. Because there is no authentication of the AD flag, this can be trivially spoofed by an attacker. However, even with secure communications between a host and the external validator, there is a risk that the external validator could become compromised. Nothing prevents a compromised external DNSSEC validator from claiming that all the records it provides are secure, even if the data is falsified, unless the client checks the DNSSEC data itself (rendering the the external validator unnecessary). For this reason, it is RECOMMENDED that DNSSEC validation always be performed on-host, even when a secure path to an external validator is available. Hope this helps. --=20 Scott Schmit --/04w6evG8XlLl3ft Content-Type: application/x-pkcs7-signature Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIIQJgYJKoZIhvcNAQcCoIIQFzCCEBMCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC DVcwggY0MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAe Fw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0 ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEp pC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9 b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54q zHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX 9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/ 4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8E BTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIw HwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wu Y29tL3Nmc2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIB FiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4IC AQAKgwh9eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8py TUnFsukDFUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMm CeUTyMyikfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIz uQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVm z/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT 5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lAp sbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076 khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8 J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRX un0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCBxswggYDoAMCAQICAwK+HTANBgkqhkiG 9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTExMDcxNzA1 MDQwNFoXDTEyMDcxNzExNDI1OVowYjEgMB4GA1UEDRMXNDY1MjU2LTBnRmI2Sk5ZWW44QnFW bUwxGzAZBgNVBAMMEmkuZ3Jva0Bjb21jYXN0Lm5ldDEhMB8GCSqGSIb3DQEJARYSaS5ncm9r QGNvbWNhc3QubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2AjLOMsBGaqN hv2FcRbfom/QCeKMXu5tUd1JY5oIDZe5y29stnd+se/zUlEkiVeMam4Jgo1c8yGNnwLVYc5/ 9xVi7Qg1Is5b9AB6aJWElJDw/jIdihymNZ2kwkSLT0wl/lzd0mXlwFJPRgQiRkmE6V0ZmjsQ jaVtllVleGBbMvmWPm92e+4Bju9P81kKz7Xr02ijETmaPdVsl+jmOaKPS8Y+2Lat2xus4Ked oJ/7aIWIpz1gRSKjAHSZ1Wmwi2TYUjYhZryChu9e1RWtqk1CycNoeusJ8xdEVN3WSnJ299w/ 3ltK/x/9rpj2j9ShQZVB4NnX6cjQs7pz1lVxvIkjcQIDAQABo4IDrTCCA6kwCQYDVR0TBAIw ADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQW BBQ29j2I0O8sRYi0So9NwwmT1caakDAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhR gjAdBgNVHREEFjAUgRJpLmdyb2tAY29tY2FzdC5uZXQwggIhBgNVHSAEggIYMIICFDCCAhAG CysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20v cG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJt ZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcg dG8gdGhlIENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4g Y29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUF BwICMIGPMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJp bGl0eSBhbmQgd2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFu ZCBMaW1pdGF0aW9ucyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAr oCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUH AQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFz czEvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0 cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQAZ5U0nL/2PQwsVfHgN7MVPbZEGzDzuj4Oy pTgz4XQFwPcCuy6U9sp1Dwmo3DyKX5nKN4xA7pslN+2Pl/kElGamX7zMCAH0xED0RTOLyk+v nDML4s+OUtWaYVnq1bZEp0F8Luq3zIslAYSebleyiz8M0EypZczsL5rOk86R2F9EYw1CBuFJ 5a4x0CmNu5o30fGNDFt+iXRlbJPp/KY25iUgVnBzJ4COT5kQjxn5lgr4t1I+BDCL5HQQ3h/8 2CzwrWVRBNb9Vqh9LL1ZtzYRt8JezoB6HkVvcKVNGlCZ+/MnvfMzPLwfbTDZC8o4d+4RH6aE LeGF2XmAOaenc/YRqm9oMYIClzCCApMCAQEwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQQIDAr4dMAkGBSsOAwIaBQCggdgwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTIwNTEzMTc1ODM5WjAjBgkqhkiG9w0BCQQxFgQUESVtbs+i 18el7VU597uLGBBGGUEweQYJKoZIhvcNAQkPMWwwajALBglghkgBZQMEASowCwYJYIZIAWUD BAEWMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAIakxG1iC Hj6bz6+aVkyKMIqMIgPbpcLyuxq6MHhcngaprPwgT5/NRxNhzF6X+mR7M5IvCAWrDuGVAJx+ iNgisfFVXQesh2pwh9MB5gnIcuc3Xs1rGnGIplp04uipdtlGTjx+YWgZPPMNHm215C9+DScu 2dJ77T6uQISOp90YqWPLPYyMVIkMl6VhkFE025lLvA23pjO28c3COOgRbqAqQYz/bdCff7ME XQVqZmE5tvrA50Us5GLQFroI6mSLFAJpAD64DNwahxZXZNu0fYVJjvTSz/wLDiLrlqYOa4R9 Xqdbvd21ezJ+BXJrWeZROU5NNSI2KkCYZzdiVraNF77TPA== --/04w6evG8XlLl3ft-- From benl@google.com Sun May 13 13:39:13 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 057F721F8504 for ; Sun, 13 May 2012 13:39:13 -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 g3XRyIiSAGCU for ; Sun, 13 May 2012 13:39:12 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2D8A821F850B for ; Sun, 13 May 2012 13:39:11 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so3271182lbb.31 for ; Sun, 13 May 2012 13:39:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding:x-system-of-record; bh=5kO2givdhpBYeI4ziY4IMvddQXe6v9ONZY0rGh3Reh8=; b=F9Tbv8fnKtvx/6YLZrnStwfVFvXTa6QUkrAFDgaclfQgqFPhEee95TQ0X62U+IVDNH PzEDGNCGSGMIDIn5bxOepfyh3Gfoiz7i5Pj3iYzHcucla1srQqLoTjnVT3mSjpFbMZxZ nshOdig1SI5LZGkTa3HQDET5m9WMGoDvwcND9OY3Io29fy5yDbNTXoT6v+UxDvSomGEZ d9WuASofK1Da1vKF3LM3d39h4xBI287MZjdR8p3VX1Q7SWDIUuTH0+XuteGScauzi9ak 8BPLWOC878oh/tquKATD7iYw1w28lQEbLEx8GqwgnxEMnIeBHt89aPRT9GByDtVvZGTE lufA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding:x-system-of-record :x-gm-message-state; bh=5kO2givdhpBYeI4ziY4IMvddQXe6v9ONZY0rGh3Reh8=; b=d+shbVgLx9QjOPzjno5yxM2O1HjfP8mRsFfwHhgtcaCkNsvP2yvL7Z99w8z/O9vSEe mOxyQQVyrTPw069FOfolkxeM8jgRDHJxDuoRaXuykb/7ALKhnm4DKw4DmBsnXZTHQX2X 6dRHmK+IzZnHzN5+6qdG5C0iBoCwLsPCPspUOWnhYKmlh0RWrdYM9oOvU15EIzUvkOEN mU/Mu4HYWHLsrC6xvGefkYPP29K2TDgDnIxNhrzwvSvxsKnLyNePRDI9lhfZ3Smp1/bV PfulZz8z5QkQw0BJbQMRZ35TxRrV2pCtrAdmdq2du3/OYNxsld76r11KyhG1dX8dqpvb eAiA== Received: by 10.152.114.106 with SMTP id jf10mr5917718lab.16.1336941551041; Sun, 13 May 2012 13:39:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.114.106 with SMTP id jf10mr5917706lab.16.1336941550889; Sun, 13 May 2012 13:39:10 -0700 (PDT) Received: by 10.112.66.136 with HTTP; Sun, 13 May 2012 13:39:10 -0700 (PDT) In-Reply-To: <20120513175839.GA8350@odin.ulthar.us> References: <201204121903.q3CJ3ucF026698@new.toad.com> <9605FDF6-096D-4159-96A6-16549E8371AB@nic.cz> <20120504031222.GA6541@odin.ulthar.us> <2354EF03-D8D0-49AD-BD99-BA6AD2616FE6@nic.cz> <20120509115626.GA31105@odin.ulthar.us> <20120513175839.GA8350@odin.ulthar.us> Date: Sun, 13 May 2012 21:39:10 +0100 Message-ID: From: Ben Laurie To: dane@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-Gm-Message-State: ALoCoQlFs1DWZ2xPxmuHfI5U8MP+X5sq4cptviMfrDpmyHtT/fUgka9lmTXUueD2Bgp4XfX1n5DSAEazkLRj0ukkB/e8EuMPW01jY7NBocBVVL6KZdLWhqEP/MKcpJ1paW8GMTgmXMWI Subject: Re: [dane] Inappropriate Section 8 of draft-ietf-dane-protocol-19.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 May 2012 20:39:13 -0000 On 13 May 2012 18:58, Scott Schmit wrote: > On Wed, May 09, 2012 at 07:56:26AM -0400, Scott Schmit wrote: >> On Wed, May 09, 2012 at 01:27:29PM +0200, Ond=C5=99ej Sur=C3=BD wrote: >> > I would certainly accept a better text. =C2=A0I share the position wit= h Stephen, >> > that we need some text, so if we have one which is better and technica= lly >> > more correct, I would be very happy. >> >> Ok, I'll work on writing this up > > This is intended to replace the -20 section 8.1: Not sure I understand the table, but the rest seems like an excellent summary to me. From paul.hoffman@vpnc.org Sun May 13 13:58:30 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9F3921F8539 for ; Sun, 13 May 2012 13:58:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.555 X-Spam-Level: X-Spam-Status: No, score=-102.555 tagged_above=-999 required=5 tests=[AWL=0.044, 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 DUnsedB-YWFW for ; Sun, 13 May 2012 13:58:30 -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 55FA621F84D6 for ; Sun, 13 May 2012 13:58:30 -0700 (PDT) Received: from [10.20.30.102] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q4DKwRsE070251 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 13 May 2012 13:58:28 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=utf-8 From: Paul Hoffman In-Reply-To: <20120513175839.GA8350@odin.ulthar.us> Date: Sun, 13 May 2012 13:58:27 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <65183D89-D725-4322-9053-F49550318C8E@vpnc.org> References: <201204121903.q3CJ3ucF026698@new.toad.com> <9605FDF6-096D-4159-96A6-16549E8371AB@nic.cz> <20120504031222.GA6541@odin.ulthar.us> <2354EF03-D8D0-49AD-BD99-BA6AD2616FE6@nic.cz> <20120509115626.GA31105@odin.ulthar.us> <20120513175839.GA8350@odin.ulthar.us> To: Scott Schmit X-Mailer: Apple Mail (2.1278) Cc: dane@ietf.org Subject: Re: [dane] Inappropriate Section 8 of draft-ietf-dane-protocol-19.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 May 2012 20:58:31 -0000 On May 13, 2012, at 10:58 AM, Scott Schmit wrote: > On Wed, May 09, 2012 at 07:56:26AM -0400, Scott Schmit wrote: >> On Wed, May 09, 2012 at 01:27:29PM +0200, Ond=C5=99ej Sur=C3=BD = wrote: >>> I would certainly accept a better text. I share the position with = Stephen, >>> that we need some text, so if we have one which is better and = technically >>> more correct, I would be very happy. >>=20 >> Ok, I'll work on writing this up >=20 > This is intended to replace the -20 section 8.1: I think most of the text is clear and correct, but inappropriate for = this document. It is about comparing DNSSEC to PKIX, not TLSA to PKIX. = It would make a great stand-alone Informational RFC (possibly expanded = even further), but isn't about TLSA. I attempted to pull out just the TLSA-related text, and it doesn't hang = together at all, unfortunately. Someone else might be able to do a = better job of that than me, however. --Paul Hoffman From i.grok@comcast.net Sun May 13 22:45:04 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC28221F8595 for ; Sun, 13 May 2012 22:45:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.514 X-Spam-Level: X-Spam-Status: No, score=-102.514 tagged_above=-999 required=5 tests=[AWL=0.085, 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 zvMWF-iZb3Uf for ; Sun, 13 May 2012 22:45:03 -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 EDBCF21F858E for ; Sun, 13 May 2012 22:45:02 -0700 (PDT) Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by qmta03.westchester.pa.mail.comcast.net with comcast id 9hks1j0060cZkys53hl34k; Mon, 14 May 2012 05:45:03 +0000 Received: from odin.ulthar.us ([68.33.77.0]) by omta10.westchester.pa.mail.comcast.net with comcast id 9hl21j00M00PQ6U3Whl3ZZ; Mon, 14 May 2012 05:45:03 +0000 Received: from odin.ulthar.us (localhost [127.0.0.1]) by odin.ulthar.us (8.14.5/8.14.3) with ESMTP id q4E5ixoN011751 for ; Mon, 14 May 2012 01:44:59 -0400 Received: (from draco@localhost) by odin.ulthar.us (8.14.5/8.14.5/Submit) id q4E5ixSu011750 for dane@ietf.org; Mon, 14 May 2012 01:44:59 -0400 Date: Mon, 14 May 2012 01:44:59 -0400 From: Scott Schmit To: dane@ietf.org Message-ID: <20120514054459.GB23015@odin.ulthar.us> Mail-Followup-To: dane@ietf.org References: <201204121903.q3CJ3ucF026698@new.toad.com> <9605FDF6-096D-4159-96A6-16549E8371AB@nic.cz> <20120504031222.GA6541@odin.ulthar.us> <2354EF03-D8D0-49AD-BD99-BA6AD2616FE6@nic.cz> <20120509115626.GA31105@odin.ulthar.us> <20120513175839.GA8350@odin.ulthar.us> <65183D89-D725-4322-9053-F49550318C8E@vpnc.org> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="yEPQxsgoJgBvi8ip" Content-Disposition: inline In-Reply-To: <65183D89-D725-4322-9053-F49550318C8E@vpnc.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Inappropriate Section 8 of draft-ietf-dane-protocol-19.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 05:45:04 -0000 --yEPQxsgoJgBvi8ip Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, May 13, 2012 at 01:58:27PM -0700, Paul Hoffman wrote: > On May 13, 2012, at 10:58 AM, Scott Schmit wrote: > > This is intended to replace the -20 section 8.1: >=20 > I think most of the text is clear and correct, but inappropriate for > this document. It is about comparing DNSSEC to PKIX, not TLSA to PKIX. > It would make a great stand-alone Informational RFC (possibly expanded > even further), but isn't about TLSA. >=20 > I attempted to pull out just the TLSA-related text, and it doesn't > hang together at all, unfortunately. Someone else might be able to do > a better job of that than me, however. I'm not sure I understand your criticism. TLSA has no security mechanism of its own--its security is wholly dependent on that of DNSSEC (as stated in the first paragraph of -20's section 8), so the only way to compare DANE's security model to PKIX is to compare DNSSEC (and the new implications due to TLSA) to PKIX. Personally, I think that's the reason you were unable to separate the two. I'll admit that I spend more time than I'd like describing DNSSEC in terms of certificates, but the only way to compare DANE to PKIX is to put them into like terms, and DNSSEC is not described that way in RFCs 4033-4035. IMHO, it's this certificate interpretation that DANE is bringing to DNSSEC. Even then, that only affects the first part of section 8.1, and I'm not sure how to interpret your criticism for the rest of the text. --=20 Scott Schmit --yEPQxsgoJgBvi8ip Content-Type: application/x-pkcs7-signature Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIIQJgYJKoZIhvcNAQcCoIIQFzCCEBMCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC DVcwggY0MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAe Fw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0 ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEp pC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9 b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54q zHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX 9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/ 4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8E BTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIw HwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wu Y29tL3Nmc2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIB FiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4IC AQAKgwh9eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8py TUnFsukDFUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMm CeUTyMyikfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIz uQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVm z/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT 5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lAp sbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076 khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8 J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRX un0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCBxswggYDoAMCAQICAwK+HTANBgkqhkiG 9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTExMDcxNzA1 MDQwNFoXDTEyMDcxNzExNDI1OVowYjEgMB4GA1UEDRMXNDY1MjU2LTBnRmI2Sk5ZWW44QnFW bUwxGzAZBgNVBAMMEmkuZ3Jva0Bjb21jYXN0Lm5ldDEhMB8GCSqGSIb3DQEJARYSaS5ncm9r QGNvbWNhc3QubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2AjLOMsBGaqN hv2FcRbfom/QCeKMXu5tUd1JY5oIDZe5y29stnd+se/zUlEkiVeMam4Jgo1c8yGNnwLVYc5/ 9xVi7Qg1Is5b9AB6aJWElJDw/jIdihymNZ2kwkSLT0wl/lzd0mXlwFJPRgQiRkmE6V0ZmjsQ jaVtllVleGBbMvmWPm92e+4Bju9P81kKz7Xr02ijETmaPdVsl+jmOaKPS8Y+2Lat2xus4Ked oJ/7aIWIpz1gRSKjAHSZ1Wmwi2TYUjYhZryChu9e1RWtqk1CycNoeusJ8xdEVN3WSnJ299w/ 3ltK/x/9rpj2j9ShQZVB4NnX6cjQs7pz1lVxvIkjcQIDAQABo4IDrTCCA6kwCQYDVR0TBAIw ADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQW BBQ29j2I0O8sRYi0So9NwwmT1caakDAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhR gjAdBgNVHREEFjAUgRJpLmdyb2tAY29tY2FzdC5uZXQwggIhBgNVHSAEggIYMIICFDCCAhAG CysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20v cG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJt ZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcg dG8gdGhlIENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4g Y29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUF BwICMIGPMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJp bGl0eSBhbmQgd2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFu ZCBMaW1pdGF0aW9ucyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAr oCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUH AQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFz czEvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0 cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQAZ5U0nL/2PQwsVfHgN7MVPbZEGzDzuj4Oy pTgz4XQFwPcCuy6U9sp1Dwmo3DyKX5nKN4xA7pslN+2Pl/kElGamX7zMCAH0xED0RTOLyk+v nDML4s+OUtWaYVnq1bZEp0F8Luq3zIslAYSebleyiz8M0EypZczsL5rOk86R2F9EYw1CBuFJ 5a4x0CmNu5o30fGNDFt+iXRlbJPp/KY25iUgVnBzJ4COT5kQjxn5lgr4t1I+BDCL5HQQ3h/8 2CzwrWVRBNb9Vqh9LL1ZtzYRt8JezoB6HkVvcKVNGlCZ+/MnvfMzPLwfbTDZC8o4d+4RH6aE LeGF2XmAOaenc/YRqm9oMYIClzCCApMCAQEwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQQIDAr4dMAkGBSsOAwIaBQCggdgwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTIwNTE0MDU0NDU5WjAjBgkqhkiG9w0BCQQxFgQUEnC3L0CW dwZfDx6o3K6v8Wra8JQweQYJKoZIhvcNAQkPMWwwajALBglghkgBZQMEASowCwYJYIZIAWUD BAEWMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAaRfcKtZ9 5VEFqce5Tr7q5v3YWxFCHpGa3Ugx65SW0ZyZk4MvRNVxZsR6VBwKy291pivvx7mP5xd37PBd 4OBdga4FTIdIe0G5m4kKBuhsRa4NIceFJO+jeLj/5CSI2sXzOe5KR9PHvBH7t5NpEfFwE1FF fwmP3zPt6mQjwn7CCSY82cCq7Q+GzbURlCs8eq8ejdBD0NKn47TihQgMlJYBiYdiAXSYdc+j k9GO9tnyAFiYVM/U0JosCXvcXOwyqAnfw9f/DNJGMXI6A4V1BBj96ykUQKymzvZIH9DvA5yx AUW1t36aSx4xcc0mfu/Bpq0GFCYo9gng0bI+OqIB+6Eosw== --yEPQxsgoJgBvi8ip-- From i.grok@comcast.net Sun May 13 22:47:00 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F9A521F859E for ; Sun, 13 May 2012 22:47:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.522 X-Spam-Level: X-Spam-Status: No, score=-102.522 tagged_above=-999 required=5 tests=[AWL=0.077, 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 ipbPS+zLHpjd for ; Sun, 13 May 2012 22:46:59 -0700 (PDT) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by ietfa.amsl.com (Postfix) with ESMTP id 7DBC721F859A for ; Sun, 13 May 2012 22:46:59 -0700 (PDT) Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta04.westchester.pa.mail.comcast.net with comcast id 9hlZ1j0011uE5Es54hmzRC; Mon, 14 May 2012 05:46:59 +0000 Received: from odin.ulthar.us ([68.33.77.0]) by omta16.westchester.pa.mail.comcast.net with comcast id 9hmz1j00R00PQ6U3chmzml; Mon, 14 May 2012 05:46:59 +0000 Received: from odin.ulthar.us (localhost [127.0.0.1]) by odin.ulthar.us (8.14.5/8.14.3) with ESMTP id q4E5kuJb011759 for ; Mon, 14 May 2012 01:46:56 -0400 Received: (from draco@localhost) by odin.ulthar.us (8.14.5/8.14.5/Submit) id q4E5kuYq011758 for dane@ietf.org; Mon, 14 May 2012 01:46:56 -0400 Date: Mon, 14 May 2012 01:46:56 -0400 From: Scott Schmit To: dane@ietf.org Message-ID: <20120514054656.GC23015@odin.ulthar.us> Mail-Followup-To: dane@ietf.org References: <201204121903.q3CJ3ucF026698@new.toad.com> <9605FDF6-096D-4159-96A6-16549E8371AB@nic.cz> <20120504031222.GA6541@odin.ulthar.us> <2354EF03-D8D0-49AD-BD99-BA6AD2616FE6@nic.cz> <20120509115626.GA31105@odin.ulthar.us> <20120513175839.GA8350@odin.ulthar.us> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="qjNfmADvan18RZcF" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Inappropriate Section 8 of draft-ietf-dane-protocol-19.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 05:47:00 -0000 --qjNfmADvan18RZcF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, May 13, 2012 at 09:39:10PM +0100, Ben Laurie wrote: > On 13 May 2012 18:58, Scott Schmit wrote: > > This is intended to replace the -20 section 8.1: >=20 > Not sure I understand the table, but the rest seems like an excellent > summary to me. Is there something specific about the table that's confusing you? --=20 Scott Schmit --qjNfmADvan18RZcF Content-Type: application/x-pkcs7-signature Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIIQJgYJKoZIhvcNAQcCoIIQFzCCEBMCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC DVcwggY0MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAe Fw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0 ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEp pC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9 b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54q zHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX 9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/ 4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8E BTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIw HwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wu Y29tL3Nmc2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIB FiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4IC AQAKgwh9eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8py TUnFsukDFUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMm CeUTyMyikfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIz uQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVm z/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT 5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lAp sbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076 khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8 J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRX un0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCBxswggYDoAMCAQICAwK+HTANBgkqhkiG 9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTExMDcxNzA1 MDQwNFoXDTEyMDcxNzExNDI1OVowYjEgMB4GA1UEDRMXNDY1MjU2LTBnRmI2Sk5ZWW44QnFW bUwxGzAZBgNVBAMMEmkuZ3Jva0Bjb21jYXN0Lm5ldDEhMB8GCSqGSIb3DQEJARYSaS5ncm9r QGNvbWNhc3QubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2AjLOMsBGaqN hv2FcRbfom/QCeKMXu5tUd1JY5oIDZe5y29stnd+se/zUlEkiVeMam4Jgo1c8yGNnwLVYc5/ 9xVi7Qg1Is5b9AB6aJWElJDw/jIdihymNZ2kwkSLT0wl/lzd0mXlwFJPRgQiRkmE6V0ZmjsQ jaVtllVleGBbMvmWPm92e+4Bju9P81kKz7Xr02ijETmaPdVsl+jmOaKPS8Y+2Lat2xus4Ked oJ/7aIWIpz1gRSKjAHSZ1Wmwi2TYUjYhZryChu9e1RWtqk1CycNoeusJ8xdEVN3WSnJ299w/ 3ltK/x/9rpj2j9ShQZVB4NnX6cjQs7pz1lVxvIkjcQIDAQABo4IDrTCCA6kwCQYDVR0TBAIw ADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQW BBQ29j2I0O8sRYi0So9NwwmT1caakDAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhR gjAdBgNVHREEFjAUgRJpLmdyb2tAY29tY2FzdC5uZXQwggIhBgNVHSAEggIYMIICFDCCAhAG CysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20v cG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJt ZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcg dG8gdGhlIENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4g Y29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUF BwICMIGPMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJp bGl0eSBhbmQgd2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFu ZCBMaW1pdGF0aW9ucyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAr oCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUH AQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFz czEvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0 cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQAZ5U0nL/2PQwsVfHgN7MVPbZEGzDzuj4Oy pTgz4XQFwPcCuy6U9sp1Dwmo3DyKX5nKN4xA7pslN+2Pl/kElGamX7zMCAH0xED0RTOLyk+v nDML4s+OUtWaYVnq1bZEp0F8Luq3zIslAYSebleyiz8M0EypZczsL5rOk86R2F9EYw1CBuFJ 5a4x0CmNu5o30fGNDFt+iXRlbJPp/KY25iUgVnBzJ4COT5kQjxn5lgr4t1I+BDCL5HQQ3h/8 2CzwrWVRBNb9Vqh9LL1ZtzYRt8JezoB6HkVvcKVNGlCZ+/MnvfMzPLwfbTDZC8o4d+4RH6aE LeGF2XmAOaenc/YRqm9oMYIClzCCApMCAQEwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQQIDAr4dMAkGBSsOAwIaBQCggdgwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTIwNTE0MDU0NjU2WjAjBgkqhkiG9w0BCQQxFgQU6K8az+4+ A6bE46BGEJGTHTUggNcweQYJKoZIhvcNAQkPMWwwajALBglghkgBZQMEASowCwYJYIZIAWUD BAEWMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAGkq1feX7 5OPv5jC2nFOEDdosnVNyUvy8GYKBn8yLx7CfullD+UWipC5VPUhge/PfzQi2loDmQ0H94/uf ZfKuK/H6mrygpkj4tg4UQy9ezYmTTJ2bMU60oU6hhnlaPvCyAfiIkCgVLgOjv83qGIzp3veh wrnHACRoHR+1CRQyRNbMYGsi17X+CX5CYNklH8ECESPhYzBj71K8OtIGlY/vv0P5iJMTO/ex Y0RrKxQBOELBr/CJtaiSc9x71mjnJQ9opdQNwGd98aSMd53pYOVj+2yCKd6u7iDCCdmMfARv KeBAk9eL+gtdgCm7h87gxDvXT6aO9EXiL9Db3IESnLwdHw== --qjNfmADvan18RZcF-- From benl@google.com Mon May 14 03:39:52 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FAB321F866C for ; Mon, 14 May 2012 03:39:52 -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 uzf4hxbi1LRI for ; Mon, 14 May 2012 03:39:52 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id CD82621F8476 for ; Mon, 14 May 2012 03:39:51 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so3628789lbb.31 for ; Mon, 14 May 2012 03:39:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-system-of-record; bh=MxOxZd5z5eM6Mohhk6hDYwXD075r164zTVYVkjNsNUI=; b=d4VJYX9KmFZYGGtKKFZx5GgMj1HSCVlYOi07y2okfRnoDibpBNzIyWDc09KZK8yvpp b/Upwqc58gGoX/B5ZTHp0O2nhwwPC9yUvh/GRQ5pj6+vAidHvqu4b42Wgsxc3gklDz0c 6hkyigP/2wU/r7I31uws3R46oBVNRBWfkYj9ZjzNwWnbc/SLJ184mXwxdpdAnBiLseny VrbGP4sGiVksYIPXVfsa9Qavd+3pDdgw3pRMo+f91jGs7Y81jxTGg0D7ug9UrVaYQlK7 bmkf2VWmcd7n9wzUCZrBjOT3MMbZbMxKP5pTF9RpAQqii08oe6AsEu0H65QqUTcglmvo tMcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-system-of-record:x-gm-message-state; bh=MxOxZd5z5eM6Mohhk6hDYwXD075r164zTVYVkjNsNUI=; b=YQaODzIkP8bPjc5uBfziaZonQ2islrhOGOIEE/hRscOFtANSTnkHaK4qriFRNDmxAZ 6g+PMMNmaxenKokaJyzGY1nJv52Ae5u/+2HdYYtZXpbioygl1yCKQh8abR1go64EYEhW KTxS7WWpW68guu/6fe4MOdS/4iDVWBpU0oYz6iOvZw3GpIDu0ot/Xl6QpqDI8zI9gP4P 42BdTqWaB8JR72d6rd1yW4ZIUkFoXx2KUhkfzqEh5mrIBl2HF/zxT5fpTZ5FFndpwcHe 6GlOOxiD8ORmy3/GfYP95XK5AnFlD0gMpnwul/2oIMc0Wnd0YAsO1bPWf6fxdNJRSYRl wEnA== Received: by 10.112.28.131 with SMTP id b3mr910838lbh.63.1336991990399; Mon, 14 May 2012 03:39:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.28.131 with SMTP id b3mr910832lbh.63.1336991990262; Mon, 14 May 2012 03:39:50 -0700 (PDT) Received: by 10.112.66.136 with HTTP; Mon, 14 May 2012 03:39:50 -0700 (PDT) In-Reply-To: <20120514054656.GC23015@odin.ulthar.us> References: <201204121903.q3CJ3ucF026698@new.toad.com> <9605FDF6-096D-4159-96A6-16549E8371AB@nic.cz> <20120504031222.GA6541@odin.ulthar.us> <2354EF03-D8D0-49AD-BD99-BA6AD2616FE6@nic.cz> <20120509115626.GA31105@odin.ulthar.us> <20120513175839.GA8350@odin.ulthar.us> <20120514054656.GC23015@odin.ulthar.us> Date: Mon, 14 May 2012 11:39:50 +0100 Message-ID: From: Ben Laurie To: dane@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true X-Gm-Message-State: ALoCoQl48i7fFFp9zJblnYA3dgJRAnNO0ulMyi+Vpa5G+Hq9UPC6NWoJkmMOW1MsUw+yrkskSdQFAt5tBW20CyTI12INNqjaKnqaVuQg5RQGAvU2KT63MfOmiZVaRddB8NxIzapIh6wW Subject: Re: [dane] Inappropriate Section 8 of draft-ietf-dane-protocol-19.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 10:39:52 -0000 On 14 May 2012 06:46, Scott Schmit wrote: > On Sun, May 13, 2012 at 09:39:10PM +0100, Ben Laurie wrote: >> On 13 May 2012 18:58, Scott Schmit wrote: >> > This is intended to replace the -20 section 8.1: >> >> Not sure I understand the table, but the rest seems like an excellent >> summary to me. > > Is there something specific about the table that's confusing you? a) "CA certificate" is quite broad - what about DV and EV? b) What is name-constrained? Also, does anyone use DLV? > > -- > Scott Schmit > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > From paul.hoffman@vpnc.org Mon May 14 07:52:20 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F35321F8476 for ; Mon, 14 May 2012 07:52:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.555 X-Spam-Level: X-Spam-Status: No, score=-102.555 tagged_above=-999 required=5 tests=[AWL=0.044, 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 FTwZRfJwC7D8 for ; Mon, 14 May 2012 07:52:19 -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 D12CA21F8807 for ; Mon, 14 May 2012 07:52:18 -0700 (PDT) Received: from [10.20.30.102] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q4EEqF3s071961 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 14 May 2012 07:52:16 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <20120514054459.GB23015@odin.ulthar.us> Date: Mon, 14 May 2012 07:52:15 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <086FDB1F-38FF-4BAE-926E-6A0E6FB2E742@vpnc.org> References: <201204121903.q3CJ3ucF026698@new.toad.com> <9605FDF6-096D-4159-96A6-16549E8371AB@nic.cz> <20120504031222.GA6541@odin.ulthar.us> <2354EF03-D8D0-49AD-BD99-BA6AD2616FE6@nic.cz> <20120509115626.GA31105@odin.ulthar.us> <20120513175839.GA8350@odin.ulthar.us> <65183D89-D725-4322-9053-F49550318C8E@vpnc.org> <20120514054459.GB23015@odin.ulthar.us> To: Scott Schmit X-Mailer: Apple Mail (2.1278) Cc: dane@ietf.org Subject: Re: [dane] Inappropriate Section 8 of draft-ietf-dane-protocol-19.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 14:52:20 -0000 On May 13, 2012, at 10:44 PM, Scott Schmit wrote: > I'm not sure I understand your criticism. TLSA has no security > mechanism of its own--its security is wholly dependent on that of = DNSSEC > (as stated in the first paragraph of -20's section 8), so the only way > to compare DANE's security model to PKIX is to compare DNSSEC (and the > new implications due to TLSA) to PKIX. Personally, I think that's the > reason you were unable to separate the two. Hrm. I see that, but I'm still having a hard time internalizing it. It = is just as true for TLSA records as for all current DNS RRtypes. TLSA = isn't the first RRtype since DNSSEC to have these properties. > I'll admit that I spend more time than I'd like describing DNSSEC in > terms of certificates, but the only way to compare DANE to PKIX is to > put them into like terms, and DNSSEC is not described that way in RFCs > 4033-4035. IMHO, it's this certificate interpretation that DANE is > bringing to DNSSEC. DANE most recently, but other RRtypes before. I suspect that DANE is the = first to get sufficient review, however. > Even then, that only affects the first part of section 8.1, and I'm = not > sure how to interpret your criticism for the rest of the text. Good point. I think I got lost after the first part and didn't see the = second bits as really being focused on DANE. Proposal: strengthen the lead-in paragraph to this section as: The security of the DNS RRtype described in this document relies on the security of DNSSEC to verify that the TLSA record has not been altered. This section describes where the security of public CAs and the security of TLSA are similar and different. This section applies equally to other security-related DNS RRtypes such as keys for IPsec and SSH. --Paul Hoffman From paul@nohats.ca Mon May 14 09:39:48 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F1B221F87E1 for ; Mon, 14 May 2012 09:39:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1K2IeD5ZMPCq for ; Mon, 14 May 2012 09:39:47 -0700 (PDT) Received: from letoams.cypherpunks.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id C3D6021F878E for ; Mon, 14 May 2012 09:39:37 -0700 (PDT) Received: by letoams.cypherpunks.ca (Postfix, from userid 500) id E84C881948; Mon, 14 May 2012 12:39:34 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by letoams.cypherpunks.ca (Postfix) with ESMTP id D84DF803A3; Mon, 14 May 2012 12:39:34 -0400 (EDT) Date: Mon, 14 May 2012 12:39:34 -0400 (EDT) From: Paul Wouters To: Ben Laurie In-Reply-To: Message-ID: References: <201204121903.q3CJ3ucF026698@new.toad.com> <9605FDF6-096D-4159-96A6-16549E8371AB@nic.cz> <20120504031222.GA6541@odin.ulthar.us> <2354EF03-D8D0-49AD-BD99-BA6AD2616FE6@nic.cz> <20120509115626.GA31105@odin.ulthar.us> <20120513175839.GA8350@odin.ulthar.us> <20120514054656.GC23015@odin.ulthar.us> User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dane@ietf.org Subject: Re: [dane] Inappropriate Section 8 of draft-ietf-dane-protocol-19.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 16:39:48 -0000 On Mon, 14 May 2012, Ben Laurie wrote: > Also, does anyone use DLV? Fedora/RHEL if you use unbound (and/or dnssec-trigger) There are still plenty of TLDs that are not signed. There are also plenty of people that cannot or will not move to a Registrar that supports DNSSEC within org/com/net. Paul From paul.hoffman@vpnc.org Mon May 14 19:12:28 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C14E321F8503 for ; Mon, 14 May 2012 19:12:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.556 X-Spam-Level: X-Spam-Status: No, score=-102.556 tagged_above=-999 required=5 tests=[AWL=0.044, 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 rWKHBIlWEc6U for ; Mon, 14 May 2012 19:12:28 -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 35ACC21F8501 for ; Mon, 14 May 2012 19:12:28 -0700 (PDT) Received: from [10.20.30.102] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q4F2CNT7037360 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 14 May 2012 19:12:24 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Mon, 14 May 2012 19:12:23 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <643D87CD-D01E-47B8-82E5-D3F57D50C80B@vpnc.org> References: To: Eric Rescorla X-Mailer: Apple Mail (2.1278) Cc: dane@ietf.org Subject: Re: [dane] Behavior in the face of no answer? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 15 May 2012 02:12:28 -0000 There doesn't seem to be convergence here, and the WG chairs and AD have = asked the authors to propose wording that might bring consensus. The = following text may be insufficient, but it's the best I can do at the = moment, and if it isn't good enough, having you propose specific changes = may be helpful. This proposed text tries to pull together: - Ekr's security analysis - The desire for a MUST that is likely to be deployed, not ignored - Acknowledgement that if the user doesn't know TLSA is being used, they = are not losing anything from the attack (And, yes, I think that the chairs should be doing this bit instead of = Jakob and I. Oh, well.) An attacker who is able to divert a user to a server under his control = is also likely to be able to block DNS requests from the user or DNS responses = being sent to the user. Thus, in order to achieve any security benefit from certificate usage 0 or 1, an application that sends a request for TLSA = records needs to get either a valid signed response containing TLSA records or verification that the domain is insecure or indeterminate. If a request = for a TLSA record does not meet one of those two criteria but the application continues with the TLS handshake anyway, the application has gotten no = benefit from TLSA and should not make any internal or external indication that = TLSA was applied. If an application has any indication that TLSA is in use = (such as through a configuration setting), that application MUST not start a TLS connection or abort a TLS handshake if either of the two criteria above = are not met. Livable? Better specific suggestions? --Paul Hoffman= From ekr@rtfm.com Mon May 14 19:31:45 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E545F21F894F for ; Mon, 14 May 2012 19:31:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.873 X-Spam-Level: X-Spam-Status: No, score=-102.873 tagged_above=-999 required=5 tests=[AWL=0.104, 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 tzFgA6UVntXo for ; Mon, 14 May 2012 19:31:45 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4C7F121F894A for ; Mon, 14 May 2012 19:31:45 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so6781381vbb.31 for ; Mon, 14 May 2012 19:31:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=Um4XcMG11qoQO4EjDoFtNHBenY+EBPhY4jQmHjstSig=; b=HRc54avyGKQ3l7oKNm1lN8wrLEomH1JamN3jfYPNauu3ypDEvG22v6tr/kNTuLZjh9 Y4z6CEY3SUTJ4oIkFqbxCT+s4mqNrK7xYR3CN/3csFMRb3LXUmACk3YKIG9j97p+CkeU MKjsSb1M8FxV6Z2/JUviUCChJwPAM5xSEwYn0esBwgRMAk+dw7/XBhaD0SgCQSmG2vMx kG0Y++IWUVkeNmPNACklHECKGpyw/t8py4b7K+NJckNJwGrB7sRQ8PMOGb6iY8beVy6b UpNUQcHfXziL3gBwl/O+fraQ9zIaAvS61WJwXQjE99XDQMSwNHESCMubC+ZzyyPakVyF C0bA== Received: by 10.52.172.194 with SMTP id be2mr312903vdc.60.1337049104132; Mon, 14 May 2012 19:31:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.35.209 with HTTP; Mon, 14 May 2012 19:31:03 -0700 (PDT) X-Originating-IP: [74.95.2.173] In-Reply-To: <643D87CD-D01E-47B8-82E5-D3F57D50C80B@vpnc.org> References: <643D87CD-D01E-47B8-82E5-D3F57D50C80B@vpnc.org> From: Eric Rescorla Date: Mon, 14 May 2012 19:31:03 -0700 Message-ID: To: Paul Hoffman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmOJS3P2sxUvae6ffQtlM7JFsfDFRFaDwXg/d3TIhTg6p11+fRISOWJ3R0vvH6R9fK2VR05 Cc: dane@ietf.org Subject: Re: [dane] Behavior in the face of no answer? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 15 May 2012 02:31:46 -0000 On Mon, May 14, 2012 at 7:12 PM, Paul Hoffman wrote= : > There doesn't seem to be convergence here, and the WG chairs and AD have = asked the authors to propose wording that might bring consensus. The follow= ing text may be insufficient, but it's the best I can do at the moment, and= if it isn't good enough, having you propose specific changes may be helpfu= l. > > This proposed text tries to pull together: > > - Ekr's security analysis > > - The desire for a MUST that is likely to be deployed, not ignored > > - Acknowledgement that if the user doesn't know TLSA is being used, they = are not losing anything from the attack > > (And, yes, I think that the chairs should be doing this bit instead of Ja= kob and I. Oh, well.) > > An attacker who is able to divert a user to a server under his control is= also > likely to be able to block DNS requests from the user or DNS responses be= ing > sent to the user. Thus, in order to achieve any security benefit from > certificate usage 0 or 1, an application that sends a request for TLSA re= cords > needs to get either a valid signed response containing TLSA records or > verification that the domain is insecure or indeterminate. If a request f= or a > TLSA record does not meet one of those two criteria but the application > continues with the TLS handshake anyway, the application has gotten no be= nefit > from TLSA and should not make any internal or external indication that TL= SA > was applied. I think this is generally fine, modulo Stephen's concerns about types 2 and= 3, which I haven't worked through yet. > If an application has any indication that TLSA is in use (such as > through a configuration setting), that application MUST not start a TLS > connection or abort a TLS handshake if either of the two criteria above a= re > not met. I feel like this is confusing. There are two senses in which TLSA might be "in use". (1) The application is trying to retrieve it. (2) The DNS serv= er is serving it. We're clearly in the first case, and it's the second which is unknown to us b/c under control of the attacker. Perhaps you mean to say "Applicaions SHOULD offer a setting to allow users to set strict TLSA checking, in which case..." From paul@cypherpunks.ca Mon May 14 19:45:05 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0B1B21F8897 for ; Mon, 14 May 2012 19:45:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021, 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 KZaZUzk-n+n6 for ; Mon, 14 May 2012 19:45:05 -0700 (PDT) Received: from letoams.cypherpunks.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 25A9421F8864 for ; Mon, 14 May 2012 19:45:05 -0700 (PDT) Received: by letoams.cypherpunks.ca (Postfix, from userid 500) id 7E17B853FE; Mon, 14 May 2012 22:45:02 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by letoams.cypherpunks.ca (Postfix) with ESMTP id 72625853FD; Mon, 14 May 2012 22:45:02 -0400 (EDT) Date: Mon, 14 May 2012 22:45:02 -0400 (EDT) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: Paul Hoffman In-Reply-To: <643D87CD-D01E-47B8-82E5-D3F57D50C80B@vpnc.org> Message-ID: References: <643D87CD-D01E-47B8-82E5-D3F57D50C80B@vpnc.org> User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: dane@ietf.org Subject: Re: [dane] Behavior in the face of no answer? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 15 May 2012 02:45:05 -0000 On Mon, 14 May 2012, Paul Hoffman wrote: > An attacker who is able to divert a user to a server under his control is also > likely to be able to block DNS requests from the user or DNS responses being > sent to the user. Thus, in order to achieve any security benefit from > certificate usage 0 or 1, an application that sends a request for TLSA records > needs to get either a valid signed response containing TLSA records or > verification that the domain is insecure or indeterminate. If a request for a > TLSA record does not meet one of those two criteria but the application > continues with the TLS handshake anyway, the application has gotten no benefit > from TLSA and should not make any internal or external indication that TLSA > was applied. If an application has any indication that TLSA is in use (such as > through a configuration setting), that application MUST not start a TLS > connection or abort a TLS handshake if either of the two criteria above are > not met. > > Livable? Better specific suggestions? Livable. I am a little confused about "signed TLSA", "insecure" or "indeterminate" together with "the two criteria". Did you mean "signed TLSA" and "insecure" as one criteria ("dnssec worked") or did you mean "indicator" and "indeterminate" as the two criteria? How about: an application that sends a request for TLSA records will get either a valid signed response (containing TLSA records or not) or reaches an indeterminate state (for instance by lack of DNS replies) [...] that application MUST not start a TLS connection or abort a TLS handshake if TLSA processing is configured and the result was indeterminate. I'm also not sure why the statement is limited to certficate usage 0 and 1. Is that because you assume no PKIX alternatives are available and thus it always has to abort for insecure/indeterminate? Paul From ekr@rtfm.com Mon May 14 19:56:17 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09B5821F8539 for ; Mon, 14 May 2012 19:56:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.877 X-Spam-Level: X-Spam-Status: No, score=-102.877 tagged_above=-999 required=5 tests=[AWL=0.100, 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 kBUXhGydjJnZ for ; Mon, 14 May 2012 19:56:16 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 55BD021F851B for ; Mon, 14 May 2012 19:56:16 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so6799799vbb.31 for ; Mon, 14 May 2012 19:56:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=elM0dfcdN4SfzxFI2FDIYZhy/SUzzIjycX28VEJAQyw=; b=PpdXX4zoDNquXVcP0I3LYvIYd2qAI0R3nojlQS0cSHOztu4h3USh7D4QbFpAUg2tGo VtGS7YmOABziYEB9JN+PF6ifMpQkykAEj4j+XxtKkT7IRqJibgVlSMyARDNRbhx7YLdt zPEUEwWpxILUjELJXeLnoJfYN/3OScTtjGNPl451+C26tOkZ8rnUGmI4TcoM71Ree0d6 Kf6BIeai+WOrVfYNDPi8z5Savlxhr63FHPG5yzZaaneH85KsGySXxygujauAGR3Ugv2d yZzckAs54CFYU1D2leHkYsguobqcMRUEvCy5y1c4HgzZXefcoFCwWmb13Z0sIMUOq/L9 lIcw== Received: by 10.52.100.229 with SMTP id fb5mr5031911vdb.102.1337050575847; Mon, 14 May 2012 19:56:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.35.209 with HTTP; Mon, 14 May 2012 19:55:35 -0700 (PDT) X-Originating-IP: [74.95.2.173] In-Reply-To: References: <643D87CD-D01E-47B8-82E5-D3F57D50C80B@vpnc.org> From: Eric Rescorla Date: Mon, 14 May 2012 19:55:35 -0700 Message-ID: To: Paul Wouters Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmbGvrxzKN+pLCLbVCtJ68kMgNe3YBm3ISNwTDuVaoEQXpHbfrIXfrz4AQVWx9rOzPKrVOM Cc: Paul Hoffman , dane@ietf.org Subject: Re: [dane] Behavior in the face of no answer? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 15 May 2012 02:56:17 -0000 On Mon, May 14, 2012 at 7:45 PM, Paul Wouters wrote: > On Mon, 14 May 2012, Paul Hoffman wrote: > >> An attacker who is able to divert a user to a server under his control i= s >> also >> likely to be able to block DNS requests from the user or DNS responses >> being >> sent to the user. Thus, in order to achieve any security benefit from >> certificate usage 0 or 1, an application that sends a request for TLSA >> records >> needs to get either a valid signed response containing TLSA records or >> verification that the domain is insecure or indeterminate. If a request >> for a >> TLSA record does not meet one of those two criteria but the application >> continues with the TLS handshake anyway, the application has gotten no >> benefit >> from TLSA and should not make any internal or external indication that >> TLSA >> was applied. If an application has any indication that TLSA is in use >> (such as >> through a configuration setting), that application MUST not start a TLS >> connection or abort a TLS handshake if either of the two criteria above >> are >> not met. >> >> Livable? Better specific suggestions? > > > Livable. I am a little confused about "signed TLSA", "insecure" or > "indeterminate" together with "the two criteria". Did you mean > "signed TLSA" and "insecure" as one criteria ("dnssec worked") or did > you mean "indicator" and "indeterminate" as the two criteria? How about: > > =A0 an application that sends a request for TLSA records will get > =A0 either a valid signed response (containing TLSA records or not) > =A0 or reaches an indeterminate state (for instance by lack of DNS > =A0 replies) > > =A0 [...] > I don't think this is what we want.. There appear to be five relevant states: * secure, bogus, indeterminate, or insecure [specified in section 4.1] * no response, DNS error, etc. [the state in question here] The relevant point here is that in the case where you were expecting DNSSEC but you get some error in the last category, then in order to get security benefit from restrictive modes, you must treat that as if it were bogus. That's different from cases where you weren't expecting DNSSEC (insecure, indeterminate), and therefore you should just be ignoring the TLSA records. > =A0 that application MUST not start a TLS connection or abort a TLS hands= hake > =A0 if TLSA processing is configured and the result was indeterminate. > > > I'm also not sure why the statement is limited to certficate usage 0 and > 1. Is that because you assume no PKIX alternatives are available and > thus it always has to abort for insecure/indeterminate? The security logic is different for restrictive records and additive record= s. Say that you're not willing to hard fail on TLSA failures but you're willin= g to suppress error warnings if you get resolvable records of type 2 and 3. Then you are getting security benefit for those records, but you're not getting any security benefit if type 0 or 1 records exist. With that said, I haven't completely worked through 2 and 3, so it might be that they have some restrictive value, in which case the above analysis applies. Arguably, it would be best to serve two different classes of records to make this clearer. -Ekr From paul@cypherpunks.ca Mon May 14 21:23:15 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 238FA21F850C for ; Mon, 14 May 2012 21:23:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019, 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 7PoBxc726Hkz for ; Mon, 14 May 2012 21:23:14 -0700 (PDT) Received: from letoams.cypherpunks.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 6BEFB21F84FF for ; Mon, 14 May 2012 21:23:14 -0700 (PDT) Received: by letoams.cypherpunks.ca (Postfix, from userid 500) id 820AB853FE; Tue, 15 May 2012 00:23:13 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by letoams.cypherpunks.ca (Postfix) with ESMTP id 7979D803A3; Tue, 15 May 2012 00:23:13 -0400 (EDT) Date: Tue, 15 May 2012 00:23:13 -0400 (EDT) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: Eric Rescorla In-Reply-To: Message-ID: References: <643D87CD-D01E-47B8-82E5-D3F57D50C80B@vpnc.org> User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Paul Hoffman , dane@ietf.org Subject: Re: [dane] Behavior in the face of no answer? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 15 May 2012 04:23:15 -0000 On Mon, 14 May 2012, Eric Rescorla wrote: > I don't think this is what we want.. There appear to be five relevant > states: > > * secure, bogus, indeterminate, or insecure [specified in section 4.1] > * no response, DNS error, etc. [the state in question here] We had these discussions before, where there is a disagreement about some cases where you are not getting some responses and what state it is supposed to be. I'm not sure we all agreed in the end - I thought some people argued that "indeterminate" does not really exist. > The relevant point here is that in the case where you were expecting > DNSSEC but you get some error in the last category if you expect a dnssec signed answer (eg because you have a validated parental DS) but you did not, the reseult is what? bogus? But if there might be a zone cut in between the parental DS you have (eg the root) and the zone, it is indeterminate? I think for TLSA, these should both be treated the same, as bogus. > to get security benefit from restrictive modes, you must treat that as > if it were bogus. That's different from cases where you weren't > expecting DNSSEC (insecure, indeterminate), and therefore you > should just be ignoring the TLSA records. You cannot know when you were NOT expecting DNSSEC unless you do DNSSEC and you a get a validated anwser that leads to an end of the trust chain before it reaches the domain you were interested in. So an attacker would also prevent you from knowing that. And if you know a domain is insecure, you don't even need to query for TLSA records, unless your model assumes a full validator logic built into the browser, as opposed to using a trusted validator on localhost. Are we expecting browsers to just query for TLSA records and ignore those received without AD bit? Or are we expecting them to implement full resolver logic? Right now, a browser can just query for TLSA records to its local resolver, and make a decision based on the AD bit. If any filtering of DNSSEC is taking place, the local resolver should be returning SERVFAIL. Do we want the browser to extract more details with CD? Or should they just hard/soft fail based on their local settings? Should they find out if this would be "bogus" or "indeterminate", or is there no point? >> I'm also not sure why the statement is limited to certficate usage 0 and >> 1. Is that because you assume no PKIX alternatives are available and >> thus it always has to abort for insecure/indeterminate? > > The security logic is different for restrictive records and additive records. > Say that you're not willing to hard fail on TLSA failures but you're willing > to suppress error warnings if you get resolvable records of type 2 and 3. > Then you are getting security benefit for those records, but you're not > getting any security benefit if type 0 or 1 records exist. Now I'm completely lost. Usage 0 and 1 is for pinning PKIX, so if you want to use TLSA to avoid rogue CA's, you can't suppress those error warnings. It's really the same as disabling TLSA. Or else we're going to have to teach browsers to remember previous TLSA state and only warn when we knew the site used to publish TLSA, but now we are indeterminate. > Arguably, it would be best to serve two different classes of records to > make this clearer. I'm not sure that matters, because if you cannot get those records, eg an indeterminate answer, you cannot make a decision based on a supposed different class of record you can't receive. The only way out to signal something about hard/soft fail for TLSA outside the DNS would be to put a market in the certificate. But then we're back to square one with rogue CAs. Paul From ekr@rtfm.com Mon May 14 21:51:19 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3691321F8800 for ; Mon, 14 May 2012 21:51:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.88 X-Spam-Level: X-Spam-Status: No, score=-102.88 tagged_above=-999 required=5 tests=[AWL=0.097, 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 TmOqmwonerEJ for ; Mon, 14 May 2012 21:51:18 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0F80521F87FB for ; Mon, 14 May 2012 21:51:15 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so6876448vbb.31 for ; Mon, 14 May 2012 21:51:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=g/WnzCrwus2eqoqSl++cpQvvHtTneJGn7D4X/Kfv5p8=; b=hj1/mIhy8yAyiyiLgvVc55DrnugaJviJ+kpqE7Igi8IDfo/q3ZoWBBVNYniD7cJGBX mhwxrjf+JhGIfLN+aaf5VvSnUG/jRyFtvOeWxWwM9K88PyLuOqbk2O9IN0SpSNCvYCfj r8BAr9rMBSNOX0wcoS5RSWM8d0C8204QTO4de6ZrtYGwOHEBIgizFimPcDyLs0Jad/Du /jNDTSyuNvUy11YKf6jodk+E2NUyPvwGyG6ZhU5oi0WyyMnSukG02n+NpS/mPvr/tQUK l+bFvGvjN1+LWPt125lGX1PFr+h+QXCmTZ1u5Vgdp9gaoeiPiRgxl/Dsue0oRJvQlltl eE2g== Received: by 10.52.100.229 with SMTP id fb5mr5146132vdb.102.1337057475295; Mon, 14 May 2012 21:51:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.35.209 with HTTP; Mon, 14 May 2012 21:50:35 -0700 (PDT) X-Originating-IP: [74.95.2.173] In-Reply-To: References: <643D87CD-D01E-47B8-82E5-D3F57D50C80B@vpnc.org> From: Eric Rescorla Date: Mon, 14 May 2012 21:50:35 -0700 Message-ID: To: Paul Wouters Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnrvgonvkgXavjZbmVjK3ysfF9x4yr4e3MfYknld9kpQ+rQXARIT+ImoCktaSLkBYwZv/ov Cc: Paul Hoffman , dane@ietf.org Subject: Re: [dane] Behavior in the face of no answer? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 15 May 2012 04:51:19 -0000 On Mon, May 14, 2012 at 9:23 PM, Paul Wouters wrote: > On Mon, 14 May 2012, Eric Rescorla wrote: > >> I don't think this is what we want.. There appear to be five relevant >> states: >> >> * secure, bogus, indeterminate, or insecure [specified in section 4.1] >> * no response, DNS error, etc. [the state in question here] > > > We had these discussions before, where there is a disagreement about > some cases where you are not getting some responses and what state it > is supposed to be. I'm not sure we all agreed in the end - I thought > some people argued that "indeterminate" does not really exist. Well, it's a listed category in 4033. If it's a null category, that's fine. >> The relevant point here is that in the case where you were expecting >> DNSSEC but you get some error in the last category > > > if you expect a dnssec signed answer (eg because you have a validated > parental DS) but you did not, Did not what? The case in question is that you get no answer or an ICMP response or something. > the reseult is what? bogus? But if there > might be a zone cut in between the parental DS you have (eg the root) > and the zone, it is indeterminate? I think for TLSA, these should both > be treated the same, as bogus. Yes, I tend to agree, but it's clear that there's not consensus on this point, so I'm focusing on describing the technical situation. > >> to get security benefit from restrictive modes, you must treat that as >> if it were bogus. That's different from cases where you weren't >> expecting DNSSEC (insecure, indeterminate), and therefore you >> should just be ignoring the TLSA records. > > > You cannot know when you were NOT expecting DNSSEC unless you do DNSSEC > and you a get a validated anwser that leads to an end of the trust chain > before it reaches the domain you were interested in. So an attacker > would also prevent you from knowing that. Yes, that's true, but I'm not sure I see the relevance. Obviously, under non-attack conditions you would expect to see this with some frequency. > And if you know a domain is > insecure, you don't even need to query for TLSA records, unless your > model assumes a full validator logic built into the browser, as opposed > to using a trusted validator on localhost. Which after all, might happen. > Are we expecting browsers to just query for TLSA records and ignore > those received without AD bit? Or are we expecting them to implement > full resolver logic? Personally, I expect browsers to not query for TLSA records at all, for the reasons that AGL indicated earlier. > Right now, a browser can just query for TLSA records to its local > resolver, and make a decision based on the AD bit. If any filtering > of DNSSEC is taking place, the local resolver should be returning > SERVFAIL. Do we want the browser to extract more details with CD? Or > should they just hard/soft fail based on their local settings? Should > they find out if this would be "bogus" or "indeterminate", or is there > no point? I don't understand any of this. Even if you trust your resolver, there are certainly ways for an attacker to suppress the response, so it's always going to be the case that you need to know what to do when you get no response. This is true whether the browser has validation logic or not. >>> I'm also not sure why the statement is limited to certficate usage 0 and >>> 1. Is that because you assume no PKIX alternatives are available and >>> thus it always has to abort for insecure/indeterminate? >> >> >> The security logic is different for restrictive records and additive >> records. >> Say that you're not willing to hard fail on TLSA failures but you're >> willing >> to suppress error warnings if you get resolvable records of type 2 and 3. >> Then you are getting security benefit for those records, but you're not >> getting any security benefit if type 0 or 1 records exist. > > > Now I'm completely lost. Usage 0 and 1 is for pinning PKIX, so if you > want to use TLSA to avoid rogue CA's, you can't suppress those error > warnings. It's really the same as disabling TLSA. Yes, hence my original post. Once again, *I* think it's silly to implement TLSA and then act in a way that allows an attacker to force you back to the posture you would have been in if you didn't implement TLSA. However, apparently there is no consensus on that point. What we're discussing now (at the chair's request) is how to characterize the security implications of that implementation choice. -Ekr From paul@cypherpunks.ca Mon May 14 22:17:12 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A4C89E801A for ; Mon, 14 May 2012 22:17:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.582 X-Spam-Level: X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.017, 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 1r2PEoQiM-2m for ; Mon, 14 May 2012 22:17:12 -0700 (PDT) Received: from letoams.cypherpunks.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id DB2D09E8006 for ; Mon, 14 May 2012 22:17:10 -0700 (PDT) Received: by letoams.cypherpunks.ca (Postfix, from userid 500) id D34B4853FE; Tue, 15 May 2012 01:17:09 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by letoams.cypherpunks.ca (Postfix) with ESMTP id C4F5C81948; Tue, 15 May 2012 01:17:09 -0400 (EDT) Date: Tue, 15 May 2012 01:17:09 -0400 (EDT) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: Eric Rescorla In-Reply-To: Message-ID: References: <643D87CD-D01E-47B8-82E5-D3F57D50C80B@vpnc.org> User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Paul Hoffman , dane@ietf.org Subject: Re: [dane] Behavior in the face of no answer? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 15 May 2012 05:17:12 -0000 On Mon, 14 May 2012, Eric Rescorla wrote: > What we're discussing now > (at the chair's request) is how to characterize the security implications > of that implementation choice. I understand that, but the proposed text is trying to define certain states that are distinguishable to give different advise, and I tried to show that one cannot distinguish some of those states. You cannot tell implementarors that "indeterminate" is different from "bogus", and that a browser can give different feedback depending on those two states. Not from a security context anyways. I'll try come up with an alternative text. Paul From ajs@anvilwalrusden.com Tue May 15 04:13:25 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51D3321F8721 for ; Tue, 15 May 2012 04:13:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.624 X-Spam-Level: X-Spam-Status: No, score=-2.624 tagged_above=-999 required=5 tests=[AWL=-0.025, 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 dIX-HElFpeDV for ; Tue, 15 May 2012 04:13:24 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id A806321F8618 for ; Tue, 15 May 2012 04:13:24 -0700 (PDT) Received: from mail.yitter.info (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 21A4C1ECB41C for ; Tue, 15 May 2012 11:13:20 +0000 (UTC) Date: Tue, 15 May 2012 07:13:18 -0400 From: Andrew Sullivan To: dane@ietf.org Message-ID: <20120515111318.GZ20521@mail.yitter.info> References: <643D87CD-D01E-47B8-82E5-D3F57D50C80B@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Behavior in the face of no answer? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 15 May 2012 11:13:25 -0000 On Mon, May 14, 2012 at 07:55:35PM -0700, Eric Rescorla wrote: > > * secure, bogus, indeterminate, or insecure [specified in section 4.1] > * no response, DNS error, etc. [the state in question here] > > The relevant point here is that in the case where you were expecting > DNSSEC but you get some error in the last category, then in order > to get security benefit from restrictive modes, you must treat that as > if it were bogus. That's different from cases where you weren't > expecting DNSSEC (insecure, indeterminate), and therefore you > should just be ignoring the TLSA records. I think the reason I find this discussion difficult is that I don't get this "expecting" thing. With DNSSEC, you have _no idea_ what to expect. What you do is ask for something, and get a response or an error. Either it is validatable or not. You can expect a DNSSEC-signed response on the basis of the DS at the parent side. In the cases you're talking about here, however, you still don't know what to expect even if the A or AAAA record you fetched before was signed and validated and so on. You might get NOTIMP, for instance. As Martin Rex argued, that response is strictly consistent with the relevant RFCs even if many of us think that it's the wrong way for a server to reply. I agree that a TLSA answer in that case adds nothing to the security; but "just ignore the TLSA records" (which, _ex hypothesi_, you didn't get under the scenario) would seem to be an argument for "fall through to traditional TLS processing". I thought that's what you wanted _not_ to happen? Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From ajs@anvilwalrusden.com Tue May 15 04:22:02 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2869B21F87F1 for ; Tue, 15 May 2012 04:22:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.624 X-Spam-Level: X-Spam-Status: No, score=-2.624 tagged_above=-999 required=5 tests=[AWL=-0.025, 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 1JZgYWBHJqfx for ; Tue, 15 May 2012 04:22:01 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 99E8421F877D for ; Tue, 15 May 2012 04:22:01 -0700 (PDT) Received: from mail.yitter.info (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 D7EF61ECB41C for ; Tue, 15 May 2012 11:21:59 +0000 (UTC) Date: Tue, 15 May 2012 07:21:58 -0400 From: Andrew Sullivan To: dane@ietf.org Message-ID: <20120515112154.GA20521@mail.yitter.info> References: <643D87CD-D01E-47B8-82E5-D3F57D50C80B@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Behavior in the face of no answer? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 15 May 2012 11:22:02 -0000 On Tue, May 15, 2012 at 12:23:13AM -0400, Paul Wouters wrote: > > if you expect a dnssec signed answer (eg because you have a validated > parental DS) but you did not, the reseult is what? bogus? Yes. > But if there > might be a zone cut in between the parental DS you have (eg the root) > and the zone, it is indeterminate? If you're not sure whether there is a zone cut because you fell off the end of a chain without determining that you were into provably insecure space, then it's bogus. Otherwise, it's insecure, not indeterminate. (DLV or a TA could make the space secure again, of course, across a probably insecure boundary, in which case it's a matter of the validation state again.) For our purposes, you can think of "Indeterminate" as "I don't have a trust anchor". This is the meaning in RFC 4033, which discusses the matter from the POV of the resolver. > Right now, a browser can just query for TLSA records to its local > resolver, and make a decision based on the AD bit. If any filtering > of DNSSEC is taking place, the local resolver should be returning > SERVFAIL. Do we want the browser to extract more details with CD? Or > should they just hard/soft fail based on their local settings? Should > they find out if this would be "bogus" or "indeterminate", or is there > no point? It is possible that the browser could also use some future to-be-invented API that provided the details without having to have a full service resolver built in. > warnings. It's really the same as disabling TLSA. Or else we're going to > have to teach browsers to remember previous TLSA state and only warn > when we knew the site used to publish TLSA, but now we are > indeterminate. Surely, that's just as bad an idea; the fact that the DNS used to contain a AAAA record is no guide to whether a site is supporting IPv6 today, by way of analogy. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From ekr@rtfm.com Tue May 15 05:17:21 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 682C321F84B4 for ; Tue, 15 May 2012 05:17:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.883 X-Spam-Level: X-Spam-Status: No, score=-102.883 tagged_above=-999 required=5 tests=[AWL=0.094, 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 QG7-cOFD33-E for ; Tue, 15 May 2012 05:17:20 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id B1B5521F8478 for ; Tue, 15 May 2012 05:17:20 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so7285731vbb.31 for ; Tue, 15 May 2012 05:17:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=kvso5ul97fYlYmUJKZwU5HaYHsGv7+X7OjBeuttVXUs=; b=gYpRkjnQDRm5qICB0oi+47fgCw9slXkQLRjgR/xFDAnvSJ34ko9XzqEJBJWowSBG04 WD890P7iAjvG/EDuamIfbUxgkWrukovQRQ8b2IPshr97Pc8VFIpc77Bzu4+Ofqtee7Lw RLhHYcCZulbRVteI7xQ/YuAvVAjhmERY66tQq/SijaA9QjQjmcOOO3zWDngHz75ExXW6 pSlpFS0inpdg0UlcRhqwrM1FQwDArbqxrTdTppGfRaQfLs/ItJKDa9javYAb5mj3qO0K cDQxhRFZ8/ZUHvAvtny/uLnaBTkBzXMeypdmTRFxOaLxlLFb1y7tT83ln1G6+J32hSr9 TI9A== Received: by 10.52.172.194 with SMTP id be2mr173967vdc.60.1337084240171; Tue, 15 May 2012 05:17:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.35.209 with HTTP; Tue, 15 May 2012 05:16:39 -0700 (PDT) X-Originating-IP: [74.95.2.169] In-Reply-To: <20120515111318.GZ20521@mail.yitter.info> References: <643D87CD-D01E-47B8-82E5-D3F57D50C80B@vpnc.org> <20120515111318.GZ20521@mail.yitter.info> From: Eric Rescorla Date: Tue, 15 May 2012 05:16:39 -0700 Message-ID: To: Andrew Sullivan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQk7vp5THTIYngKMMS/qgMT5SOim0JPXvu/RHVbIDas3oERWmbx/tl8Q2HYqNiIGIIBrDMKb Cc: dane@ietf.org Subject: Re: [dane] Behavior in the face of no answer? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 15 May 2012 12:17:21 -0000 On Tue, May 15, 2012 at 4:13 AM, Andrew Sullivan w= rote: > On Mon, May 14, 2012 at 07:55:35PM -0700, Eric Rescorla wrote: >> >> * secure, bogus, indeterminate, or insecure [specified in section 4.1] >> * no response, DNS error, etc. [the state in question here] >> >> The relevant point here is that in the case where you were expecting >> DNSSEC but you get some error in the last category, then in order >> to get security benefit from restrictive modes, you must treat that as >> if it were bogus. That's different from cases where you weren't >> expecting DNSSEC (insecure, indeterminate), and therefore you >> should just be ignoring the TLSA records. > > I think the reason I find this discussion difficult is that I don't > get this "expecting" thing. =A0With DNSSEC, you have _no idea_ what to > expect. =A0What you do is ask for something, and get a response or an > error. =A0Either it is validatable or not. =A0You can expect a > DNSSEC-signed response on the basis of the DS at the parent side. > > In the cases you're talking about here, however, you still don't know > what to expect even if the A or AAAA record you fetched before was > signed and validated and so on. =A0You might get NOTIMP, for instance. > As Martin Rex argued, that response is strictly consistent with the > relevant RFCs even if many of us think that it's the wrong way for a > server to reply. =A0I agree that a TLSA answer in that case adds nothing > to the security; but "just ignore the TLSA records" (which, _ex > hypothesi_, you didn't get under the scenario) would seem to be an > argument for "fall through to traditional TLS processing". =A0I thought > that's what you wanted _not_ to happen? Let's take a step back. You're a resolver. You generate a request for a given RR, say an A record. It comes back with no signature at all. Under one set of information about the state of the world (call that S), you generate a resolution failure. Under another set of information (call that I) you consider it a result to the application but tell it that the request isn't DNSSEC signed. When I say "expecting DNSSEC", I mean condition "S" Because the signature is what secures the DNSSEC response (assuming end-to-end resolution), when you get an unsigned response, no response, or an error like NOTIMPL, if you are in condition S you need (at least if you want to be secure) to make the most pessimistic set of assumptions about what the response would have been if whatever error (or attacker behavior) caused you to get what you got had not supervened. On the other hand, if you are condition I, then you should be returning a response. It's still not cryptographically secure, but there is no reason to believe it would have been. Presumably DNSSEC does in fact know how to distinguish these cases, else any unsigned response of any kind would lead to resolution failures. What we are talking about is extending that logic to a different set of security requirements. =A0What makes this case different is that in the case of the A record, the most pessimistic response is "does not exist". In the case of the TLSA record (types 0 and 1), the most pessimistic response is "exists and forbids the certificate I am about to get". -Ekr From paul@cypherpunks.ca Tue May 15 05:19:27 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55BF821F8925 for ; Tue, 15 May 2012 05:19:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.584 X-Spam-Level: X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=0.015, 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 Q3I+2XmwJbBs for ; Tue, 15 May 2012 05:19:26 -0700 (PDT) Received: from letoams.cypherpunks.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id C210121F8920 for ; Tue, 15 May 2012 05:19:26 -0700 (PDT) Received: by letoams.cypherpunks.ca (Postfix, from userid 500) id C9E27853FE; Tue, 15 May 2012 08:19:24 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by letoams.cypherpunks.ca (Postfix) with ESMTP id BFD2A803A3; Tue, 15 May 2012 08:19:24 -0400 (EDT) Date: Tue, 15 May 2012 08:19:24 -0400 (EDT) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: Andrew Sullivan In-Reply-To: <20120515112154.GA20521@mail.yitter.info> Message-ID: References: <643D87CD-D01E-47B8-82E5-D3F57D50C80B@vpnc.org> <20120515112154.GA20521@mail.yitter.info> User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: dane@ietf.org Subject: Re: [dane] Behavior in the face of no answer? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 15 May 2012 12:19:27 -0000 On Tue, 15 May 2012, Andrew Sullivan wrote: >> warnings. It's really the same as disabling TLSA. Or else we're going to >> have to teach browsers to remember previous TLSA state and only warn >> when we knew the site used to publish TLSA, but now we are >> indeterminate. > > Surely, that's just as bad an idea; the fact that the DNS used to > contain a AAAA record is no guide to whether a site is supporting > IPv6 today, by way of analogy. Yes, it is as bad as the cert partrol plugin that tracks PKIX states in a browser. But it's better then disabling TLSA at all in the face of DNS errors (where we assume most errors are genuine network errors and not attacks). Paul From i.grok@comcast.net Tue May 15 06:47:00 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 227F021F89DC for ; Tue, 15 May 2012 06:47:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.528 X-Spam-Level: X-Spam-Status: No, score=-102.528 tagged_above=-999 required=5 tests=[AWL=0.072, 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 dNDNdMBxQPqg for ; Tue, 15 May 2012 06:46:59 -0700 (PDT) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by ietfa.amsl.com (Postfix) with ESMTP id 6F44621F89CD for ; Tue, 15 May 2012 06:46:59 -0700 (PDT) Received: from omta03.westchester.pa.mail.comcast.net ([76.96.62.27]) by qmta10.westchester.pa.mail.comcast.net with comcast id ADN91j0050bG4ec5ADmvKm; Tue, 15 May 2012 13:46:55 +0000 Received: from odin.ulthar.us ([68.33.77.0]) by omta03.westchester.pa.mail.comcast.net with comcast id ADmv1j00F00PQ6U3PDmvAl; Tue, 15 May 2012 13:46:55 +0000 Received: from odin.ulthar.us (localhost [127.0.0.1]) by odin.ulthar.us (8.14.5/8.14.3) with ESMTP id q4FDkqk5020534 for ; Tue, 15 May 2012 09:46:52 -0400 Received: (from draco@localhost) by odin.ulthar.us (8.14.5/8.14.5/Submit) id q4FDkqXm020533 for dane@ietf.org; Tue, 15 May 2012 09:46:52 -0400 Date: Tue, 15 May 2012 09:46:52 -0400 From: Scott Schmit To: dane@ietf.org Message-ID: <20120515134652.GA15583@odin.ulthar.us> Mail-Followup-To: dane@ietf.org References: <201204121903.q3CJ3ucF026698@new.toad.com> <9605FDF6-096D-4159-96A6-16549E8371AB@nic.cz> <20120504031222.GA6541@odin.ulthar.us> <2354EF03-D8D0-49AD-BD99-BA6AD2616FE6@nic.cz> <20120509115626.GA31105@odin.ulthar.us> <20120513175839.GA8350@odin.ulthar.us> <65183D89-D725-4322-9053-F49550318C8E@vpnc.org> <20120514054459.GB23015@odin.ulthar.us> <086FDB1F-38FF-4BAE-926E-6A0E6FB2E742@vpnc.org> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="zYM0uCDKw75PZbzx" Content-Disposition: inline In-Reply-To: <086FDB1F-38FF-4BAE-926E-6A0E6FB2E742@vpnc.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Inappropriate Section 8 of draft-ietf-dane-protocol-19.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 13:47:00 -0000 --zYM0uCDKw75PZbzx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, May 14, 2012 at 07:52:15AM -0700, Paul Hoffman wrote: > On May 13, 2012, at 10:44 PM, Scott Schmit wrote: >=20 > Proposal: strengthen the lead-in paragraph to this section as: > The security of the DNS RRtype described in this document relies on > the security of DNSSEC to verify that the TLSA record has not been > altered. This section describes where the security of public CAs > and the security of TLSA are similar and different. This section > applies equally to other security-related DNS RRtypes such as > keys for IPsec and SSH. That works for me. --=20 Scott Schmit --zYM0uCDKw75PZbzx Content-Type: application/x-pkcs7-signature Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIIQJgYJKoZIhvcNAQcCoIIQFzCCEBMCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC DVcwggY0MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAe Fw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0 ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEp pC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9 b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54q zHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX 9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/ 4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8E BTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIw HwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wu Y29tL3Nmc2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIB FiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4IC AQAKgwh9eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8py TUnFsukDFUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMm CeUTyMyikfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIz uQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVm z/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT 5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lAp sbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076 khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8 J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRX un0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCBxswggYDoAMCAQICAwK+HTANBgkqhkiG 9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTExMDcxNzA1 MDQwNFoXDTEyMDcxNzExNDI1OVowYjEgMB4GA1UEDRMXNDY1MjU2LTBnRmI2Sk5ZWW44QnFW bUwxGzAZBgNVBAMMEmkuZ3Jva0Bjb21jYXN0Lm5ldDEhMB8GCSqGSIb3DQEJARYSaS5ncm9r QGNvbWNhc3QubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2AjLOMsBGaqN hv2FcRbfom/QCeKMXu5tUd1JY5oIDZe5y29stnd+se/zUlEkiVeMam4Jgo1c8yGNnwLVYc5/ 9xVi7Qg1Is5b9AB6aJWElJDw/jIdihymNZ2kwkSLT0wl/lzd0mXlwFJPRgQiRkmE6V0ZmjsQ jaVtllVleGBbMvmWPm92e+4Bju9P81kKz7Xr02ijETmaPdVsl+jmOaKPS8Y+2Lat2xus4Ked oJ/7aIWIpz1gRSKjAHSZ1Wmwi2TYUjYhZryChu9e1RWtqk1CycNoeusJ8xdEVN3WSnJ299w/ 3ltK/x/9rpj2j9ShQZVB4NnX6cjQs7pz1lVxvIkjcQIDAQABo4IDrTCCA6kwCQYDVR0TBAIw ADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQW BBQ29j2I0O8sRYi0So9NwwmT1caakDAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhR gjAdBgNVHREEFjAUgRJpLmdyb2tAY29tY2FzdC5uZXQwggIhBgNVHSAEggIYMIICFDCCAhAG CysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20v cG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJt ZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcg dG8gdGhlIENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4g Y29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUF BwICMIGPMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJp bGl0eSBhbmQgd2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFu ZCBMaW1pdGF0aW9ucyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAr oCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUH AQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFz czEvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0 cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQAZ5U0nL/2PQwsVfHgN7MVPbZEGzDzuj4Oy pTgz4XQFwPcCuy6U9sp1Dwmo3DyKX5nKN4xA7pslN+2Pl/kElGamX7zMCAH0xED0RTOLyk+v nDML4s+OUtWaYVnq1bZEp0F8Luq3zIslAYSebleyiz8M0EypZczsL5rOk86R2F9EYw1CBuFJ 5a4x0CmNu5o30fGNDFt+iXRlbJPp/KY25iUgVnBzJ4COT5kQjxn5lgr4t1I+BDCL5HQQ3h/8 2CzwrWVRBNb9Vqh9LL1ZtzYRt8JezoB6HkVvcKVNGlCZ+/MnvfMzPLwfbTDZC8o4d+4RH6aE LeGF2XmAOaenc/YRqm9oMYIClzCCApMCAQEwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQQIDAr4dMAkGBSsOAwIaBQCggdgwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTIwNTE1MTM0NjUyWjAjBgkqhkiG9w0BCQQxFgQUMAD6mKS0 Jk8b16zPGrZDtZBbL5kweQYJKoZIhvcNAQkPMWwwajALBglghkgBZQMEASowCwYJYIZIAWUD BAEWMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAmTsaeMnS y4bE0SdVoXHZ74ZPLs87axTCqP1uONzCangJFOWjMQTl2W1ZwaX0zw/rge4GOcPM/n8z7Voq bJ4vC5NFLHMv6Y4YVnQZVMExYJDjo2j9lgiv1rriqvCZkZ9Rh3giQXhuGW3wcSYJAtTI1TmV jeuhWqW45z2k2iPE+Xqvj9pYjOPUL+4LT5ZjV9UWQUCehdFy2RHsTUAaIoWnf6YoG57FI/aC e+n1QiG8CkF0mf9xTwTXu8oFrX5bjndfCtKq2GuZiHNbOWAStS69+vq1YXeRKNeJhd9bPXPl TovnWJ0jJEpvVjSRrYz7xcFNp9jOQJaVJ3vAAakBEd2JDg== --zYM0uCDKw75PZbzx-- From i.grok@comcast.net Tue May 15 07:04:54 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EE4721F86FE for ; Tue, 15 May 2012 07:04:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.533 X-Spam-Level: X-Spam-Status: No, score=-102.533 tagged_above=-999 required=5 tests=[AWL=0.066, 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 TuIXPMuqz1Vi for ; Tue, 15 May 2012 07:04:53 -0700 (PDT) Received: from qmta03.emeryville.ca.mail.comcast.net (qmta03.emeryville.ca.mail.comcast.net [76.96.30.32]) by ietfa.amsl.com (Postfix) with ESMTP id B04C621F86FC for ; Tue, 15 May 2012 07:04:53 -0700 (PDT) Received: from omta20.emeryville.ca.mail.comcast.net ([76.96.30.87]) by qmta03.emeryville.ca.mail.comcast.net with comcast id ABm11j00L1smiN4A3E4tps; Tue, 15 May 2012 14:04:53 +0000 Received: from odin.ulthar.us ([68.33.77.0]) by omta20.emeryville.ca.mail.comcast.net with comcast id AE4s1j00N00PQ6U8gE4s1u; Tue, 15 May 2012 14:04:53 +0000 Received: from odin.ulthar.us (localhost [127.0.0.1]) by odin.ulthar.us (8.14.5/8.14.3) with ESMTP id q4FE4oXo020583 for ; Tue, 15 May 2012 10:04:50 -0400 Received: (from draco@localhost) by odin.ulthar.us (8.14.5/8.14.5/Submit) id q4FE4nnJ020582 for dane@ietf.org; Tue, 15 May 2012 10:04:49 -0400 Date: Tue, 15 May 2012 10:04:49 -0400 From: Scott Schmit To: dane@ietf.org Message-ID: <20120515140449.GB15583@odin.ulthar.us> Mail-Followup-To: dane@ietf.org References: <201204121903.q3CJ3ucF026698@new.toad.com> <9605FDF6-096D-4159-96A6-16549E8371AB@nic.cz> <20120504031222.GA6541@odin.ulthar.us> <2354EF03-D8D0-49AD-BD99-BA6AD2616FE6@nic.cz> <20120509115626.GA31105@odin.ulthar.us> <20120513175839.GA8350@odin.ulthar.us> <20120514054656.GC23015@odin.ulthar.us> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="p4qYPpj5QlsIQJ0K" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Inappropriate Section 8 of draft-ietf-dane-protocol-19.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 14:04:54 -0000 --p4qYPpj5QlsIQJ0K Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, May 14, 2012 at 11:39:50AM +0100, Ben Laurie wrote: > On 14 May 2012 06:46, Scott Schmit wrote: > > On Sun, May 13, 2012 at 09:39:10PM +0100, Ben Laurie wrote: > >> On 13 May 2012 18:58, Scott Schmit wrote: > >> > This is intended to replace the -20 section 8.1: > >> > >> Not sure I understand the table, but the rest seems like an excellent > >> summary to me. > > > > Is there something specific about the table that's confusing you? >=20 > a) "CA certificate" is quite broad - what about DV and EV? PKIX doesn't talk about DV/OV/EV -- that's a CA/B Forum standard. It's probably most analogous to a DV cert. > b) What is name-constrained? See RFC 5280 (search for "name constraint") > Also, does anyone use DLV? IIRC, Fedora still enables it by default in both bind & unbound--in fact, fedoraproject.org is only validated via dlv.isc.org. --=20 Scott Schmit --p4qYPpj5QlsIQJ0K Content-Type: application/x-pkcs7-signature Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIIQJgYJKoZIhvcNAQcCoIIQFzCCEBMCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC DVcwggY0MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAe Fw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0 ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEp pC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9 b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54q zHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX 9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/ 4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8E BTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIw HwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wu Y29tL3Nmc2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIB FiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4IC AQAKgwh9eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8py TUnFsukDFUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMm CeUTyMyikfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIz uQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVm z/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT 5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lAp sbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076 khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8 J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRX un0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCBxswggYDoAMCAQICAwK+HTANBgkqhkiG 9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTExMDcxNzA1 MDQwNFoXDTEyMDcxNzExNDI1OVowYjEgMB4GA1UEDRMXNDY1MjU2LTBnRmI2Sk5ZWW44QnFW bUwxGzAZBgNVBAMMEmkuZ3Jva0Bjb21jYXN0Lm5ldDEhMB8GCSqGSIb3DQEJARYSaS5ncm9r QGNvbWNhc3QubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2AjLOMsBGaqN hv2FcRbfom/QCeKMXu5tUd1JY5oIDZe5y29stnd+se/zUlEkiVeMam4Jgo1c8yGNnwLVYc5/ 9xVi7Qg1Is5b9AB6aJWElJDw/jIdihymNZ2kwkSLT0wl/lzd0mXlwFJPRgQiRkmE6V0ZmjsQ jaVtllVleGBbMvmWPm92e+4Bju9P81kKz7Xr02ijETmaPdVsl+jmOaKPS8Y+2Lat2xus4Ked oJ/7aIWIpz1gRSKjAHSZ1Wmwi2TYUjYhZryChu9e1RWtqk1CycNoeusJ8xdEVN3WSnJ299w/ 3ltK/x/9rpj2j9ShQZVB4NnX6cjQs7pz1lVxvIkjcQIDAQABo4IDrTCCA6kwCQYDVR0TBAIw ADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQW BBQ29j2I0O8sRYi0So9NwwmT1caakDAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhR gjAdBgNVHREEFjAUgRJpLmdyb2tAY29tY2FzdC5uZXQwggIhBgNVHSAEggIYMIICFDCCAhAG CysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20v cG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJt ZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcg dG8gdGhlIENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4g Y29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUF BwICMIGPMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJp bGl0eSBhbmQgd2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFu ZCBMaW1pdGF0aW9ucyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAr oCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUH AQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFz czEvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0 cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQAZ5U0nL/2PQwsVfHgN7MVPbZEGzDzuj4Oy pTgz4XQFwPcCuy6U9sp1Dwmo3DyKX5nKN4xA7pslN+2Pl/kElGamX7zMCAH0xED0RTOLyk+v nDML4s+OUtWaYVnq1bZEp0F8Luq3zIslAYSebleyiz8M0EypZczsL5rOk86R2F9EYw1CBuFJ 5a4x0CmNu5o30fGNDFt+iXRlbJPp/KY25iUgVnBzJ4COT5kQjxn5lgr4t1I+BDCL5HQQ3h/8 2CzwrWVRBNb9Vqh9LL1ZtzYRt8JezoB6HkVvcKVNGlCZ+/MnvfMzPLwfbTDZC8o4d+4RH6aE LeGF2XmAOaenc/YRqm9oMYIClzCCApMCAQEwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQQIDAr4dMAkGBSsOAwIaBQCggdgwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTIwNTE1MTQwNDQ5WjAjBgkqhkiG9w0BCQQxFgQUXKWRfhAy /CBS/tA+/R+R0LbVQ3EweQYJKoZIhvcNAQkPMWwwajALBglghkgBZQMEASowCwYJYIZIAWUD BAEWMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAz4PFTf65 nwHCjW2T/2eIAzYXfweI0DDFU5U9XT3/draRD2F9mJ97gfKYjGUyM0InNvBZzuQMB4d9f6jo 0OhvNuRNssjyi6ObBmQxI0WhZx1aoFXG5txDmbkHbAEibujpTnd4hlxLlxsIJE/txV/+lVVO C1tRt9c5ptwwp85jZ+g1inQxFDvyoQkiPTl2wBBijjdzQTpXvVnJQKjNgl4u22Hg5QwWnpuF 7EYqZL0/9qlXMVC4P1YjM4IOX99/cGvZSWvRrXtVrriyWDg05tWkV7AN/T4ZcBGIwv/OHBVj Mnn1nWnNydV02BSx/aYCXuzWkF68Dqn6nHydRHB/T98DgA== --p4qYPpj5QlsIQJ0K-- From benl@google.com Tue May 15 07:24:21 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7080621F87F8 for ; Tue, 15 May 2012 07:24: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 yABcDuBRBYGs for ; Tue, 15 May 2012 07:24:21 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id A50D221F8811 for ; Tue, 15 May 2012 07:24:20 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so4765991lbb.31 for ; Tue, 15 May 2012 07:24:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-system-of-record; bh=bYLCA2U23QGnepDaj+6PTO+W2lWI478VSYWU4G+uZnY=; b=KpdIaOhiiw/AAlWHu5c0aKVRbosI+pDhLoEXoAPviyqnm+tgYEMALDcV5tm0tyQeib WEzq0YW5xsoR6/zCp8DFYYRxA3Vyg5jSlAnOXQKmleDGeOK6lbuQcW8YpvC2FBcrEkzD g4lPrpM02CyoQ41AijSpgaXrVqNu/6bqSZv6FStoYK8KNnZd7n417BJ4kUAE7mMWPpiR ARMB4uvN5KCiQcaTN53It84j7WpNNEunVGR2hmSNQCTMVdC2+4eDKFjhOaSs/4IZs1de YLXzJQKzI9i0BFqDtVAjghm/SGyKZzSXUPRU7hJihyEBkt2ZYr9pyZGqOtf+g1cxjKg5 tELA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-system-of-record:x-gm-message-state; bh=bYLCA2U23QGnepDaj+6PTO+W2lWI478VSYWU4G+uZnY=; b=lvAVCdF2FCHLaZbd902ULCmgARQyUGmuJWiMuPlfNpPeBRqDqG6swRfjDnPfmn99pQ G+sB5upyVaCT5X58eR3t6uj3xxkwHBRlYn68BkZF5hz/S/cLzWTowqxFzifZwB77gybi kjcigppPZwvEvKqxgJMvmfQvHc7VINpWq1QV2zn3L15ZYSMPPOtzplg3BOUC3Si48ZOO WEqM0+KWOzUzsj5P+DVEUBWNs2qQSd50Nq0tyOqkdwHY8mbXchSiHfaqA4zV2h4Q7MAM L02GUXXpUzhp4Jr989ZShGr2QQ/KW/drShaKH0F/EIWaLKurPYuDXkIQn/a8rWitre46 vB4Q== Received: by 10.152.114.106 with SMTP id jf10mr4614365lab.16.1337091859621; Tue, 15 May 2012 07:24:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.114.106 with SMTP id jf10mr4614357lab.16.1337091859548; Tue, 15 May 2012 07:24:19 -0700 (PDT) Received: by 10.112.66.136 with HTTP; Tue, 15 May 2012 07:24:19 -0700 (PDT) In-Reply-To: <20120515140449.GB15583@odin.ulthar.us> References: <201204121903.q3CJ3ucF026698@new.toad.com> <9605FDF6-096D-4159-96A6-16549E8371AB@nic.cz> <20120504031222.GA6541@odin.ulthar.us> <2354EF03-D8D0-49AD-BD99-BA6AD2616FE6@nic.cz> <20120509115626.GA31105@odin.ulthar.us> <20120513175839.GA8350@odin.ulthar.us> <20120514054656.GC23015@odin.ulthar.us> <20120515140449.GB15583@odin.ulthar.us> Date: Tue, 15 May 2012 15:24:19 +0100 Message-ID: From: Ben Laurie To: dane@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true X-Gm-Message-State: ALoCoQnwj/r8AReVRHpqB2O/0irFxbI4it7GqmxJeq7b50G+ghkHO4RI6v2hSSLBJVwzV+Gtw8jeHJAl1xcfBgkKGnu9JBU6nNMzFG1jf/BLNGSLE4POr8stE5Ww5OsVJW/YKIgr5Y1i Subject: Re: [dane] Inappropriate Section 8 of draft-ietf-dane-protocol-19.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 14:24:21 -0000 On 15 May 2012 15:04, Scott Schmit wrote: > On Mon, May 14, 2012 at 11:39:50AM +0100, Ben Laurie wrote: >> On 14 May 2012 06:46, Scott Schmit wrote: >> > On Sun, May 13, 2012 at 09:39:10PM +0100, Ben Laurie wrote: >> >> On 13 May 2012 18:58, Scott Schmit wrote: >> >> > This is intended to replace the -20 section 8.1: >> >> >> >> Not sure I understand the table, but the rest seems like an excellent >> >> summary to me. >> > >> > Is there something specific about the table that's confusing you? >> >> a) "CA certificate" is quite broad - what about DV and EV? > > PKIX doesn't talk about DV/OV/EV -- that's a CA/B Forum standard. > It's probably most analogous to a DV cert. Then I guess CAs don't use PKIX :-) If you want to compare TLSA to CA certificates, then don't you have to use whatever standards they use? >> b) What is name-constrained? > > See RFC 5280 (search for "name constraint") Heh - I know what it means, it wasn't clear to me what had the property... From paul.hoffman@vpnc.org Tue May 15 07:41:22 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C978D21F87DB for ; Tue, 15 May 2012 07:41:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.556 X-Spam-Level: X-Spam-Status: No, score=-102.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 8E8s53OOdXuk for ; Tue, 15 May 2012 07:41:22 -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 2742A21F8741 for ; Tue, 15 May 2012 07:41:22 -0700 (PDT) Received: from [10.20.30.102] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q4FEfHAw096737 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 15 May 2012 07:41:18 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Tue, 15 May 2012 07:41:16 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201204121903.q3CJ3ucF026698@new.toad.com> <9605FDF6-096D-4159-96A6-16549E8371AB@nic.cz> <20120504031222.GA6541@odin.ulthar.us> <2354EF03-D8D0-49AD-BD99-BA6AD2616FE6@nic.cz> <20120509115626.GA31105@odin.ulthar.us> <20120513175839.GA8350@odin.ulthar.us> <20120514054656.GC23015@odin.ulthar.us> <20120515140449.GB15583@odin.ulthar.us> To: Ben Laurie X-Mailer: Apple Mail (2.1278) Cc: dane@ietf.org Subject: Re: [dane] Inappropriate Section 8 of draft-ietf-dane-protocol-19.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 14:41:22 -0000 On May 15, 2012, at 7:24 AM, Ben Laurie wrote: > On 15 May 2012 15:04, Scott Schmit wrote: >> On Mon, May 14, 2012 at 11:39:50AM +0100, Ben Laurie wrote: >>> On 14 May 2012 06:46, Scott Schmit wrote: >>>> On Sun, May 13, 2012 at 09:39:10PM +0100, Ben Laurie wrote: >>>>> On 13 May 2012 18:58, Scott Schmit wrote: >>>>>> This is intended to replace the -20 section 8.1: >>>>>=20 >>>>> Not sure I understand the table, but the rest seems like an = excellent >>>>> summary to me. >>>>=20 >>>> Is there something specific about the table that's confusing you? >>>=20 >>> a) "CA certificate" is quite broad - what about DV and EV? >>=20 >> PKIX doesn't talk about DV/OV/EV -- that's a CA/B Forum standard. >> It's probably most analogous to a DV cert. >=20 > Then I guess CAs don't use PKIX :-) >=20 > If you want to compare TLSA to CA certificates, then don't you have to > use whatever standards they use? No. There is not even vaguely an equivalent in the DNSSEC world for EV = certs, nor for validation that gets you the equivalent of the green bar. --Paul Hoffman From ajs@anvilwalrusden.com Tue May 15 07:55:09 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42DD521F88E8 for ; Tue, 15 May 2012 07:55:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.624 X-Spam-Level: X-Spam-Status: No, score=-2.624 tagged_above=-999 required=5 tests=[AWL=-0.025, 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 Ti7WSe0JkT6W for ; Tue, 15 May 2012 07:55:08 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 8EF1B21F88BF for ; Tue, 15 May 2012 07:55:08 -0700 (PDT) Received: from mail.yitter.info (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 F18631ECB41C for ; Tue, 15 May 2012 14:55:07 +0000 (UTC) Date: Tue, 15 May 2012 10:55:06 -0400 From: Andrew Sullivan To: dane@ietf.org Message-ID: <20120515145506.GC20521@mail.yitter.info> References: <643D87CD-D01E-47B8-82E5-D3F57D50C80B@vpnc.org> <20120515111318.GZ20521@mail.yitter.info> 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] Behavior in the face of no answer? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 15 May 2012 14:55:09 -0000 On Tue, May 15, 2012 at 05:16:39AM -0700, Eric Rescorla wrote: > You're a resolver. > > You generate a request for a given RR, say an A record. It comes back > with no signature at all. Under one set of information about the state > of the world (call that S), you generate a resolution failure. Under > another set of information (call that I) you consider it a result to > the application but tell it that the request isn't DNSSEC signed. When > I say "expecting DNSSEC", I mean condition "S" Are you talking about a case where by, for local policy reasons, if you don't get a DNSSEC-validating response, you produce an error (probably the functional equivalent of SERVFAIL) for consumption by the calling application? The reason I ask is this: > Presumably DNSSEC does in fact know how to distinguish these cases, > else any unsigned response of any kind would lead to resolution > failures. How? If you're talking about the description of the world as I interpreted above, then unsigned responses of any kind _would_ lead to resolution failures. That's why nobody would turn that knob on except in very narrow circumstances. If you're talking about normal operation of a validating resolver, then you can distinguish between "this response is signed and validatable, and everything in the delegation chain is too" (secure); "this response is signed but not validatable in some way", or, "this response is not signed but I can prove it should be" (bogus); "this response is not signed and I can prove that it needn't be" ([probvably] insecure); "I don't know about this case" (indeterminate). But these states don't extend to the errors (except Name Error). In the case of an error or simple non-response, you just don't have the data. You can't draw any conclusion. Normally, you don't have to, of course: if you don't know the A record or SRV record or whatever, you can't do anything more, and your action fails. (This is not "does not exist", but "I can't find it". For a naive user this difference might not matter; "the site is broken". But it does matter for the purposes of caching and so on. The possibility of a bad cache is part of why I don't want to say "treat as bogus" for this purpose.) In the DANE case, as you point out, what we're doing is adding to the DNS supplementary data about a different data path. That's the reason that, when you get an error or don't get a response, you need to draw a conclusion. This is an unusual thing to do with the DNS. I therefore think you're right that, if for use case 0 or 1, the responsible deployer would want the attempted connection to fail. That's the security the additional data (the TLSA record) is supposed to offer. I've argued that approach is dangerous except in really unusual circumstances, because it seems likely to result in surprising random failures sometimes. One of those failures is bound to cause people to say, "Turn TLSA off," and then we lose all the TLSA features. Alternatively, it will cause people faced with a TLS negotiation failure to fall back to no-TLS versions of whatever they're using (which is probably spelled "http" for this worry), and I think that's worse. Surely, some people will deploy TLSA in use 0 or 1 without understanding the failure modes ("more security is better", "turn it up to 11", and so on). It seemed to me that the proferred additional text explained the above (the upshot being that use 0 and 1 are both very close to useless). Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From ajs@anvilwalrusden.com Tue May 15 07:57:24 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FD9C21F8593 for ; Tue, 15 May 2012 07:57:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.623 X-Spam-Level: X-Spam-Status: No, score=-2.623 tagged_above=-999 required=5 tests=[AWL=-0.024, 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 RiafDzMjJoqE for ; Tue, 15 May 2012 07:57:24 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 0D95121F85CF for ; Tue, 15 May 2012 07:57:24 -0700 (PDT) Received: from mail.yitter.info (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 22E941ECB41C for ; Tue, 15 May 2012 14:57:23 +0000 (UTC) Date: Tue, 15 May 2012 10:57:21 -0400 From: Andrew Sullivan To: dane@ietf.org Message-ID: <20120515145721.GD20521@mail.yitter.info> References: <643D87CD-D01E-47B8-82E5-D3F57D50C80B@vpnc.org> <20120515112154.GA20521@mail.yitter.info> 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] Behavior in the face of no answer? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 15 May 2012 14:57:24 -0000 On Tue, May 15, 2012 at 08:19:24AM -0400, Paul Wouters wrote: > > Yes, it is as bad as the cert partrol plugin that tracks PKIX states > in a browser. But it's better then disabling TLSA at all in the face > of DNS errors (where we assume most errors are genuine network errors > and not attacks). I think ekr is arguing that use cases 0 and 1 are different than use cases 2 and 3; it seems to me that in use cases 2 and 3, if you can't get an answer out of the DNS you're already screwed: you can't proceed with a TLS connection, because you don't have the necessary material to do the negotiation. What did I miss? Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From benl@google.com Tue May 15 08:44:29 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC25821F895A for ; Tue, 15 May 2012 08:44:29 -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=[AWL=-0.000, 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 1-00NbwxbTAN for ; Tue, 15 May 2012 08:44:28 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5AD0A21F8936 for ; Tue, 15 May 2012 08:44:28 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so4845130lbb.31 for ; Tue, 15 May 2012 08:44:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record; bh=6a+8GROq/61H6H9kNEw0xzI8nigquV99K8SdVbzlLGI=; b=TZiVBNw3QpAL87fT5c3X6FyKlTVlRZ/UWk/KO4mzi8NwwmwToCAiq1fo9Eptqgv142 nBCLNvOV4Ch4QZOvYSJhABmmxCwxrkmyJYBCqVCICxy5BZn+eMqp6RReAWouqQGAhoNs w1PafjTGsYlA5vc2SelEcCigvANtApzYURDZKFRZK+WjCRkwylw+uRWxaQo3wZusEC8O tF7/pQu8lrkGAPvDEebF5w+pSPL/tiJSXXZu9+m3d42QPmQogPqV2JfwkI4jnySnRXvY mwjCtvshdNLKuIQeDS4Di8Jc/cpkJBGkmLMpZxSRHt1M9hicaVw7gtqZvlv8TzWHCoSD IqtQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=6a+8GROq/61H6H9kNEw0xzI8nigquV99K8SdVbzlLGI=; b=c1faiwrvLqUIYI9B/A7mndR9IoPmTd4rfAvsmtGn3O+GblftJkkVMVjIAAgAByeP7Z +BKDHj27IdVh/Wn27Ee//7w9rJYHt/jrLBW45oMC5OwujiyN1sRX8JZr30HM/e44lDTJ ZDv9gAV2hHUDYaPpQyNjJXLuebg+lplFfFPmiiGv9h9fUaWRAELv5IwRYNqVGtZEkq98 HkrjgWodceV9RPSkobshpClgWAjHaM7NBcQjE0XZtLRCAP/5BSHdSbV9VcCYSkM2YfMb MXFKNXYkLamn/qkS8I3u1jTenfcoqFmd+6Zlfnzx8Sq1zpCs2B3v0gXFfE1AaFhCl22B manw== Received: by 10.152.147.33 with SMTP id th1mr13215477lab.9.1337096667332; Tue, 15 May 2012 08:44:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.147.33 with SMTP id th1mr13215460lab.9.1337096667139; Tue, 15 May 2012 08:44:27 -0700 (PDT) Received: by 10.112.66.136 with HTTP; Tue, 15 May 2012 08:44:27 -0700 (PDT) In-Reply-To: References: <201204121903.q3CJ3ucF026698@new.toad.com> <9605FDF6-096D-4159-96A6-16549E8371AB@nic.cz> <20120504031222.GA6541@odin.ulthar.us> <2354EF03-D8D0-49AD-BD99-BA6AD2616FE6@nic.cz> <20120509115626.GA31105@odin.ulthar.us> <20120513175839.GA8350@odin.ulthar.us> <20120514054656.GC23015@odin.ulthar.us> <20120515140449.GB15583@odin.ulthar.us> Date: Tue, 15 May 2012 16:44:27 +0100 Message-ID: From: Ben Laurie To: Paul Hoffman Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true X-Gm-Message-State: ALoCoQmzFrl7tT3fJmhJZgpT69rGt1lQ94Dc8U7qFNPYA2PgY0U2gaCUJijMvjoQjBkz1da3dwi22gkH8KVDf0ujhJHCrlajpmR7f7eqY3swhNFCwvnWNwhITeTJ6/WSA//450Y/M1sK Cc: dane@ietf.org Subject: Re: [dane] Inappropriate Section 8 of draft-ietf-dane-protocol-19.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 15:44:29 -0000 On 15 May 2012 15:41, Paul Hoffman wrote: > On May 15, 2012, at 7:24 AM, Ben Laurie wrote: > >> On 15 May 2012 15:04, Scott Schmit wrote: >>> On Mon, May 14, 2012 at 11:39:50AM +0100, Ben Laurie wrote: >>>> On 14 May 2012 06:46, Scott Schmit wrote: >>>>> On Sun, May 13, 2012 at 09:39:10PM +0100, Ben Laurie wrote: >>>>>> On 13 May 2012 18:58, Scott Schmit wrote: >>>>>>> This is intended to replace the -20 section 8.1: >>>>>> >>>>>> Not sure I understand the table, but the rest seems like an excellent >>>>>> summary to me. >>>>> >>>>> Is there something specific about the table that's confusing you? >>>> >>>> a) "CA certificate" is quite broad - what about DV and EV? >>> >>> PKIX doesn't talk about DV/OV/EV -- that's a CA/B Forum standard. >>> It's probably most analogous to a DV cert. >> >> Then I guess CAs don't use PKIX :-) >> >> If you want to compare TLSA to CA certificates, then don't you have to >> use whatever standards they use? > > No. There is not even vaguely an equivalent in the DNSSEC world for EV certs, nor for validation that gets you the equivalent of the green bar. Exactly! From ajs@anvilwalrusden.com Tue May 15 08:55:19 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1026E21F8944 for ; Tue, 15 May 2012 08:55:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.623 X-Spam-Level: X-Spam-Status: No, score=-2.623 tagged_above=-999 required=5 tests=[AWL=-0.024, 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 e7-YTrt-GxcX for ; Tue, 15 May 2012 08:55:18 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 61D5521F88AD for ; Tue, 15 May 2012 08:55:18 -0700 (PDT) Received: from mail.yitter.info (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 C68671ECB41C for ; Tue, 15 May 2012 15:55:17 +0000 (UTC) Date: Tue, 15 May 2012 11:55:15 -0400 From: Andrew Sullivan To: dane@ietf.org Message-ID: <20120515155515.GH20521@mail.yitter.info> References: <643D87CD-D01E-47B8-82E5-D3F57D50C80B@vpnc.org> <20120515111318.GZ20521@mail.yitter.info> <20120515145506.GC20521@mail.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120515145506.GC20521@mail.yitter.info> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Behavior in the face of no answer? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 15 May 2012 15:55:19 -0000 I know, replying to myself. On Tue, May 15, 2012 at 10:55:06AM -0400, Andrew Sullivan wrote: > In the DANE case, as you point out, what we're doing is adding to the > DNS supplementary data about a different data path. That's the reason > that, when you get an error or don't get a response, you need to draw > a conclusion. This is an unusual thing to do with the DNS. An off-list conversation with Paul Hoffman (thanks, Paul) leads me to try to make this more precise. What we are doing in the DANE case, with uses 0 and 1, is to add constraints to the operation of another protocol. That is, use 2 and 3 provide a full-blown change to another protocol. E.g., 3 says "use this cert or key" so you don't end up following an X.509 chain of trust when doing your TLS negotiation. But 0 and 1 don't do that; instead they say, "Do your PKIX work as normal, but here's an additional constraint." This adding of constraints is the thing that is unusual to do with the DNS. Paul convinced me pretty quickly that this is not the first time we've done it, but it's unusual enough that when we do it we may not realise what we're doing. (On reflection, for instance, I think that SPF, when used with a mail server that rejects the mail at EHLO due to SPF failure, amounts to a case like this.) I am currently calling these cases "constraint assertions in the DNS" because I don't have a nicer name. I think those calling for funny handling of normal DNS conditions like error messages have identified a fundamental need in constraint-assertion cases, because if one cannot receive a message about the existence of such a constraint assertion, one has a problem. This doesn't leave me more certain of what to say in the draft, but at least I have a clearer idea of what's at issue. Does anyone else think this way of thinking about the difference is helpful? Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From nweaver@icsi.berkeley.edu Tue May 15 09:06:33 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CFC221F89AF for ; Tue, 15 May 2012 09:06:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.465 X-Spam-Level: X-Spam-Status: No, score=-2.465 tagged_above=-999 required=5 tests=[AWL=0.134, 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 6D5CDYk5g6s5 for ; Tue, 15 May 2012 09:06:32 -0700 (PDT) Received: from rock.ICSI.Berkeley.EDU (rock.ICSI.Berkeley.EDU [192.150.186.19]) by ietfa.amsl.com (Postfix) with ESMTP id C693721F8993 for ; Tue, 15 May 2012 09:06:32 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 4CAE92C4017; Tue, 15 May 2012 09:06:32 -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 liblnUZCYXxt; Tue, 15 May 2012 09:06:32 -0700 (PDT) Received: from gala.icir.org (gala [192.150.187.49]) (Authenticated sender: nweaver) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 095F82C4002; Tue, 15 May 2012 09:06:32 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Nicholas Weaver In-Reply-To: <20120515155515.GH20521@mail.yitter.info> Date: Tue, 15 May 2012 09:06:31 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <2C1EFBF9-D29F-4BBA-A003-95BFCF9111E4@icsi.berkeley.edu> References: <643D87CD-D01E-47B8-82E5-D3F57D50C80B@vpnc.org> <20120515111318.GZ20521@mail.yitter.info> <20120515145506.GC20521@mail.yitter.info> <20120515155515.GH20521@mail.yitter.info> To: Andrew Sullivan X-Mailer: Apple Mail (2.1257) Cc: dane@ietf.org Subject: Re: [dane] Behavior in the face of no answer? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 15 May 2012 16:06:33 -0000 On May 15, 2012, at 8:55 AM, Andrew Sullivan wrote: > I am currently calling these cases "constraint assertions in the DNS" > because I don't have a nicer name. I think those calling for funny > handling of normal DNS conditions like error messages have identified > a fundamental need in constraint-assertion cases, because if one > cannot receive a message about the existence of such a constraint > assertion, one has a problem. =20 >=20 > This doesn't leave me more certain of what to say in the draft, but at > least I have a clearer idea of what's at issue. Does anyone else > think this way of thinking about the difference is helpful? Yes. =20 It say either "Hard Failure" or "Annoy the @#)(*#@ User Failure" on = inability to fetch a proper DNSSEC validating record when one is = expected. Because the TLS system in practice already has a constraint system, = Certificate Revocation Lists, which say "Despite the certificate being = valid, don't use these certificates". The CRL check is a "fail open" = (proceed if unable to contact the CRL server), its now viewed as useless = and is being discontinued at least in Chrome, and I'd expect other = browsers to follow suit. Since the existing "add constraint" system is now considered useless = because of the "fail open" nature, any new constraint system MUST be = either "fail closed" or "fail annoying" if it can't get the necessary = records from DNS. From mrex@sap.com Tue May 15 09:52:20 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 651DA21F853C for ; Tue, 15 May 2012 09:52:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.084 X-Spam-Level: X-Spam-Status: No, score=-10.084 tagged_above=-999 required=5 tests=[AWL=0.165, 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 nnCKuicrpI+1 for ; Tue, 15 May 2012 09:52:19 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 9F12221F842C for ; Tue, 15 May 2012 09:52:19 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q4FGqHss029920 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 15 May 2012 18:52:17 +0200 (MEST) From: Martin Rex Message-Id: <201205151652.q4FGqFZP020706@fs4113.wdf.sap.corp> To: ekr@rtfm.com (Eric Rescorla) Date: Tue, 15 May 2012 18:52:15 +0200 (MEST) In-Reply-To: from "Eric Rescorla" at May 14, 12 07:31:03 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] Behavior in the face of no answer? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 16:52:20 -0000 Eric Rescorla wrote: > > > If an application has any indication that TLSA is in use (such as > > through a configuration setting), that application MUST not start a TLS > > connection or abort a TLS handshake if either of the two criteria above are > > not met. > > I feel like this is confusing. There are two senses in which TLSA might > be "in use". (1) The application is trying to retrieve it. (2) The DNS server > is serving it. We're clearly in the first case, and it's the second which > is unknown to us b/c under control of the attacker. Perhaps you > mean to say "Applicaions SHOULD offer a setting to allow users to > set strict TLSA checking, in which case..." Similar to OCSP, any hard-fail requirement is going to create a significant usability issue, and at worst, cause users to fallback from a HTTPS-but-not-DANE-verifiable URL for a login page to a plain HTTP login page -- which is making things *MUCH* worse. I do not believe in DANE hard-fail without a DNSSEC records stapling TLS extension (similar to the OCSP stapling TLS extension). And as a fallback, browsers could use a TLSA & server-cert lock, i.e. memorizing information from the last visit of a site and using that to perform server endpoint identification in case that DNSSEC lookups fail when roaming. -Martin From ekr@rtfm.com Tue May 15 09:56:09 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34C1321F889F for ; Tue, 15 May 2012 09:56:09 -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 dGWD1YZNzugZ for ; Tue, 15 May 2012 09:56:08 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9ADF821F884D for ; Tue, 15 May 2012 09:56:08 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so7621631vbb.31 for ; Tue, 15 May 2012 09:56:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=i7XQIHtqhzZJXYqxPe5A+DZQ1F/7FsBk7OGOAQ3Je8c=; b=h5FbddwM35QxTOkc73hYlhmTlCovhhtSJrz9AE/zyeNOpwNDPvR/J8JNzvpsMUKa+S QTVgHphjC398Qty/BSOA4Qe0any9v39p+cZl5utv1H+tPB2DDmFkFKBoI/6Yv+0AtDr7 NSlrPjBNJAKlwyBUlSQyuR0zGM1hPq107DSKwatyCAn1EbLnnWxkZ7BRztTfzUgx6+8/ qMYDK4cCniNlTKA54Nkd5jfg6ReVwu0/71sVvoCm3fxl+dVDAvcU6pALMw4XTPqj0S2j +6TMNeppX33vNlXVbWUhHMxk+uBENSEucFIlLtjFTeZWp6Tjl5U/vDrYJOwtFLXV2JrK p3EQ== Received: by 10.220.150.148 with SMTP id y20mr7705018vcv.26.1337100968085; Tue, 15 May 2012 09:56:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.35.209 with HTTP; Tue, 15 May 2012 09:55:27 -0700 (PDT) X-Originating-IP: [63.245.220.224] In-Reply-To: <201205151652.q4FGqFZP020706@fs4113.wdf.sap.corp> References: <201205151652.q4FGqFZP020706@fs4113.wdf.sap.corp> From: Eric Rescorla Date: Tue, 15 May 2012 09:55:27 -0700 Message-ID: To: mrex@sap.com Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkaYOsJ7WTDqHSjufPMbWtkm1WuA+zqtO3a1cDby/zS1Ym84vXZWw2JXi6yP/Z88uc3B0ge Cc: paul.hoffman@vpnc.org, dane@ietf.org Subject: Re: [dane] Behavior in the face of no answer? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 15 May 2012 16:56:09 -0000 On Tue, May 15, 2012 at 9:52 AM, Martin Rex wrote: > And as a fallback, browsers could use a TLSA & server-cert lock, i.e. > memorizing information from the last visit of a site and using that > to perform server endpoint identification in case that DNSSEC lookups > fail when roaming. At which point it's hard to understand how this is better than cert pinning via HSTS. -Ekr From mrex@sap.com Tue May 15 10:04:40 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9294921F88C5 for ; Tue, 15 May 2012 10:04:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.086 X-Spam-Level: X-Spam-Status: No, score=-10.086 tagged_above=-999 required=5 tests=[AWL=0.163, 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 rDXpzEYyjAaV for ; Tue, 15 May 2012 10:04: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 E2F2421F880B for ; Tue, 15 May 2012 10:04:38 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q4FH4aQS001228 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 15 May 2012 19:04:36 +0200 (MEST) From: Martin Rex Message-Id: <201205151704.q4FH4YbT021349@fs4113.wdf.sap.corp> To: ekr@rtfm.com (Eric Rescorla) Date: Tue, 15 May 2012 19:04:34 +0200 (MEST) In-Reply-To: from "Eric Rescorla" at May 15, 12 09:55:27 am 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] Behavior in the face of no answer? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 17:04:41 -0000 Eric Rescorla wrote: > > On Tue, May 15, 2012 at 9:52 AM, Martin Rex wrote: > > And as a fallback, browsers could use a TLSA & server-cert lock, i.e. > > memorizing information from the last visit of a site and using that > > to perform server endpoint identification in case that DNSSEC lookups > > fail when roaming. > > At which point it's hard to understand how this is better than cert pinning > via HSTS. Such a TLSA & server-cert lock is supposed to be transient substitute for the lack of DNSSEC connectivity. That memorized information will need to be updated whenever full DNSSEC connectivity is available. -Martin From ekr@rtfm.com Tue May 15 10:06:28 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D7CD21F89AD for ; Tue, 15 May 2012 10:06:28 -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 xocXF6tRxDB8 for ; Tue, 15 May 2012 10:06:27 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id AE83721F893D for ; Tue, 15 May 2012 10:06:27 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so7633735vbb.31 for ; Tue, 15 May 2012 10:06:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=Wfb2bRPEf8WV5KnQL7OMNkTq0wrfjVIo35HtLvLVBqs=; b=HEIu1Bw5gyTPWsygrtiK3L2Zw8O0Xjw59qmN7i8HAwfKwGgyNZ7u9WGiz00ieM5i6G 5XbBelh5zWm3le0qeXlroVasU7BwEDeUFZtI85MFmtyxttCofvHDU1Ne/f/P0jUKD4UY N7orn4GBKuIalnTJCDV/omlo7HHtPdfWgf9GV8f6kM466Rprh7JdWWFBnBFFI+0SZk91 Fz56auKxrsuFkdTJdmTIL8GrBaxlhnwNIOoUq9wj5ZW4Uo0PZX+Um1TQmwzFKSIguJQG dlgScMUysc3c4pxB8BbtCnAJdWQBs+KOL39SyOy5thEiDZMxyAMi5U9uO/8OsVEUkZLV dTfA== Received: by 10.220.240.73 with SMTP id kz9mr33040vcb.9.1337101586774; Tue, 15 May 2012 10:06:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.35.209 with HTTP; Tue, 15 May 2012 10:05:46 -0700 (PDT) X-Originating-IP: [63.245.220.224] In-Reply-To: <201205151704.q4FH4YbT021349@fs4113.wdf.sap.corp> References: <201205151704.q4FH4YbT021349@fs4113.wdf.sap.corp> From: Eric Rescorla Date: Tue, 15 May 2012 10:05:46 -0700 Message-ID: To: mrex@sap.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnNwiM9w0hDYgzzcM4CP0kOfozLyderW9DZ7CpDEZFx5sH2QCXFbawy5ver11oQHvUWU8lI Cc: paul.hoffman@vpnc.org, dane@ietf.org Subject: Re: [dane] Behavior in the face of no answer? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 15 May 2012 17:06:28 -0000 On Tue, May 15, 2012 at 10:04 AM, Martin Rex wrote: > Eric Rescorla wrote: >> >> On Tue, May 15, 2012 at 9:52 AM, Martin Rex wrote: >> > And as a fallback, browsers could use a TLSA & server-cert lock, i.e. >> > memorizing information from the last visit of a site and using that >> > to perform server endpoint identification in case that DNSSEC lookups >> > fail when roaming. >> >> At which point it's hard to understand how this is better than cert pinn= ing >> via HSTS. > > Such a TLSA & server-cert lock is supposed to be transient substitute for > the lack of DNSSEC connectivity. =A0That memorized information will need > to be updated whenever full DNSSEC connectivity is available. And the HSTS information can be updated whenever you go to the server. -Ekr From mrex@sap.com Tue May 15 10:20:17 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7698B21F8830 for ; Tue, 15 May 2012 10:20:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.087 X-Spam-Level: X-Spam-Status: No, score=-10.087 tagged_above=-999 required=5 tests=[AWL=0.162, 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 C+pM91knVmcj for ; Tue, 15 May 2012 10:20:16 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 8EF1E21F8829 for ; Tue, 15 May 2012 10:20:16 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q4FHKFtK002915 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 15 May 2012 19:20:15 +0200 (MEST) From: Martin Rex Message-Id: <201205151720.q4FHKEpY022449@fs4113.wdf.sap.corp> To: ekr@rtfm.com (Eric Rescorla) Date: Tue, 15 May 2012 19:20:14 +0200 (MEST) In-Reply-To: from "Eric Rescorla" at May 15, 12 10:05:46 am 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] Behavior in the face of no answer? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 17:20:17 -0000 Eric Rescorla wrote: > > On Tue, May 15, 2012 at 10:04 AM, Martin Rex wrote: > > Eric Rescorla wrote: > >> > >> On Tue, May 15, 2012 at 9:52 AM, Martin Rex wrote: > >> > And as a fallback, browsers could use a TLSA & server-cert lock, i.e. > >> > memorizing information from the last visit of a site and using that > >> > to perform server endpoint identification in case that DNSSEC lookups > >> > fail when roaming. > >> > >> At which point it's hard to understand how this is better than cert pinning > >> via HSTS. > > > > Such a TLSA & server-cert lock is supposed to be transient substitute for > > the lack of DNSSEC connectivity.  That memorized information will need > > to be updated whenever full DNSSEC connectivity is available. > > And the HSTS information can be updated whenever you go to the server. In case that you are referring to this: http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security it seems to only convey an indication from the server to the client to use HTTPS rather than HTTP to access the server. DANE/TLSA is supposed to provide an (independent) confirmation from the DNS admin, that the server certificate presented by the server is the *real* one. I somehow fail to see what these two have in common. -Martin From ekr@rtfm.com Tue May 15 10:50:26 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A820B21F86C4 for ; Tue, 15 May 2012 10:50:26 -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 ScpMbRMj9kmj for ; Tue, 15 May 2012 10:50:26 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id E0AE021F86C3 for ; Tue, 15 May 2012 10:50:25 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so7686402vbb.31 for ; Tue, 15 May 2012 10:50:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=KAWjHBIcTVoii0aZgoNalTitfHuJrdzD9YhBLbQfruQ=; b=Tl6Mh2UM7vq9+jAdnQEL/sOuISt58de7iHj+uVPzaplOD5m1w9XjqTDZhV530Ab/h8 A+F2pek5abp+ijYA87Bc2zPeB8SuOyA2eAsbC5StInRnGr11EiciJwNdn7xdmoL5L5Ob DA2o7zQdOTAFsDkvN7tCk+yDjHN3RJONbhhZfuQP4NgREAyL96jKa4BSE9zPo14ovSsp rAlLDb8IGDVYW622Ip2/5K21jXAZRFkVuJBwyvaCzSN/HPRg6BSwxCCb9U0cFUtAWjnr 4D6DLHrxvdRSY1Z+aZOu4vTiZlPeyTZwET9V4FyEyFZDCO6SBR8FfENfeyRJv04DXHxE lf1Q== Received: by 10.52.100.229 with SMTP id fb5mr6162487vdb.102.1337104225370; Tue, 15 May 2012 10:50:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.35.209 with HTTP; Tue, 15 May 2012 10:49:45 -0700 (PDT) X-Originating-IP: [63.245.220.224] In-Reply-To: <201205151720.q4FHKEpY022449@fs4113.wdf.sap.corp> References: <201205151720.q4FHKEpY022449@fs4113.wdf.sap.corp> From: Eric Rescorla Date: Tue, 15 May 2012 10:49:45 -0700 Message-ID: To: mrex@sap.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmeED5Xn4Df2F55nTSwtAKqlgngzCH+kiFb2lmNZcFngmZvtIL+YeSVstTqpRJ7UUqguHT4 Cc: paul.hoffman@vpnc.org, dane@ietf.org Subject: Re: [dane] Behavior in the face of no answer? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 15 May 2012 17:50:26 -0000 On Tue, May 15, 2012 at 10:20 AM, Martin Rex wrote: > Eric Rescorla wrote: >> >> On Tue, May 15, 2012 at 10:04 AM, Martin Rex wrote: >> > Eric Rescorla wrote: >> >> >> >> On Tue, May 15, 2012 at 9:52 AM, Martin Rex wrote: >> >> > And as a fallback, browsers could use a TLSA & server-cert lock, i.= e. >> >> > memorizing information from the last visit of a site and using that >> >> > to perform server endpoint identification in case that DNSSEC looku= ps >> >> > fail when roaming. >> >> >> >> At which point it's hard to understand how this is better than cert p= inning >> >> via HSTS. >> > >> > Such a TLSA & server-cert lock is supposed to be transient substitute = for >> > the lack of DNSSEC connectivity. =A0That memorized information will ne= ed >> > to be updated whenever full DNSSEC connectivity is available. >> >> And the HSTS information can be updated whenever you go to the server. > > In case that you are referring to this: > > =A0http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security http://tools.ietf.org/wg/websec/draft-ietf-websec-key-pinning/ -Ekr From paul.hoffman@vpnc.org Tue May 15 11:32:17 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86F5521F8888 for ; Tue, 15 May 2012 11:32:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.557 X-Spam-Level: X-Spam-Status: No, score=-102.557 tagged_above=-999 required=5 tests=[AWL=0.042, 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 6A-o-eOmTrDx for ; Tue, 15 May 2012 11:32:17 -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 D0F7B21F885C for ; Tue, 15 May 2012 11:32:16 -0700 (PDT) Received: from [10.20.30.102] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q4FIWF7H007851 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 15 May 2012 11:32:16 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Tue, 15 May 2012 11:32:15 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8B30DD88-3AB5-4ED4-BDE6-87E50F60D8D3@vpnc.org> References: <643D87CD-D01E-47B8-82E5-D3F57D50C80B@vpnc.org> To: Eric Rescorla X-Mailer: Apple Mail (2.1278) Cc: dane@ietf.org Subject: Re: [dane] Behavior in the face of no answer? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 15 May 2012 18:32:17 -0000 (Going back a bit in the discussion, using the only wording we have.) On May 14, 2012, at 7:31 PM, Eric Rescorla wrote: > On Mon, May 14, 2012 at 7:12 PM, Paul Hoffman = wrote: >> There doesn't seem to be convergence here, and the WG chairs and AD = have asked the authors to propose wording that might bring consensus. = The following text may be insufficient, but it's the best I can do at = the moment, and if it isn't good enough, having you propose specific = changes may be helpful. >>=20 >> This proposed text tries to pull together: >>=20 >> - Ekr's security analysis >>=20 >> - The desire for a MUST that is likely to be deployed, not ignored >>=20 >> - Acknowledgement that if the user doesn't know TLSA is being used, = they are not losing anything from the attack >>=20 >> (And, yes, I think that the chairs should be doing this bit instead = of Jakob and I. Oh, well.) >>=20 >> An attacker who is able to divert a user to a server under his = control is also >> likely to be able to block DNS requests from the user or DNS = responses being >> sent to the user. Thus, in order to achieve any security benefit from >> certificate usage 0 or 1, an application that sends a request for = TLSA records >> needs to get either a valid signed response containing TLSA records = or >> verification that the domain is insecure or indeterminate. If a = request for a >> TLSA record does not meet one of those two criteria but the = application >> continues with the TLS handshake anyway, the application has gotten = no benefit >> from TLSA and should not make any internal or external indication = that TLSA >> was applied. >=20 > I think this is generally fine, modulo Stephen's concerns about types = 2 and 3, > which I haven't worked through yet. Nor have I, but at least we're sure that we agree on 0 and 1. >> If an application has any indication that TLSA is in use (such as >> through a configuration setting), that application MUST not start a = TLS >> connection or abort a TLS handshake if either of the two criteria = above are >> not met. >=20 > I feel like this is confusing. There are two senses in which TLSA = might > be "in use". (1) The application is trying to retrieve it. (2) The DNS = server > is serving it. We're clearly in the first case, and it's the second = which > is unknown to us b/c under control of the attacker. Perhaps you > mean to say "Applicaions SHOULD offer a setting to allow users to > set strict TLSA checking, in which case..." I don't think people have been talking about suggesting that the = application let the user choose between strict and not-strict; I think = most people here are against that. But I agree that the sentence is = confusing because it makes "configuration setting" a subset of TLSA = indication. Instead of that sentence, I propose: If an application has a configuration setting for turning on TLSA use, or has any indication that TLSA is in use (regardless of whether or not this is configurable), that application MUST not start a TLS connection or abort a TLS handshake if either of the two criteria above = are not met. This does not say "and you might have hard failure configurable", but = instead says "if the user might think that TLSA is in use, you have to = hard fail if they are not getting the security that they might expect". --Paul Hoffman From warren@kumari.net Tue May 15 12:32:10 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E58C721F8866 for ; Tue, 15 May 2012 12:32:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.046 X-Spam-Level: X-Spam-Status: No, score=-106.046 tagged_above=-999 required=5 tests=[AWL=0.553, 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 73vtJc2+qAe5 for ; Tue, 15 May 2012 12:32:09 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 12E3C21F8849 for ; Tue, 15 May 2012 12:32:08 -0700 (PDT) Received: from [192.168.0.12] (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id 20CC71B402F8; Tue, 15 May 2012 15:32:08 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: Warren Kumari In-Reply-To: <8B30DD88-3AB5-4ED4-BDE6-87E50F60D8D3@vpnc.org> Date: Tue, 15 May 2012 15:32:44 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <643D87CD-D01E-47B8-82E5-D3F57D50C80B@vpnc.org> <8B30DD88-3AB5-4ED4-BDE6-87E50F60D8D3@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1257) Cc: dane@ietf.org Subject: Re: [dane] Behavior in the face of no answer? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 15 May 2012 19:32:10 -0000 On May 15, 2012, at 2:32 PM, Paul Hoffman wrote: > (Going back a bit in the discussion, using the only wording we have.) Thank you -- and I ask that if folk are unhappy with the current wording = they propose alternate. Simply grumping (and repeating yourself) isn't = nearly as effective at communicating what you actually *mean* as = providing suitable text... =20 >=20 > On May 14, 2012, at 7:31 PM, Eric Rescorla wrote: >=20 >> On Mon, May 14, 2012 at 7:12 PM, Paul Hoffman = wrote: >>> There doesn't seem to be convergence here, and the WG chairs and AD = have asked the authors to propose wording that might bring consensus. = The following text may be insufficient, but it's the best I can do at = the moment, and if it isn't good enough, having you propose specific = changes may be helpful. >>>=20 >>> This proposed text tries to pull together: >>>=20 >>> - Ekr's security analysis >>>=20 >>> - The desire for a MUST that is likely to be deployed, not ignored >>>=20 >>> - Acknowledgement that if the user doesn't know TLSA is being used, = they are not losing anything from the attack >>>=20 >>> (And, yes, I think that the chairs should be doing this bit instead = of Jakob and I. Oh, well.) >>>=20 >>> An attacker who is able to divert a user to a server under his = control is also >>> likely to be able to block DNS requests from the user or DNS = responses being >>> sent to the user. Thus, in order to achieve any security benefit = from >>> certificate usage 0 or 1, an application that sends a request for = TLSA records >>> needs to get either a valid signed response containing TLSA records = or >>> verification that the domain is insecure or indeterminate. If a = request for a >>> TLSA record does not meet one of those two criteria but the = application >>> continues with the TLS handshake anyway, the application has gotten = no benefit >>> from TLSA and should not make any internal or external indication = that TLSA >>> was applied. >>=20 >> I think this is generally fine, modulo Stephen's concerns about types = 2 and 3, >> which I haven't worked through yet. >=20 > Nor have I, but at least we're sure that we agree on 0 and 1. >=20 >>> If an application has any indication that TLSA is in use (such as >>> through a configuration setting), that application MUST not start a = TLS >>> connection or abort a TLS handshake if either of the two criteria = above are >>> not met. >>=20 >> I feel like this is confusing. There are two senses in which TLSA = might >> be "in use". (1) The application is trying to retrieve it. (2) The = DNS server >> is serving it. We're clearly in the first case, and it's the second = which >> is unknown to us b/c under control of the attacker. Perhaps you >> mean to say "Applicaions SHOULD offer a setting to allow users to >> set strict TLSA checking, in which case..." >=20 > I don't think people have been talking about suggesting that the = application let the user choose between strict and not-strict; I think = most people here are against that. This may be my fault -- a long time back (in this thread) I proposed = having implmentations default to not-strict and then, in a few years = (once there is less DNSSEC breakage by CPE, etc), vendors would turn the = knob to strict mode. Educated / security concious users would also be = able to turn the knob if they so desired. This was just an idea, and perhaps a bad one! > But I agree that the sentence is confusing because it makes = "configuration setting" a subset of TLSA indication. Instead of that = sentence, I propose: >=20 > If an application has a configuration setting for turning on TLSA use, > or has any indication that TLSA is in use (regardless of whether or = not > this is configurable), that application MUST not start a TLS > connection or abort a TLS handshake if either of the two criteria = above are > not met. >=20 > This does not say "and you might have hard failure configurable", but = instead says "if the user might think that TLSA is in use, you have to = hard fail if they are not getting the security that they might expect". This sounds good to me, but what does the user do in this case? Simply = remove the s from https:// (assuming a browser)? Do we need to mention = anything, or leave this up to the application? There is already stuff = like HSTS / web sec, etc for this=85 Yes, I should be proposing text here, but I'm not really taking a stand, = rather trying to get feedback... W >=20 > --Paul Hoffman >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane >=20 From nweaver@icsi.berkeley.edu Tue May 15 12:57:27 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D8B921F867C for ; Tue, 15 May 2012 12:57:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.477 X-Spam-Level: X-Spam-Status: No, score=-2.477 tagged_above=-999 required=5 tests=[AWL=0.122, 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 O-zMdHyrBcab for ; Tue, 15 May 2012 12:57:26 -0700 (PDT) Received: from rock.ICSI.Berkeley.EDU (rock.ICSI.Berkeley.EDU [192.150.186.19]) by ietfa.amsl.com (Postfix) with ESMTP id ECAF221F8648 for ; Tue, 15 May 2012 12:57:26 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id E33332C4019; Tue, 15 May 2012 12:57:26 -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 fwUihJ5dnDnZ; Tue, 15 May 2012 12:57:26 -0700 (PDT) Received: from gala.icir.org (gala [192.150.187.49]) (Authenticated sender: nweaver) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id A81492C4002; Tue, 15 May 2012 12:57:26 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: Nicholas Weaver In-Reply-To: Date: Tue, 15 May 2012 12:57:26 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0A5761EE-24D2-4D75-8F9B-5F8AF3B54C61@icsi.berkeley.edu> References: <643D87CD-D01E-47B8-82E5-D3F57D50C80B@vpnc.org> <8B30DD88-3AB5-4ED4-BDE6-87E50F60D8D3@vpnc.org> To: Warren Kumari X-Mailer: Apple Mail (2.1257) Cc: Paul Hoffman , dane@ietf.org Subject: Re: [dane] Behavior in the face of no answer? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 15 May 2012 19:57:27 -0000 On May 15, 2012, at 12:32 PM, Warren Kumari wrote: > This may be my fault -- a long time back (in this thread) I proposed = having implmentations default to not-strict and then, in a few years = (once there is less DNSSEC breakage by CPE, etc), vendors would turn the = knob to strict mode. Educated / security concious users would also be = able to turn the knob if they so desired. >=20 > This was just an idea, and perhaps a bad one! CPE bugs should be regarded as "Forever Day". Instead, any client-side DNSSEC application must take pains to both map = the brokenness and be prepared to work around it, including: bypassing = the configured recursive resolver to use a DNSSEC passing external = resolver or just fetching directly, switching to TCP, and even = connecting to DNSSEC passing resolvers which are configured to use a = non-standard port. From warren@kumari.net Tue May 15 13:00:41 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92A4B21F87EA for ; Tue, 15 May 2012 13:00:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.07 X-Spam-Level: X-Spam-Status: No, score=-106.07 tagged_above=-999 required=5 tests=[AWL=0.529, 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 l3Gkl+BH+p5r for ; Tue, 15 May 2012 13:00:41 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 1669F21F8781 for ; Tue, 15 May 2012 13:00:41 -0700 (PDT) Received: from [192.168.0.12] (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id 499E91B402F8; Tue, 15 May 2012 16:00:35 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: Warren Kumari In-Reply-To: <0A5761EE-24D2-4D75-8F9B-5F8AF3B54C61@icsi.berkeley.edu> Date: Tue, 15 May 2012 16:01:11 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <9846723D-F255-480B-A014-5CAA95FC365F@kumari.net> References: <643D87CD-D01E-47B8-82E5-D3F57D50C80B@vpnc.org> <8B30DD88-3AB5-4ED4-BDE6-87E50F60D8D3@vpnc.org> <0A5761EE-24D2-4D75-8F9B-5F8AF3B54C61@icsi.berkeley.edu> To: Nicholas Weaver X-Mailer: Apple Mail (2.1257) Cc: Paul Hoffman , dane@ietf.org Subject: Re: [dane] Behavior in the face of no answer? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 15 May 2012 20:00:41 -0000 On May 15, 2012, at 3:57 PM, Nicholas Weaver wrote: >=20 > On May 15, 2012, at 12:32 PM, Warren Kumari wrote: >> This may be my fault -- a long time back (in this thread) I proposed = having implmentations default to not-strict and then, in a few years = (once there is less DNSSEC breakage by CPE, etc), vendors would turn the = knob to strict mode. Educated / security concious users would also be = able to turn the knob if they so desired. >>=20 >> This was just an idea, and perhaps a bad one! >=20 > CPE bugs should be regarded as "Forever Day". Yes, there are likely to be broken CPE for a really long time, but a: = the percentage should be dropping over time (years) and b: other = brokenness should also be decreasing over time. >=20 > Instead, any client-side DNSSEC application must take pains to both = map the brokenness and be prepared to work around it, including: = bypassing the configured recursive resolver to use a DNSSEC passing = external resolver or just fetching directly, switching to TCP, and even = connecting to DNSSEC passing resolvers which are configured to use a = non-standard port. These are all options, but way outside of what we can (or should) = describe in this document=85 W= From mrex@sap.com Tue May 15 13:08:56 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B507011E8072 for ; Tue, 15 May 2012 13:08:56 -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 QTcUov+LFF1j for ; Tue, 15 May 2012 13:08: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 E331C11E80A3 for ; Tue, 15 May 2012 13:08:55 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q4FK8sdN022621 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 15 May 2012 22:08:54 +0200 (MEST) From: Martin Rex Message-Id: <201205152008.q4FK8rAx001987@fs4113.wdf.sap.corp> To: ekr@rtfm.com (Eric Rescorla) Date: Tue, 15 May 2012 22:08:53 +0200 (MEST) In-Reply-To: from "Eric Rescorla" at May 15, 12 10:05:46 am 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] Behavior in the face of no answer? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 20:08:56 -0000 Eric Rescorla wrote: > > On Tue, May 15, 2012 at 10:04 AM, Martin Rex wrote: > > Eric Rescorla wrote: > >> > >> On Tue, May 15, 2012 at 9:52 AM, Martin Rex wrote: > >> > And as a fallback, browsers could use a TLSA & server-cert lock, i.e. > >> > memorizing information from the last visit of a site and using that > >> > to perform server endpoint identification in case that DNSSEC lookups > >> > fail when roaming. > >> > >> At which point it's hard to understand how this is better than cert pinning > >> via HSTS. > > > > Such a TLSA & server-cert lock is supposed to be transient substitute for > > the lack of DNSSEC connectivity.  That memorized information will need > > to be updated whenever full DNSSEC connectivity is available. > > And the HSTS information can be updated whenever you go to the server. But the HSTS has a clear hen-and-edd problem: You can _only_ get updates when the verification based on the previous information is still possible, otherwise your browser will not establish the communication channel that is a pre-requisite to obtain the updated information. To me it looks like it will be pretty easy to lock yourself out, since you have no influence about how frequently the client accesses a site. (that is like replicating the DNS root key rollover problem for every single site). -Martin From ekr@rtfm.com Tue May 15 13:25:29 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6DBB21F86CA for ; Tue, 15 May 2012 13:25:29 -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 YQjImnDSI7U6 for ; Tue, 15 May 2012 13:25:29 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3891021F8829 for ; Tue, 15 May 2012 13:25:29 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so4185vbb.31 for ; Tue, 15 May 2012 13:25:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=TRH7YOh4cqvndSXDqIQyQm5hwbJNUc+q97LXWXNKDqk=; b=N+96mUBTaurgp6cdAbnpmXO+iYL1NRZXCEVWSXvSZK4eAvTVItaaEvVtYNG6x9htx8 ylZPDNXKTdc4r3YALyEqBTMR7bKd6yi9SZH5C3o9mnMO+SdFK9HXoEij5B7kziiyGI2/ uPBi9dynM4JD+oA8Ok6mbVodN478PGiLs1KLHmfDJ3WZMMaQhNw2/cpRD2zkxqMeB7ig f0vjjssRP7rB0WlTVqwjjIQVBntjFGFohhDMdcHZQv3c0XqSEpovKw02b/F0Cnf+NJj/ Y6B/gVs/xgbbXwa3pKfRy2smEt6222GFK/a1E/qhLWBVqSSbGMS/ggJF+gbkcyKy5aK+ J9UQ== Received: by 10.220.150.148 with SMTP id y20mr243478vcv.26.1337113528594; Tue, 15 May 2012 13:25:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.35.209 with HTTP; Tue, 15 May 2012 13:24:48 -0700 (PDT) X-Originating-IP: [63.245.220.224] In-Reply-To: <201205152008.q4FK8rAx001987@fs4113.wdf.sap.corp> References: <201205152008.q4FK8rAx001987@fs4113.wdf.sap.corp> From: Eric Rescorla Date: Tue, 15 May 2012 13:24:48 -0700 Message-ID: To: mrex@sap.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQklH032+8HjNrsZZqOdD/fVHmhTZ3I8JgktvP3e09lznEj4E/gA6T5JzS2I7MFxNIHVKf3M Cc: paul.hoffman@vpnc.org, dane@ietf.org Subject: Re: [dane] Behavior in the face of no answer? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 15 May 2012 20:25:29 -0000 On Tue, May 15, 2012 at 1:08 PM, Martin Rex wrote: > Eric Rescorla wrote: >> >> On Tue, May 15, 2012 at 10:04 AM, Martin Rex wrote: >> > Eric Rescorla wrote: >> >> >> >> On Tue, May 15, 2012 at 9:52 AM, Martin Rex wrote: >> >> > And as a fallback, browsers could use a TLSA & server-cert lock, i.= e. >> >> > memorizing information from the last visit of a site and using that >> >> > to perform server endpoint identification in case that DNSSEC looku= ps >> >> > fail when roaming. >> >> >> >> At which point it's hard to understand how this is better than cert p= inning >> >> via HSTS. >> > >> > Such a TLSA & server-cert lock is supposed to be transient substitute = for >> > the lack of DNSSEC connectivity. =A0That memorized information will ne= ed >> > to be updated whenever full DNSSEC connectivity is available. >> >> And the HSTS information can be updated whenever you go to the server. > > But the HSTS has a clear hen-and-edd problem: =A0You can _only_ get updat= es > when the verification based on the previous information is still possible= , > otherwise your browser will not establish the communication channel that > is a pre-requisite to obtain the updated information. > > To me it looks like it will be pretty easy to lock yourself out, since > you have no influence about how frequently the client accesses a site. 1. The pins expire, so you advertise both old and new pins (but continue to use the old key) until all old pins have expired. 2. There are techniques for breaking the pin. I'm not suggesting that this draft is perfect, but really these are fairly obvious objections that have been discussed extensively in websec. -Ekr From warren@kumari.net Tue May 15 13:28:41 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91F2A21F8891 for ; Tue, 15 May 2012 13:28:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.092 X-Spam-Level: X-Spam-Status: No, score=-106.092 tagged_above=-999 required=5 tests=[AWL=0.507, 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 Wx5lhh8idBYJ for ; Tue, 15 May 2012 13:28:41 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id ECFA321F8850 for ; Tue, 15 May 2012 13:28:40 -0700 (PDT) Received: from [192.168.0.12] (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id 37DCB1B402F8; Tue, 15 May 2012 16:28:40 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: Warren Kumari In-Reply-To: Date: Tue, 15 May 2012 16:29:16 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201205152008.q4FK8rAx001987@fs4113.wdf.sap.corp> To: Eric Rescorla X-Mailer: Apple Mail (2.1257) Cc: paul.hoffman@vpnc.org, dane@ietf.org Subject: Re: [dane] Behavior in the face of no answer? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 15 May 2012 20:28:41 -0000 On May 15, 2012, at 4:24 PM, Eric Rescorla wrote: > On Tue, May 15, 2012 at 1:08 PM, Martin Rex wrote: >> Eric Rescorla wrote: >>>=20 >>> On Tue, May 15, 2012 at 10:04 AM, Martin Rex wrote: >>>> Eric Rescorla wrote: >>>>>=20 >>>>> On Tue, May 15, 2012 at 9:52 AM, Martin Rex wrote: >>>>>> And as a fallback, browsers could use a TLSA & server-cert lock, = i.e. >>>>>> memorizing information from the last visit of a site and using = that >>>>>> to perform server endpoint identification in case that DNSSEC = lookups >>>>>> fail when roaming. >>>>>=20 >>>>> At which point it's hard to understand how this is better than = cert pinning >>>>> via HSTS. >>>>=20 >>>> Such a TLSA & server-cert lock is supposed to be transient = substitute for >>>> the lack of DNSSEC connectivity. That memorized information will = need >>>> to be updated whenever full DNSSEC connectivity is available. >>>=20 >>> And the HSTS information can be updated whenever you go to the = server. >>=20 >> But the HSTS has a clear hen-and-edd problem: You can _only_ get = updates >> when the verification based on the previous information is still = possible, >> otherwise your browser will not establish the communication channel = that >> is a pre-requisite to obtain the updated information. >>=20 >> To me it looks like it will be pretty easy to lock yourself out, = since >> you have no influence about how frequently the client accesses a = site. >=20 > 1. The pins expire, so you advertise both old and new pins (but = continue > to use the old key) until all old pins have expired. > 2. There are techniques for breaking the pin. >=20 > I'm not suggesting that this draft is perfect, but really these are > fairly obvious > objections that have been discussed extensively in web sec. Agreed, and if folk would like to object further, I'd suggest: 1: *reading* the docs and discussions in web sec and then, if you still = have a beef,=20 2: taking the discussion to web sec=85 W >=20 > -Ekr > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane >=20 From warren@kumari.net Tue May 15 13:28:49 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48B7611E80BA for ; Tue, 15 May 2012 13:28:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.112 X-Spam-Level: X-Spam-Status: No, score=-106.112 tagged_above=-999 required=5 tests=[AWL=0.487, 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 riSihdzCF0ty for ; Tue, 15 May 2012 13:28:48 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 83C7811E80B6 for ; Tue, 15 May 2012 13:28:48 -0700 (PDT) Received: from [192.168.0.12] (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id C0A3F1B402F8; Tue, 15 May 2012 16:28:47 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: Warren Kumari In-Reply-To: <8B30DD88-3AB5-4ED4-BDE6-87E50F60D8D3@vpnc.org> Date: Tue, 15 May 2012 16:29:25 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <9411A21C-7CE4-4E99-88A5-834DF04476FD@kumari.net> References: <643D87CD-D01E-47B8-82E5-D3F57D50C80B@vpnc.org> <8B30DD88-3AB5-4ED4-BDE6-87E50F60D8D3@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1257) Cc: dane@ietf.org Subject: Re: [dane] Behavior in the face of no answer? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 15 May 2012 20:28:49 -0000 On May 15, 2012, at 2:32 PM, Paul Hoffman wrote: > (Going back a bit in the discussion, using the only wording we have.) >=20 > On May 14, 2012, at 7:31 PM, Eric Rescorla wrote: >=20 >> On Mon, May 14, 2012 at 7:12 PM, Paul Hoffman = wrote: >>> There doesn't seem to be convergence here, and the WG chairs and AD = have asked the authors to propose wording that might bring consensus. = The following text may be insufficient, but it's the best I can do at = the moment, and if it isn't good enough, having you propose specific = changes may be helpful. >>>=20 >>> This proposed text tries to pull together: >>>=20 >>> - Ekr's security analysis >>>=20 >>> - The desire for a MUST that is likely to be deployed, not ignored >>>=20 >>> - Acknowledgement that if the user doesn't know TLSA is being used, = they are not losing anything from the attack >>>=20 >>> (And, yes, I think that the chairs should be doing this bit instead = of Jakob and I. Oh, well.) >>>=20 >>> An attacker who is able to divert a user to a server under his = control is also >>> likely to be able to block DNS requests from the user or DNS = responses being >>> sent to the user. Thus, in order to achieve any security benefit = from >>> certificate usage 0 or 1, an application that sends a request for = TLSA records >>> needs to get either a valid signed response containing TLSA records = or >>> verification that the domain is insecure or indeterminate. If a = request for a >>> TLSA record does not meet one of those two criteria but the = application >>> continues with the TLS handshake anyway, the application has gotten = no benefit >>> from TLSA and should not make any internal or external indication = that TLSA >>> was applied. >>=20 >> I think this is generally fine, modulo Stephen's concerns about types = 2 and 3, >> which I haven't worked through yet. >=20 > Nor have I, but at least we're sure that we agree on 0 and 1. >=20 >>> If an application has any indication that TLSA is in use (such as >>> through a configuration setting), that application MUST not start a = TLS >>> connection or abort a TLS handshake if either of the two criteria = above are >>> not met. >>=20 >> I feel like this is confusing. There are two senses in which TLSA = might >> be "in use". (1) The application is trying to retrieve it. (2) The = DNS server >> is serving it. We're clearly in the first case, and it's the second = which >> is unknown to us b/c under control of the attacker. Perhaps you >> mean to say "Applicaions SHOULD offer a setting to allow users to >> set strict TLSA checking, in which case..." >=20 > I don't think people have been talking about suggesting that the = application let the user choose between strict and not-strict; I think = most people here are against that. But I agree that the sentence is = confusing because it makes "configuration setting" a subset of TLSA = indication. Instead of that sentence, I propose: >=20 > If an application has a configuration setting for turning on TLSA use, > or has any indication that TLSA is in use (regardless of whether or = not > this is configurable), that application MUST not start a TLS > connection or abort a TLS handshake if either of the two criteria = above are > not met. >=20 > This does not say "and you might have hard failure configurable", but = instead says "if the user might think that TLSA is in use, you have to = hard fail if they are not getting the security that they might expect". Does anyone have any *specific* updates to this text that they would = like to provide? Can you live with this text (note: I didn't say "Are you infinitely = happy with this text", just "Can you live with"=85)=20 W >=20 > --Paul Hoffman >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane >=20 From gnu@toad.com Tue May 15 18:16:31 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 876C521F8757 for ; Tue, 15 May 2012 18:16:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.363 X-Spam-Level: X-Spam-Status: No, score=0.363 tagged_above=-999 required=5 tests=[AWL=0.266, BAYES_00=-2.599, RCVD_IN_NJABL_RELAY=2.696] 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 G3M493NgBo65 for ; Tue, 15 May 2012 18:16:30 -0700 (PDT) Received: from new.toad.com (new.toad.com [209.237.225.253]) by ietfa.amsl.com (Postfix) with ESMTP id C545921F86E8 for ; Tue, 15 May 2012 18:16:30 -0700 (PDT) Received: from new.toad.com (localhost.localdomain [127.0.0.1]) by new.toad.com (8.12.9/8.12.9) with ESMTP id q4G1GTcF015332; Tue, 15 May 2012 18:16:29 -0700 Message-Id: <201205160116.q4G1GTcF015332@new.toad.com> To: Paul Hoffman In-reply-to: <643D87CD-D01E-47B8-82E5-D3F57D50C80B@vpnc.org> References: <643D87CD-D01E-47B8-82E5-D3F57D50C80B@vpnc.org> Comments: In-reply-to Paul Hoffman message dated "Mon, 14 May 2012 19:12:23 -0700." Date: Tue, 15 May 2012 18:16:29 -0700 From: John Gilmore Cc: dane@ietf.org Subject: Re: [dane] Behavior in the face of no answer? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 16 May 2012 01:16:31 -0000 Here's my review of the text Paul Hoffman posted Monday 14 May 19:12:23: > An attacker who is able to divert a user to a server under his control is also > likely to be able to block DNS requests from the user or DNS responses being > sent to the user. Thus, in order to achieve any security benefit from > certificate usage 0 or 1, an application that sends a request for TLSA records > needs to get either a valid signed response containing TLSA records or > verification that the domain is insecure or indeterminate. If a request for a > TLSA record does not meet one of those two criteria but the application > continues with the TLS handshake anyway, the application has gotten no benefit > from TLSA and should not make any internal or external indication that TLSA > was applied. If an application has any indication that TLSA is in use (such as > through a configuration setting), that application MUST not start a TLS > connection or abort a TLS handshake if either of the two criteria above are > not met. An attacker who is able to divert a user to a server under his control is also likely to be able to block DNS requests from the user or DNS responses being sent to the user. Thus, in order to achieve any security benefit from certificate usage 0 or 1, the protocol requires that when DNS responses have not arrived or are not valid, the TLS connection must not succeed. To proceed with a DANE TLSA transaction, an application MUST get either a Secure response containing TLSA records for the relevant domain name, a Secure response proving that there are no TLSA records for the relevant domain name, or verification that the domain name is Insecure. (Secure and Insecure are defined in section 4.3 of RFC 4035.) If the response(s) from a TLSA record query do not meet any of the above criteria, but the application continues with the TLS handshake anyway, the application is in violation of this protocol specification. It MUST NOT make any internal or external indication that the DANE TLSA protocol is in effect. If an application has any indication that the DANE TLSA protocol is in use (such as through a configuration setting), that application MUST NOT start a TLS connection, and MUST abort any pending TLS handshake, if none of the criteria in the previous paragraph are not met. (End of text for somewhere in RFC.) It isn't clear where in the RFC this text would go. Some of it seems to be explanatory and other parts seem to be normative. My comments are that this text is not usable, even after my modifications. It chats about motivations. It tries to define a protocol specification, saying what the application should do to follow that spec. It then says "if you violate this spec in this particular way, don't call it DANE TLSA". Then it says that twice, or three times. I don't see the point of that. If they violate the spec in any other way, they shouldn't call it DANE TLSA either. I would remove the last paragraph entirely. I would move the first paragraph off into a security-related section. I'd keep the short paragraph beginning "To proceed with a DANE TLSA transaction,". I think it's progress to have text that defines the VALID ways to proceed with the protocol, rather than getting lost in the weeds of all the possible INVALID ways to fail. John From gnu@toad.com Tue May 15 18:24:19 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C69521F86A0 for ; Tue, 15 May 2012 18:24:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.349 X-Spam-Level: X-Spam-Status: No, score=0.349 tagged_above=-999 required=5 tests=[AWL=0.252, BAYES_00=-2.599, RCVD_IN_NJABL_RELAY=2.696] 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 TUuOxYfmwNDb for ; Tue, 15 May 2012 18:24:19 -0700 (PDT) Received: from new.toad.com (new.toad.com [209.237.225.253]) by ietfa.amsl.com (Postfix) with ESMTP id 0F68C21F863C for ; Tue, 15 May 2012 18:24:19 -0700 (PDT) Received: from new.toad.com (localhost.localdomain [127.0.0.1]) by new.toad.com (8.12.9/8.12.9) with ESMTP id q4G1OIcF015532; Tue, 15 May 2012 18:24:18 -0700 Message-Id: <201205160124.q4G1OIcF015532@new.toad.com> To: John Gilmore In-reply-to: <201205160116.q4G1GTcF015332@new.toad.com> References: <643D87CD-D01E-47B8-82E5-D3F57D50C80B@vpnc.org> <201205160116.q4G1GTcF015332@new.toad.com> Comments: In-reply-to John Gilmore message dated "Tue, 15 May 2012 18:16:29 -0700." Date: Tue, 15 May 2012 18:24:18 -0700 From: John Gilmore Cc: Paul Hoffman , dane@ietf.org Subject: Re: [dane] Behavior in the face of no answer? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 16 May 2012 01:24:19 -0000 > responses being sent to the user. Thus, in order to achieve any > security benefit from certificate usage 0 or 1, the protocol requires > that when DNS responses have not arrived or are not valid, the TLS > connection must not succeed. It's easy for a Man in the Middle to subvert cert usage 3 this way too. They just issue themselves a cert signed by some subverted public CA, block your TLSA DNS responses, and then if you proceed with TLS, you'll accept the key signed by the subverted public CA, since you never saw the record that says "This server is secured by THIS PUBLIC KEY RIGHT HERE, and not anything else." This attack also works against cert usage 2. Thus I'm not sure why this proposed graf even mentions cert usages 0 and 1, except perhaps to remind the PKIX fans among us that proceeding in the face of DNS blockage causes even their favorite forms of TLSA to be vulnerable. Thus I'd revise that text (for a security section somewhere) to: An attacker who is able to divert a user to a server under his control is also likely to be able to block DNS requests from the user or DNS responses being sent to the user. Thus, in order to achieve any security benefit from DANE TLSA, the protocol requires that when DNS responses have not arrived or are not valid, the TLS connection must not succeed. John From gnu@toad.com Tue May 15 19:13:23 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FA5411E80AF for ; Tue, 15 May 2012 19:13:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.337 X-Spam-Level: X-Spam-Status: No, score=0.337 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599, RCVD_IN_NJABL_RELAY=2.696] 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 oRBkAKhdxcR6 for ; Tue, 15 May 2012 19:13:23 -0700 (PDT) Received: from new.toad.com (new.toad.com [209.237.225.253]) by ietfa.amsl.com (Postfix) with ESMTP id F3C5211E8095 for ; Tue, 15 May 2012 19:13:22 -0700 (PDT) Received: from new.toad.com (localhost.localdomain [127.0.0.1]) by new.toad.com (8.12.9/8.12.9) with ESMTP id q4G2DGcF017008; Tue, 15 May 2012 19:13:16 -0700 Message-Id: <201205160213.q4G2DGcF017008@new.toad.com> To: Paul Wouters In-reply-to: References: <643D87CD-D01E-47B8-82E5-D3F57D50C80B@vpnc.org> <20120515112154.GA20521@mail.yitter.info> Comments: In-reply-to Paul Wouters message dated "Tue, 15 May 2012 08:19:24 -0400." Date: Tue, 15 May 2012 19:13:16 -0700 From: John Gilmore Cc: dane@ietf.org Subject: [dane] Network errors ARE attacks - on the end-to-end-principle X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 16 May 2012 02:13:23 -0000 > But it's better then disabling TLSA at all in the face > of DNS errors (where we assume most errors are genuine network errors > and not attacks). "Genuine network errors" from buggy proxies or intentional firewalls or intentional or accidental censorship systems ARE attacks. They are attacks on the fundamental end-to-end premise of the Internet. The default state of the networking world, pre-Internet, is that network providers felt free to block or modify data in transit, for their own convenience, profit, whim, or by accident. They'd control what services you could access, what channels you could watch, etc, etc, etc. It was assumed that the owner of the communications channel had every right and every business reason to limit who you were allowed to talk to, and on what topics. The Internet changed all that, making it clear what a huge benefit the public could derive from a system that delivered end-users' data end-to-end, unmodified, from anywhere, to anywhere. Finally you could access YOUR CHOICE of data and services from anywhere -- not "this service is only available on France Telecom's Teletext system" and "You can't email that guy because he's on MCI Mail and you're on The Source". Now that Moore's Law's newly available crunchons enabled today's complex radio modulations and equally complex presentation protocols, you can get all those same services wirelessly, instead of what the incumbent providers kept designing over and over ("You can only get this WAP-based information service on AT&T mobile phones" and "To watch this TV show that you've already paid for, you have to be physically plugged into this coaxial cable.") Since the public rise of the Internet in the '90s was not cryptographically secured end-to-end, providers eventually realized that they could somewhat go back to their old ways of messing with end-users' data for their own convenience, profit, whim, or by accident. Like Comcast blocking BitTorrent traffic by forging RST packets, AT&T Mobile deliberately dropping packets when it had the capacity to carry them, just to discourage "unlimited" usage, or certain carriers declining to carry packets for "over the top" video. Or shipping buggy DNS proxies that mess up Port 53 UDP traffic in their subnet. Most users didn't notice, which allowed the providers to often get away with censoring the ones who did notice. DNSSEC and DANE are just part of the leading edge of a trend to secure Internet traffic end-to-end. This will make more such blockages and modifications much more apparent -- turning them from possibly-unnoticed inconveniences into denial-of-service failures. But the end result will be that (1) users will realize they are being censored; (2) providers will clean up the accidental and whim-related censorship; and (3) users will migrate to providers who offer them reliable end-to-end service without interruptions for the provider's convenience or profit. And in that way, the Internet will route around these attacks on the end-to-end principle. This is a good thing, despite the distributed pain involved in fixing all those broken devices and misguided providers. John From marka@isc.org Tue May 15 19:15:19 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 154CC11E80B5 for ; Tue, 15 May 2012 19:15:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.115 X-Spam-Level: X-Spam-Status: No, score=-2.115 tagged_above=-999 required=5 tests=[AWL=0.484, 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 N4Be3KUbuMj9 for ; Tue, 15 May 2012 19:15:18 -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 51CF911E8095 for ; Tue, 15 May 2012 19:15:18 -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 "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id 7C99A5F9A30; Wed, 16 May 2012 02:15:03 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:210b:6ab2:ca5:2c98]) (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 6E9CE216C33; Wed, 16 May 2012 02:15:01 +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 6E54A20A8104; Wed, 16 May 2012 12:14:59 +1000 (EST) To: mrex@sap.com From: Mark Andrews References: <201205151652.q4FGqFZP020706@fs4113.wdf.sap.corp> In-reply-to: Your message of "Tue, 15 May 2012 18:52:15 +0200." <201205151652.q4FGqFZP020706@fs4113.wdf.sap.corp> Date: Wed, 16 May 2012 12:14:59 +1000 Message-Id: <20120516021459.6E54A20A8104@drugs.dv.isc.org> Cc: paul.hoffman@vpnc.org, dane@ietf.org Subject: Re: [dane] Behavior in the face of no answer? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 16 May 2012 02:15:19 -0000 In message <201205151652.q4FGqFZP020706@fs4113.wdf.sap.corp>, Martin Rex writes : > Eric Rescorla wrote: > > > > > If an application has any indication that TLSA is in use (such as > > > through a configuration setting), that application MUST not start a TLS > > > connection or abort a TLS handshake if either of the two criteria above a > re > > > not met. > > > > I feel like this is confusing. There are two senses in which TLSA might > > be "in use". (1) The application is trying to retrieve it. (2) The DNS serv > er > > is serving it. We're clearly in the first case, and it's the second which > > is unknown to us b/c under control of the attacker. Perhaps you > > mean to say "Applicaions SHOULD offer a setting to allow users to > > set strict TLSA checking, in which case..." > > Similar to OCSP, any hard-fail requirement is going to create a > significant usability issue, and at worst, cause users to fallback > from a HTTPS-but-not-DANE-verifiable URL for a login page to > a plain HTTP login page -- which is making things *MUCH* worse. No. It is NOT similar to OCSP. OSCP answers come from somewhere else. For 99.99% of TLSA answers they come from the *same* zone as the address/CNAME/SRV records of the server you are connecting to. If you can get one you should to 99.99% be able to get the answer to the other. If you get a answer to the address query but not the TLSA query you will almost certainly have a broken DNS proxy and if I was a web browser vendor I would be putting up a big message saying: You appear to have a broken DNS proxy. Please contact you DNS proxy vendor for a fix. For more information click hear: http://browser.vendor/broken_DNS_proxy.html > I do not believe in DANE hard-fail without a DNSSEC records stapling > TLS extension (similar to the OCSP stapling TLS extension). > > And as a fallback, browsers could use a TLSA & server-cert lock, i.e. > memorizing information from the last visit of a site and using that > to perform server endpoint identification in case that DNSSEC lookups > fail when roaming. > > > -Martin > > _______________________________________________ > 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 gnu@toad.com Tue May 15 19:45:41 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B931A11E80CE for ; Tue, 15 May 2012 19:45:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.326 X-Spam-Level: X-Spam-Status: No, score=0.326 tagged_above=-999 required=5 tests=[AWL=0.229, BAYES_00=-2.599, RCVD_IN_NJABL_RELAY=2.696] 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 QNBGJz-F2caQ for ; Tue, 15 May 2012 19:45:40 -0700 (PDT) Received: from new.toad.com (new.toad.com [209.237.225.253]) by ietfa.amsl.com (Postfix) with ESMTP id 5A25021F86B0 for ; Tue, 15 May 2012 19:45:40 -0700 (PDT) Received: from new.toad.com (localhost.localdomain [127.0.0.1]) by new.toad.com (8.12.9/8.12.9) with ESMTP id q4G2jecF018863 for ; Tue, 15 May 2012 19:45:40 -0700 Message-Id: <201205160245.q4G2jecF018863@new.toad.com> To: dane@ietf.org In-reply-to: <20120513175839.GA8350@odin.ulthar.us> References: <201204121903.q3CJ3ucF026698@new.toad.com> <9605FDF6-096D-4159-96A6-16549E8371AB@nic.cz> <20120504031222.GA6541@odin.ulthar.us> <2354EF03-D8D0-49AD-BD99-BA6AD2616FE6@nic.cz> <20120509115626.GA31105@odin.ulthar.us> <20120513175839.GA8350@odin.ulthar.us> Comments: In-reply-to Scott Schmit message dated "Sun, 13 May 2012 13:58:39 -0400." Date: Tue, 15 May 2012 19:45:40 -0700 From: John Gilmore Subject: Re: [dane] Inappropriate Section 8 of draft-ietf-dane-protocol-19.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 02:45:41 -0000 Scott Schmit proposed: > This is intended to replace the -20 section 8.1: I tried to interact off-list with Scott on this text over the weekend, but he was apparently unable to receive emails from me. (They may be in his spam folder -- or may just have been thrown away by his email provider.) Luckily, the IETF mailing lists aren't censoring their incoming email, and Scott's provider's likely email censorship is almost certainly based on shooting the messenger, not the message -- thus you-all and Scott can see *this* message. Unfortunately I don't have finished text to propose for this long section 8. I was traveling and will be traveling again, likely without Internet, thru next Tuesday. Here are my unseen offlist emails, containing comments on his text, plus some new text that's unfinished but which I think presents a better flow of concepts for the reader to understand. John Message-Id: <201205130338.q4D3c7cF012761@new.toad.com> To: Scott Schmit , James Cloos , John Gilmore Subject: Re: [dane] [OFFLIST] Revising section 8.1 In-reply-to: <201205120150.q4C1o8cF027279@new.toad.com> References: <201204121903.q3CJ3ucF026698@new.toad.com> <9605FDF6-096D-4159-96A6-16549E8371AB@nic.cz> <20120504031222.GA6541@odin.ulthar.us> <2354EF03-D8D0-49AD-BD99-BA6AD2616FE6@nic.cz> <20120509115626.GA31105@odin.ulthar.us> <20120510133731.GA21205@odin.ulthar.us> <201205120150.q4C1o8cF027279@new.toad.com> Comments: In-reply-to John Gilmore message dated "Fri, 11 May 2012 18:50:08 -0700." Date: Sat, 12 May 2012 20:38:07 -0700 From: John Gilmore Here is some more text for section 8.1. It is unrelated to the text that you sent me. It's more about how I would start to explain it. It's still pretty rough but perhaps you can see more of where I'm going. It turns out that this is quite a complicated topic, since DANE is so flexible and since there are so many options, both for the deployer and for the attacker. I'm traveling this weekend and only getting to work intermittently, so you'll see more intermediate forms than usual, since I'm sending them even in rough form, when I get into a time period where I can't work on it for some hours. Thank you for the collaboration. John Comparing DANE to Public CAs Deploying the DANE TLS protocol to replace the classic TLS protocol in a system (such as in a network of secure web browsers) changes the system's security and availability tradeoffs. Throughout the following, we assume that traditional TLS is deployed with a wide variety of PKIX CAs as trust anchors, as is common in today's secure Web browsers. We also assume that DANE TLS is deployed with a single DNSSEC trust anchor at the root zone (trusting one public key, or perhaps two keys for rollover). DANE TLS is a flexible system that can be deployed on each TLS server in a variety of configurations. For security and availability purposes, these break down to two basic configurations: with PKIX CAs and without them. A TLS server whose domain name uses TLSA records with certificate usages 0, 1, or 2 (XXX) use PKIX CAs. The DANE TLSprotocol is designed such that these servers will have higher security and lower availability. Some circumstances in which an insecure connection would be permitted by traditional TLS will instead cause DANE TLS to block connectivity. These situations include many circumstances in which a "man in the middle" has gained access to the connection. Some of these are malicious attacks; others are intentional configurations (such as a connection proxied through a corporate firewall via a "wildcard" CA certificate). In addition, the DANE TLS connection can also be disrupted by various DNS or DNSSEC failures that would not have prevented the traditional TLS connection. A TLS server whose domain name uses TLSA records with certificate usage 3 does not use PKIX CAs. For such servers, DANE TLS eliminates the security risks and availability issues of PKIX. The security and availability of any resulting DANE TLS connections will all be derived from the security and availability of DNS and DNSSEC. In one expected deployment scenario, a secure web site that currently uses traditional TLS will add a DANE certificate usage 3 record. This would allow traditional TLS clients to access it via the network of PKIX CAs, while only allowing DANE TLS clients to access it via DNSSEC. This configuration provides the high availability and low security of PKIX for traditional clients, while offering high security with lower availability for DANE TLS clients. (The same web site may also be accessible using HTTP without TLS, giving clients an even higher availability access path with very little security.) Message-Id: <201205120150.q4C1o8cF027279@new.toad.com> To: Scott Schmit cc: John Gilmore , James Cloos Subject: Re: [dane] [OFFLIST] Revising section 8.1 In-reply-to: <20120510133731.GA21205@odin.ulthar.us> References: <201204121903.q3CJ3ucF026698@new.toad.com> <9605FDF6-096D-4159-96A6-16549E8371AB@nic.cz> <20120504031222.GA6541@odin.ulthar.us> <2354EF03-D8D0-49AD-BD99-BA6AD2616FE6@nic.cz> <20120509115626.GA31105@odin.ulthar.us> <20120510133731.GA21205@odin.ulthar.us> Comments: In-reply-to Scott Schmit message dated "Thu, 10 May 2012 09:37:31 -0400." Date: Fri, 11 May 2012 18:50:08 -0700 From: John Gilmore I have provided revised text below. The edits are relatively minor unless marked by commentary in the left margin. I have started with your text and done an edit pass over it. But I think it doesn't really present concepts in an easy to understand order. I would like a shot at writing it more clearly...but am sending you this now to keep things moving. John 8.1. Comparing DANE to Public CAs The security of the DNS RRtype described in this document relies on the security of DNSSEC to verify that the TLSA record has not been altered. [The above paragraph is moved from section 8, as it seems to fit here better.] DNSSEC binds an identity to a key by combining a DNSKEY record with an associated RRSIG record. One or more associated DS records then form a signing chain extending from the client's trust anchors to the RR of interest. Though the DNSSEC protocol doesn't enforce it, DNSKEYs are often marked with a SEP flag indicating whether the key is a Zone Signing Key (ZSK) or a Key Signing Key (KSK). ZSKs protect records in the zone (including DS records), and KSKs protect ZSK DNSKEY records. The TLSA RRtype allows keys from the DNSSEC PKI hierarchy to authenticate keys wrapped in PKIX certificates for a particular host name, protocol, and port. All of these records constrain the keys that they identify to names that are within the domain signing the certificate. [DLV is defined in a pair of Informational RFCs, is not part of the standards track, and should not be mentioned by standards track RFCs. It was a circumvention used by a few bleeding edge folks until the root zone was signed. It's signed now.] [Is it legal for a parent zone to sign records for which there is a subdomain DS/NS/DNSKEY? I'd imagine not, but need to check the DNSSEC RFCs.] [No, it's invalid. The parent zone can only make RRSIGs for records in its zone. Subdomains with NS's have their own separate zones.] The mapping between DNSSEC RRtypes and the analogous PKIX certificate type is shown in the following table: +----------------+------------------+---------------+ | DNSSEC RRtype | Analogous PKIX | Name- | | + RRSIG | Certificate | Constrained? | +----------------+------------------+---------------+ | DNSKEY (KSK) | CA Certificate | Yes | +----------------+------------------+---------------+ | DNSKEY (ZSK) | CA Certificate | Yes | | | (w/ DS/DLV RRs) | | | +------------------+---------------+ | | EE Certificate | Yes | | | (w/o DS/DLV RRs) | | +----------------+------------------+---------------+ | DS | CA Certificate | Yes | +----------------+------------------+---------------+ | DLV | CA Certificate | No | +----------------+------------------+---------------+ | TLSA | CA Certificate | Yes | +----------------+------------------+---------------+ [I'm not sure what the point of including this table is. I'd remove it. (Delete the DLV mentions if you keep it.)] 8.1.1. Risk of Key Compromise The risk that a given certificate is fake despite having a valid signing chain is related to the number of keys that can contribute to the validation of the certificate, the quality of protection each key receives, the value of each key to an attacker, and the value of falsifying the certificate. DNSSEC allows any set of domains to be configured as trust anchors, but most clients are likely to use the root zone as its only trust anchor. Also, because a given DNSKEY can only sign RRs for that zone, the number of keys capable of compromising a given TLSA RR is limited to the number of zones between the TLSA RR and the nearest trust anchor. Typically, this will be six keys--half of which will be KSKs. Don't use the acronym KSK, expand it and explain it. The DNSSEC RFCs are obtuse on this topic, even if people read them. PKIX [RFCxxxx?] only describes how to validate a certificate based on a client-chosen set of trust anchors, but says nothing about how many trust anchors to use, how many, or how they are constrained. That said, as currently deployed, PKIX clients typically use a large number of trust anchors provided with the client or operating system software. These trust anchors are selected carefully, but with a desire for broad interoperability. The trust anchors and CA certificates for public CAs rarely have name constraints applied. Recent efforts to determine how many keys are trusted by a typical client estimate the number to be around 1500. [Quora] [Quora =3D http://www.quora.com/SSL-Certificates/How-many-intermediate-Cert= ificate-Authorities-are-there] A combination of technical protections, process controls, and personnel experience contribute to the quality of security that keys receive. The security surrounding DNSSEC DNSKEYs varies significantly. The KSK/ZSK split allows the KSK to be stored offline and protected more carefully than the ZSK, but not all domains will do so. The security applied to a zone's DNSKEYs will be proportional to the value of the domain. For example, the root DNSKEY has protections and controls comparable to or exceeding that of public CAs [Root-DPS]. On the other end of the spectrum, small domains might provide no more protection to their keys than they do to their other data. [Root-DPS =3D https://www.iana.org/dnssec/icann-dps.txt] The security surrounding public CAs also varies. However, due to financial incentives and standards imposed by client software maintainers for acceptance into their set of trust anchors, CAs generally employ security experts and protect their keys carefully, though compromises are not unheard of. 8.1.2. Impact of Key Compromise The impact of a key compromise differs significantly between the two models. Public CAs are not typically constrained in what names they can sign, and therefore a compromise of even one CA allows the attacker to generate a certificate for any name in the DNS. A domain holder can get a certificate from any CA, or even multiple CAs simultaneously, making it impossible for a client to determine whether the certificate it is validating is legitimate or fraudulent. DNSKEYs are inherently limited in what they can sign, so a compromise of the DNSKEY for example.com provides no avenue of attack against example.org. Even the impact of a compromise of .com's DNSKEY, while considerable, would be limited to .com domains. Only the compromise of the root DNSKEY would have the equivalent impact of an unconstrained public CA. Because a TLS certificate association is constrained to its associated name, protocol, and port, the PKIX certificate is similarly constrained, even if its public CAs signing the certificate (if any) are not. [I don't know what that paragraph means. What is a "TLS certificate association"? Do you mean a TLSA certificate association, or something from vintage TLS?] 8.1.3. Detection of Key Compromise If a key is compromised, rapid and reliable detection is important in order to limit the impact of the compromise. In this regard, neither model prevents an attacker from near-invisibly attacking their victim, provided that the necessary keys are compromised. If a public CA is compromised, only the victim will see the fraudulent certificate, as there is typically no publically-accessible directory of all the certificates issued by a CA that can be inspected. DNS RRs are typically published publically. However, the attacker could also allow the uncompromised records to be published to the Internet as usual but provide a compromised DNS view to the victim to achieve the same effect. 8.1.4. Spoofing Hostnames Some CAs implement technical controls to ensure that certificates are not issued to domains that with names similar to popular & prone-to-attack domains. Of course, an attacker can attempt to circumvent this restriction by finding a CA willing to issue the certificate anyway. However, by using DNSSEC and TLSA, the attacker can circumvent this check completely. I'm not sure of the point of this paragraph; I would delete it. 8.2. External DNSSEC Validators Due to a lack of DNSSEC support in the most commonly-deployed stub resolvers today, a number of ISPs have begun checking DNSSEC in the recursive resolvers they provide to their customers, setting the AD flag as appropriate. DNSSEC-aware clients could use that data, ignoring the fact that the DNSSEC data has been validated externally. Because there is no authentication of the AD flag, this can be trivially spoofed by an attacker. However, even when there is secure communication between a host and an external validator, there is a risk that the external validator could become compromised. Nothing prevents a compromised external DNSSEC validator from claiming that all the records it provides are secure, even if the data is falsified, unless the client receives and checks the DNSSEC data itself (rendering the the external validator unnecessary). For this reason, it is RECOMMENDED that DNSSEC validation always be performed on-host, even when a secure path to an external validator is available. > Thanks in advance for your help! You're welcome. John From i.grok@comcast.net Tue May 15 21:16:52 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0AB611E80D3 for ; Tue, 15 May 2012 21:16:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.537 X-Spam-Level: X-Spam-Status: No, score=-102.537 tagged_above=-999 required=5 tests=[AWL=0.062, 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 xzCnO7JUBVJv for ; Tue, 15 May 2012 21:16:52 -0700 (PDT) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [76.96.62.56]) by ietfa.amsl.com (Postfix) with ESMTP id D0E8811E80C2 for ; Tue, 15 May 2012 21:16:51 -0700 (PDT) Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by qmta06.westchester.pa.mail.comcast.net with comcast id AUGl1j0030cZkys56UGro7; Wed, 16 May 2012 04:16:51 +0000 Received: from odin.ulthar.us ([68.33.77.0]) by omta10.westchester.pa.mail.comcast.net with comcast id AUGr1j00500PQ6U3WUGrr4; Wed, 16 May 2012 04:16:51 +0000 Received: from odin.ulthar.us (localhost [127.0.0.1]) by odin.ulthar.us (8.14.5/8.14.3) with ESMTP id q4G4GnIT022324 for ; Wed, 16 May 2012 00:16:49 -0400 Received: (from draco@localhost) by odin.ulthar.us (8.14.5/8.14.5/Submit) id q4G4GmTh022323 for dane@ietf.org; Wed, 16 May 2012 00:16:48 -0400 Date: Wed, 16 May 2012 00:16:48 -0400 From: Scott Schmit To: dane@ietf.org Message-ID: <20120516041648.GA20621@odin.ulthar.us> Mail-Followup-To: dane@ietf.org References: <9605FDF6-096D-4159-96A6-16549E8371AB@nic.cz> <20120504031222.GA6541@odin.ulthar.us> <2354EF03-D8D0-49AD-BD99-BA6AD2616FE6@nic.cz> <20120509115626.GA31105@odin.ulthar.us> <20120513175839.GA8350@odin.ulthar.us> <20120514054656.GC23015@odin.ulthar.us> <20120515140449.GB15583@odin.ulthar.us> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="dDRMvlgZJXvWKvBx" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Inappropriate Section 8 of draft-ietf-dane-protocol-19.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 04:16:52 -0000 --dDRMvlgZJXvWKvBx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, May 15, 2012 at 03:24:19PM +0100, Ben Laurie wrote: > On 15 May 2012 15:04, Scott Schmit wrote: > > On Mon, May 14, 2012 at 11:39:50AM +0100, Ben Laurie wrote: > >> > >> a) "CA certificate" is quite broad - what about DV and EV? > > > > PKIX doesn't talk about DV/OV/EV -- that's a CA/B Forum standard. > > It's probably most analogous to a DV cert. >=20 > Then I guess CAs don't use PKIX :-) No, they do, but EV certs are PKIX certificates with a particular CA-specific certificate policy from client-approved trust anchors. > >> b) What is name-constrained? > > > > See RFC 5280 (search for "name constraint") >=20 > Heh - I know what it means, it wasn't clear to me what had the property... Using DNSSEC, while example.org can sign RRs for example.org or sub.example.org, it can't sign RRs for org, ., example.net, etc. Also, if it delegates sub2.example.org, it can't sign RRs for that either. --=20 Scott Schmit --dDRMvlgZJXvWKvBx Content-Type: application/x-pkcs7-signature Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIIQJgYJKoZIhvcNAQcCoIIQFzCCEBMCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC DVcwggY0MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAe Fw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0 ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEp pC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9 b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54q zHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX 9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/ 4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8E BTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIw HwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wu Y29tL3Nmc2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIB FiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4IC AQAKgwh9eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8py TUnFsukDFUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMm CeUTyMyikfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIz uQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVm z/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT 5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lAp sbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076 khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8 J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRX un0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCBxswggYDoAMCAQICAwK+HTANBgkqhkiG 9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTExMDcxNzA1 MDQwNFoXDTEyMDcxNzExNDI1OVowYjEgMB4GA1UEDRMXNDY1MjU2LTBnRmI2Sk5ZWW44QnFW bUwxGzAZBgNVBAMMEmkuZ3Jva0Bjb21jYXN0Lm5ldDEhMB8GCSqGSIb3DQEJARYSaS5ncm9r QGNvbWNhc3QubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2AjLOMsBGaqN hv2FcRbfom/QCeKMXu5tUd1JY5oIDZe5y29stnd+se/zUlEkiVeMam4Jgo1c8yGNnwLVYc5/ 9xVi7Qg1Is5b9AB6aJWElJDw/jIdihymNZ2kwkSLT0wl/lzd0mXlwFJPRgQiRkmE6V0ZmjsQ jaVtllVleGBbMvmWPm92e+4Bju9P81kKz7Xr02ijETmaPdVsl+jmOaKPS8Y+2Lat2xus4Ked oJ/7aIWIpz1gRSKjAHSZ1Wmwi2TYUjYhZryChu9e1RWtqk1CycNoeusJ8xdEVN3WSnJ299w/ 3ltK/x/9rpj2j9ShQZVB4NnX6cjQs7pz1lVxvIkjcQIDAQABo4IDrTCCA6kwCQYDVR0TBAIw ADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQW BBQ29j2I0O8sRYi0So9NwwmT1caakDAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhR gjAdBgNVHREEFjAUgRJpLmdyb2tAY29tY2FzdC5uZXQwggIhBgNVHSAEggIYMIICFDCCAhAG CysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20v cG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJt ZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcg dG8gdGhlIENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4g Y29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUF BwICMIGPMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJp bGl0eSBhbmQgd2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFu ZCBMaW1pdGF0aW9ucyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAr oCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUH AQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFz czEvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0 cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQAZ5U0nL/2PQwsVfHgN7MVPbZEGzDzuj4Oy pTgz4XQFwPcCuy6U9sp1Dwmo3DyKX5nKN4xA7pslN+2Pl/kElGamX7zMCAH0xED0RTOLyk+v nDML4s+OUtWaYVnq1bZEp0F8Luq3zIslAYSebleyiz8M0EypZczsL5rOk86R2F9EYw1CBuFJ 5a4x0CmNu5o30fGNDFt+iXRlbJPp/KY25iUgVnBzJ4COT5kQjxn5lgr4t1I+BDCL5HQQ3h/8 2CzwrWVRBNb9Vqh9LL1ZtzYRt8JezoB6HkVvcKVNGlCZ+/MnvfMzPLwfbTDZC8o4d+4RH6aE LeGF2XmAOaenc/YRqm9oMYIClzCCApMCAQEwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQQIDAr4dMAkGBSsOAwIaBQCggdgwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTIwNTE2MDQxNjQ4WjAjBgkqhkiG9w0BCQQxFgQU2lJi0dsf eiW4/cm3Ck2YdAnuRTYweQYJKoZIhvcNAQkPMWwwajALBglghkgBZQMEASowCwYJYIZIAWUD BAEWMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAAMEOg9xE yKBI+0HV/U5re1xat3ceXJXhHgVE8oU95HwBtwENSbwZw14cwqhbsk8Y7z1Bg3whSicobOmS h45KRLyRa9bdW2GYLfUonQt1BA/uLXbv8AtSUVyBotR0fOflGGq1LoSdLlH4BAAFqJrttEPq KHaK8+v+xUFTiaXvzH7X4Ne1FQzG6Rl0d5zY9DzLizWjgF/VnGDstGj9S5Tg5oNSnGA3CMv3 4s/s2IfjrZDWAAYOOsWSJ5tJAKZjrMSgzd/qncIIJQt7wUqbU1A0mhPwBw9tK9pJk0PzXnjI ON1Tgnabol/Wl6i1+g/IcaamSEZBqHiL1/uv16mu3rY5Ig== --dDRMvlgZJXvWKvBx-- From mrex@sap.com Wed May 16 00:53:58 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCE9B21F87D0 for ; Wed, 16 May 2012 00:53:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.09 X-Spam-Level: X-Spam-Status: No, score=-10.09 tagged_above=-999 required=5 tests=[AWL=0.159, 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 QZqfHHFxW+hK for ; Wed, 16 May 2012 00:53:58 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 03CDD21F865C for ; Wed, 16 May 2012 00:53:57 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q4G7ruCB009707 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 16 May 2012 09:53:56 +0200 (MEST) From: Martin Rex Message-Id: <201205160753.q4G7rsjL011572@fs4113.wdf.sap.corp> To: warren@kumari.net (Warren Kumari) Date: Wed, 16 May 2012 09:53:54 +0200 (MEST) In-Reply-To: from "Warren Kumari" at May 15, 12 03:32:44 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] Behavior in the face of no answer? 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, 16 May 2012 07:53:59 -0000 Warren Kumari wrote: > > > > I don't think people have been talking about suggesting that the > > application let the user choose between strict and not-strict; > > I think most people here are against that. > > This may be my fault -- a long time back (in this thread) I proposed > having implmentations default to not-strict and then, in a few years > (once there is less DNSSEC breakage by CPE, etc), vendors would turn > the knob to strict mode. Educated / security concious users would > also be able to turn the knob if they so desired. > > This was just an idea, and perhaps a bad one! That was a perfectly reasonable one, and is the approach that is being used for the TLS renegotiation_info extension (rfc5746): http://tools.ietf.org/html/rfc5746#section-4 And no, the world did not end because of browsers and other TLS-clients not being strict about TLS renegotiation (i.e. hard-failing on servers that do not support it). -Martin From mrex@sap.com Wed May 16 02:43:49 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25D1321F86C3 for ; Wed, 16 May 2012 02:43:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.092 X-Spam-Level: X-Spam-Status: No, score=-10.092 tagged_above=-999 required=5 tests=[AWL=0.157, 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 hDLOVT-+Rg9S for ; Wed, 16 May 2012 02:43:45 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id B85E221F870B for ; Wed, 16 May 2012 02:43:44 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q4G9hYPP026460 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 16 May 2012 11:43:34 +0200 (MEST) From: Martin Rex Message-Id: <201205160943.q4G9hXOJ017665@fs4113.wdf.sap.corp> To: gnu@toad.com (John Gilmore) Date: Wed, 16 May 2012 11:43:33 +0200 (MEST) In-Reply-To: <201205160213.q4G2DGcF017008@new.toad.com> from "John Gilmore" at May 15, 12 07:13: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] Network errors ARE attacks - on the end-to-end-principle 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, 16 May 2012 09:43:49 -0000 John Gilmore wrote: > > > But it's better then disabling TLSA at all in the face > > of DNS errors (where we assume most errors are genuine network errors > > and not attacks). > > "Genuine network errors" from buggy proxies or intentional firewalls > or intentional or accidental censorship systems ARE attacks. They are > attacks on the fundamental end-to-end premise of the Internet. Where have you been during the last 10 years? There is no such thing an a "fundamental end-to-end premise" on the Internet. And if it ever existed, it ceased to exist ~10 years ago. (and for good, because it would entirely preclude privacy). > > The Internet changed all that, making it clear what a huge benefit the > public could derive from a system that delivered end-users' data > end-to-end, unmodified, from anywhere, to anywhere. That is not the case here. Telco's providing Internet Access for mobile devices regulary block traffic to VoiP providers _and_ regularly prevent your smartphone or tablet from forwarding IP datagrams to other devices ("tethering") unless you pay extra. > > Or shipping buggy DNS proxies that mess up Port 53 UDP traffic in > their subnet. Most users didn't notice, which allowed the providers > to often get away with censoring the ones who did notice. You seem to be unaware of the IETF full Standard "STD-13" http://tools.ietf.org/html/std13#section-2.3.4 Those DNS proxies are perfectly Standards-compliant. Maybe the IETF should come around to merging contents of later documents with STD-13 and work this successor through document maturity levels to full standard in order to replace the *CURRENT* STD-13, similar to what has been done with 821->2821->5321 and 822->2822->5322, so that when implementations of the *current* STD-13 in the installed base have died off, one can start complaining about non-support of DNSSEC. -Martin From ynir@checkpoint.com Wed May 16 03:32:00 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81E9221F8709 for ; Wed, 16 May 2012 03:32:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.416 X-Spam-Level: X-Spam-Status: No, score=-10.416 tagged_above=-999 required=5 tests=[AWL=0.183, BAYES_00=-2.599, 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 H3tSzWflUdG3 for ; Wed, 16 May 2012 03:32:00 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 8077E21F8700 for ; Wed, 16 May 2012 03:31:58 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (dlpgw.checkpoint.com [194.29.34.27]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id q4GAVu0s017704; Wed, 16 May 2012 13:31:56 +0300 X-CheckPoint: {4FB38F35-0-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Wed, 16 May 2012 13:31:55 +0300 From: Yoav Nir To: "mrex@sap.com" Date: Wed, 16 May 2012 13:31:50 +0300 Thread-Topic: [dane] Network errors ARE attacks - on the end-to-end-principle Thread-Index: Ac0zTxzV7uZf/OjoSvqm55aBwXtueg== Message-ID: <1C09F467-004B-4EB7-87C2-92CBDF74E967@checkpoint.com> References: <201205160943.q4G9hXOJ017665@fs4113.wdf.sap.corp> In-Reply-To: <201205160943.q4G9hXOJ017665@fs4113.wdf.sap.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dane@ietf.org" Subject: Re: [dane] Network errors ARE attacks - on the end-to-end-principle X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 16 May 2012 10:32:00 -0000 On May 16, 2012, at 12:43 PM, Martin Rex wrote: > John Gilmore wrote: >>=20 >>> But it's better then disabling TLSA at all in the face >>> of DNS errors (where we assume most errors are genuine network errors >>> and not attacks). >>=20 >> "Genuine network errors" from buggy proxies or intentional firewalls >> or intentional or accidental censorship systems ARE attacks. They are >> attacks on the fundamental end-to-end premise of the Internet. >=20 > Where have you been during the last 10 years? > There is no such thing an a "fundamental end-to-end premise" on the > Internet. And if it ever existed, it ceased to exist ~10 years ago. 15. Most networks have a NAT, including almost all home networks. Most corp= orate networks have some kind of firewall. If you want end-to-end, you have= to roll your own through IPsec or TLS, and even then you're likely to get = load balancers at the server side, and the occasional decrypting proxy on t= he client side. Yoav= From henry.story@bblfish.net Wed May 16 04:46:17 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59F9321F86EE for ; Wed, 16 May 2012 04:46:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fQJKccFh4ivk for ; Wed, 16 May 2012 04:46:16 -0700 (PDT) Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id 3962F21F86E4 for ; Wed, 16 May 2012 04:46:15 -0700 (PDT) Received: by wgbds11 with SMTP id ds11so5276575wgb.1 for ; Wed, 16 May 2012 04:46:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=DG3TrlHKI+BCPNLWS3Za/9oZx0UHX/69cqf2P1scVME=; b=DLE1zIQCnAc/0cumAOO0HXniREVa/nQhCkvThmpUV33oytVDYMLY0gVVoYXWZlAFTH YlNs5Sl+QYlKAhq9MjCQSrPGaIibMp90i/P4ieOd273BVspHnerg/GBBDKDPqQSkVETd kCs11Lts7D0eMzyr5eXgRoVyNjkVR2E9Vq88OgW2zURyroiWwL5b1HVrV+A4sQnuVGOQ dtJDANgL9vo56cL5dJIPxcQYFjJFxwldiJT7h2A42xz6BqLpuFwjXwUOpDPzLUBtZ587 l+VQBJpLdL07HpntIONVuLgLEpl1Y+THs0cQCLZNKyAiySTXBMLouJpshYPYtx+hgtEH AFSw== Received: by 10.180.81.36 with SMTP id w4mr7200495wix.16.1337168774758; Wed, 16 May 2012 04:46:14 -0700 (PDT) Received: from bblfish.home (AAubervilliers-651-1-269-153.w86-212.abo.wanadoo.fr. [86.212.204.153]) by mx.google.com with ESMTPS id fo7sm49066723wib.9.2012.05.16.04.46.09 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 16 May 2012 04:46:11 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Henry Story In-Reply-To: <201205160213.q4G2DGcF017008@new.toad.com> Date: Wed, 16 May 2012 13:46:08 +0200 Content-Transfer-Encoding: 7bit Message-Id: <6633F8AF-B8E7-4386-AB81-444780868BF8@bblfish.net> References: <643D87CD-D01E-47B8-82E5-D3F57D50C80B@vpnc.org> <20120515112154.GA20521@mail.yitter.info> <201205160213.q4G2DGcF017008@new.toad.com> To: John Gilmore X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQmVEacX+nLlb1hUdK6h15ZmwXH/hnOccwKkEH/qWZ1nLxhaP9LSGswOcSE6yQHLHSgwJJ70 Cc: dane@ietf.org Subject: Re: [dane] Network errors ARE attacks - on the end-to-end-principle X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 16 May 2012 11:46:17 -0000 On 16 May 2012, at 04:13, John Gilmore wrote: >> But it's better then disabling TLSA at all in the face >> of DNS errors (where we assume most errors are genuine network errors >> and not attacks). > > "Genuine network errors" from buggy proxies or intentional firewalls > or intentional or accidental censorship systems ARE attacks. They are > attacks on the fundamental end-to-end premise of the Internet. > > The default state of the networking world, pre-Internet, is that > network providers felt free to block or modify data in transit, for > their own convenience, profit, whim, or by accident. They'd control > what services you could access, what channels you could watch, etc, > etc, etc. It was assumed that the owner of the communications channel > had every right and every business reason to limit who you were allowed > to talk to, and on what topics. > > The Internet changed all that, making it clear what a huge benefit the > public could derive from a system that delivered end-users' data > end-to-end, unmodified, from anywhere, to anywhere. Finally you could > access YOUR CHOICE of data and services from anywhere -- not "this > service is only available on France Telecom's Teletext system" and > "You can't email that guy because he's on MCI Mail and you're on The > Source". Now that Moore's Law's newly available crunchons enabled > today's complex radio modulations and equally complex presentation > protocols, you can get all those same services wirelessly, instead of > what the incumbent providers kept designing over and over ("You can > only get this WAP-based information service on AT&T mobile phones" and > "To watch this TV show that you've already paid for, you have to be > physically plugged into this coaxial cable.") > > Since the public rise of the Internet in the '90s was not > cryptographically secured end-to-end, providers eventually realized > that they could somewhat go back to their old ways of messing with > end-users' data for their own convenience, profit, whim, or by > accident. Like Comcast blocking BitTorrent traffic by forging RST > packets, AT&T Mobile deliberately dropping packets when it had the > capacity to carry them, just to discourage "unlimited" usage, or > certain carriers declining to carry packets for "over the top" video. > Or shipping buggy DNS proxies that mess up Port 53 UDP traffic in > their subnet. Most users didn't notice, which allowed the providers > to often get away with censoring the ones who did notice. > > DNSSEC and DANE are just part of the leading edge of a trend to secure > Internet traffic end-to-end. This will make more such blockages and > modifications much more apparent -- turning them from > possibly-unnoticed inconveniences into denial-of-service failures. > > But the end result will be that (1) users will realize they are being > censored; (2) providers will clean up the accidental and whim-related > censorship; and (3) users will migrate to providers who offer them > reliable end-to-end service without interruptions for the provider's > convenience or profit. > > And in that way, the Internet will route around these attacks on the > end-to-end principle. > > This is a good thing, despite the distributed pain involved in fixing > all those broken devices and misguided providers. I completely agree. Thanks for putting it so clearly. > > John > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane Social Web Architect http://bblfish.net/ From henry.story@bblfish.net Wed May 16 04:55:49 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6C7E21F8700 for ; Wed, 16 May 2012 04:55:49 -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 ExMEwjh7SD+G for ; Wed, 16 May 2012 04:55:49 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id DB6F821F86FD for ; Wed, 16 May 2012 04:55:48 -0700 (PDT) Received: by wibhn6 with SMTP id hn6so519030wib.13 for ; Wed, 16 May 2012 04:55:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=Ue7W0oMDKwer9PlgeZ058B0POgsfOdp2nvbXcLgAepI=; b=BgD1PmveeZc6FKg0G82yCOzhE0vxE5MsAqvrXKgrlTkt0lochBsE/nELFXd37UrAYb plhHEb2taCWSo4kAQFZMxSRLkh/FjvrTc/ZEyBihtD1HQwRjPUhoeWmvd0wpNPdLe5YB oLld9L75p1tdg+dGNg6TD4JyQcKSO693txoJ8ep/NfI6jxq+rxQwIUVOVNTX1rIZpW4y 9XR3xoJDOb8evSFsk/lnisCPBn+pysCyuon8QbWB7EAjXKMfT5ihyAc/qsQfS8DdXw3J 4Vmf/QyIlvtSX6++VX1rsUpUSsya9cpMUlCdYKab3Zzgu9fJucBTFDAlYzIYJCtbJ+Yw zdPg== Received: by 10.216.215.194 with SMTP id e44mr1024665wep.61.1337169347916; Wed, 16 May 2012 04:55:47 -0700 (PDT) Received: from bblfish.home (AAubervilliers-651-1-269-153.w86-212.abo.wanadoo.fr. [86.212.204.153]) by mx.google.com with ESMTPS id r2sm8438427wif.7.2012.05.16.04.55.45 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 16 May 2012 04:55:47 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Henry Story In-Reply-To: <1C09F467-004B-4EB7-87C2-92CBDF74E967@checkpoint.com> Date: Wed, 16 May 2012 13:55:44 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201205160943.q4G9hXOJ017665@fs4113.wdf.sap.corp> <1C09F467-004B-4EB7-87C2-92CBDF74E967@checkpoint.com> To: Yoav Nir X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQlQ7oFn/BKZo5bSzd+kmiRwLVSno6JUPMzxwi5946z8Gw8beu8+XUsd5GDiE4kH2sTT/RMe Cc: "dane@ietf.org" Subject: Re: [dane] Network errors ARE attacks - on the end-to-end-principle X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 16 May 2012 11:55:49 -0000 On 16 May 2012, at 12:31, Yoav Nir wrote: >=20 > On May 16, 2012, at 12:43 PM, Martin Rex wrote: >=20 >> John Gilmore wrote: >>>=20 >>>> But it's better then disabling TLSA at all in the face >>>> of DNS errors (where we assume most errors are genuine network = errors >>>> and not attacks). >>>=20 >>> "Genuine network errors" from buggy proxies or intentional firewalls >>> or intentional or accidental censorship systems ARE attacks. They = are >>> attacks on the fundamental end-to-end premise of the Internet. >>=20 >> Where have you been during the last 10 years? >> There is no such thing an a "fundamental end-to-end premise" on the >> Internet. And if it ever existed, it ceased to exist ~10 years ago. >=20 > 15. Most networks have a NAT, including almost all home networks. Most = corporate networks have some kind of firewall. If you want end-to-end, = you have to roll your own through IPsec or TLS, and even then you're = likely to get load balancers at the server side, and the occasional = decrypting proxy on the client side. The point of John Gilmore's inspirational mail is that end-to-end is the = aim of the architecture of the internet. It is because it was architected for = end to=20 end communication that it has had such positive effects. The reasons = these working groups exist is to remove the technical reasons for this not always = being possible, such as by for example working on ipv6. When the technical reasons have been = moved out of the way the network effects and political pressure can be built up to solve = the deployment problems. Luckily the network effect works in favour of those who work = for freedom. Henry >=20 > Yoav > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane Social Web Architect http://bblfish.net/ From sm@resistor.net Wed May 16 08:01:01 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20C0B21F8631 for ; Wed, 16 May 2012 08:01:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.482 X-Spam-Level: X-Spam-Status: No, score=-102.482 tagged_above=-999 required=5 tests=[AWL=0.117, 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 BYW5wfxtjxgO for ; Wed, 16 May 2012 08:00:58 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D8D621F862F for ; Wed, 16 May 2012 08:00:58 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q4GF0lhk012392; Wed, 16 May 2012 08:00:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1337180452; i=@resistor.net; bh=svb8HrKI61+NX4Q1vken+KIrtfwyBDMkPHQ/xULNKzA=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=yvuhfm5T/ceFeiTHvb+pYrPiOTkUjkfAC0TQUd/VfZwFQSqvEF+fPBy+ZUxQVTQQB VWowN7FyZn/Pd8WvjYnmZn9RWqbiUYjuvuCLyTHNHnuBWXPXdo1D3oC56fwuA+lu52 7icinmZbeplwIQA05vRv/qupAvE9/reDYYPFl4jA= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1337180452; i=@resistor.net; bh=svb8HrKI61+NX4Q1vken+KIrtfwyBDMkPHQ/xULNKzA=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=mGqoEXrtG0pIt3nogyUbrcTKIvf6ubyMHsy1HMwniXlLx20HLFiXM4EXgTPayHnc4 mgtdfTR8c5mnq/6Q7SJeOveP0XLsswUzPpTHpvoH8iomOkTx5KxqrBDsFaRsSQ78R0 fPhil55t4cMFW1r81XJTDXyWHKpkCFraaO1uBchk= Message-Id: <6.2.5.6.2.20120516072229.0a1f93a8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 16 May 2012 07:56:20 -0700 To: Henry Story From: SM In-Reply-To: References: <201205160943.q4G9hXOJ017665@fs4113.wdf.sap.corp> <1C09F467-004B-4EB7-87C2-92CBDF74E967@checkpoint.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: dane@ietf.org Subject: Re: [dane] Network errors ARE attacks - on the end-to-end-principle X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 16 May 2012 15:01:01 -0000 Hi Henry, At 04:55 16-05-2012, Henry Story wrote: >The point of John Gilmore's inspirational mail is that end-to-end is >the aim of >the architecture of the internet. It is because it was architected for end to >end communication that it has had such positive effects. The reasons >these working That is how things were. How things are is a matter of religion. >groups exist is to remove the technical reasons for this not always >being possible, such >as by for example working on ipv6. When the technical reasons have >been moved out of the >way the network effects and political pressure can be built up to >solve the deployment >problems. Luckily the network effect works in favour of those who >work for freedom. Sometimes technical reasons are used as a reason for not doing a non-technical change. The technical folks declare an issue as out of scope while the non-technical folks assume that the technical folks have considered and addressed the issue. The message at https://www.ietf.org/mail-archive/web/dane/current/msg05009.html mentioned some awkward truths. It could be said that there are good reasons for a person not to take a stance by side-stepping the issue(s). Regards, -sm From mcr@sandelman.ca Wed May 16 08:15:31 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29FD821F86A8 for ; Wed, 16 May 2012 08:15:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.743 X-Spam-Level: X-Spam-Status: No, score=-1.743 tagged_above=-999 required=5 tests=[AWL=0.211, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] 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 zlGcC2gCV2-3 for ; Wed, 16 May 2012 08:15:30 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 7431621F865E for ; Wed, 16 May 2012 08:15:30 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by relay.sandelman.ca (Postfix) with ESMTPS id F03648320 for ; Wed, 16 May 2012 11:14:10 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 5F9BB98B98; Wed, 16 May 2012 11:15:29 -0400 (EDT) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 52B8D98470 for ; Wed, 16 May 2012 11:15:29 -0400 (EDT) From: Michael Richardson To: dane@ietf.org In-Reply-To: <201205160213.q4G2DGcF017008@new.toad.com> References: <643D87CD-D01E-47B8-82E5-D3F57D50C80B@vpnc.org> <20120515112154.GA20521@mail.yitter.info> <201205160213.q4G2DGcF017008@new.toad.com> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) Date: Wed, 16 May 2012 11:15:29 -0400 Message-ID: <27659.1337181329@marajade.sandelman.ca> Sender: mcr@sandelman.ca Subject: Re: [dane] Network errors ARE attacks - on the end-to-end-principle X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 16 May 2012 15:15:31 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I just wanted to +1 on John Gilmore's very well reasoned arguments. I can not reply to each point myself, and John does it better than I. - -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Finger me for keys iQEVAwUBT7PEaYCLcPvd0N1lAQLv3wf9HJlM8+sJerbF4keZOlztEcHU56z/K4vj 9IULlrokHXGgy3jE3YGzUmPDCJJnwAQ/ALETT4bU7P0pKdoRU+aQMuc1CW9/zdjk jLQhNyaAusx9fEqDxE9GXZbpHkRdepBciKyv/smqxJFaV0z+iyoFaGlvGY0bxkxm /I/hmSmKUkWHiNuxKmx1tSSE2X+AYeLVZXVeno8PvnYPMEiMmFC4Cb23PhMkj4ln yHDjFtThISMg8af80//pTgvx4rgVeJSyMAgm2tYbp3wSLnD0o9G8n24keY+6X82T SbET2J9TeeH3nwa7cA9DEzLlVAIn/6zTyLS+fmfmp8j5CE0DTPKjVQ== =UkyF -----END PGP SIGNATURE----- -- Michael Richardson , Sandelman Software Works IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ From ajs@anvilwalrusden.com Wed May 16 08:19:49 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4CCF21F85C5 for ; Wed, 16 May 2012 08:19:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[AWL=-0.020, 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 j-ysJSlIRpoP for ; Wed, 16 May 2012 08:19:49 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 17BDD21F852E for ; Wed, 16 May 2012 08:19:49 -0700 (PDT) Received: from mail.yitter.info (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 834AE1ECB41C for ; Wed, 16 May 2012 15:19:48 +0000 (UTC) Date: Wed, 16 May 2012 11:19:46 -0400 From: Andrew Sullivan To: dane@ietf.org Message-ID: <20120516151946.GJ26714@mail.yitter.info> References: <643D87CD-D01E-47B8-82E5-D3F57D50C80B@vpnc.org> <20120515112154.GA20521@mail.yitter.info> <201205160213.q4G2DGcF017008@new.toad.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201205160213.q4G2DGcF017008@new.toad.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Network errors ARE attacks - on the end-to-end-principle X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 16 May 2012 15:19:49 -0000 On Tue, May 15, 2012 at 07:13:16PM -0700, John Gilmore wrote: > "Genuine network errors" from buggy proxies or intentional firewalls > or intentional or accidental censorship systems ARE attacks. They are > attacks on the fundamental end-to-end premise of the Internet. But (1) bugs are different from intentional blockage and (2) not all of this is strictly speaking buggy. The fact that some ancient gateway can't cope with RRTYPEs it doesn't know is, IMO, a disgrace; but they can say (correctly) that they just don't implement that RFC, and be quite right. I would like the market to reject such devices as useless, but it hasn't yet. > But the end result will be that (1) users will realize they are being > censored; (2) providers will clean up the accidental and whim-related > censorship; and (3) users will migrate to providers who offer them > reliable end-to-end service without interruptions for the provider's > convenience or profit. I suppose that the above is intended to argue that the market will reject such devices as useless. I think we have a first mover principle in the way, however. These "users" of which you speak would need to form a fairly detailed theory of operation of the Internet in order to understand what the problem is. I don't believe that most of them will, and I don't think they ought to need to either. Therefore, I would prefer that we build documents that permit useful incremental addition of features to the network. To drag this back on topic, in light of the above I need to think harder about the argument, elsewhere in this thread, that uses 2 and 3 are also undermined by the no-answer attack, because if that's the case then I suspect DANE is undeployable as it stands. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From ekr@rtfm.com Wed May 16 09:57:40 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92A5421F847E for ; Wed, 16 May 2012 09:57:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.886 X-Spam-Level: X-Spam-Status: No, score=-102.886 tagged_above=-999 required=5 tests=[AWL=0.091, 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 B582XJBNMReS for ; Wed, 16 May 2012 09:57:39 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5948921F847F for ; Wed, 16 May 2012 09:57:39 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so1073967vbb.31 for ; Wed, 16 May 2012 09:57:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=9h7jmNedIEly798TZf3cvjAG8LrG2xb6hKN3seQHPS8=; b=P3rKiwRR56oiLYG3HMT8vp+rYsHubaOw6yrot9Ql7cuyhGWw89QYLGTuPhGCnR5Jmx OkdqYCVP/sNsb+Le6kAx4aUDZr1tP/WB98FYZMKYVEFHhPQRWt92ETWqbnwGWewvsZmp 19UMLI3uiUfl8Fv7WaREim6FAIFY555Ak/CVbxC0K9UTB1/orcjS4nvId+ngKyqw8vcc XOMjhnYwlGRRRa2hlCN0lxCVMihgjggqJ0m937XmQrw2Qa2mkaSHwBU5uN41c3YPnxNg ORwB9Al3jsphJ5F3ryxObcm5VY2Scp9QYito7gZn1TH5ff8wQGjP0Okc9OiDqm+5ASXL QQzA== Received: by 10.52.177.41 with SMTP id cn9mr2434528vdc.53.1337187458861; Wed, 16 May 2012 09:57:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.35.209 with HTTP; Wed, 16 May 2012 09:56:58 -0700 (PDT) X-Originating-IP: [74.95.2.173] In-Reply-To: <201205160124.q4G1OIcF015532@new.toad.com> References: <643D87CD-D01E-47B8-82E5-D3F57D50C80B@vpnc.org> <201205160116.q4G1GTcF015332@new.toad.com> <201205160124.q4G1OIcF015532@new.toad.com> From: Eric Rescorla Date: Wed, 16 May 2012 09:56:58 -0700 Message-ID: To: John Gilmore Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkXOnKTbTD6tYXPnQNiNIsvqTyDf1sezt0XtHmdCOnXuwKyEOQpN5q8dvpNTD7X+cAOYG3P Cc: Paul Hoffman , dane@ietf.org Subject: Re: [dane] Behavior in the face of no answer? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 16 May 2012 16:57:40 -0000 On Tue, May 15, 2012 at 6:24 PM, John Gilmore wrote: >> responses being sent to the user. =A0Thus, in order to achieve any >> security benefit from certificate usage 0 or 1, the protocol requires >> that when DNS responses have not arrived or are not valid, the TLS >> connection must not succeed. > > It's easy for a Man in the Middle to subvert cert usage 3 this way > too. =A0They just issue themselves a cert signed by some subverted > public CA, block your TLSA DNS responses, and then if you proceed with > TLS, you'll accept the key signed by the subverted public CA, since > you never saw the record that says "This server is secured by THIS > PUBLIC KEY RIGHT HERE, and not anything else." > > This attack also works against cert usage 2. =A0Thus I'm not sure why > this proposed graf even mentions cert usages 0 and 1, except perhaps > to remind the PKIX fans among us that proceeding in the face of DNS > blockage causes even their favorite forms of TLSA to be vulnerable. It's there because I hadn't had time to really think about 2 and 3 but I was sure about 0 and 1. With that said, it's not true that 2 and 3 are the same as 0 and 1. Imagine a client which asks for TLSA records and pays attention to 2 and 3 but ignores 0 and 1. That client could (assuming people actually serve TLSA records) avoid showing the red screen of death for some self-signed sites. Surely that is indeed of security value, although it does not offer any defense against CA compromise. -Ekr From peter.van.dijk@netherlabs.nl Wed May 16 10:43:38 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2839321F85B7 for ; Wed, 16 May 2012 10:43:38 -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 KWn4iit-HXfR for ; Wed, 16 May 2012 10:43:37 -0700 (PDT) Received: from shannon.7bits.nl (shannon.7bits.nl [IPv6:2a01:1b0:202:40::1]) by ietfa.amsl.com (Postfix) with ESMTP id 22D4621F854C for ; Wed, 16 May 2012 10:43:37 -0700 (PDT) Received: from tesla.fritz.box (a80-101-233-235.adsl.xs4all.nl [80.101.233.235]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: peter) by shannon.7bits.nl (Postfix) with ESMTPSA id 211881BB94; Wed, 16 May 2012 19:43:34 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Peter van Dijk In-Reply-To: <72C87898-41D6-45B0-B4F8-EEACED13BA66@vpnc.org> Date: Wed, 16 May 2012 19:43:34 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0E4DEE78-EF31-405D-B1B2-49093A24B4EB@netherlabs.nl> References: <20120309184424.5853.82819.idtracker@ietfa.amsl.com> <72C87898-41D6-45B0-B4F8-EEACED13BA66@vpnc.org> To: IETF DANE WG list X-Mailer: Apple Mail (2.1257) Subject: [dane] local-part case-sensitivity (was: draft-hoffman-dane-smime-03.txt) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 17:43:38 -0000 Hello Paul, list, On Mar 9, 2012, at 19:53 , Paul Hoffman wrote: > We have updated the S/MIME draft based on some new interest from a few = folks. We cleaned up one technical detail (look for "Base32"), and added = a privacy-related security consideration. Applying base32 in this way ignores that local-parts are case sensitive = (RFC5321 2.4, 4.1.2; RFC6530 10.1, 13). I feel that case-sensitivity in = SMTP is a mistake, but it's a mistake SMTP/email-related drafts/specs = cannot just ignore. A few suggestions: 1) specify that the local-part is lowercased before encoding it with = base32, and clarify that this deviates from relevant specification. 2) specify that whatever choice of case a sender picks has to be present = under the _smimecert label. 3) investigate whether Punycode&friends solve this problem in a more = satisfying manner. Other suggestions are welcome, of course. Kind regards, --=20 Peter van Dijk Netherlabs Computer Consulting BV - http://www.netherlabs.nl/ From paul@cypherpunks.ca Wed May 16 11:07:23 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F29F421F848A for ; Wed, 16 May 2012 11:07:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.014, 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 Xzt0w+HPLgve for ; Wed, 16 May 2012 11:07:21 -0700 (PDT) Received: from letoams.cypherpunks.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id ED39221F86A2 for ; Wed, 16 May 2012 11:07:19 -0700 (PDT) Received: by letoams.cypherpunks.ca (Postfix, from userid 500) id 703A0853FE; Wed, 16 May 2012 14:07:17 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by letoams.cypherpunks.ca (Postfix) with ESMTP id 61DF1853FD; Wed, 16 May 2012 14:07:17 -0400 (EDT) Date: Wed, 16 May 2012 14:07:17 -0400 (EDT) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: Eric Rescorla In-Reply-To: Message-ID: References: <643D87CD-D01E-47B8-82E5-D3F57D50C80B@vpnc.org> <201205160116.q4G1GTcF015332@new.toad.com> <201205160124.q4G1OIcF015532@new.toad.com> User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: dane@ietf.org Subject: Re: [dane] Behavior in the face of no answer? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 16 May 2012 18:07:23 -0000 On Wed, 16 May 2012, Eric Rescorla wrote: > That client could (assuming people actually serve > TLSA records) openswan.org and nohats.ca currently serve TLSA records, and fedoraproject.org will publish these in a few days. nohats.ca is also using a CA. for testing, the site rogue.nohats.ca is signed by a different CA that mismatches the TLSA record. Paul From paul.hoffman@vpnc.org Wed May 16 12:53:21 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20B8621F85B9 for ; Wed, 16 May 2012 12:53:21 -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 VWzEIrUh4mpt for ; Wed, 16 May 2012 12:53:20 -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 873E421F85B5 for ; Wed, 16 May 2012 12:53:20 -0700 (PDT) Received: from sn87.proper.com (sn87.proper.com [75.101.18.87]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q4GJrH9d065553 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 16 May 2012 12:53:18 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <0E4DEE78-EF31-405D-B1B2-49093A24B4EB@netherlabs.nl> Date: Wed, 16 May 2012 12:53:16 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120309184424.5853.82819.idtracker@ietfa.amsl.com> <72C87898-41D6-45B0-B4F8-EEACED13BA66@vpnc.org> <0E4DEE78-EF31-405D-B1B2-49093A24B4EB@netherlabs.nl> To: Peter van Dijk X-Mailer: Apple Mail (2.1278) Cc: IETF DANE WG list Subject: Re: [dane] local-part case-sensitivity (was: draft-hoffman-dane-smime-03.txt) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 19:53:21 -0000 On May 16, 2012, at 10:43 AM, Peter van Dijk wrote: > Applying base32 in this way ignores that local-parts are case = sensitive (RFC5321 2.4, 4.1.2; RFC6530 10.1, 13). I feel that = case-sensitivity in SMTP is a mistake, but it's a mistake = SMTP/email-related drafts/specs cannot just ignore. >=20 > A few suggestions: > 1) specify that the local-part is lowercased before encoding it with = base32, and clarify that this deviates from relevant specification. > 2) specify that whatever choice of case a sender picks has to be = present under the _smimecert label. > 3) investigate whether Punycode&friends solve this problem in a more = satisfying manner. I am completely confused here. The current draft says: 1. The user name (the "left-hand side" of the email address, called the "local-part" in [RFC2822] and the "local part" in [RFC6530]), is encoded with Base32 [RFC4648], to become the left-most label in the prepared domain name. This does not include the "@" character that separates the left and right sides of the email address. This preserves any case in the local part. Your suggestion (1) destroys = the case. It is also not valid for local parts that do not have clean = lower-casing rules; we went through this mess with IDNA2003. Why not just leave the case as-is? --Paul Hoffman From peter.van.dijk@netherlabs.nl Wed May 16 13:04:08 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B90621F865A for ; Wed, 16 May 2012 13:04:08 -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 rPJZex96SoZp for ; Wed, 16 May 2012 13:04:07 -0700 (PDT) Received: from shannon.7bits.nl (shannon.7bits.nl [IPv6:2a01:1b0:202:40::1]) by ietfa.amsl.com (Postfix) with ESMTP id B924821F864A for ; Wed, 16 May 2012 13:04:07 -0700 (PDT) Received: from tesla.fritz.box (a80-101-233-235.adsl.xs4all.nl [80.101.233.235]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: peter) by shannon.7bits.nl (Postfix) with ESMTPSA id C36C41BB94; Wed, 16 May 2012 22:04:06 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Peter van Dijk In-Reply-To: Date: Wed, 16 May 2012 22:04:06 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120309184424.5853.82819.idtracker@ietfa.amsl.com> <72C87898-41D6-45B0-B4F8-EEACED13BA66@vpnc.org> <0E4DEE78-EF31-405D-B1B2-49093A24B4EB@netherlabs.nl> To: IETF DANE WG list X-Mailer: Apple Mail (2.1257) Subject: Re: [dane] local-part case-sensitivity (was: draft-hoffman-dane-smime-03.txt) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 20:04:08 -0000 Hello Paul, On May 16, 2012, at 21:53 , Paul Hoffman wrote: > I am completely confused here. The current draft says: > 1. The user name (the "left-hand side" of the email address, called > the "local-part" in [RFC2822] and the "local part" in = [RFC6530]), > is encoded with Base32 [RFC4648], to become the left-most label > in the prepared domain name. This does not include the "@" > character that separates the left and right sides of the email > address. > This preserves any case in the local part. Your suggestion (1) = destroys the case. It is also not valid for local parts that do not have = clean lower-casing rules; we went through this mess with IDNA2003. I will try to clarify. Base32 certainly preserves case, and in that = sense appears to honor the case-sensitivity requirement in 2822/6530. However, most (if not almost all) mail servers on the internet treat = chris@example.com and Chris@example.com as the same user - and 2822/6530 = do not prohibit this. If we base32-encode 'chris' but the user chooses = to mail from 'Chris', the DNS lookup will not match and his S/MIME cert = cannot be verified. I cannot conceive of an encoding scheme that honors case-sensitivity = without hampering the 99% of implementations that are actually case = insensitive. Base32 enforces case-sensitivity, which breaks most = implementations; a more plain encoding (like encoding 'chris' as = 'chris') (apart from having other issues - the exact reason you went = with base32) would be case-insensitive and would thus violate 2822/6530. Kind regards, --=20 Peter van Dijk Netherlabs Computer Consulting BV - http://www.netherlabs.nl/ From paul.hoffman@vpnc.org Wed May 16 15:18:43 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1668621F876C for ; Wed, 16 May 2012 15:18:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.558 X-Spam-Level: X-Spam-Status: No, score=-102.558 tagged_above=-999 required=5 tests=[AWL=0.041, 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 yhkIdxPM23Gb for ; Wed, 16 May 2012 15:18:42 -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 7F0D521F872E for ; Wed, 16 May 2012 15:18:42 -0700 (PDT) Received: from [10.20.30.102] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q4GMIfL9070409 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 16 May 2012 15:18:41 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Wed, 16 May 2012 15:18:40 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0217F3B8-98B7-48CA-9A08-609F8E51AA41@vpnc.org> References: <20120309184424.5853.82819.idtracker@ietfa.amsl.com> <72C87898-41D6-45B0-B4F8-EEACED13BA66@vpnc.org> <0E4DEE78-EF31-405D-B1B2-49093A24B4EB@netherlabs.nl> To: Peter van Dijk X-Mailer: Apple Mail (2.1278) Cc: IETF DANE WG list Subject: Re: [dane] local-part case-sensitivity (was: draft-hoffman-dane-smime-03.txt) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 22:18:43 -0000 But we are not talking about sending mail to this name: we are talking = about how to find the DNS record for the user. I can add something to = the effect of "you need to know what the exact name that would be used = is, and it is likely to be lowercase". --Paul Hoffman From marka@isc.org Wed May 16 16:14:31 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 336099E8029 for ; Wed, 16 May 2012 16:14:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.136 X-Spam-Level: X-Spam-Status: No, score=-2.136 tagged_above=-999 required=5 tests=[AWL=0.463, 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 7GRT-ZwIh4dP for ; Wed, 16 May 2012 16:14:30 -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 51F9B9E8028 for ; Wed, 16 May 2012 16:14:30 -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 "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id 1F2545F98B9; Wed, 16 May 2012 23:14:15 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:4d9d:63d1:95fc:acb8]) (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 EE71A216C33; Wed, 16 May 2012 23:14:12 +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 1B72920ACED7; Thu, 17 May 2012 09:14:07 +1000 (EST) To: Andrew Sullivan From: Mark Andrews References: <643D87CD-D01E-47B8-82E5-D3F57D50C80B@vpnc.org> <20120515112154.GA20521@mail.yitter.info> <201205160213.q4G2DGcF017008@new.toad.com> <20120516151946.GJ26714@mail.yitter.info> In-reply-to: Your message of "Wed, 16 May 2012 11:19:46 -0400." <20120516151946.GJ26714@mail.yitter.info> Date: Thu, 17 May 2012 09:14:07 +1000 Message-Id: <20120516231408.1B72920ACED7@drugs.dv.isc.org> Cc: dane@ietf.org Subject: Re: [dane] Network errors ARE attacks - on the end-to-end-principle X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 16 May 2012 23:14:31 -0000 In message <20120516151946.GJ26714@mail.yitter.info>, Andrew Sullivan writes: > On Tue, May 15, 2012 at 07:13:16PM -0700, John Gilmore wrote: > > > "Genuine network errors" from buggy proxies or intentional firewalls > > or intentional or accidental censorship systems ARE attacks. They are > > attacks on the fundamental end-to-end premise of the Internet. > > But (1) bugs are different from intentional blockage and (2) not all > of this is strictly speaking buggy. The fact that some ancient > gateway can't cope with RRTYPEs it doesn't know is, IMO, a disgrace; > but they can say (correctly) that they just don't implement that RFC, > and be quite right. I would like the market to reject such devices as > useless, but it hasn't yet. For the market to reject such devices it needs to be *aware* of such devices. When 99.999% of queries are A records the market doesn't get the feedback it needs to operate. When you let the faults be seen the buggy software does get removed. How many load balancers return NXDOMAIN to AAAA queries when there are A records at the name now? It used to be a reasonably common bug. We let the pain of that bug be visible and the problem is mostly gone. I don't know how many times I had to say to a customer reporting a bug in named because the lookups worked with a different nameserver that it was a because we supported both IPv4 and IPv6 when the other vendors didn't and that made the remote bug visible. > > But the end result will be that (1) users will realize they are being > > censored; (2) providers will clean up the accidental and whim-related > > censorship; and (3) users will migrate to providers who offer them > > reliable end-to-end service without interruptions for the provider's > > convenience or profit. > > I suppose that the above is intended to argue that the market will > reject such devices as useless. I think we have a first mover > principle in the way, however. These "users" of which you speak would > need to form a fairly detailed theory of operation of the Internet in > order to understand what the problem is. I don't believe that most of > them will, and I don't think they ought to need to either. Therefore, > I would prefer that we build documents that permit useful incremental > addition of features to the network. > > To drag this back on topic, in light of the above I need to think > harder about the argument, elsewhere in this thread, that uses 2 and 3 > are also undermined by the no-answer attack, because if that's the > case then I suspect DANE is undeployable as it stands. > > Best, > > A > > -- > Andrew Sullivan > ajs@anvilwalrusden.com > _______________________________________________ > 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 warren@kumari.net Wed May 16 16:22:00 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C88EF21F877E for ; Wed, 16 May 2012 16:21:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.154 X-Spam-Level: X-Spam-Status: No, score=-106.154 tagged_above=-999 required=5 tests=[AWL=0.445, 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 4TpUjQUdBCTx for ; Wed, 16 May 2012 16:21:57 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 38A5821F8758 for ; Wed, 16 May 2012 16:21:53 -0700 (PDT) Received: from [192.168.0.12] (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id 9DAEB1B402CA; Wed, 16 May 2012 19:21:52 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: Warren Kumari In-Reply-To: <20120516151946.GJ26714@mail.yitter.info> Date: Wed, 16 May 2012 19:21:56 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <7CED0263-3C3F-4016-B078-3CC34802B8E5@kumari.net> References: <643D87CD-D01E-47B8-82E5-D3F57D50C80B@vpnc.org> <20120515112154.GA20521@mail.yitter.info> <201205160213.q4G2DGcF017008@new.toad.com> <20120516151946.GJ26714@mail.yitter.info> To: Andrew Sullivan X-Mailer: Apple Mail (2.1257) Cc: dane@ietf.org Subject: Re: [dane] Network errors ARE attacks - on the end-to-end-principle X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 16 May 2012 23:22:00 -0000 On May 16, 2012, at 11:19 AM, Andrew Sullivan wrote: > On Tue, May 15, 2012 at 07:13:16PM -0700, John Gilmore wrote: >=20 >> "Genuine network errors" from buggy proxies or intentional firewalls >> or intentional or accidental censorship systems ARE attacks. They = are >> attacks on the fundamental end-to-end premise of the Internet. >=20 > But (1) bugs are different from intentional blockage and (2) not all > of this is strictly speaking buggy. The fact that some ancient > gateway can't cope with RRTYPEs it doesn't know is, IMO, a disgrace; > but they can say (correctly) that they just don't implement that RFC, > and be quite right. I would like the market to reject such devices as > useless, but it hasn't yet. >=20 >> But the end result will be that (1) users will realize they are being >> censored; (2) providers will clean up the accidental and whim-related >> censorship; and (3) users will migrate to providers who offer them >> reliable end-to-end service without interruptions for the provider's >> convenience or profit. >=20 > I suppose that the above is intended to argue that the market will > reject such devices as useless. I think we have a first mover > principle in the way, however. These "users" of which you speak would > need to form a fairly detailed theory of operation of the Internet in > order to understand what the problem is. I don't believe that most of > them will, and I don't think they ought to need to either. Therefore, > I would prefer that we build documents that permit useful incremental > addition of features to the network. >=20 > To drag this back on topic, Thank you -- I was away from mail for part of today and this thread was = going *way* off-topic=85 *Please*, lets try and keep this (and other threads on dane@) on-topic, = and civil=85. > in light of the above I need to think > harder about the argument, elsewhere in this thread, that uses 2 and 3 > are also undermined by the no-answer attack, because if that's the > case then I suspect DANE is undeployable as it stands. >=20 > Best, >=20 > A >=20 > --=20 > Andrew Sullivan > ajs@anvilwalrusden.com > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane >=20 From marka@isc.org Wed May 16 19:38:27 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FD2021F86CA for ; Wed, 16 May 2012 19:38:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.164 X-Spam-Level: X-Spam-Status: No, score=-2.164 tagged_above=-999 required=5 tests=[AWL=0.435, 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 uR060lUAcaNH for ; Wed, 16 May 2012 19:38:26 -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 1F32821F8682 for ; Wed, 16 May 2012 19:38:26 -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 "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id 026485F9A1F; Thu, 17 May 2012 02:38:11 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:4d9d:63d1:95fc:acb8]) (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 46B04216C36; Thu, 17 May 2012 02:38:09 +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 AE67F20AEDB1; Thu, 17 May 2012 12:38:06 +1000 (EST) To: Peter van Dijk From: Mark Andrews References: <20120309184424.5853.82819.idtracker@ietfa.amsl.com> <72C87898-41D6-45B0-B4F8-EEACED13BA66@vpnc.org> <0E4DEE78-EF31-405D-B1B2-49093A24B4EB@netherlabs.nl> In-reply-to: Your message of "Wed, 16 May 2012 22:04:06 +0200." Date: Thu, 17 May 2012 12:38:06 +1000 Message-Id: <20120517023806.AE67F20AEDB1@drugs.dv.isc.org> Cc: IETF DANE WG list Subject: Re: [dane] local-part case-sensitivity (was: draft-hoffman-dane-smime-03.txt) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2012 02:38:30 -0000 In message , Peter van Dijk writes: > Hello Paul, > > On May 16, 2012, at 21:53 , Paul Hoffman wrote: > > > I am completely confused here. The current draft says: > > 1. The user name (the "left-hand side" of the email address, called > > the "local-part" in [RFC2822] and the "local part" in [RFC6530]), > > is encoded with Base32 [RFC4648], to become the left-most label > > in the prepared domain name. This does not include the "@" > > character that separates the left and right sides of the email > > address. > > This preserves any case in the local part. Your suggestion (1) destroys the > case. It is also not valid for local parts that do not have clean lower-casi > ng rules; we went through this mess with IDNA2003. > > > I will try to clarify. Base32 certainly preserves case, and in that sense app > ears to honor the case-sensitivity requirement in 2822/6530. > > However, most (if not almost all) mail servers on the internet treat chris@ex > ample.com and Chris@example.com as the same user - and 2822/6530 do not prohi > bit this. If we base32-encode 'chris' but the user chooses to mail from 'Chri > s', the DNS lookup will not match and his S/MIME cert cannot be verified. You can down case the lookup and return multiple certs with different cases in the appropriate field in the cert itself. The client just needs to do a little bit more work to pick out the correct cert from the DNS response. Now I don't know if a cert can specify that it should be matched case insenitively for the local field or not but if the system treats the local part as being case insensitive that should be reflected in the cert or else there are already lots of mis-match issues. > I cannot conceive of an encoding scheme that honors case-sensitivity without > hampering the 99% of implementations that are actually case insensitive. Base > 32 enforces case-sensitivity, which breaks most implementations; a more plain > encoding (like encoding 'chris' as 'chris') (apart from having other issues > - the exact reason you went with base32) would be case-insensitive and would > thus violate 2822/6530. > > Kind regards, > -- > Peter van Dijk > Netherlabs Computer Consulting BV - http://www.netherlabs.nl/ > > _______________________________________________ > 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 internet-drafts@ietf.org Thu May 17 10:30:17 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2749C21F870B; Thu, 17 May 2012 10:30:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.229 X-Spam-Level: X-Spam-Status: No, score=-102.229 tagged_above=-999 required=5 tests=[AWL=0.370, 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 t0BEFESQhhb5; Thu, 17 May 2012 10:30:16 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7869021F86C7; Thu, 17 May 2012 10:30:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120517173016.16297.41396.idtracker@ietfa.amsl.com> Date: Thu, 17 May 2012 10:30:16 -0700 Cc: dane@ietf.org Subject: [dane] I-D Action: draft-ietf-dane-protocol-21.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2012 17:30:17 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the DNS-based Authentication of Named Ent= ities Working Group of the IETF. Title : The DNS-Based Authentication of Named Entities (DANE) Tr= ansport Layer Security (TLS) Protocol: TLSA Author(s) : Paul Hoffman Jakob Schlyter Filename : draft-ietf-dane-protocol-21.txt Pages : 37 Date : 2012-05-17 Encrypted communication on the Internet often uses Transport Level Security (TLS), which depends on third parties to certify the keys used. This document improves on that situation by enabling the administrators of domain names to specify the keys used in that domain's TLS servers. This requires matching improvements in TLS client software, but no change in TLS server software. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dane-protocol-21.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-dane-protocol-21.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-dane-protocol/ From iesg-secretary@ietf.org Thu May 17 14:02:20 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2288F21F84F0; Thu, 17 May 2012 14:02:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.433 X-Spam-Level: X-Spam-Status: No, score=-102.433 tagged_above=-999 required=5 tests=[AWL=0.166, 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 D+DODFVOtVMF; Thu, 17 May 2012 14:02:19 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A04521F879F; Thu, 17 May 2012 14:02:19 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120517210219.20276.61908.idtracker@ietfa.amsl.com> Date: Thu, 17 May 2012 14:02:19 -0700 Cc: dane@ietf.org Subject: [dane] Last Call: (The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA) to Proposed Standard X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2012 21:02:20 -0000 The IESG has received a request from the DNS-based Authentication of Named Entities WG (dane) to consider the following document: - 'The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA' as Proposed Standard This is a 2nd IETF LC on this document. The reason is that there were quite a few text changes, though no protocol changes, as a result of the 1st IETF LC and we'd like to check if the comments have been addressed in an acceptable (note: not perfectl!) manner. The difference between -19 and -21 can be seen at: https://tools.ietf.org/rfcdiff?url1=draft-ietf-dane-protocol-19&difftype=--html&submit=Go!&url2=draft-ietf-dane-protocol-21 The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-05-31. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Encrypted communication on the Internet often uses Transport Level Security (TLS), which depends on third parties to certify the keys used. This document improves on that situation by enabling the administrators of domain names to specify the keys used in that domain's TLS servers. This requires matching improvements in TLS client software, but no change in TLS server software. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-dane-protocol/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-dane-protocol/ballot/ No IPR declarations have been submitted directly on this I-D. From stephen.farrell@cs.tcd.ie Thu May 17 14:08:19 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 410C721F8754 for ; Thu, 17 May 2012 14:08:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.277 X-Spam-Level: X-Spam-Status: No, score=-102.277 tagged_above=-999 required=5 tests=[AWL=0.322, 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 CH27q7rKSUt8 for ; Thu, 17 May 2012 14:08:17 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 3BBB821F8740 for ; Thu, 17 May 2012 14:08:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 53C8B153579 for ; Thu, 17 May 2012 22:08:14 +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=1337288892; bh=11qwgCPa78l8Ge P75yAmMeJ+eZ6ImW/+3BrSWmUo/+U=; b=eSOJ5cm2n07neOGIRr0R/CKu2frDhv PR241sbDEvGo/3XsjWixYhnsPA6LPOhWSJp2JHaV4t2+mRxjFcFxhojqjh5S83lx 0HG0vdnGz6X/N5AUZycCkuZvFFhI09zzjzX3TSCkEvHf3fO7Grh7DWtfOKafCGCT szNNNyPQy3QJNJbmxF4fg2+r6DAMqhr+aozIhvskvXJGpmCwO3VQBc6bAT9tEs6U znzZgg5OI6F0TmRKpkQcDaZQYCZWXRge2MHgDDb9QyZ0xBy/Co94Lqgj2E0S1KEe aaCuOLpdloPIRC6ij5aK9lXnku9Us9/KPp5B0vHnn13oluSNSJ4wKUhA== 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 mroYCnWO9Yks for ; Thu, 17 May 2012 22:08:12 +0100 (IST) Received: from [10.87.48.4] (unknown [86.44.70.59]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id B37FA171590 for ; Thu, 17 May 2012 22:08:12 +0100 (IST) Message-ID: <4FB568BB.4030207@cs.tcd.ie> Date: Thu, 17 May 2012 22:08:11 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: dane References: <20120517210219.20276.61908.idtracker@ietfa.amsl.com> In-Reply-To: <20120517210219.20276.61908.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.4.1 X-Forwarded-Message-Id: <20120517210219.20276.61908.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [dane] Fwd: Last Call: (The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA) to Proposed Standard X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 17 May 2012 21:08:19 -0000 Hi, Given the numerous changes a few folks asked me to do another IETF LC and I think that's fair enough. In the event that we have managed to achieve IETF conensus on this (which I hope will be the case), this IETF LC won't delay anything since the earliest the draft would in any case be on an IESG agenda is in three weeks time. Lastly, pretty-please - can we try to keep the discussion on topic, and limited to the delta between -19 and -21? Oh, and <1000 mails would be nice too:-) Cheers, S. -------- Original Message -------- Subject: Last Call: (The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA) to Proposed Standard Date: Thu, 17 May 2012 14:02:19 -0700 From: The IESG Reply-To: ietf@ietf.org To: IETF-Announce CC: dane@ietf.org The IESG has received a request from the DNS-based Authentication of Named Entities WG (dane) to consider the following document: - 'The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA' as Proposed Standard This is a 2nd IETF LC on this document. The reason is that there were quite a few text changes, though no protocol changes, as a result of the 1st IETF LC and we'd like to check if the comments have been addressed in an acceptable (note: not perfectl!) manner. The difference between -19 and -21 can be seen at: https://tools.ietf.org/rfcdiff?url1=draft-ietf-dane-protocol-19&difftype=--html&submit=Go!&url2=draft-ietf-dane-protocol-21 The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-05-31. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Encrypted communication on the Internet often uses Transport Level Security (TLS), which depends on third parties to certify the keys used. This document improves on that situation by enabling the administrators of domain names to specify the keys used in that domain's TLS servers. This requires matching improvements in TLS client software, but no change in TLS server software. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-dane-protocol/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-dane-protocol/ballot/ No IPR declarations have been submitted directly on this I-D. From hallam@gmail.com Mon May 21 05:59:57 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E4C521F859E for ; Mon, 21 May 2012 05:59:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.11 X-Spam-Level: X-Spam-Status: No, score=-2.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, 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 J6LIlCJW9DE9 for ; Mon, 21 May 2012 05:59:56 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 990AA21F8573 for ; Mon, 21 May 2012 05:59:56 -0700 (PDT) Received: by obbeh20 with SMTP id eh20so10070653obb.31 for ; Mon, 21 May 2012 05:59:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=i6EglfE4h6JZtCxjVEnVDfBn/q0rNApyz7PfhDSU+Rc=; b=N88nXw1FxzjXPO4d+axrSHEO2Pt2y7+iLnsm6qxKD0qHJzRV+WCrFe3vgGbBd3L5Vp mLBBloH3dlg9p9Q3FLJ2KkluWSOiL4L20to9II+MfVfg4UnzBxMwlQPjiLXeXDw+cVts xGHSphUSwNI0nZpmywN66MlukmRlVDpDcV9Fb1imPZXt9ASuajjZtAWgVbWeYSwfB64e iVzJ5eNjUa8q8ff0rEiKv+mZjxaeOfliOMnng9CgdqaFe0R3zJaSJXJngoIMaom/skIb 89o/LKUOxKHZiYmjo8KPYXWHUFU6CA0blxuFbTckFIS9eT/dkLhmcgDNeI//6f08Ho0a 1F5A== MIME-Version: 1.0 Received: by 10.182.2.193 with SMTP id 1mr19165823obw.46.1337605196178; Mon, 21 May 2012 05:59:56 -0700 (PDT) Received: by 10.182.227.34 with HTTP; Mon, 21 May 2012 05:59:56 -0700 (PDT) In-Reply-To: References: <201205160943.q4G9hXOJ017665@fs4113.wdf.sap.corp> <1C09F467-004B-4EB7-87C2-92CBDF74E967@checkpoint.com> Date: Mon, 21 May 2012 08:59:56 -0400 Message-ID: From: Phillip Hallam-Baker To: Henry Story Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "dane@ietf.org" Subject: Re: [dane] Network errors ARE attacks - on the end-to-end-principle X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 21 May 2012 12:59:57 -0000 No, his rather emotional account is wrong. If Gilmore was right then Tor would also be an attack on the Internet architecture. It isn't. Before arguing the end to end principle, I suggest that people actually wrote what David Clarke wrote rather than second hand lore. It is actually an argument about complexity and the cost/benefit tradeoffs that result from placing complexity in one place or the other. David is a pragmatist, not an ideologue. Without NAT, the Internet would have run out of IPv4 addresses over ten years ago. Since the design of IPv6 was intended to prevent OSI networking from winning the standards race rather than actually meeting the address space crunch, a solution like NAT was inevitable. Firewalls have an important function, one that is fully understood and accepted in the INTER-NETWORKING protocols. The core concept of the internet is not the end-to-end principle but the idea that the inter-net is a network of networks. The only core principles of the Internet are that all the systems use the DNS for naming and IP is used to exchange messages between networks. End-to-End IP is not and never has been a core principle of the Internet as deployed. Until 1993 when the Web appeared there was an expectation that it would take another decade at least before networks all converged on using just IP. Email was not designed as an end to end protocol, it had to contend with a dozen WAN and LAN protocols. It was only when the Web arrived with the encyclopedia galactica online but only if you had IP, that the tipping point was established and there was an advantage to TCP/IP end to end. But even the Web was designed with the concept of proxies from the start. A border firewall delineates the boundary between the network I control and the network that I do not control and am not responsible for. It is an obviously necessary function. I have over 50 IP connected devices on my home network and that will almost certainly rise to 100 as IP enabled phones and thermostats and temperature monitors are deployed. I do not want to spend any time worrying about applying patches to such devices. They do not require unrestricted network access, therefore by the principle of least privilege they must not have it. On Wed, May 16, 2012 at 7:55 AM, Henry Story wrot= e: > > On 16 May 2012, at 12:31, Yoav Nir wrote: > >> >> On May 16, 2012, at 12:43 PM, Martin Rex wrote: >> >>> John Gilmore wrote: >>>> >>>>> But it's better then disabling TLSA at all in the face >>>>> of DNS errors (where we assume most errors are genuine network errors >>>>> and not attacks). >>>> >>>> "Genuine network errors" from buggy proxies or intentional firewalls >>>> or intentional or accidental censorship systems ARE attacks. =A0They a= re >>>> attacks on the fundamental end-to-end premise of the Internet. >>> >>> Where have you been during the last 10 years? >>> There is no such thing an a "fundamental end-to-end premise" on the >>> Internet. =A0And if it ever existed, it ceased to exist ~10 years ago. >> >> 15. Most networks have a NAT, including almost all home networks. Most c= orporate networks have some kind of firewall. If you want end-to-end, you h= ave to roll your own through IPsec or TLS, and even then you're likely to g= et load balancers at the server side, and the occasional decrypting proxy o= n the client side. > > The point of John Gilmore's inspirational mail is that end-to-end is the = aim of > the architecture of the internet. It is because it was architected for en= d to > end communication that it has had such positive effects. The reasons thes= e working > groups exist is to remove the technical reasons for this not always being= possible, such > as by for example working on ipv6. =A0When the technical reasons have bee= n moved out of the > way the network effects and political pressure can be built up to solve t= he deployment > problems. Luckily the network effect works in favour of those who work fo= r freedom. > > Henry > >> >> Yoav >> _______________________________________________ >> 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 --=20 Website: http://hallambaker.com/ From fanf2@hermes.cam.ac.uk Fri May 25 10:15:39 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E71C921F8750 for ; Fri, 25 May 2012 10:15: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=[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 NmC33IgxpyxE for ; Fri, 25 May 2012 10:15:39 -0700 (PDT) Received: from ppsw-51.csi.cam.ac.uk (ppsw-51.csi.cam.ac.uk [131.111.8.151]) by ietfa.amsl.com (Postfix) with ESMTP id D9BC321F874F for ; Fri, 25 May 2012 10:15:38 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:49881) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:fanf2) id 1SXy6y-00046A-Yv (Exim 4.72) (return-path ); Fri, 25 May 2012 18:15:36 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1SXy6y-00013r-MC (Exim 4.67) (return-path ); Fri, 25 May 2012 18:15:36 +0100 Date: Fri, 25 May 2012 18:15:36 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: dane@ietf.org, ietf-smtp@imc.org Message-ID: User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Subject: [dane] draft-fanf-dane-smtp X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 25 May 2012 17:15:40 -0000 I have just submitted an I-D describing how to use DANE with SMTP. All comments welcome. Tony. -- f.anthony.n.finch http://dotat.at/ Hebrides, Bailey: Northeasterly in Hebrides at first, otherwise southeasterly 4 or 5. Slight or moderate. Fog patches. Moderate, occasionally very poor. ---------- Forwarded message ---------- Date: Fri, 25 May 2012 10:10:23 -0700 From: internet-drafts@ietf.org To: dot@dotat.at Subject: New Version Notification for draft-fanf-dane-smtp-00.txt A new version of I-D, draft-fanf-dane-smtp-00.txt has been successfully submitted by Tony Finch and posted to the IETF repository. Filename: draft-fanf-dane-smtp Revision: 00 Title: Secure inter-domain SMTP with TLS, DNSSEC and TLSA records. Creation date: 2012-05-25 WG ID: Individual Submission Number of pages: 8 Abstract: SMTP supports STARTTLS for inter-domain mail transfer, but it only provides very limited security because the server's certificate cannot be authenticated. This memo specifies how TLSA records in the DNS can be used for proper MX target server authentication. The IETF Secretariat From ned.freed@mrochek.com Fri May 25 11:42:27 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CC6121F8781 for ; Fri, 25 May 2012 11:42:27 -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 E+e5nH54ErCV for ; Fri, 25 May 2012 11:42:26 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 14C4521F8782 for ; Fri, 25 May 2012 11:42:26 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OFWCYKMNQO002EOA@mauve.mrochek.com> for dane@ietf.org; Fri, 25 May 2012 11:42:16 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OFQWV49GTC0006TF@mauve.mrochek.com>; Fri, 25 May 2012 11:42:08 -0700 (PDT) Message-id: <01OFWCYFVKQ80006TF@mauve.mrochek.com> Date: Fri, 25 May 2012 11:38:54 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Fri, 25 May 2012 18:15:36 +0100" MIME-version: 1.0 Content-type: TEXT/PLAIN References: To: Tony Finch Cc: ietf-smtp@imc.org, dane@ietf.org Subject: Re: [dane] draft-fanf-dane-smtp X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 25 May 2012 18:42:27 -0000 Just read through it. I think the approach is correct, in particular the choice to put the TLSA at the server host name level rather than the mail domain level is the correct one. As you explain in Appendix A, this is the only way it can work given the use of cross-ADMD MXes for things like secondary service. You might want to put something in the security considerations section about the trust involved when you have a signed MX pointing to a secondary outside your ADMD. Ned > I have just submitted an I-D describing how to use DANE with SMTP. All > comments welcome. > Tony. > -- > f.anthony.n.finch http://dotat.at/ > Hebrides, Bailey: Northeasterly in Hebrides at first, otherwise southeasterly > 4 or 5. Slight or moderate. Fog patches. Moderate, occasionally very poor. > ---------- Forwarded message ---------- > Date: Fri, 25 May 2012 10:10:23 -0700 > From: internet-drafts@ietf.org > To: dot@dotat.at > Subject: New Version Notification for draft-fanf-dane-smtp-00.txt > A new version of I-D, draft-fanf-dane-smtp-00.txt has been successfully submitted by Tony Finch and posted to the IETF repository. > Filename: draft-fanf-dane-smtp > Revision: 00 > Title: Secure inter-domain SMTP with TLS, DNSSEC and TLSA records. > Creation date: 2012-05-25 > WG ID: Individual Submission > Number of pages: 8 > Abstract: > SMTP supports STARTTLS for inter-domain mail transfer, but it only > provides very limited security because the server's certificate > cannot be authenticated. This memo specifies how TLSA records in the > DNS can be used for proper MX target server authentication. > The IETF Secretariat From fanf2@hermes.cam.ac.uk Fri May 25 11:46:00 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E6AB21F873B for ; Fri, 25 May 2012 11:46:00 -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 cXVdJTmif6yF for ; Fri, 25 May 2012 11:45:59 -0700 (PDT) Received: from ppsw-52.csi.cam.ac.uk (ppsw-52.csi.cam.ac.uk [131.111.8.152]) by ietfa.amsl.com (Postfix) with ESMTP id AD66421F8736 for ; Fri, 25 May 2012 11:45:59 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:35938) by ppsw-52.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1SXzWP-0007rN-Ff (Exim 4.72) (return-path ); Fri, 25 May 2012 19:45:57 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1SXzWP-0003ty-Qc (Exim 4.67) (return-path ); Fri, 25 May 2012 19:45:57 +0100 Date: Fri, 25 May 2012 19:45:57 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Ned Freed In-Reply-To: <01OFWCYFVKQ80006TF@mauve.mrochek.com> Message-ID: References: <01OFWCYFVKQ80006TF@mauve.mrochek.com> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: ietf-smtp@imc.org, dane@ietf.org Subject: Re: [dane] draft-fanf-dane-smtp X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 25 May 2012 18:46:00 -0000 Ned Freed wrote: > Just read through it. I think the approach is correct Thanks for the quick review :-) > You might want to put something in the security considerations section > about the trust involved when you have a signed MX pointing to a > secondary outside your ADMD. A good suggestion, thanks again. Tony. -- f.anthony.n.finch http://dotat.at/ Sole, Lundy, Fastnet, Irish Sea, Shannon: Easterly or northeasterly 5 to 7, occasionally gale 8. Moderate or rough. Thundery showers. Moderate or good, occasionally poor. From warren@kumari.net Fri May 25 13:51:10 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5740A21F87E4 for ; Fri, 25 May 2012 13:51:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.449 X-Spam-Level: X-Spam-Status: No, score=-106.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 nZs7AlDZxUy7 for ; Fri, 25 May 2012 13:51:09 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 7C9EE21F87DE for ; Fri, 25 May 2012 13:51:09 -0700 (PDT) Received: from [192.168.0.12] (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id 09BCE1B40180; Fri, 25 May 2012 16:51:07 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: Warren Kumari In-Reply-To: <01OFWCYFVKQ80006TF@mauve.mrochek.com> Date: Fri, 25 May 2012 16:51:27 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <23815EAC-DFB4-4A9A-8DEA-D9664FFFAD27@kumari.net> References: <01OFWCYFVKQ80006TF@mauve.mrochek.com> To: Ned Freed X-Mailer: Apple Mail (2.1278) Cc: ietf-smtp@imc.org, dane@ietf.org Subject: Re: [dane] draft-fanf-dane-smtp X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 25 May 2012 20:51:10 -0000 On May 25, 2012, at 2:38 PM, Ned Freed wrote: > Just read through it. And I haven't read it yet (blush), other than the intro, but wanted to = say thanks to Tony for submitting this -- we had discussed having the = "How to do DANE with " series, but hadn't made much progress yet=85 W > I think the approach is correct, in particular the > choice to put the TLSA at the server host name level rather than the = mail > domain level is the correct one. As you explain in Appendix A, this is = the > only way it can work given the use of cross-ADMD MXes for things like > secondary service. >=20 > You might want to put something in the security considerations section = about > the trust involved when you have a signed MX pointing to a secondary = outside=20 > your ADMD. >=20 > Ned >=20 >> I have just submitted an I-D describing how to use DANE with SMTP. = All >> comments welcome. >=20 >=20 >> Tony. >> -- >> f.anthony.n.finch http://dotat.at/ >> Hebrides, Bailey: Northeasterly in Hebrides at first, otherwise = southeasterly >> 4 or 5. Slight or moderate. Fog patches. Moderate, occasionally very = poor. >=20 >> ---------- Forwarded message ---------- >> Date: Fri, 25 May 2012 10:10:23 -0700 >> From: internet-drafts@ietf.org >> To: dot@dotat.at >> Subject: New Version Notification for draft-fanf-dane-smtp-00.txt >=20 >> A new version of I-D, draft-fanf-dane-smtp-00.txt has been = successfully submitted by Tony Finch and posted to the IETF repository. >=20 >> Filename: draft-fanf-dane-smtp >> Revision: 00 >> Title: Secure inter-domain SMTP with TLS, DNSSEC and = TLSA records. >> Creation date: 2012-05-25 >> WG ID: Individual Submission >> Number of pages: 8 >=20 >> Abstract: >> SMTP supports STARTTLS for inter-domain mail transfer, but it only >> provides very limited security because the server's certificate >> cannot be authenticated. This memo specifies how TLSA records in = the >> DNS can be used for proper MX target server authentication. >=20 >=20 >=20 >=20 >> The IETF Secretariat >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane >=20 From rbarnes@bbn.com Fri May 25 14:09:14 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B10E21F8813 for ; Fri, 25 May 2012 14:09:14 -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 p0syt2pIjL5Y for ; Fri, 25 May 2012 14:09:13 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id C96F221F8812 for ; Fri, 25 May 2012 14:09:13 -0700 (PDT) Received: from ros-dhcp192-1-51-6.bbn.com ([192.1.51.6]:55991) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SY1kU-0005Ap-W8; Fri, 25 May 2012 17:08:39 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <01OFWCYFVKQ80006TF@mauve.mrochek.com> Date: Fri, 25 May 2012 17:09:09 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <01OFWCYFVKQ80006TF@mauve.mrochek.com> To: Ned Freed X-Mailer: Apple Mail (2.1278) Cc: dane@ietf.org Subject: Re: [dane] draft-fanf-dane-smtp X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 25 May 2012 21:09:14 -0000 I don't really see the need to rule out the use of TLSA records under = the MX name instead of the server name. As long as they're signed, they = don't create any additional vulnerability. In fact, if you could = provision signed TLSA, you don't really need signed MX. --Richard =20 On May 25, 2012, at 2:38 PM, Ned Freed wrote: > Just read through it. I think the approach is correct, in particular = the > choice to put the TLSA at the server host name level rather than the = mail > domain level is the correct one. As you explain in Appendix A, this is = the > only way it can work given the use of cross-ADMD MXes for things like > secondary service. >=20 > You might want to put something in the security considerations section = about > the trust involved when you have a signed MX pointing to a secondary = outside=20 > your ADMD. >=20 > Ned >=20 >> I have just submitted an I-D describing how to use DANE with SMTP. = All >> comments welcome. >=20 >=20 >> Tony. >> -- >> f.anthony.n.finch http://dotat.at/ >> Hebrides, Bailey: Northeasterly in Hebrides at first, otherwise = southeasterly >> 4 or 5. Slight or moderate. Fog patches. Moderate, occasionally very = poor. >=20 >> ---------- Forwarded message ---------- >> Date: Fri, 25 May 2012 10:10:23 -0700 >> From: internet-drafts@ietf.org >> To: dot@dotat.at >> Subject: New Version Notification for draft-fanf-dane-smtp-00.txt >=20 >> A new version of I-D, draft-fanf-dane-smtp-00.txt has been = successfully submitted by Tony Finch and posted to the IETF repository. >=20 >> Filename: draft-fanf-dane-smtp >> Revision: 00 >> Title: Secure inter-domain SMTP with TLS, DNSSEC and = TLSA records. >> Creation date: 2012-05-25 >> WG ID: Individual Submission >> Number of pages: 8 >=20 >> Abstract: >> SMTP supports STARTTLS for inter-domain mail transfer, but it only >> provides very limited security because the server's certificate >> cannot be authenticated. This memo specifies how TLSA records in = the >> DNS can be used for proper MX target server authentication. >=20 >=20 >=20 >=20 >> The IETF Secretariat >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From fanf2@hermes.cam.ac.uk Fri May 25 14:58:23 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A049521F87F1 for ; Fri, 25 May 2012 14:58:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ipE9QYFPDrCp for ; Fri, 25 May 2012 14:58:22 -0700 (PDT) Received: from ppsw-41.csi.cam.ac.uk (ppsw-41.csi.cam.ac.uk [131.111.8.141]) by ietfa.amsl.com (Postfix) with ESMTP id 92C6A21F87DD for ; Fri, 25 May 2012 14:58:22 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from host86-163-247-136.range86-163.btcentralplus.com ([86.163.247.136]:56143 helo=[192.168.1.66]) by ppsw-41.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:587) with esmtpsa (PLAIN:fanf2) (TLSv1:AES128-SHA:128) id 1SY2WZ-00016B-Qj (Exim 4.72) (return-path ); Fri, 25 May 2012 22:58:20 +0100 References: <01OFWCYFVKQ80006TF@mauve.mrochek.com> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (9B206) From: Tony Finch Date: Fri, 25 May 2012 22:58:09 +0100 To: "Richard L. Barnes" Sender: Tony Finch Cc: Ned Freed , "dane@ietf.org" Subject: Re: [dane] draft-fanf-dane-smtp X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 25 May 2012 21:58:23 -0000 On 25 May 2012, at 22:09, "Richard L. Barnes" wrote: > I don't really see the need to rule out the use of TLSA records under the M= X name instead of the server name. Please read the appendix. Tony. -- f.anthony.n.finch http://dotat.at/= From ned.freed@mrochek.com Fri May 25 23:22:03 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5234221F864C for ; Fri, 25 May 2012 23:22:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 5x3jZovQcnHo for ; Fri, 25 May 2012 23:22:02 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 7286F21F864B for ; Fri, 25 May 2012 23:22:02 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OFX1DZGRWG001YZ9@mauve.mrochek.com> for dane@ietf.org; Fri, 25 May 2012 23:21:54 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OFQWV49GTC0006TF@mauve.mrochek.com>; Fri, 25 May 2012 23:21:41 -0700 (PDT) Message-id: <01OFX1DRMJUY0006TF@mauve.mrochek.com> Date: Fri, 25 May 2012 23:07:55 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Fri, 25 May 2012 22:58:09 +0100" MIME-version: 1.0 Content-type: TEXT/PLAIN References: <01OFWCYFVKQ80006TF@mauve.mrochek.com> To: Tony Finch Cc: Ned Freed , "dane@ietf.org" Subject: Re: [dane] draft-fanf-dane-smtp X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 26 May 2012 06:22:03 -0000 > On 25 May 2012, at 22:09, "Richard L. Barnes" wrote: > > I don't really see the need to rule out the use of TLSA records under the MX name instead of the server name. > Please read the appendix. To be fair, the appendix is more about why host name TLSA records have to be supported, not why you couldn't support domain TLSA records as well. The main problem with having both is it complicates things considerably with no real added benefit, and that's a really bad thing to do in a security protocol like this. And part of that added complexity is understanding that, as Appendix A points out, there are real-world use cases where domain TLSA records cannot be made to work. This creates complicated criteria for when they domain MX records can be used and when they cannot. Finally, one of the advantages of host name TLSA records is they require no additional SMTP server functionality. In order to use domain TLSA records Server Name Indication support is nearly essential, and in my experience at least support for this extension is currently uncommon. Requiring server as well as client upgrades also seems like a bad idea. Ned From cloos@jhcloos.com Sat May 26 17:24:38 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BF2821F84CE for ; Sat, 26 May 2012 17:24:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.672 X-Spam-Level: X-Spam-Status: No, score=-1.672 tagged_above=-999 required=5 tests=[AWL=0.927, 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 0spIHkqBPlUQ for ; Sat, 26 May 2012 17:24:37 -0700 (PDT) Received: from eagle.jhcloos.com (eagle.jhcloos.com [207.210.242.212]) by ietfa.amsl.com (Postfix) with ESMTP id D184521F847D for ; Sat, 26 May 2012 17:24:37 -0700 (PDT) Received: by eagle.jhcloos.com (Postfix, from userid 10) id F215A40164; Sun, 27 May 2012 00:24:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=eagle; t=1338078277; bh=2uts5n5Gn4uYLmqPRfWFXu+lD/27rbsHEM3ogC6ty04=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=Xvh/vVkLdENv52xgG1TB0YYJwyRWyKljPcWv67kM9iDj4Ebk1avYXBPuBT0qXWHm4 yN4ED8Pjx3B02yaujWOf2HbtNPHGdFju0Lj9izmG+24SMe4ubb6snAub0CLrOCp9Fa 5yXwmGjk1GbOOQRLnt2BBH97YxK2P3GpcwAEAY3s= Received: by carbon.jhcloos.org (Postfix, from userid 500) id E2F8936004B; Sun, 27 May 2012 00:13:46 +0000 (UTC) From: James Cloos To: Tony Finch In-Reply-To: (Tony Finch's message of "Fri, 25 May 2012 18:15:36 +0100") References: User-Agent: Gnus/5.130004 (Ma Gnus v0.4) Emacs/24.1.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2012 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: Sat, 26 May 2012 20:13:45 -0400 Message-ID: Lines: 17 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Hashcash: 1:30:120527:dot@dotat.at::duFoP587ODpssNY2:0000B8iNB X-Hashcash: 1:30:120527:dane@ietf.org::kr8CFvTEAP/ks8n+:000I3ZKL X-Hashcash: 1:30:120527:ietf-smtp@imc.org::dvqyPmIcHJqsnnvN:0000000000000000000000000000000000000000000Gmo5h Cc: ietf-smtp@imc.org, dane@ietf.org Subject: Re: [dane] draft-fanf-dane-smtp X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 27 May 2012 00:24:38 -0000 I've read the draft now. It looks good. §3 specifies that the hostname MUST be in the cert as an DNS-ID and also MAY be there as a CN-ID. I suspect there are enough MXs in use still using certs generated (with long validity periods) which were genreated back when only CN was used for the dns names. Should the draft allow either-or? Or is there too much precedent in the TLS specs to allow that in a new rfc? Otherwise it looks spot on. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From i.grok@comcast.net Sat May 26 19:52:59 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D05EE21F84E4 for ; Sat, 26 May 2012 19:52:59 -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 FYBCYD-UUkas for ; Sat, 26 May 2012 19:52:59 -0700 (PDT) Received: from qmta03.emeryville.ca.mail.comcast.net (qmta03.emeryville.ca.mail.comcast.net [76.96.30.32]) by ietfa.amsl.com (Postfix) with ESMTP id 4976C21F84C8 for ; Sat, 26 May 2012 19:52:59 -0700 (PDT) Received: from omta24.emeryville.ca.mail.comcast.net ([76.96.30.92]) by qmta03.emeryville.ca.mail.comcast.net with comcast id EqSp1j0031zF43QA3qsz3r; Sun, 27 May 2012 02:52:59 +0000 Received: from odin.ulthar.us ([68.33.77.0]) by omta24.emeryville.ca.mail.comcast.net with comcast id Eqsx1j00B00PQ6U8kqsyht; Sun, 27 May 2012 02:52:59 +0000 Received: from odin.ulthar.us (localhost [127.0.0.1]) by odin.ulthar.us (8.14.5/8.14.3) with ESMTP id q4R2qrV6004924 for ; Sat, 26 May 2012 22:52:53 -0400 Received: (from draco@localhost) by odin.ulthar.us (8.14.5/8.14.5/Submit) id q4R2qr3c004923 for dane@ietf.org; Sat, 26 May 2012 22:52:53 -0400 Date: Sat, 26 May 2012 22:52:53 -0400 From: Scott Schmit To: dane@ietf.org Message-ID: <20120527025253.GA16928@odin.ulthar.us> Mail-Followup-To: dane@ietf.org References: MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="G4iJoqBmSsgzjUCe" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] draft-fanf-dane-smtp X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 27 May 2012 02:53:00 -0000 --G4iJoqBmSsgzjUCe Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, May 26, 2012 at 08:13:45PM -0400, James Cloos wrote: > I've read the draft now. It looks good. I agree. > =A73 specifies that the hostname MUST be in the cert as an DNS-ID and > also MAY be there as a CN-ID. >=20 > I suspect there are enough MXs in use still using certs generated (with > long validity periods) which were genreated back when only CN was used > for the dns names. >=20 > Should the draft allow either-or? Or is there too much precedent in the > TLS specs to allow that in a new rfc? If there's no authentication today, then regenerating the cert shouldn't be a big deal. --=20 Scott Schmit --G4iJoqBmSsgzjUCe Content-Type: application/x-pkcs7-signature Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIIQJgYJKoZIhvcNAQcCoIIQFzCCEBMCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC DVcwggY0MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAe Fw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0 ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEp pC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9 b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54q zHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX 9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/ 4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8E BTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIw HwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wu Y29tL3Nmc2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIB FiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4IC AQAKgwh9eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8py TUnFsukDFUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMm CeUTyMyikfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIz uQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVm z/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT 5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lAp sbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076 khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8 J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRX un0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCBxswggYDoAMCAQICAwK+HTANBgkqhkiG 9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTExMDcxNzA1 MDQwNFoXDTEyMDcxNzExNDI1OVowYjEgMB4GA1UEDRMXNDY1MjU2LTBnRmI2Sk5ZWW44QnFW bUwxGzAZBgNVBAMMEmkuZ3Jva0Bjb21jYXN0Lm5ldDEhMB8GCSqGSIb3DQEJARYSaS5ncm9r QGNvbWNhc3QubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2AjLOMsBGaqN hv2FcRbfom/QCeKMXu5tUd1JY5oIDZe5y29stnd+se/zUlEkiVeMam4Jgo1c8yGNnwLVYc5/ 9xVi7Qg1Is5b9AB6aJWElJDw/jIdihymNZ2kwkSLT0wl/lzd0mXlwFJPRgQiRkmE6V0ZmjsQ jaVtllVleGBbMvmWPm92e+4Bju9P81kKz7Xr02ijETmaPdVsl+jmOaKPS8Y+2Lat2xus4Ked oJ/7aIWIpz1gRSKjAHSZ1Wmwi2TYUjYhZryChu9e1RWtqk1CycNoeusJ8xdEVN3WSnJ299w/ 3ltK/x/9rpj2j9ShQZVB4NnX6cjQs7pz1lVxvIkjcQIDAQABo4IDrTCCA6kwCQYDVR0TBAIw ADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQW BBQ29j2I0O8sRYi0So9NwwmT1caakDAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhR gjAdBgNVHREEFjAUgRJpLmdyb2tAY29tY2FzdC5uZXQwggIhBgNVHSAEggIYMIICFDCCAhAG CysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20v cG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJt ZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcg dG8gdGhlIENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4g Y29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUF BwICMIGPMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJp bGl0eSBhbmQgd2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFu ZCBMaW1pdGF0aW9ucyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAr oCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUH AQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFz czEvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0 cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQAZ5U0nL/2PQwsVfHgN7MVPbZEGzDzuj4Oy pTgz4XQFwPcCuy6U9sp1Dwmo3DyKX5nKN4xA7pslN+2Pl/kElGamX7zMCAH0xED0RTOLyk+v nDML4s+OUtWaYVnq1bZEp0F8Luq3zIslAYSebleyiz8M0EypZczsL5rOk86R2F9EYw1CBuFJ 5a4x0CmNu5o30fGNDFt+iXRlbJPp/KY25iUgVnBzJ4COT5kQjxn5lgr4t1I+BDCL5HQQ3h/8 2CzwrWVRBNb9Vqh9LL1ZtzYRt8JezoB6HkVvcKVNGlCZ+/MnvfMzPLwfbTDZC8o4d+4RH6aE LeGF2XmAOaenc/YRqm9oMYIClzCCApMCAQEwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQQIDAr4dMAkGBSsOAwIaBQCggdgwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTIwNTI3MDI1MjUzWjAjBgkqhkiG9w0BCQQxFgQUxug6XSY2 HJQaHGlKCQPiSwfoao8weQYJKoZIhvcNAQkPMWwwajALBglghkgBZQMEASowCwYJYIZIAWUD BAEWMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEABz6xnzQG hzTxGeW28diJQDfSVfXlBZ6CFd4lFXrDcy6JeXBm9P8DsvOmshTyHZnnzOKwNgw8CockW2Yk hpk2+LM98ryqD32RII/O2MmcBR0ydlVv8brzkon2L3pEEkrCjAGFdl8SRo/t8g7IlUDVCJcD YZLcP0Frk0RmLOVrSHvL2rBp8itDq6MI+NmfjOgkXat66gIQxerV8KdewchXHYIHZCoCU2c4 a6apdIZaQUrfoR+SZ3WljYiiAtrDywJfeqw5a/7TEHYBa9xnIKlchniSmJ82GCxJPwcHm34c 1TRINLzsht5msO5mi4gQAhtgzPl03oiC/J3tTYhUnTggHw== --G4iJoqBmSsgzjUCe-- From hsantos@isdg.net Sun May 27 15:44:58 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F11121F857D for ; Sun, 27 May 2012 15:44:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.193 X-Spam-Level: X-Spam-Status: No, score=-100.193 tagged_above=-999 required=5 tests=[AWL=-0.053, BAYES_20=-0.74, J_CHICKENPOX_66=0.6, 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 YlycNRPzJShe for ; Sun, 27 May 2012 15:44:57 -0700 (PDT) Received: from news.winserver.com (pop3.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 1C59921F84A0 for ; Sun, 27 May 2012 15:44:56 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3373; t=1338158689; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=MoGlw9QXtKlQ9q4xH8V7+Za6jDU=; b=o7DkDeGeIs2pbQHt/vQh cMNw8A5qtFg/AySolzg0sdgp0VBm1sAIJ8XRqgTTpJ1pY9AtegNBrapGJwZLX8zv iYdzewi9m5HCdHETrYnMxPHmyT7YsVi1Y4F3jwm6+2FRVSs6l5OafSvcf8aNS8hn 3frQhKClPKz+AxmAZSP+zHI= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for dane@ietf.org; Sun, 27 May 2012 18:44:49 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from opensite.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 2770505409.5632.4576; Sun, 27 May 2012 18:44:48 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3373; t=1338158646; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=pye/wFt HvglMRx79lx4w79MEgSjpdnM0VGJZN5l9js4=; b=A8VrSJ0nrjztkMrznsC93qp 7MfC+4ojJzceBnunT0H72CgJMc57ooyMb3N2Tq3sNOvDaVzFX4P2N39b+zzoz+1T UjRe66Q/t6SSiVYA0JWZa/CJjr2C/WWP8d262GjeA6oCRS5HAKi5bb4ufWuBQ1pX ppgFjujruRj0z1M9jgkk= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for dane@ietf.org; Sun, 27 May 2012 18:44:06 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3369378800.9800.6280; Sun, 27 May 2012 18:44:05 -0400 Message-ID: <4FC2AE5F.5010308@isdg.net> Date: Sun, 27 May 2012 18:44:47 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Tony Finch References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 28 May 2012 05:15:36 -0700 Cc: ietf-smtp@imc.org, dane@ietf.org Subject: Re: [dane] draft-fanf-dane-smtp X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 27 May 2012 22:44:58 -0000 Tony Finch wrote: > I have just submitted an I-D describing how to use DANE with SMTP. All > comments welcome. Hi Tony, I think an example should be added to make it clear what an possible implementator would be considering. Showing maybe where similar idea(s) is applied now. So if I read your document right, please correct, this would be akin to a BROWSER (interactive client) doing a "Common Name" check. If so, I seem to recall some SMTP clients, interactive clients as with a MUA, also doing a popup for the user, but I may lumping that with our own wcSMTPJr client we provide as a command line tool for sending a message, usually for testing. which has an option to check the "common name" is the same as the host provide to connect. Here an example run: D:\local> wcsmtpuser /site:mail.winserver.com wcSmtpUser 3.1 (c) 2004-2010 SSI (/? for help) - ini file : wcsmtpuser.ini - ini section : mail.winserver.com - server name : mail.winserver.com - user name : hector.santos - use ssl : YES - auth method : 1 * connecting to 208.247.131.9:25 S: 220-winserver.com Wildcat! ESMTP Server v6.4.454.1 ready S: 220-************** WARNING: FOR AUTHORIZED USE ONLY! ********************** S: 220-* THIS SYSTEM DO NOT AUTHORIZE THE USE OF ITS PROPRIETARY COMPUTERS * S: 220-* AND COMPUTER NETWORKS TO ACCEPT, TRANSMIT, OR DISTRIBUTE UNSOLICITED * S: 220-* BULK E-MAIL SENT FROM THE INTERNET. THIS SYSTEM WILL RESTRICT ACCESS * S: 220-* TO CAN-SPAM (US S. 877) COMPLIANT CLIENTS ONLY. * S: 220 ************************************************************************ C: EHLO hdev20.santronics.com S: 250-winserver.com, Pleased to meet you. S: 250-SIZE 10240000 S: 250-8BITMIME S: 250-SUBMITTER S: 250-ETRN S: 250-AUTH CRAM-MD5 LOGIN PLAIN PLAIN-MD5 SHA-1 S: 250-AUTH=LOGIN S: 250-HELP S: 250 STARTTLS C: STARTTLS S: 220 Ready to start TLS ** SSL Negotiated session ** Certicate Information File: secure.winserver.com.cert ** CERT Common Name : secure.winserver.com ** CERT Organization: secure.winserver.com ** CERT Valid Until : Dec 27 18:55:51 2012 GMT (Days Left: 214) ** CA Country : US ** CA Organiziation : GoDaddy.com, Inc. ** CA Common Name : Go Daddy Secure Certification Authority !! connection domain : mail.winserver.com !! common name : secure.winserver.com !! Certificate CONNECTION DOMAIN and COMMON NAME mismatch! Accept? Yes or No? My MX is mail.winserver.com but I have been using our secure.winserver.com sub-domain for the SSL certificate. wcSMTPjr has three options (per host section): Cert.Expired.Allow=0 # cert expiration check Cert.NoMatch.Server.Allow=0 # CN vs connecting host check Cert.NoMatch.Host.Allow=1 # CN vs PTR records of IP check So if the above make sense, how does this DANE-SMTP proposal help me, as an example like including the TLSA record that needs to be created? I guess, if anything else, there are two client suggestions to highlight: - Automated MTA (router) - Interactive MUA smtp client Like RFC5321 provides insight here, only with an MUA-SMTP client can you do "human" confirmation checks or graceful aborts without losing the message. The MUA-SMTP client may fail to send the message if any 55x is issued, like with a RCPT TO command. But with a MTA router, it continues. Make sense? Thanks -- HLS From hsantos@isdg.net Sun May 27 16:08:30 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8457121F8596 for ; Sun, 27 May 2012 16:08:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.964 X-Spam-Level: X-Spam-Status: No, score=-100.964 tagged_above=-999 required=5 tests=[AWL=0.771, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, 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 f28j8Ax7Q722 for ; Sun, 27 May 2012 16:08:29 -0700 (PDT) Received: from news.winserver.com (mail.catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 9CF3E21F8585 for ; Sun, 27 May 2012 16:08:29 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1007; t=1338160104; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=k08TOYqyP1f4/yRBPVwBzHN+ZBI=; b=hY2wzhe5gJDOB9U2dYoC kZs7mi/k8GSI1BqIImMgySfxiNtboaREL1MednQqvP5OPT+88W01/U9Qp9T19Cs+ KOwSJfYTgTpqfYjzy6I+iIDyQ7KWKIPQtRfO0U9xr56DVgHE1oYlZrhrMmbJGfy2 0wFL/CWKhxDhbcNG0umq3o4= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for dane@ietf.org; Sun, 27 May 2012 19:08:24 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from opensite.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 2771921071.5632.2952; Sun, 27 May 2012 19:08:23 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1007; t=1338160064; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=Y6/+Nry AsqBaPhOiIqk7N4WmUDVK/hz9/J3yLI4G3jM=; b=a7MTDl+qih6Uu/GiNzknOiO JcxkZ710LGcTp0msoMXsHK86XjfbWBust+EWl5UyCg7QDe184srjBsqL8VEnUggL 2J+jTZzuSpO8Ql9qXQE3ALm8Ak20RBuhq/gkDj2n+kUrWK+63nx39PAVa7a13cck W1f8GN2snMjU3b4vxr5w= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for dane@ietf.org; Sun, 27 May 2012 19:07:44 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3370796675.9802.6760; Sun, 27 May 2012 19:07:43 -0400 Message-ID: <4FC2B3E9.3020206@isdg.net> Date: Sun, 27 May 2012 19:08:25 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: James Cloos References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Mon, 28 May 2012 05:15:36 -0700 Cc: ietf-smtp@imc.org, dane@ietf.org Subject: Re: [dane] draft-fanf-dane-smtp X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 27 May 2012 23:08:30 -0000 James Cloos wrote: > I've read the draft now. It looks good. > > §3 specifies that the hostname MUST be in the cert as an DNS-ID and > also MAY be there as a CN-ID. > > I suspect there are enough MXs in use still using certs generated (with > long validity periods) which were genreated back when only CN was used > for the dns names. How this this apply to use usage of global wildcard certs? in additional, not a CA wildcard signed cert, but a unique domain? For example, I use secure.winserver.com for our HTTPS (web site) SSL for eCommence mainly, but since the FTP, SMTP, POP, NNTP and TELNET servers is running on the same machine so I use the same cert for their TLS capabilities or specific implicit SSL ports, if any, as well. If a TLSA record allows for an server authorized association of the CN=secure.winserver.com with the connecting host name, then I can see some worth in this dane-smtp proposal - from the client POV seeking a higher level of security. -- HLS From i.grok@comcast.net Mon May 28 09:09:33 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBF9021F85C6 for ; Mon, 28 May 2012 09:09: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 ORrGeH2C-fip for ; Mon, 28 May 2012 09:09:32 -0700 (PDT) Received: from qmta13.emeryville.ca.mail.comcast.net (qmta13.emeryville.ca.mail.comcast.net [76.96.27.243]) by ietfa.amsl.com (Postfix) with ESMTP id 6915421F8613 for ; Mon, 28 May 2012 09:09:32 -0700 (PDT) Received: from omta21.emeryville.ca.mail.comcast.net ([76.96.30.88]) by qmta13.emeryville.ca.mail.comcast.net with comcast id FTpZ1j0021u4NiLADU9YPJ; Mon, 28 May 2012 16:09:32 +0000 Received: from odin.ulthar.us ([68.33.77.0]) by omta21.emeryville.ca.mail.comcast.net with comcast id FU9W1j00H00PQ6U8hU9XKQ; Mon, 28 May 2012 16:09:32 +0000 Received: from odin.ulthar.us (localhost [127.0.0.1]) by odin.ulthar.us (8.14.5/8.14.3) with ESMTP id q4SG9RNr025479 for ; Mon, 28 May 2012 12:09:27 -0400 Received: (from draco@localhost) by odin.ulthar.us (8.14.5/8.14.5/Submit) id q4SG9Rv7025478 for dane@ietf.org; Mon, 28 May 2012 12:09:27 -0400 Date: Mon, 28 May 2012 12:09:27 -0400 From: Scott Schmit To: dane@ietf.org Message-ID: <20120528160927.GA24042@odin.ulthar.us> Mail-Followup-To: dane@ietf.org References: <4FC2AE5F.5010308@isdg.net> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="2oS5YaxWCcQjTEyO" Content-Disposition: inline In-Reply-To: <4FC2AE5F.5010308@isdg.net> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] draft-fanf-dane-smtp X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 28 May 2012 16:09:33 -0000 --2oS5YaxWCcQjTEyO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, May 27, 2012 at 06:44:47PM -0400, Hector Santos wrote: > My MX is mail.winserver.com but I have been using our > secure.winserver.com sub-domain for the SSL certificate. >=20 > So if the above make sense, how does this DANE-SMTP proposal help > me, as an example like including the TLSA record that needs to be > created? IMHO, you generate a self-signed certificate with a dnsname (and/or CN) of mail.winserver.com and use TLSA certificate usage 3. Based on your trace, your certificate isn't valid currently, so it shouldn't break anything. --=20 Scott Schmit --2oS5YaxWCcQjTEyO Content-Type: application/x-pkcs7-signature Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIIQJgYJKoZIhvcNAQcCoIIQFzCCEBMCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC DVcwggY0MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAe Fw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0 ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEp pC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9 b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54q zHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX 9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/ 4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8E BTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIw HwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wu Y29tL3Nmc2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIB FiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4IC AQAKgwh9eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8py TUnFsukDFUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMm CeUTyMyikfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIz uQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVm z/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT 5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lAp sbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076 khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8 J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRX un0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCBxswggYDoAMCAQICAwK+HTANBgkqhkiG 9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTExMDcxNzA1 MDQwNFoXDTEyMDcxNzExNDI1OVowYjEgMB4GA1UEDRMXNDY1MjU2LTBnRmI2Sk5ZWW44QnFW bUwxGzAZBgNVBAMMEmkuZ3Jva0Bjb21jYXN0Lm5ldDEhMB8GCSqGSIb3DQEJARYSaS5ncm9r QGNvbWNhc3QubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2AjLOMsBGaqN hv2FcRbfom/QCeKMXu5tUd1JY5oIDZe5y29stnd+se/zUlEkiVeMam4Jgo1c8yGNnwLVYc5/ 9xVi7Qg1Is5b9AB6aJWElJDw/jIdihymNZ2kwkSLT0wl/lzd0mXlwFJPRgQiRkmE6V0ZmjsQ jaVtllVleGBbMvmWPm92e+4Bju9P81kKz7Xr02ijETmaPdVsl+jmOaKPS8Y+2Lat2xus4Ked oJ/7aIWIpz1gRSKjAHSZ1Wmwi2TYUjYhZryChu9e1RWtqk1CycNoeusJ8xdEVN3WSnJ299w/ 3ltK/x/9rpj2j9ShQZVB4NnX6cjQs7pz1lVxvIkjcQIDAQABo4IDrTCCA6kwCQYDVR0TBAIw ADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQW BBQ29j2I0O8sRYi0So9NwwmT1caakDAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhR gjAdBgNVHREEFjAUgRJpLmdyb2tAY29tY2FzdC5uZXQwggIhBgNVHSAEggIYMIICFDCCAhAG CysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20v cG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJt ZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcg dG8gdGhlIENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4g Y29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUF BwICMIGPMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJp bGl0eSBhbmQgd2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFu ZCBMaW1pdGF0aW9ucyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAr oCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUH AQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFz czEvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0 cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQAZ5U0nL/2PQwsVfHgN7MVPbZEGzDzuj4Oy pTgz4XQFwPcCuy6U9sp1Dwmo3DyKX5nKN4xA7pslN+2Pl/kElGamX7zMCAH0xED0RTOLyk+v nDML4s+OUtWaYVnq1bZEp0F8Luq3zIslAYSebleyiz8M0EypZczsL5rOk86R2F9EYw1CBuFJ 5a4x0CmNu5o30fGNDFt+iXRlbJPp/KY25iUgVnBzJ4COT5kQjxn5lgr4t1I+BDCL5HQQ3h/8 2CzwrWVRBNb9Vqh9LL1ZtzYRt8JezoB6HkVvcKVNGlCZ+/MnvfMzPLwfbTDZC8o4d+4RH6aE LeGF2XmAOaenc/YRqm9oMYIClzCCApMCAQEwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQQIDAr4dMAkGBSsOAwIaBQCggdgwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTIwNTI4MTYwOTI3WjAjBgkqhkiG9w0BCQQxFgQUk79TCUwJ Q/OuqjUdjoYj1LJLt4MweQYJKoZIhvcNAQkPMWwwajALBglghkgBZQMEASowCwYJYIZIAWUD BAEWMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAl8jgbF6j 0ke0z5CuCJJ/2T5zOsnuwZ/Bjr1io4mCnss7+dikknozevc+NxNH7PcHGuVVAegcd9NMLee+ TSHsyV4jOvCzLEaD1JqZ7eRZS0BzOaeL6asLH9gPWo/DECHHrTNcwnQjatUz1wIpdiA6TrsQ gYngtn7dGzBgS0+q62/o7vOUNKHiTnYafaa7oOgW4Dbgg4wcDKj5HLhh9KXHkTkEmFRCHjfA ugKrA6TVSyQcTwySz4QBjz6BDSDUlV7/NfuVRzqN5HSq0zW5wB7n8fm28buy0t71tWjEH9xv vD3GT8Dk00iZKc4eUafeMSDSxcQWY9eq+rSuhy9neydWdQ== --2oS5YaxWCcQjTEyO-- From fanf2@hermes.cam.ac.uk Tue May 29 04:54:57 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94EA221F8656 for ; Tue, 29 May 2012 04:54:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.854 X-Spam-Level: X-Spam-Status: No, score=-5.854 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11, 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 ZOrA4SWDaSM1 for ; Tue, 29 May 2012 04:54:54 -0700 (PDT) Received: from ppsw-51.csi.cam.ac.uk (ppsw-51.csi.cam.ac.uk [131.111.8.151]) by ietfa.amsl.com (Postfix) with ESMTP id 4F20121F8621 for ; Tue, 29 May 2012 04:54:50 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:33928) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:fanf2) id 1SZL0i-0005FU-Ws (Exim 4.72) (return-path ); Tue, 29 May 2012 12:54:48 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1SZL0i-0008IO-3v (Exim 4.67) (return-path ); Tue, 29 May 2012 12:54:48 +0100 Date: Tue, 29 May 2012 12:54:48 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: James Cloos In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="1870870024-887428266-1338292345=:10076" Content-ID: Sender: Tony Finch Cc: ietf-smtp@imc.org, dane@ietf.org Subject: Re: [dane] draft-fanf-dane-smtp X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 29 May 2012 11:54:57 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --1870870024-887428266-1338292345=:10076 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-15 Content-Transfer-Encoding: QUOTED-PRINTABLE Content-ID: James Cloos wrote: > > I've read the draft now. It looks good. Thanks. > =A73 specifies that the hostname MUST be in the cert as an DNS-ID and > also MAY be there as a CN-ID. That is basically adapting what RFC 6125 says to the specifics of SMTP, i.e. subsetting the possible identities (omitting SRV etc.). Perhaps I ought to make the DNS-ID a SHOULD rather than MUST to follow RFC 6125 more exactly. Tony. --=20 f.anthony.n.finch http://dotat.at/ Thames, Dover, Wight, Portland, Plymouth: Variable 3 or 4. Smooth or slight= =2E Fog patches. Moderate, occasionally very poor. --1870870024-887428266-1338292345=:10076-- From fanf2@hermes.cam.ac.uk Tue May 29 04:59:29 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 073F111E8089 for ; Tue, 29 May 2012 04:59:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.351 X-Spam-Level: X-Spam-Status: No, score=-6.351 tagged_above=-999 required=5 tests=[AWL=0.248, 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 yvH9mzXkyw1x for ; Tue, 29 May 2012 04:59:28 -0700 (PDT) Received: from ppsw-41.csi.cam.ac.uk (ppsw-41.csi.cam.ac.uk [131.111.8.141]) by ietfa.amsl.com (Postfix) with ESMTP id EDE5811E8087 for ; Tue, 29 May 2012 04:59:27 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:35812) by ppsw-41.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:fanf2) id 1SZL5B-0000f9-Rz (Exim 4.72) (return-path ); Tue, 29 May 2012 12:59:26 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1SZL5B-0000d2-Gz (Exim 4.67) (return-path ); Tue, 29 May 2012 12:59:25 +0100 Date: Tue, 29 May 2012 12:59:25 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Hector Santos In-Reply-To: <4FC2AE5F.5010308@isdg.net> Message-ID: References: <4FC2AE5F.5010308@isdg.net> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: ietf-smtp@imc.org, dane@ietf.org Subject: Re: [dane] draft-fanf-dane-smtp X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 29 May 2012 11:59:29 -0000 Hector Santos wrote: > > I guess, if anything else, there are two client suggestions to highlight: > > - Automated MTA (router) > - Interactive MUA smtp client The draft is for inter-domain SMTP so message submission is out of scope. I don't think I can make this clearer. Tony. -- f.anthony.n.finch http://dotat.at/ Cromarty, Forth, Tyne, Dogger: Variable 3 or 4. Slight or moderate. Occasional rain. Moderate or good, occasionally poor later. From fanf2@hermes.cam.ac.uk Tue May 29 05:04:15 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 125A511E8087 for ; Tue, 29 May 2012 05:04:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.413 X-Spam-Level: X-Spam-Status: No, score=-6.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k4tDlVCG6QwD for ; Tue, 29 May 2012 05:04:13 -0700 (PDT) Received: from ppsw-52.csi.cam.ac.uk (ppsw-52.csi.cam.ac.uk [131.111.8.152]) by ietfa.amsl.com (Postfix) with ESMTP id 98F1421F8823 for ; Tue, 29 May 2012 05:04:13 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:56141) by ppsw-52.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1SZL9l-0000RZ-FL (Exim 4.72) (return-path ); Tue, 29 May 2012 13:04:09 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1SZL9l-0001P7-Lp (Exim 4.67) (return-path ); Tue, 29 May 2012 13:04:09 +0100 Date: Tue, 29 May 2012 13:04:09 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Hector Santos In-Reply-To: <4FC2B3E9.3020206@isdg.net> Message-ID: References: <4FC2B3E9.3020206@isdg.net> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: ietf-smtp@imc.org, dane@ietf.org Subject: Re: [dane] draft-fanf-dane-smtp X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 29 May 2012 12:04:15 -0000 Hector Santos wrote: > > If a TLSA record allows for an server authorized association of the > CN=secure.winserver.com with the connecting host name, then I can see some > worth in this dane-smtp proposal - from the client POV seeking a higher level > of security. Of course you can do that. You just have to ensure the names match, i.e. the MX target and TLSA owner have to match the certificate. The final version of this draft will probably have how-to appendix along the lines of draft-ietf-dane-protocol appendix A. Tony. -- f.anthony.n.finch http://dotat.at/ East Viking, North Utsire, South Utsire: Northerly or northwesterly 4 or 5, increasing 6 for a time. Moderate, occasionally rough. Fair. Good. From fanf2@hermes.cam.ac.uk Tue May 29 05:16:12 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7F2621F8713 for ; Tue, 29 May 2012 05:16:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.45 X-Spam-Level: X-Spam-Status: No, score=-6.45 tagged_above=-999 required=5 tests=[AWL=0.149, 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 sG7jD7hOTXkt for ; Tue, 29 May 2012 05:16:12 -0700 (PDT) Received: from ppsw-50.csi.cam.ac.uk (ppsw-50.csi.cam.ac.uk [131.111.8.150]) by ietfa.amsl.com (Postfix) with ESMTP id CFC0E21F8711 for ; Tue, 29 May 2012 05:16:11 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:54882) by ppsw-50.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1SZLLJ-0004eN-si (Exim 4.72) (return-path ); Tue, 29 May 2012 13:16:05 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1SZLLJ-0003It-Tu (Exim 4.67) (return-path ); Tue, 29 May 2012 13:16:05 +0100 Date: Tue, 29 May 2012 13:16:05 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Ned Freed In-Reply-To: <01OFX1DRMJUY0006TF@mauve.mrochek.com> Message-ID: References: <01OFWCYFVKQ80006TF@mauve.mrochek.com> <01OFX1DRMJUY0006TF@mauve.mrochek.com> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: "dane@ietf.org" Subject: Re: [dane] draft-fanf-dane-smtp X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 29 May 2012 12:16:12 -0000 Ned Freed wrote: > > To be fair, the appendix is more about why host name TLSA records have to be > supported, not why you couldn't support domain TLSA records as well. Thanks for explaining this for me :-) I hope you don't mind if I add some of your words to the draft. Tony. -- f.anthony.n.finch http://dotat.at/ Forties: Variable 3 or 4, becoming northwesterly 5 later in far northeast. Moderate, occasionally slight in west. Occasional rain in southwest. Moderate or good. From ned.freed@mrochek.com Tue May 29 17:21:56 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7537511E8177 for ; Tue, 29 May 2012 17:21:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ExaCsgFj+N5x for ; Tue, 29 May 2012 17:21:55 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 996ED11E8173 for ; Tue, 29 May 2012 17:21:55 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OG29YYJB4G002CPU@mauve.mrochek.com> for dane@ietf.org; Tue, 29 May 2012 17:21:50 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OFYZ0QA6000006TF@mauve.mrochek.com>; Tue, 29 May 2012 17:21:43 -0700 (PDT) Message-id: <01OG29YUT4Z00006TF@mauve.mrochek.com> Date: Tue, 29 May 2012 17:21:20 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Tue, 29 May 2012 13:16:05 +0100" MIME-version: 1.0 Content-type: TEXT/PLAIN References: <01OFWCYFVKQ80006TF@mauve.mrochek.com> <01OFX1DRMJUY0006TF@mauve.mrochek.com> To: Tony Finch Cc: Ned Freed , "dane@ietf.org" Subject: Re: [dane] draft-fanf-dane-smtp X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 30 May 2012 00:21:56 -0000 > Ned Freed wrote: > > > > To be fair, the appendix is more about why host name TLSA records have to be > > supported, not why you couldn't support domain TLSA records as well. > Thanks for explaining this for me :-) I hope you don't mind if I add some > of your words to the draft. No problem! I'm glad you found them useful. Ned From fanf2@hermes.cam.ac.uk Tue May 29 17:31:44 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3115A11E817D for ; Tue, 29 May 2012 17:31:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.475 X-Spam-Level: X-Spam-Status: No, score=-6.475 tagged_above=-999 required=5 tests=[AWL=0.124, 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 sR-il-g9HSBY for ; Tue, 29 May 2012 17:31:43 -0700 (PDT) Received: from ppsw-52.csi.cam.ac.uk (ppsw-52.csi.cam.ac.uk [131.111.8.152]) by ietfa.amsl.com (Postfix) with ESMTP id 0248D11E817B for ; Tue, 29 May 2012 17:31:40 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:57461) by ppsw-52.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1SZT6L-0003LX-FI (Exim 4.72) (return-path ); Tue, 29 May 2012 21:33:09 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1SZT6L-0005iS-MO (Exim 4.67) (return-path ); Tue, 29 May 2012 21:33:09 +0100 Date: Tue, 29 May 2012 21:33:09 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: dane@ietf.org, ietf-smtp@imc.org In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Subject: [dane] draft-fanf-dane-smtp-01 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2012 00:31:44 -0000 I have uploaded a revised version. I am rather unsure about sections 4 and 5 so all cheers and jeers welcome, especially if backed up with some kind of reasoning :-) Tony. -- f.anthony.n.finch http://dotat.at/ Thames: Variable 3 or 4. Smooth or slight. Fog patches developing, occasional rain. Moderate or good, occasionally very poor. ---------- Forwarded message ---------- Date: Tue, 29 May 2012 13:22:40 -0700 From: internet-drafts@ietf.org To: dot@dotat.at Subject: New Version Notification for draft-fanf-dane-smtp-01.txt A new version of I-D, draft-fanf-dane-smtp-01.txt has been successfully submitted by Tony Finch and posted to the IETF repository. Filename: draft-fanf-dane-smtp Revision: 01 Title: Secure inter-domain SMTP with TLS, DNSSEC and TLSA records. Creation date: 2012-05-29 WG ID: Individual Submission Number of pages: 11 Abstract: SMTP supports STARTTLS for inter-domain mail transfer, but it only provides very limited security because the server's certificate cannot be authenticated. This memo specifies how TLSA records in the DNS can be used for proper MX target server authentication. The IETF Secretariat From marka@isc.org Tue May 29 20:18:27 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2055411E80A3 for ; Tue, 29 May 2012 20:18:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 MtRZv3eagezE for ; Tue, 29 May 2012 20:18:26 -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 6B15011E8099 for ; Tue, 29 May 2012 20:18:26 -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 "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id 8F78D5F98E5; Wed, 30 May 2012 03:18:07 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:4802:9d08:cf06:aca5]) (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 8B862216C36; Wed, 30 May 2012 03:18:00 +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 CA9DB210F638; Wed, 30 May 2012 13:17:56 +1000 (EST) To: Hector Santos From: Mark Andrews References: <4FC2AE5F.5010308@isdg.net> <4FC58201.7010701@isdg.net> In-reply-to: Your message of "Tue, 29 May 2012 22:12:17 -0400." <4FC58201.7010701@isdg.net> Date: Wed, 30 May 2012 13:17:56 +1000 Message-Id: <20120530031756.CA9DB210F638@drugs.dv.isc.org> Cc: ietf-smtp@imc.org, dane@ietf.org Subject: Re: [dane] draft-fanf-dane-smtp X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 30 May 2012 03:18:27 -0000 In message <4FC58201.7010701@isdg.net>, Hector Santos writes: > > Tony Finch wrote: > > Hector Santos wrote: > >> I guess, if anything else, there are two client suggestions to highlight: > >> > >> - Automated MTA (router) > >> - Interactive MUA smtp client > > > > The draft is for inter-domain SMTP so message submission is out of scope. > > I don't think I can make this clearer. > > > > Tony. > > Oh, so that is what you meant by "inter-domain." I am not use to > using that term within the confines of mail systems but it fits. > Other terms are "routers," "relays," etc or just MTA. I prefer router. > > Inter-domain SMTP: SMTP between different ADMDs across the public > Internet, where a client sends mail to a publicly-referenced SMTP > server. > > I suggest to add an i.e. > > i.e. a router, relaying MTA, not an MUA with a possible interactive > CN vs Host domain checking method where the HUMAN is involved. > > Anyway, ironically, we are having a related thread now in our support > forum regarding a sysop asking about self-signed vs CA signed certs. > > My question is: > > If the client has to be modified to do this extra TLSA check, then why > not just add login to do a CA 3rd party repository? Or support OCSP > (Online Certificate Status Protocol) RFC2560? OCSP is for when the CA knows the CERT is compromised. TLSA, mode X, is to detect mis-issued CERT by some CA. Different threat models. OCSP are sometimes unreachable even when you have the address and CERT. TLSA records will almost always be available if you can retrieve the address as they live below the address in the DNS and are usually in the same zone. Different failure models. > When change is proposed, then it has to have a payoff. A client > trusting a self-signed signature is going to be pre-defined or > pre-arranged or known upfront. TLSA, mode Y, allows you to trust the self signed CERT by providing a verifiable secure chain of trust back to a DNS trust anchor rather than a CA trust anchor. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From hsantos@isdg.net Tue May 29 19:12:05 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3F4511E80A3 for ; Tue, 29 May 2012 19:12:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.192 X-Spam-Level: X-Spam-Status: No, score=-101.192 tagged_above=-999 required=5 tests=[AWL=0.485, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311, 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 MFVUhNJErUDa for ; Tue, 29 May 2012 19:12:05 -0700 (PDT) Received: from mail.catinthebox.net (mail.santronics.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id D806011E809A for ; Tue, 29 May 2012 19:12:04 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1386; t=1338343920; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=lCd7Bfztd8Nl4UTs3FC2J87e32E=; b=Wta7TDV+YNz2xBttWEYM R1JTij6C0kE+ch0zglRP3sSf4VGHf1785KwHz9LuTV0rPZ8doED1gEv5iFw4VQdK nMkLDJaGVPoP90zZGssYWkQjCfzqSm3asCUnhb2ZboUbmZmY1gjbgKtbtKk4aqX9 xAo8Inh207+VAs+zQnxUfu0= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for dane@ietf.org; Tue, 29 May 2012 22:12:00 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 2955734257.7640.3644; Tue, 29 May 2012 22:11:59 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1386; t=1338343874; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=PNqHySK vMJDtFcuTn0w+lZjh33xQX8puNTmHhz20DJI=; b=LVxXI1Tnca7mmXBlUZEk/v+ fg0l3qVJHBV8NNNEt+BUtKiCd/UBP2Wp6NOOzC/EbaHQKNirmNgBLhdpTNEJw6TU mp/vOxpNs8xqTL6fZu7yk8cZ+I5vGFKZbX1Bc3B4x1CpduR3UKo/2IotTj+hpcBg qKKDRFN0qfWfZ8CCfer8= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for dane@ietf.org; Tue, 29 May 2012 22:11:14 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3554606878.10571.6968; Tue, 29 May 2012 22:11:13 -0400 Message-ID: <4FC58201.7010701@isdg.net> Date: Tue, 29 May 2012 22:12:17 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Tony Finch References: <4FC2AE5F.5010308@isdg.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 30 May 2012 02:23:28 -0700 Cc: ietf-smtp@imc.org, dane@ietf.org Subject: Re: [dane] draft-fanf-dane-smtp X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 30 May 2012 02:12:05 -0000 Tony Finch wrote: > Hector Santos wrote: >> I guess, if anything else, there are two client suggestions to highlight: >> >> - Automated MTA (router) >> - Interactive MUA smtp client > > The draft is for inter-domain SMTP so message submission is out of scope. > I don't think I can make this clearer. > > Tony. Oh, so that is what you meant by "inter-domain." I am not use to using that term within the confines of mail systems but it fits. Other terms are "routers," "relays," etc or just MTA. I prefer router. Inter-domain SMTP: SMTP between different ADMDs across the public Internet, where a client sends mail to a publicly-referenced SMTP server. I suggest to add an i.e. i.e. a router, relaying MTA, not an MUA with a possible interactive CN vs Host domain checking method where the HUMAN is involved. Anyway, ironically, we are having a related thread now in our support forum regarding a sysop asking about self-signed vs CA signed certs. My question is: If the client has to be modified to do this extra TLSA check, then why not just add login to do a CA 3rd party repository? Or support OCSP (Online Certificate Status Protocol) RFC2560? When change is proposed, then it has to have a payoff. A client trusting a self-signed signature is going to be pre-defined or pre-arranged or known upfront. -- HLS From yaronf.ietf@gmail.com Wed May 30 10:53:46 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14B7211E808D for ; Wed, 30 May 2012 10:53:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 LDpRgEzG7gfr for ; Wed, 30 May 2012 10:53:45 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 38C8C21F8627 for ; Wed, 30 May 2012 10:53:44 -0700 (PDT) Received: by bkty8 with SMTP id y8so84670bkt.31 for ; Wed, 30 May 2012 10:53:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=r1QQXmXVSZ88hAL07rsFoEhnrJoopoObiO3z5YdkKv8=; b=I7CfFL26jzEw+PSuj3IlraCd+4bIa+Rbn+WE2nLtOMNLRjPs9sWI2KpwXtG3E+pGak QAh0HY/lm9nMwwyGuCdI0u0ezhKiU7ZFnwQM3khSSPPaTaRzcCyEvh4adw9HKqqoCLrp p5o793WuW1a/mTSrM45GtihW7QS+spFhL0yaHCHgHNzmNtfGZDNlKLB6K0CoBS/8FvaG X57iu9ZW96feJP1AiOpvpdQzyM4ldnAycr8eDyX7aAIod2faTfcNs5X1PiuJcOa8vJSk yOPlYJVDi0DPOHF6+mDH8utIiMrUEkhbkS+1r2a/ZSwF/ISak1xY0atLCX4rgoLtvt/8 lilg== Received: by 10.204.152.199 with SMTP id h7mr10313492bkw.39.1338400423114; Wed, 30 May 2012 10:53:43 -0700 (PDT) Received: from [10.0.0.4] ([109.65.178.113]) by mx.google.com with ESMTPS id ie3sm541165bkc.1.2012.05.30.10.53.41 (version=SSLv3 cipher=OTHER); Wed, 30 May 2012 10:53:42 -0700 (PDT) Message-ID: <4FC65EA4.20103@gmail.com> Date: Wed, 30 May 2012 20:53:40 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: dane@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [dane] DANE+SMTP draft X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 30 May 2012 17:53:46 -0000 Hi, I just noticed the new draft that strengthens the use of SMTP STARTTLS. I have always been under the impression that STARTTLS is weak in actual use because a MITM attacker can cause it not to be negotiated at all (a bid-down attack over the unencrypted, unauthenticated cleartext SMTP). So strengthening the TLS authentication is sort of like closing the barn door after the horse has already gone. Am I missing something? At the very least, this should be mentioned in the security considerations. Thanks, Yaron From hsantos@isdg.net Wed May 30 14:43:52 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A43511E80AE for ; Wed, 30 May 2012 14:43:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.774 X-Spam-Level: X-Spam-Status: No, score=-101.774 tagged_above=-999 required=5 tests=[AWL=0.825, 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 YcQqetwPHAjn for ; Wed, 30 May 2012 14:43:51 -0700 (PDT) Received: from pop3.winserver.com (groups.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 2992A11E80AB for ; Wed, 30 May 2012 14:43:50 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2289; t=1338414222; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=g5f8WJa8cnh36vjboVdVUZUD1KA=; b=kdJE5PdY0F6HXA2uUnKE HojPYmn+vX+VU4u5N6oghQYT+VBB3wJ/wSmgexGXLNBv6otqy8dkWl06AoYmXaA+ IpCpkKQhtSN3BRKBig8gwtJxZtABLDyScH+s8X+yp14gDt2mOVUrWKUEsxk+TM08 9f7spE2mmSwf8lnn/D+1boo= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for dane@ietf.org; Wed, 30 May 2012 17:43:42 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from hector.wildcatblog.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3026036482.8587.2136; Wed, 30 May 2012 17:43:42 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2289; t=1338414175; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=2GGAgb8 u67j0FMBQAZ9ho75TMmurih4QEstggcND4PI=; b=eRKnUq1D81fKcHE74Sb52nC 3jus4nxxD9IlkqPTQL+QdtdTAJ5gZFQmNGiWYsvDq33tHQV7WLMGnm31GWgHfxXZ edrNb0WkC/r7cYG/nzjcZygH2RxtwTPCA7TCGv1+1X99UQb33o5lNmXZvgZ8gEZW dE94jM79Pnz8roAUVl00= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for dane@ietf.org; Wed, 30 May 2012 17:42:55 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3624907644.10693.4792; Wed, 30 May 2012 17:42:54 -0400 Message-ID: <4FC694AA.2030206@isdg.net> Date: Wed, 30 May 2012 17:44:10 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Mark Andrews References: <4FC2AE5F.5010308@isdg.net> <4FC58201.7010701@isdg.net> <20120530031756.CA9DB210F638@drugs.dv.isc.org> In-Reply-To: <20120530031756.CA9DB210F638@drugs.dv.isc.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 30 May 2012 14:45:53 -0700 Cc: ietf-smtp@imc.org, dane@ietf.org Subject: Re: [dane] draft-fanf-dane-smtp X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 30 May 2012 21:43:52 -0000 Mark Andrews wrote: >> My question is: >> >> If the client has to be modified to do this extra TLSA check, then why >> not just add login to do a CA 3rd party repository? Or support OCSP >> (Online Certificate Status Protocol) RFC2560? > OCSP is for when the CA knows the CERT is compromised. > TLSA, mode X, is to detect mis-issued CERT by some CA. > > Different threat models. > > OCSP are sometimes unreachable even when you have the address and CERT. > TLSA records will almost always be available if you can retrieve the address > as they live below the address in the DNS and are usually in the same zone. > > Different failure models. Yes, but its always been used for whatever the CA responds with and whatever the client decides to do as a negative response, but as the modus operandi has been, a positive response has "trust value." I've seen it used in cases where a browser check provides a perfect SSL resolution, but with modern browsers having OCSP enabled now, it will provide a failure/security notification to the user. In the case I recall, a big national chain store purchased a set of wildcard domains, then wanted to add more the same day, and there was a revocation issue that failure when OCSP was enabled. So I guess that all falls under a "compromise" threat/failure window. >> When change is proposed, then it has to have a payoff. A client >> trusting a self-signed signature is going to be pre-defined or >> pre-arranged or known upfront. > > TLSA, mode Y, allows you to trust the self signed CERT by providing > a verifiable secure chain of trust back to a DNS trust anchor rather > than a CA trust anchor. > Thanks for your comments. At best, this proposal offers an easier protocol. But its not ready for prime time until the DNS servers better support unnamed types and across the OS platform board. I think we would like a SMTP/TLS model where clients support/service the CA market, in the same way Browsers do for SSL/TLS certificates. I can see an SMTP Server Extension that offers service keywords for the level of enforcement. This may answer one of the lingering questions the DANE-SMTP drafts states that the server has no way to know the client has looked up a TLSA record. -- HLS From i.grok@comcast.net Wed May 30 15:05:38 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A28521F8631 for ; Wed, 30 May 2012 15:05:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_44=0.6, 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 IB-I1rtPJcUF for ; Wed, 30 May 2012 15:05:37 -0700 (PDT) Received: from qmta12.emeryville.ca.mail.comcast.net (qmta12.emeryville.ca.mail.comcast.net [76.96.27.227]) by ietfa.amsl.com (Postfix) with ESMTP id CDB0A21F8620 for ; Wed, 30 May 2012 15:05:37 -0700 (PDT) Received: from omta18.emeryville.ca.mail.comcast.net ([76.96.30.74]) by qmta12.emeryville.ca.mail.comcast.net with comcast id GC5n1j0031bwxycACN5dZL; Wed, 30 May 2012 22:05:37 +0000 Received: from odin.ulthar.us ([68.33.77.0]) by omta18.emeryville.ca.mail.comcast.net with comcast id GN5c1j00E00PQ6U8eN5cmB; Wed, 30 May 2012 22:05:37 +0000 Received: from odin.ulthar.us (localhost [127.0.0.1]) by odin.ulthar.us (8.14.5/8.14.3) with ESMTP id q4UM5WVG004698 for ; Wed, 30 May 2012 18:05:32 -0400 Received: (from draco@localhost) by odin.ulthar.us (8.14.5/8.14.5/Submit) id q4UM5WTX004697 for dane@ietf.org; Wed, 30 May 2012 18:05:32 -0400 Date: Wed, 30 May 2012 18:05:32 -0400 From: Scott Schmit To: dane@ietf.org Message-ID: <20120530220532.GA4565@odin.ulthar.us> Mail-Followup-To: dane@ietf.org References: <4FC65EA4.20103@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="2oS5YaxWCcQjTEyO" Content-Disposition: inline In-Reply-To: <4FC65EA4.20103@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] DANE+SMTP draft X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 30 May 2012 22:05:38 -0000 --2oS5YaxWCcQjTEyO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, May 30, 2012 at 08:53:40PM +0300, Yaron Sheffer wrote: > I just noticed the new draft that strengthens the use of SMTP STARTTLS. >=20 > I have always been under the impression that STARTTLS is weak in > actual use because a MITM attacker can cause it not to be negotiated > at all (a bid-down attack over the unencrypted, unauthenticated > cleartext SMTP). So strengthening the TLS authentication is sort of > like closing the barn door after the horse has already gone. Am I > missing something? At the very least, this should be mentioned in > the security considerations. STARTTLS is only weak today because the client has no way to know a priori that it should expect it to be available. With this document, the client knows that secure TLSA record =3D STARTTLS MUST work and the indicated certificate MUST be offered, or the connection fails. This is explained on page 4 of -01. --=20 Scott Schmit --2oS5YaxWCcQjTEyO Content-Type: application/x-pkcs7-signature Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIIQJgYJKoZIhvcNAQcCoIIQFzCCEBMCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC DVcwggY0MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAe Fw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0 ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEp pC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9 b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54q zHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX 9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/ 4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8E BTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIw HwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wu Y29tL3Nmc2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIB FiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4IC AQAKgwh9eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8py TUnFsukDFUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMm CeUTyMyikfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIz uQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVm z/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT 5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lAp sbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076 khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8 J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRX un0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCBxswggYDoAMCAQICAwK+HTANBgkqhkiG 9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTExMDcxNzA1 MDQwNFoXDTEyMDcxNzExNDI1OVowYjEgMB4GA1UEDRMXNDY1MjU2LTBnRmI2Sk5ZWW44QnFW bUwxGzAZBgNVBAMMEmkuZ3Jva0Bjb21jYXN0Lm5ldDEhMB8GCSqGSIb3DQEJARYSaS5ncm9r QGNvbWNhc3QubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2AjLOMsBGaqN hv2FcRbfom/QCeKMXu5tUd1JY5oIDZe5y29stnd+se/zUlEkiVeMam4Jgo1c8yGNnwLVYc5/ 9xVi7Qg1Is5b9AB6aJWElJDw/jIdihymNZ2kwkSLT0wl/lzd0mXlwFJPRgQiRkmE6V0ZmjsQ jaVtllVleGBbMvmWPm92e+4Bju9P81kKz7Xr02ijETmaPdVsl+jmOaKPS8Y+2Lat2xus4Ked oJ/7aIWIpz1gRSKjAHSZ1Wmwi2TYUjYhZryChu9e1RWtqk1CycNoeusJ8xdEVN3WSnJ299w/ 3ltK/x/9rpj2j9ShQZVB4NnX6cjQs7pz1lVxvIkjcQIDAQABo4IDrTCCA6kwCQYDVR0TBAIw ADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQW BBQ29j2I0O8sRYi0So9NwwmT1caakDAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhR gjAdBgNVHREEFjAUgRJpLmdyb2tAY29tY2FzdC5uZXQwggIhBgNVHSAEggIYMIICFDCCAhAG CysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20v cG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJt ZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcg dG8gdGhlIENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4g Y29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUF BwICMIGPMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJp bGl0eSBhbmQgd2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFu ZCBMaW1pdGF0aW9ucyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAr oCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUH AQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFz czEvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0 cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQAZ5U0nL/2PQwsVfHgN7MVPbZEGzDzuj4Oy pTgz4XQFwPcCuy6U9sp1Dwmo3DyKX5nKN4xA7pslN+2Pl/kElGamX7zMCAH0xED0RTOLyk+v nDML4s+OUtWaYVnq1bZEp0F8Luq3zIslAYSebleyiz8M0EypZczsL5rOk86R2F9EYw1CBuFJ 5a4x0CmNu5o30fGNDFt+iXRlbJPp/KY25iUgVnBzJ4COT5kQjxn5lgr4t1I+BDCL5HQQ3h/8 2CzwrWVRBNb9Vqh9LL1ZtzYRt8JezoB6HkVvcKVNGlCZ+/MnvfMzPLwfbTDZC8o4d+4RH6aE LeGF2XmAOaenc/YRqm9oMYIClzCCApMCAQEwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQQIDAr4dMAkGBSsOAwIaBQCggdgwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTIwNTMwMjIwNTMyWjAjBgkqhkiG9w0BCQQxFgQUkTe7UHFQ V/qRQMZ37hgMEDhR5pwweQYJKoZIhvcNAQkPMWwwajALBglghkgBZQMEASowCwYJYIZIAWUD BAEWMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAPukIM+W/ dNzZ9X0ZJfnR4HsJQ6S403xtRTHvrT2unJwVmShzZDQtMECtb0qZ3KrZAgkmQ6yuWWHd+CPE 9FdVNXKBxvAGYE2rPb6QNjvXWVsB3Ss74fmp3tCYHg5asBNPhNZ/wew5jjExUOCv57ujie+N xP4LA8RXfvrD/BJQp8toEvvuYWKnWgWfPSqdyCDBZIG2v93VMST//fW1l0zWtc+XriOduKi0 cCuKM/qqr2gdhvawqpx9B51wrMVvz3LZOyTv8UTtrpmDLS9RRfrXRaSX3Sv0nOalBSRWTUp2 3At3maYM3By144RR5fejhVtVBdPb4dg9GfLafU/P+HEa1Q== --2oS5YaxWCcQjTEyO-- From marka@isc.org Wed May 30 17:18:34 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C3AC11E811A for ; Wed, 30 May 2012 17:18:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.479 X-Spam-Level: X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.120, 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 fZWAYuaXPghK for ; Wed, 30 May 2012 17:18:33 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 3C77E11E80D5 for ; Wed, 30 May 2012 17:18:33 -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 "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS id EF3F7C9744; Thu, 31 May 2012 00:18:19 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:b1d0:6c12:e098:f5d4]) (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 91B58216C33; Thu, 31 May 2012 00:18:19 +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 16FCB2116DF4; Thu, 31 May 2012 10:18:13 +1000 (EST) To: Hector Santos From: Mark Andrews References: <4FC2AE5F.5010308@isdg.net> <4FC58201.7010701@isdg.net> <20120530031756.CA9DB210F638@drugs.dv.isc.org> <4FC694AA.2030206@isdg.net> In-reply-to: Your message of "Wed, 30 May 2012 17:44:10 -0400." <4FC694AA.2030206@isdg.net> Date: Thu, 31 May 2012 10:18:13 +1000 Message-Id: <20120531001814.16FCB2116DF4@drugs.dv.isc.org> Cc: ietf-smtp@imc.org, dane@ietf.org Subject: Re: [dane] draft-fanf-dane-smtp X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 31 May 2012 00:18:34 -0000 In message <4FC694AA.2030206@isdg.net>, Hector Santos writes: > Mark Andrews wrote: > > >> My question is: > >> > >> If the client has to be modified to do this extra TLSA check, then why > >> not just add login to do a CA 3rd party repository? Or support OCSP > >> (Online Certificate Status Protocol) RFC2560? > > > OCSP is for when the CA knows the CERT is compromised. > > TLSA, mode X, is to detect mis-issued CERT by some CA. > > > > Different threat models. > > > > OCSP are sometimes unreachable even when you have the address and CERT. > > TLSA records will almost always be available if you can retrieve the addres > s > > as they live below the address in the DNS and are usually in the same zone. > > > > Different failure models. > > Yes, but its always been used for whatever the CA responds with and > whatever the client decides to do as a negative response, but as the > modus operandi has been, a positive response has "trust value." I've > seen it used in cases where a browser check provides a perfect SSL > resolution, but with modern browsers having OCSP enabled now, it will > provide a failure/security notification to the user. In the case I > recall, a big national chain store purchased a set of wildcard > domains, then wanted to add more the same day, and there was a > revocation issue that failure when OCSP was enabled. > > So I guess that all falls under a "compromise" threat/failure window. > > >> When change is proposed, then it has to have a payoff. A client > >> trusting a self-signed signature is going to be pre-defined or > >> pre-arranged or known upfront. > > > > TLSA, mode Y, allows you to trust the self signed CERT by providing > > a verifiable secure chain of trust back to a DNS trust anchor rather > > than a CA trust anchor. > > > > Thanks for your comments. > > At best, this proposal offers an easier protocol. But its not ready > for prime time until the DNS servers better support unnamed types and > across the OS platform board. Actually I believe it is ready for prime time. If the DNS servers don't support DNSSEC then the MX, A and AAAA will come back as insecure unless the administrators of the zones are insane. If the DNS servers do support DNSSEC and the MX, A and AAAA answers come back as secure, then a TLSA lookup should succeed as the TLSA lookups will be from the same zones as the MX, A and AAAA lookups or will be in a secure zone beneath the zone that returned these answers. All DNSSEC aware servers are required to support unknown types. By checking the MX, A and AAAA results you elimitate the possibility of NOTIMP on the TLSA lookup. If DNSSEC is being broken then all bets are off. > I think we would like a SMTP/TLS model where clients support/service > the CA market, in the same way Browsers do for SSL/TLS certificates. > I can see an SMTP Server Extension that offers service keywords for > the level of enforcement. This may answer one of the lingering > questions the DANE-SMTP drafts states that the server has no way to > know the client has looked up a TLSA record. > > > -- > HLS > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From matt@mattmccutchen.net Wed May 30 20:43:03 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A84D11E80DF for ; Wed, 30 May 2012 20:43:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LlRiO38bOHr6 for ; Wed, 30 May 2012 20:43:02 -0700 (PDT) Received: from homiemail-a62.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id 2E55B11E80B7 for ; Wed, 30 May 2012 20:43:01 -0700 (PDT) Received: from homiemail-a62.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a62.g.dreamhost.com (Postfix) with ESMTP id 8E81763406F; Wed, 30 May 2012 20:43:01 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=message-id :subject:from:to:cc:date:in-reply-to:references:content-type :content-transfer-encoding:mime-version; q=dns; s= mattmccutchen.net; b=LfgDXsW73XDO3LFi2PuKcIAJt0bhQsWHGj9xzddpnyf qRF8d9dAxmhArp6nFSEZAloHykU7grKZ5jIYdLRa27/XBQedZ7kCqUx1tEa/opW7 lpBWvENYjL8qClPGjUPhf82xZ4ad4jVGBd10V/B95tXFQqc6IzJxpXSFmBBXMRNg = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= message-id:subject:from:to:cc:date:in-reply-to:references :content-type:content-transfer-encoding:mime-version; s= mattmccutchen.net; bh=0l1VtVLjAkIXnmu6sxWHzypzzUk=; b=Q/tHEP4DlS YF+NEsmCJo68iMZ25XmSR3N34lXiElNSoCxrXukJ4Fr8CVM2ln3xLMOc758M4CG5 VbMwL/lfkBK1flqIYiozxWeK0itHO92fuswAEvkbV4gVnPB5E0FHCTk+uWSrQ8Nv 2CZaME2Dyi4HXkeYWsTgE/WbbxfPxYoBA= 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-a62.g.dreamhost.com (Postfix) with ESMTPSA id 4E6F963406E; Wed, 30 May 2012 20:43:01 -0700 (PDT) Message-ID: <1338435781.1728.29.camel@localhost> From: Matt McCutchen To: Tony Finch Date: Wed, 30 May 2012 20:43:01 -0700 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 Cc: ietf-smtp@imc.org, dane@ietf.org Subject: Re: [dane] draft-fanf-dane-smtp X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 31 May 2012 03:43:03 -0000 [This message, originally sent 2012-05-27, did not seem to reach the archives. Sending it again.] On Fri, 2012-05-25 at 18:15 +0100, Tony Finch wrote: > I have just submitted an I-D describing how to use DANE with SMTP. All > comments welcome. This approach is not going to work. My understanding (http://www.ietf.org/mail-archive/web/keyassure/current/msg01215.html) is that a TLSA RRset at a given endpoint (DNS name + transport + port) is not a guarantee that a TLS service is offered at that endpoint. It only indicates the server certificates to be considered authentic if a client wants to attempt a connection to such a TLS service. Indeed, an organization with an existing private CA may publish may cover its entire zone with TLSA RRsets of usage 2 referring to that CA. And I cover all the unused names in mattmccutchen.net with dummy TLSA RRsets (SHA256 0000...0000) to ensure that TLS clients will never successfully authenticate a TLS service that I do not offer if a MITM attacker tries to spoof one into existence with a fraudulent certificate from a public CA. A mail client that is already configured to require authenticated TLS could certainly use DANE. But it would be incorrect for a client to refuse to deliver insecurely because it found a secure TLSA RRset. For that kind of logic, we need something like HASTLS. -- Matt From yaronf.ietf@gmail.com Wed May 30 21:28:32 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A01F111E80A3 for ; Wed, 30 May 2012 21:28:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.299 X-Spam-Level: X-Spam-Status: No, score=-103.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_44=0.6, 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 e8IcLP8hUrUN for ; Wed, 30 May 2012 21:28:31 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 90FD011E80F2 for ; Wed, 30 May 2012 21:28:31 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so336313wgb.13 for ; Wed, 30 May 2012 21:28:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=BKy5fL+ISa4Z+M3C6Uzs1pHLuEQBY412yihzJ7aYhm8=; b=0qWR/KNPcRO4zIW6nL4kBP1PYoDCTd6NTghXofx4xH5r39BWv8CCKTesRfMuqMXxn2 FwXUxvX0PjKfS2h8QX2ibwMm1BXqQNmrcnTjmMf6EacyogOLPd+OONZ/QecufPtBfrtW 7sIDHJdA0M6JN+4xg5Gcppb/3Ev6Zy4KWnHwnMEXduOsnwCTMpQMF1/DaNghNp9UT/9/ 2/bDuB6uImxskqgd/UBCiwsMbfMt4AefeF8bKIuFyNjMzuQZJbjVMw87HlGDSTXXgEQ1 F/+gWnPQ0/lfNzUcc7wH2KuXu137uKwRqoVUHgCxJcLz3T6QCtnHOsuW43zjc1Vxb2uM 8h4w== Received: by 10.216.211.8 with SMTP id v8mr11569534weo.176.1338438510713; Wed, 30 May 2012 21:28:30 -0700 (PDT) Received: from [10.0.0.4] ([109.65.178.113]) by mx.google.com with ESMTPS id m20sm1216318wie.6.2012.05.30.21.28.29 (version=SSLv3 cipher=OTHER); Wed, 30 May 2012 21:28:29 -0700 (PDT) Message-ID: <4FC6F36B.4080103@gmail.com> Date: Thu, 31 May 2012 07:28:27 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: dane@ietf.org References: <4FC65EA4.20103@gmail.com> <20120530220532.GA4565@odin.ulthar.us> In-Reply-To: <20120530220532.GA4565@odin.ulthar.us> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dane] DANE+SMTP draft X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 31 May 2012 04:28:32 -0000 Hi Scott, thanks for your response. Yes, this is indeed explained on page 4. However: - The document has: "If any of these checks fail, the client MUST disconnect from the server and treat this as a temporary failure." This is unrealistic - if the server is not provisioned with a correct certificate, this is not a temporary condition. In actual use, such failures are more likely to be caused by provisioning issues than by malicious attacks. - In addition, this sentence conflicts with the earlier text "If these security requirements are not satisfied, this protocol does not take effect. The client SHOULD fall back to insecure delivery (which might be over unauthenticated TLS)." So we do allow fallback to "unauthenticated TLS" (and implicitly also to plaintext?), which is in fact vulnerable to the same MITM attacker. Regards, Yaron On 05/31/2012 01:05 AM, Scott Schmit wrote: > On Wed, May 30, 2012 at 08:53:40PM +0300, Yaron Sheffer wrote: >> I just noticed the new draft that strengthens the use of SMTP STARTTLS. >> >> I have always been under the impression that STARTTLS is weak in >> actual use because a MITM attacker can cause it not to be negotiated >> at all (a bid-down attack over the unencrypted, unauthenticated >> cleartext SMTP). So strengthening the TLS authentication is sort of >> like closing the barn door after the horse has already gone. Am I >> missing something? At the very least, this should be mentioned in >> the security considerations. > > STARTTLS is only weak today because the client has no way to know a > priori that it should expect it to be available. With this document, > the client knows that secure TLSA record = STARTTLS MUST work and the > indicated certificate MUST be offered, or the connection fails. > > This is explained on page 4 of -01. > > > > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From fanf2@hermes.cam.ac.uk Thu May 31 03:59:45 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08D5821F8666 for ; Thu, 31 May 2012 03:59:45 -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.217, BAYES_00=-2.599, J_CHICKENPOX_44=0.6, 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 GnEfUcOY8zMm for ; Thu, 31 May 2012 03:59:44 -0700 (PDT) Received: from ppsw-51.csi.cam.ac.uk (ppsw-51.csi.cam.ac.uk [131.111.8.151]) by ietfa.amsl.com (Postfix) with ESMTP id E1A1C21F865A for ; Thu, 31 May 2012 03:59:43 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:33495) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:fanf2) id 1Sa36U-00024E-X8 (Exim 4.72) (return-path ); Thu, 31 May 2012 11:59:42 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1Sa36T-0008Um-Uk (Exim 4.67) (return-path ); Thu, 31 May 2012 11:59:41 +0100 Date: Thu, 31 May 2012 11:59:41 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Yaron Sheffer In-Reply-To: <4FC6F36B.4080103@gmail.com> Message-ID: References: <4FC65EA4.20103@gmail.com> <20120530220532.GA4565@odin.ulthar.us> <4FC6F36B.4080103@gmail.com> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: dane@ietf.org Subject: Re: [dane] DANE+SMTP draft X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 31 May 2012 10:59:45 -0000 Yaron Sheffer wrote: > > - The document has: "If any of these checks fail, the client MUST disconnect > from the server and treat this as a temporary failure." This is unrealistic - > if the server is not provisioned with a correct certificate, this is not a > temporary condition. In actual use, such failures are more likely to be caused > by provisioning issues than by malicious attacks. You are right that other provisioning errors in SMTP lead to permanent failures. Mail will bounce if you fail to configure your MTA to accept mail for a domain, or if you fail to put the necessary records in the DNS. The underlying assumption is that the network is a benign environment and this kind of error is a mistake not an attack. That is not true for a security protocol. So for SMTP+TLSA I think it's better to be robust not brittle. The sender will still get delay notifications if the provisioning error persists. > - In addition, this sentence conflicts with the earlier text "If these > security requirements are not satisfied, this protocol does not take effect. > The client SHOULD fall back to insecure delivery (which might be over > unauthenticated TLS)." So we do allow fallback to "unauthenticated TLS" (and > implicitly also to plaintext?), which is in fact vulnerable to the same MITM > attacker. No, the fallback occurs when the DNSSEC part of the protocol has not been (completely) deployed. A MITM cannot spoof DNSSEC responses, so it can't force a downgrade on the MX or TLSA lookups. I think you are right that the wording is not clear so I shall improve it. Thanks for the feedback. Tony. -- f.anthony.n.finch http://dotat.at/ Dover, Wight, Portland, Plymouth: West or southwest 4 or 5, occasionally 6 in Dover. Slight or moderate. Fog patches. Moderate, occasionally very poor. From fanf2@hermes.cam.ac.uk Thu May 31 07:46:36 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A4A221F866A for ; Thu, 31 May 2012 07:46:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.045 X-Spam-Level: X-Spam-Status: No, score=-5.045 tagged_above=-999 required=5 tests=[AWL=-1.346, BAYES_00=-2.599, J_CHICKENPOX_44=0.6, MANGLED_WANT=2.3, 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 YqYn2-SfZNe0 for ; Thu, 31 May 2012 07:46:35 -0700 (PDT) Received: from ppsw-52.csi.cam.ac.uk (ppsw-52.csi.cam.ac.uk [131.111.8.152]) by ietfa.amsl.com (Postfix) with ESMTP id 3C97D21F86D7 for ; Thu, 31 May 2012 07:46:35 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:42947) by ppsw-52.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1Sa6e0-0001vR-F4 (Exim 4.72) (return-path ); Thu, 31 May 2012 15:46:32 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1Sa6e0-00030r-9f (Exim 4.67) (return-path ); Thu, 31 May 2012 15:46:32 +0100 Date: Thu, 31 May 2012 15:46:32 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Matt McCutchen In-Reply-To: <1338435781.1728.29.camel@localhost> Message-ID: References: <1338435781.1728.29.camel@localhost> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: ietf-smtp@imc.org, dane@ietf.org Subject: Re: [dane] draft-fanf-dane-smtp X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 31 May 2012 14:46:36 -0000 Matt McCutchen wrote: > > This approach is not going to work. I think you mean that you want weaker semantics for SMTP+TLSA than I have specified. I have deliberately stated that extra semantics apply - in the intro I wrote: As well as its normal function of providing an association between a domain name and a certificate, we are also using the existance of a TLSA record to signal to the client that it can expect a valid server certificate. I agree that this might be a job for the HASTLS record - I wan't aware of it. I can change the spec to require another DNS lookup for HASTLS if others think this is worth doing. The historical baggage for SMTP and HTTP are rather different so I am not sure it makes sense to apply an HTTP fix to SMTP. It would add significant programming and provisioning complexity, and I don't think your use cases justify it. (For instance, your wildcard TLSA records are useless without accompanying address or SRV records.) On the other hand perhaps it would be nice to have better consistency across protocols. Tony. -- f.anthony.n.finch http://dotat.at/ Trafalgar: Easterly or northeasterly 5 to 7, increasing gale 8, occasionally severe gale 9 later in southeast, otherwise mainly northerly 4 or 5, occasionally 6. Slight or moderate, occasionally rough in southeast. Thundery showers later in east. Good, occasionally poor in east. From paul.hoffman@vpnc.org Thu May 31 08:05:42 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27B4921F868A for ; Thu, 31 May 2012 08:05:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.874 X-Spam-Level: X-Spam-Status: No, score=-101.874 tagged_above=-999 required=5 tests=[AWL=0.725, 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 ulzsKKc9T8fg for ; Thu, 31 May 2012 08:05: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 7AD7421F867F for ; Thu, 31 May 2012 08:05:40 -0700 (PDT) Received: from [10.20.30.102] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q4VF5bOr040332 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 31 May 2012 08:05:39 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <1338435781.1728.29.camel@localhost> Date: Thu, 31 May 2012 08:05:37 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1338435781.1728.29.camel@localhost> To: IETF DANE WG list X-Mailer: Apple Mail (2.1278) Cc: ietf-smtp@imc.org Subject: Re: [dane] draft-fanf-dane-smtp X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 31 May 2012 15:05:42 -0000 On May 30, 2012, at 8:43 PM, Matt McCutchen wrote: > My understanding > (http://www.ietf.org/mail-archive/web/keyassure/current/msg01215.html) > is that a TLSA RRset at a given endpoint (DNS name + transport + port) > is not a guarantee that a TLS service is offered at that endpoint. It > only indicates the server certificates to be considered authentic if a > client wants to attempt a connection to such a TLS service. =20 Correct. > Indeed, an > organization with an existing private CA may publish may cover its > entire zone with TLSA RRsets of usage 2 referring to that CA. And I > cover all the unused names in mattmccutchen.net with dummy TLSA RRsets > (SHA256 0000...0000) to ensure that TLS clients will never = successfully > authenticate a TLS service that I do not offer if a MITM attacker = tries > to spoof one into existence with a fraudulent certificate from a = public > CA. It could do so if it wanted. That doesn't mean it is a good idea to do = so. > A mail client that is already configured to require authenticated TLS > could certainly use DANE. But it would be incorrect for a client to > refuse to deliver insecurely because it found a secure TLSA RRset. =20 That's incorrect. draft-fanf-dane-smtp is defining the specific use of = TLSA for _25._tcp.hostname. (It would be good if it said so in the = Introduction.) > For > that kind of logic, we need something like HASTLS. The second paragraph of the Security Considerations covers this. I think = HASTLS might be a good idea, but the IETF still needs to have the = discussion of layering of these types of announcements. > This approach is not going to work. =20 It will work fine for everyone who doesn't do the "cover every port and = assume that no future protocol will ever define how specific = applications will use TLSA". --Paul Hoffman From fanf2@hermes.cam.ac.uk Thu May 31 08:24:26 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBB8B11E8095 for ; Thu, 31 May 2012 08:24:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.372 X-Spam-Level: X-Spam-Status: No, score=-6.372 tagged_above=-999 required=5 tests=[AWL=0.227, 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 kKD+f205C0hd for ; Thu, 31 May 2012 08:24:26 -0700 (PDT) Received: from ppsw-50.csi.cam.ac.uk (ppsw-50.csi.cam.ac.uk [131.111.8.150]) by ietfa.amsl.com (Postfix) with ESMTP id 1EF4B11E808C for ; Thu, 31 May 2012 08:24:26 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:36800) by ppsw-50.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1Sa7Ef-00047a-qE (Exim 4.72) (return-path ); Thu, 31 May 2012 16:24:25 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1Sa7Ef-0000sp-5x (Exim 4.67) (return-path ); Thu, 31 May 2012 16:24:25 +0100 Date: Thu, 31 May 2012 16:24:25 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Paul Hoffman In-Reply-To: Message-ID: References: <1338435781.1728.29.camel@localhost> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: ietf-smtp@imc.org, IETF DANE WG list Subject: Re: [dane] draft-fanf-dane-smtp X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 31 May 2012 15:24:27 -0000 Paul Hoffman wrote: > > That's incorrect. draft-fanf-dane-smtp is defining the specific use of > TLSA for _25._tcp.hostname. (It would be good if it said so in the > Introduction.) I've added that to my working copy. Thanks for the suggestion. Tony. -- f.anthony.n.finch http://dotat.at/ Dover, Wight, Portland, Plymouth: Southwest 4 or 5, occasionally 6 at first, becoming variable 3 or 4 later. Slight or moderate. Occasional drizzle, fog patches. Moderate or good, occasionally very poor. From fanf2@hermes.cam.ac.uk Thu May 31 10:39:42 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 351C111E80CA for ; Thu, 31 May 2012 10:39:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.391 X-Spam-Level: X-Spam-Status: No, score=-6.391 tagged_above=-999 required=5 tests=[AWL=0.208, 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 8Iv3fU5hEQbl for ; Thu, 31 May 2012 10:39:41 -0700 (PDT) Received: from ppsw-51.csi.cam.ac.uk (ppsw-51.csi.cam.ac.uk [131.111.8.151]) by ietfa.amsl.com (Postfix) with ESMTP id 376FC11E80A4 for ; Thu, 31 May 2012 10:39:41 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:58334) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:fanf2) id 1Sa9LW-00033G-Y5 (Exim 4.72) (return-path ); Thu, 31 May 2012 18:39:38 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1Sa9LW-0004oO-Hq (Exim 4.67) (return-path ); Thu, 31 May 2012 18:39:38 +0100 Date: Thu, 31 May 2012 18:39:38 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: dane@ietf.org, ietf-smtp@imc.org In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Subject: [dane] draft-fanf-dane-smtp-02 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 31 May 2012 17:39:42 -0000 Another version, with less added text this time - I've included a copy of the change log below. Many thanks to everyone who has taken the time to read the draft and comment. Clarify the wording that describes how a client determines that this protocol is in effect. Divide the security considerations into sub-sections, and add a subsection on denial of service. Clarify intro, mentioning TLSA owner name format. Extend the scope to cover MTA-to-MTA mail within an ADMD as well as between ADMDs. Tony. -- f.anthony.n.finch http://dotat.at/ Viking: North 4 or 5, backing northwest 5 or 6. Moderate, occasionally rough later. Showers. Good. ---------- Forwarded message ---------- Date: Thu, 31 May 2012 10:33:51 -0700 From: internet-drafts@ietf.org To: dot@dotat.at Subject: New Version Notification for draft-fanf-dane-smtp-02.txt A new version of I-D, draft-fanf-dane-smtp-02.txt has been successfully submitted by Tony Finch and posted to the IETF repository. Filename: draft-fanf-dane-smtp Revision: 02 Title: Secure SMTP with TLS, DNSSEC and TLSA records. Creation date: 2012-05-31 WG ID: Individual Submission Number of pages: 13 Abstract: SMTP has a STARTTLS extension, but (especially in the case of inter- domain mail transfer) it only provides very limited security because it does not specify how to authenticate the server's certificate. This memo specifies how TLSA records in the DNS can be used for proper SMTP server authentication. The IETF Secretariat From ott@mirix.org Thu May 31 12:10:26 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCAF711E8072 for ; Thu, 31 May 2012 12:10:26 -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 ABToFSFBtdpH for ; Thu, 31 May 2012 12:10:26 -0700 (PDT) Received: from a.mirix.org (a.mirix.org [IPv6:2a01:4f8:7d:108:17::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0803821F8598 for ; Thu, 31 May 2012 12:10:25 -0700 (PDT) Received: from [2a01:170:1064:a010:c029:8246:63a7:b8d8] (helo=blackbird.mirix.org) by a.mirix.org with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.77) (envelope-from ) id 1SaAlM-0004yz-OW for dane@ietf.org; Thu, 31 May 2012 21:10:24 +0200 Message-ID: <4FC7C220.3060001@mirix.org> Date: Thu, 31 May 2012 21:10:24 +0200 From: Matthias-Christian Ott User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.4) Gecko/20120510 Icedove/10.0.4 MIME-Version: 1.0 To: dane@ietf.org X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [dane] DANE OpenPGP support X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 31 May 2012 19:11:12 -0000 I don't know if it is already to late to change something, but I noticed that the latest DANE draft does not include support for OpenPGP which is supported in TLS as of RFC6091 and is implemented by GnuTLS. Perhaps it is best to create an amending RFC because the current DANE draft is intended for the Standards Track whereas RFC6091 is not. I just wanted to bring this to your attention because I was told that this has not been considered so far. - Matthias-Christian Ott From stpeter@stpeter.im Thu May 31 17:05:17 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 269AE11E80A6 for ; Thu, 31 May 2012 17:05: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=[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 LYa97EVtHugT for ; Thu, 31 May 2012 17:05:16 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id B89A011E8080 for ; Thu, 31 May 2012 17:05:16 -0700 (PDT) Received: from [192.168.0.7] (unknown [216.17.179.239]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id C951C4005A; Thu, 31 May 2012 18:21:48 -0600 (MDT) Message-ID: <4FC8073C.1030500@stpeter.im> Date: Thu, 31 May 2012 18:05:16 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Matthias-Christian Ott References: <4FC7C220.3060001@mirix.org> In-Reply-To: <4FC7C220.3060001@mirix.org> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: dane@ietf.org Subject: Re: [dane] DANE OpenPGP support X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 00:05:17 -0000 On 5/31/12 1:10 PM, Matthias-Christian Ott wrote: > I don't know if it is already to late to change something, but I noticed > that the latest DANE draft does not include support for OpenPGP which is > supported in TLS as of RFC6091 and is implemented by GnuTLS. Perhaps it > is best to create an amending RFC because the current DANE draft is > intended for the Standards Track whereas RFC6091 is not. > > I just wanted to bring this to your attention because I was told that > this has not been considered so far. My understanding is that it was considered and deemed out of scope for now. You'll notice that there are some hooks for other certificate types in the text, but someone will need to define those usages since they're out of scope for the core spec. Peter -- Peter Saint-Andre https://stpeter.im/