From nobody Wed Apr 2 09:30:30 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 162AB1A01FB for ; Wed, 2 Apr 2014 09:30:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id miSpBcJq1ro1 for ; Wed, 2 Apr 2014 09:30:25 -0700 (PDT) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) by ietfa.amsl.com (Postfix) with ESMTP id A5E161A023E for ; Wed, 2 Apr 2014 09:30:24 -0700 (PDT) Received: by mail-la0-f54.google.com with SMTP id mc6so374606lab.13 for ; Wed, 02 Apr 2014 09:30:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=yKMtTQMAB8zrF4GhLLBSfr7k/r03ZekizKlTraTtCao=; b=eXesO5Zxlq3dRi2BsEhOJMqEHyxAWdbvf4ZWWQLdbMIX1cmqgpHe9JUenwQHszvS4z u8UGawC4DCEOCFKV5rsakdWnobZhhYlCU15OHVrsTa8Fn5rt4OZReM7feSClmz6ixGxy 1FgjAxLcCF8dfCz1iNGh3syqSKyBBoE/hlVfdgEAr4H0aUegff/VeVjukPEWCLXkRWv3 xNCDIckyHEkK4iWzxiwEbxGSIkd/gNIYFz5vEmdWio4ET8RfexESwZKd5rD54emeRelp vQDhfPgnEejp5tSqYE/Aybl7Lwdwf20S7vDyhKe1KkMH+zDttdmySFDwpKsyvLCCowOs oYgQ== X-Gm-Message-State: ALoCoQmcJCekiAMca7nvCXJ5WY5SQXeKOV0dILezWDrLssXXBmp6ygviY4djHxmSgDcZqhemaFFK MIME-Version: 1.0 X-Received: by 10.112.89.234 with SMTP id br10mr625345lbb.60.1396456220062; Wed, 02 Apr 2014 09:30:20 -0700 (PDT) Received: by 10.114.0.243 with HTTP; Wed, 2 Apr 2014 09:30:20 -0700 (PDT) X-Originating-IP: [98.244.98.35] In-Reply-To: References: Date: Thu, 3 Apr 2014 00:30:20 +0800 Message-ID: From: Warren Kumari To: "Murray S. Kucherawy" Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/HrCUR6nXgsjtbHQXnRnkyn1qTHk Cc: "" Subject: Re: [dane] Adopting draft-wouters-dane-openpgp and draft-wouters-dane-openpgpkey-usage X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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 Apr 2014 16:30:29 -0000 On Thu, Mar 6, 2014 at 7:45 PM, Murray S. Kucherawy wrote: > This may be an ignorant question, but why would DANE handle these? They > barely make reference to DANE at all, and certainly not in a normative > sense. Apologies for the delay in responding. Travel got in the way... The DANE WG charter / objective says: "Specify mechanisms and techniques that allow Internet applications to establish cryptographically secured communications by using information distributed through DNSSEC for discovering and authenticating public keys which are associated with a service located at a domain name." So, even though this isn't TLSA, it fits nicely in our charter. We've chatted about this, and the support from others, and would like to adopt the drafts. Paul, can you please resubmit as draft-ietf-dane- ? W > > > On Wed, Mar 5, 2014 at 11:12 PM, Warren Kumari wrote: >> >> On Mon, Mar 3, 2014 at 8:11 PM, Jakob Schlyter wrote: >> > On 18 feb 2014, at 16:11, Warren Kumari wrote: >> > >> >> This starts a Call for Adoption for draft-wouters-dane-openpgp and >> >> draft-wouters-dane-openpgpkey-usage. >> >> >> >> These drafts are available here: >> >> https://datatracker.ietf.org/doc/draft-wouters-dane-openpgp/ >> >> and >> >> https://datatracker.ietf.org/doc/draft-wouters-dane-openpgpkey-usage/ >> >> >> >> >> >> Please review these two draft to see if you think if they are suitable >> >> for adoption by the DANE WG. >> > >> > Yes, please adopt. >> >> Great, thanks for all the feedback we have received so far. These >> will be (briefly) discussed tomorrow at the f2f meeting, but feel free >> to carry on providing feedback as well (those that haven't) >> >> W >> >> >> > >> > jakob >> > >> >> _______________________________________________ >> dane mailing list >> dane@ietf.org >> https://www.ietf.org/mailman/listinfo/dane > > From nobody Fri Apr 4 06:31:46 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CA221A0190 for ; Fri, 4 Apr 2014 06:31:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.912 X-Spam-Level: X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5bLRpF38upgn for ; Fri, 4 Apr 2014 06:31:38 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 6AD2F1A017C for ; Fri, 4 Apr 2014 06:31:38 -0700 (PDT) Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s34DVXHC002068 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 4 Apr 2014 09:31:33 -0400 Received: from pspacek.brq.redhat.com (pspacek.brq.redhat.com [10.34.4.156]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s34DVVMR003133 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Fri, 4 Apr 2014 09:31:33 -0400 Message-ID: <533EB433.5060204@redhat.com> Date: Fri, 04 Apr 2014 15:31:31 +0200 From: Petr Spacek Organization: Red Hat User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: dane@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/Gg4BQlvO_P5JOsG0RJBajkOXKFg Subject: [dane] AD bit handling in stub-resolvers: conclusions and compromises X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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 Apr 2014 13:31:42 -0000 Hello, Let me sum up the discussion and document the compromise for archaeologists: It seems that almost everyone agree that local validating resolver is the best option. People start to disagree when it comes to questions like "Is it feasible to rely on a local validating resolver in the near future? How can applications detect that a validating resolver is not configured and that DNS responses can't be trusted?" Aim of the proposal below is to enable applications to stay safe on systems without a validating resolver. Approach A ========== One approach is to do nothing in stub resolvers and rely on validating resolvers or application logic. This approach was mentioned by Paul Wouters , Prasad Pandit , Carlos O'Donell , Olafur Gudmundsson . It seems that the main concern about AD bit stripping in stub resolvers is compatibility with existing applications which rely on AD bit: http://www.ietf.org/mail-archive/web/dane/current/msg06521.html http://www.ietf.org/mail-archive/web/dane/current/msg06497.html After further discussion, it seems that pwouters is okay with AD bit stripping in stub resolver if it is explicitly requested by a calling application. (E.g. by special resolver initialization.) Approach B ========== The other approach is to do AD bit stripping in stub resolvers by default. It was proposed to add system-wide setting for this (e.g. to resolv.conf) and default to "strip AD bit unless admin configured something else". This approach was mentioned by Petr Spacek , Simo Sorce , Viktor Dukhovni , Tony Finch , James Cloos . viktor1dane thinks that compatibility concerns are not well-founded: http://www.ietf.org/mail-archive/web/dane/current/msg06523.html Naturally, application has to be able to do run-time check that it is using a library with this new behavior to avoid running in unsafe environment. Compromise ========== *Local validating resolver is strongly recommended.* - Introduce a new system-wide setting for AD bit stripping. - Add a new flag or initialization function to stub resolver API. Resolver behavior will depend on this new flag: -- Old applications (not using the new flag or new initialization call): Never strip AD bits. 100 % compatibility is guaranteed. -- New applications (actively using the flag): Stub resolver will strip all AD bits by default until admin configures some trusted name servers. Applications using the new resolver flags will fail safe on systems with no configured trusted resolver i.e. an application will request AD bit stripping from the stub resolver and the AD bit will be stripped until the admin configured a trusted resolver. Next Steps ========== Define what is yet not defined: - System-wide configuration format (e.g. modify resolv.conf vs. add a new file) - Propose specific API changes for major DNS libraries (glibc, maybe ldns and co.) - Prepare recommendation for application developers how and when to use a new API Further discussion about implementation details will happen on mailing lists related to the particular DNS libraries. Please speak up *now* if you have strong technical objections against the high-level idea described above. -- Petr Spacek @ Red Hat From nobody Fri Apr 4 11:28:02 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CB811A022B for ; Fri, 4 Apr 2014 11:27:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.311 X-Spam-Level: X-Spam-Status: No, score=-2.311 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f5PQ2YUnBGMj for ; Fri, 4 Apr 2014 11:27:53 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id 887741A0235 for ; Fri, 4 Apr 2014 11:27:53 -0700 (PDT) Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.3.174.1; Fri, 4 Apr 2014 14:27:37 -0400 Received: from postmark.nist.gov (129.6.16.94) by WSXGHUB1.xchange.nist.gov (129.6.18.96) with Microsoft SMTP Server (TLS) id 8.3.327.1; Fri, 4 Apr 2014 14:27:46 -0400 Received: from [127.0.0.1] (31-140.antd.nist.gov [129.6.140.31]) by postmark.nist.gov (8.13.8/8.13.1) with ESMTP id s34IRWkO022694; Fri, 4 Apr 2014 14:27:33 -0400 Message-ID: <533EF994.7000009@nist.gov> Date: Fri, 4 Apr 2014 14:27:32 -0400 From: Stephen Nightingale Organization: NIST User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-NIST-MailScanner-Information: Archived-At: http://mailarchive.ietf.org/arch/msg/dane/GoIvyY1zxAbHIUGfCdSWwUEDoJQ Cc: proj-had Subject: [dane] An Update on Danelaw X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: night@nist.gov List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 18:27:58 -0000 An update on the HAD-Pilot 'danelaw' test system at NIST seems appropriate: https://www.had-pilot.com/dane/danelaw.html. The three DANE clients based on TLSlite 0.4.6, GnuTLS 3.1.16 and OpenSSL 1.0.1e all now incorporate Viktor Dukhovni's 'C' language dane checker and return consistent - though not identical - results. The three https servers based on the TLS implementations are accessed in conjunction with TLSA records that serve the full range of certificate usages. There are, though one or two issues with these servers (discussed at the end of this report). A useful function that this 3x3 configuration allows is to serve as the basis for a TLS interoperability exercise. Extended to include Firefox, Chrome and IE web browsers, and the set of DANE servers listed on Dan York's ISOC DANE 360 site, this allows a full 6 client X 15 server interoperability matrix. While TLS interoperability is not strictly the bailiwick of DANE, DANE is certainly affected by it, so I will summarize that exercise here. Parameter setting in these three implementations is very limited, so the exercise proceeds with more or less out-of-the-box settings for their respective Python applications: TLSlite as native Python, GnuTLS with python-gnutls, and OpenSSL with Twisted. The core of the investigation with the 3x3 interoperability matrix of TLSlite, GnuTLS and OpenSSL clients and servers is fully successful, and all clients complete a TLS handshake with all servers. Extended to the ISOC DANE 360, plus additional sites announced on the DANE mailgroup, most interoperate, but a number of failures is seen: - Dougbarton.us works with GnuTLS, but generates handshake failures with TLSlite and OpenSSL. - Kumari.net and Spodhuis.org both complete handshakes with TLSlite and GnuTLS, but fail against OpenSSL. - The verified.danetest.com and broken.danetest.com sites fail for the reason mentioned by Paul Wouters in his March 20th DANE group posting. A fuller interoperability exercise awaits the development of an explicit TLS interoperability test suite, and associated extension of the clients and servers to facilitate parameter setting. For the sites that get past TLS interoperability, there are three sites that fail DANE: - bad-hash.verisign and bad-params.verisign are intentionally broken and designed to fail. - Kumari.net returns 403 forbidden to TLSlite and GnuTLS, but works with the Browsers. I am guessing the 403 is generated because my clients do not send a certificate. I will be testing for bi-directional verification sometime in the future. Now that Viktor's dane checker is incorporated in the three clients, the number of seriously wrong issues is hopefully minimized. Robust feedback is of course always welcome. There are still some issues with the servers, though: The TLSlite server is running all 2xx certificate uses, serving a certificate chain of length 2, with a wild card end certificate. However the process goes 'stale' after about 24 hours of up time, and so needs to be restarted daily. GnuTLS is running all 0xx and 1xx certificate uses, serving a single end certificate per use. It runs 24/7 robustly. It can only be configured to take a single end certificate for the server handshake. When presented with a concatenation of PEM certs, it will send only the end cert in the server side handshake. This is curious, because the GnuTLS client will retrieve the full cert chain in communication with, e.g., the TLSlite server. I will be seeking enlightenment on this issue on the gnutls-help mailgroup. The OpenSSL DANE server is running all 3xx certificate uses, with a single wild card end certificate. Whether it can serve a full PEM concatenated certificate chain is a question still to be investigated. The near-future course of the DANE project at NIST will now focus on SMTP uses, for both MUAs and MTAs. Stephen Nightingale, NIST. From nobody Fri Apr 4 21:03:39 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5853D1A024C for ; Fri, 4 Apr 2014 21:03:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1vBRJXwMvqBQ for ; Fri, 4 Apr 2014 21:03:33 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 010911A0143 for ; Fri, 4 Apr 2014 21:03:32 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id C4DC02AABD5; Sat, 5 Apr 2014 04:03:26 +0000 (UTC) Date: Sat, 5 Apr 2014 04:03:26 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140405040326.GO12559@mournblade.imrryr.org> References: <533EF994.7000009@nist.gov> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="/2994txjAzEdQwm5" Content-Disposition: inline In-Reply-To: <533EF994.7000009@nist.gov> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/u8VMya5PqibkKei0ZaU-L_WDtRg Subject: Re: [dane] An Update on Danelaw X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Apr 2014 04:03:37 -0000 --/2994txjAzEdQwm5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Apr 04, 2014 at 02:27:32PM -0400, Stephen Nightingale wrote: > https://www.had-pilot.com/dane/danelaw.html. > The three DANE clients based on TLSlite 0.4.6, GnuTLS 3.1.16 and OpenSSL > 1.0.1e all now incorporate Viktor Dukhovni's 'C' language dane checker > and return consistent - though not identical - results. To be precise, currently each of these: connects, dumps the server certificate chain to a PEM chain file, and invokes my DANE verification code in an "offline" mode to validate the chain against each of the TLSA records. That way the verification code is independent of the TLS toolkit used to complete the connection. > - Dougbarton.us works with GnuTLS, but generates handshake failures with > TLSlite and OpenSSL. Something is not right with the above, at least with OpenSSL 1.0.1 I get a working SSL connection with dougbarton.us. Now this server presents a chain with just the leaf certificate, even though the issuing CA is an intermediate CA. When I put both the intermediate cert (attached) and its issuing root (attached) in a CAfile, I can verify the dougbarton.us "1 0 2" TLSA record just fine. > - Kumari.net and Spodhuis.org both complete handshakes with TLSlite and > GnuTLS, but fail against OpenSSL. OpenSSL succeeds for me with spodhuis.org. Same StartCom root and intermediate as dougbarton.us, but spodhuis actually presents a full chain. Likewise www.kumari.net works, and the "TLSA 1 0 1" record matches with the PKIX root from Equifax. Do connections to these sites work for you with "openssl s_client"? This warrants further investigation. > - Kumari.net returns 403 forbidden to TLSlite and GnuTLS, but works with the > Browsers. I am guessing the 403 is generated because my clients do not send > a certificate. I will be testing for bi-directional verification sometime > in the future. That's an application layer issue, that is not really relevant for testing DANE. Once the TLS session is up, you can just disconnect, without even sending an HTTP request. > GnuTLS is running all 0xx and 1xx certificate uses, serving a single end > certificate per use. It runs 24/7 robustly. It can only be configured to > take a single end certificate for the server handshake. When presented with > a concatenation of PEM certs, it will send only the end cert in the server > side handshake. That does not sound right, are you sure about that? RFC 2246, 4346 and 5246 all require servers to present a chain with more than just the leaf certificate unless directly issued by a root CA. So it would be rather surprising of GnuTLS were not capable of presenting a complete chain. Almost certainly you just need to invoke it differently to load a complete chain. > The OpenSSL DANE server is running all 3xx certificate uses, with a single > wild card end certificate. Whether it can serve a full PEM concatenated > certificate chain is a question still to be investigated. OpenSSL definitely supports presenting a complete chain. > The near-future course of the DANE project at NIST will now focus on SMTP > uses, for both MUAs and MTAs. I think the issues with the HTTP use case are not protocol-specific and will crop up again with SMTP. So they should be addressed. -- Viktor. --/2994txjAzEdQwm5 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="startcom-int.pem" subject=/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Class 1 Primary Intermediate Server CA issuer=/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Certification Authority -----BEGIN CERTIFICATE----- MIIGNDCCBBygAwIBAgIBGDANBgkqhkiG9w0BAQUFADB9MQswCQYDVQQGEwJJTDEW MBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwg Q2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwHhcNMDcxMDI0MjA1NDE3WhcNMTcxMDI0MjA1NDE3WjCB jDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0 YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgU2VydmVyIENBMIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtonGrO8JUngHrJJj0PREGBiE gFYfka7hh/oyULTTRwbw5gdfcA4Q9x3AzhA2NIVaD5Ksg8asWFI/ujjo/OenJOJA pgh2wJJuniptTT9uYSAK21ne0n1jsz5G/vohURjXzTCm7QduO3CHtPn66+6CPAVv kvek3AowHpNz/gfK11+AnSJYUq4G2ouHI2mw5CrY6oPSvfNx23BaKA+vWjhwRRI/ ME3NO68X5Q/LoKldSKqxYVDLNM08XMML6BDAjJvwAwNi/rJsPnIO7hxDKslIDlc5 xDEhyBDBLIf+VJVSH1I8MRKbf+fAoKVZ1eKPPvDVqOHXcDGpxLPPr21TLwb0pwID AQABo4IBrTCCAakwDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAQYwHQYD VR0OBBYEFOtCNNCYsKuf9BtrCPfMZC7vDixFMB8GA1UdIwQYMBaAFE4L7xqkQFul F2mHMMo0aEPQQa7yMGYGCCsGAQUFBwEBBFowWDAnBggrBgEFBQcwAYYbaHR0cDov L29jc3Auc3RhcnRzc2wuY29tL2NhMC0GCCsGAQUFBzAChiFodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS9zZnNjYS5jcnQwWwYDVR0fBFQwUjAnoCWgI4YhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0 c3NsLmNvbS9zZnNjYS5jcmwwgYAGA1UdIAR5MHcwdQYLKwYBBAGBtTcBAgEwZjAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0 BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRl LnBkZjANBgkqhkiG9w0BAQUFAAOCAgEAIQlJPqWIbuALi0jaMU2P91ZXouHTYlfp tVbzhUV1O+VQHwSL5qBaPucAroXQ+/8gA2TLrQLhxpFy+KNN1t7ozD+hiqLjfDen xk+PNdb01m4Ge90h2c9W/8swIkn+iQTzheWq8ecf6HWQTd35RvdCNPdFWAwRDYSw xtpdPvkBnufh2lWVvnQce/xNFE+sflVHfXv0pQ1JHpXo9xLBzP92piVH0PN1Nb6X t1gW66pceG/sUzCv6gRNzKkC4/C2BBL2MLERPZBOVmTX3DxDX3M570uvh+v2/miI RHLq0gfGabDBoYvvF0nXYbFFSF87ICHpW7LM9NfpMfULFWE7epTj69m8f5SuauNi YpaoZHy4h/OZMn6SolK+u/hlz8nyMPyLwcKmltdfieFcNID1j0cHL7SRv7Gifl9L WtBbnySGBVFaaQNlQ0lxxeBvlDRr9hvYqbBMflPrj0jfyjO1SPo2ShpTpjMM0InN SRXNiTE8kMBy12VLUjWKRhFEuT2OKGWmPnmeXAhEKa2wNREuIU640ucQPl2Eg7PD wuTSxv0JS3QJ3fGz0xk+gA2iCxnwOOfFwq/iI9th4p1cbiCJSS4jarJiwUW0n6+L p/EiO/h94pDQehn7Skzj0n1fSoMD7SfWI55rjbRZotnvbIIp3XUZPD9MEI3vu3Un 0q6Dp6jOW6c= -----END CERTIFICATE----- --/2994txjAzEdQwm5 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="startcom-root.pem" subject=/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Certification Authority issuer=/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Certification Authority -----BEGIN CERTIFICATE----- MIIHyTCCBbGgAwIBAgIBATANBgkqhkiG9w0BAQUFADB9MQswCQYDVQQGEwJJTDEW MBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwg Q2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwHhcNMDYwOTE3MTk0NjM2WhcNMzYwOTE3MTk0NjM2WjB9 MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3Rh cnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwggIiMA0GCSqGSIb3DQEBAQUA A4ICDwAwggIKAoICAQDBiNsJvGxGfHiflXu1M5DycmLWwTYgIiRezul38kMKogZk pMyONvg45iPwbm2xPN1yo4UcodM9tDMr0y+v/uqwQVlntsQGfQqedIXWeUyAN3rf OQVSWff0G0ZDpNKFhdLDcfN1YjS6LIp/Ho/u7TTQEceWzVI9ujPW3U3eCztKS5/C Ji/6tRYccjV3yjxd5srhJosaNnZcAdt0FCX+7bWgiA/deMotHweXMAEtcnn6RtYT Kqi5pquDSR3l8u/d5AGOGAqPY1MWhWKpDhk6zLVmpsJrdAfkK+F2PrRt2PZE4XNi HzvEvqBTViVsUQn3qqvKv3b9bZvzndu/PWa8DFaqr5hIlTpL36dYUNk4dalb6kMM Av+Z6+hsTXBbKWWc3apdzK8BMewM69KN6Oqce+Zu9ydmDBpI125C4z/eIT574Q1w +2OqqGwaVLRcJXrJosmLFqa7LH4XXgVNWG4SHQHuEhANxjJ/GP/89PrNbpHoNkm+ Gkhpi8KWTRoSsmkXwQqQ1vp5Iki/untp+HDH+no32NgN0nZPV/+Qt+OR0t3vwmC3 Zzrd/qqc8NSLf3Iizsafl7b4r4qgEKjZ+xjGtrVcUjyJthkqcwEKDwOzEmDyei+B 26Nu/yYwl/WL3YlXtq09s68rxbd2AvCl1iuahhQqcvbjM4xdCUsT37uMdBNSSwID AQABo4ICUjCCAk4wDAYDVR0TBAUwAwEB/zALBgNVHQ8EBAMCAa4wHQYDVR0OBBYE FE4L7xqkQFulF2mHMMo0aEPQQa7yMGQGA1UdHwRdMFswLKAqoCiGJmh0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3Js LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwuY3JsMIIBXQYDVR0gBIIBVDCCAVAwggFM BgsrBgEEAYG1NwEBATCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0 Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFy dGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3Rh cnQgQ29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlh YmlsaXR5LCByZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2Yg dGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFp bGFibGUgYXQgaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJ YIZIAYb4QgEBBAQDAgAHMDgGCWCGSAGG+EIBDQQrFilTdGFydENvbSBGcmVlIFNT TCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTANBgkqhkiG9w0BAQUFAAOCAgEAFmyZ 9GYMNPXQhV59CuzaEE44HF7fpiUFS5Eyweg78T3dRAlbB0mKKctmArexmvclmAk8 jhvh3TaHK0u7aNM5Zj2gJsfyOZEdUauCe37Vzlrk4gNXcGmXCPleWKYK34wGmkUW FjgKXlf2Ysd6AgXmvB618p70qSmD+LIU424oh0TDkBreOKk8rENNZEXO3SipXPJz ewT4F+irsfMuXGRuczE6Eri8sxHkfY+BUZo7jYn0TZNmezwD7dOaHZrzZVD1oNB1 ny+v8OqCQ5j4aZyJecRDjkZy42Q2Eq/3JR44iZB3fsNrarnDy0RLrHiQi+fHLB5L EUTINFInzQpdn4XBidUaePKVEFMy3YCEZnXZtWgo+2EuvoSoOMCZEoalHmdkrQYu L6lwhceWD3yJZfWOQ1QOq92lgDmUYMA0yZZwLKMS9R9Ie70cfmu3nZD0Ijuu+Pwq yvqCUqDvr0tVk+vBtfAii6w0TiYiBKGHLHVKt+V9E9e4DGTANtLJL4YSjCMJwRuC O3NJo2pXh5Tl1njFmUNj403gdy3hZZlyaQQaRwnmDwFWJPsfvw55qVguucQJAX6V um0ABj6y6koQOdjQK/W/7HW/lwLFCRsI3FU34oH7N4RDYiDK51ZLZer+bMEkkySh NOsF/5oirpt9P/FlUQqmMGqz9IgcgA38corog14= -----END CERTIFICATE----- --/2994txjAzEdQwm5-- From nobody Sat Apr 5 16:31:37 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 614211A0192 for ; Sat, 5 Apr 2014 16:31:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.631 X-Spam-Level: X-Spam-Status: No, score=-0.631 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id frUPR_6BWPFm for ; Sat, 5 Apr 2014 16:31:31 -0700 (PDT) Received: from mail-lb0-f178.google.com (mail-lb0-f178.google.com [209.85.217.178]) by ietfa.amsl.com (Postfix) with ESMTP id 810E01A01AC for ; Sat, 5 Apr 2014 16:31:30 -0700 (PDT) Received: by mail-lb0-f178.google.com with SMTP id s7so3506190lbd.23 for ; Sat, 05 Apr 2014 16:31:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=kgrPSkSrMoZJn1xMETfKyo72apUGTMzAg0CM3yQ5sFQ=; b=hWc6GacTNdc8ovQ/JJKUhu21lxOsoTYj6N6kGGSjNxdKAiWO1mOtzynwxr+ZLdBJjN TAeJ7P8bUJkZHLmhiQe9lpJq0BEht2nM/iLH946B6488xt7kX2TUkARRZTUMwcQJ8Fdo xXoLRzMnCAD+xTVrWxe4nafwqp0H8Jr684L/saqkNan2s/2Z2Ow0Tf+A7nL7orA/AfkI nkAIi6A5IZ1zHoJXbKbr7OoYBjbr86Is5lduvquqzUOmekunbc0bybWodUJUkVwp0yex yut1/HK7S9dhLMsfwCFGUiIiq6Q0wedOyksh+BVAlSwM9oMPLT7LROb7WaLsU1Pz9vbe tGyA== X-Gm-Message-State: ALoCoQkB0UkKHLIOb7n9PeZto8fXlrkwDELfafJVw4HOofLyJhyBzFVYd6qOZoxvlX9KsedpZ+cs MIME-Version: 1.0 X-Received: by 10.112.135.106 with SMTP id pr10mr13988431lbb.24.1396740685076; Sat, 05 Apr 2014 16:31:25 -0700 (PDT) Received: by 10.114.0.243 with HTTP; Sat, 5 Apr 2014 16:31:25 -0700 (PDT) X-Originating-IP: [66.84.81.58] In-Reply-To: <20140405040326.GO12559@mournblade.imrryr.org> References: <533EF994.7000009@nist.gov> <20140405040326.GO12559@mournblade.imrryr.org> Date: Sun, 6 Apr 2014 07:31:25 +0800 Message-ID: From: Warren Kumari To: "" Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/StaJrQLxEK9PTFX50TZeltlkTeE Subject: Re: [dane] An Update on Danelaw X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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 Apr 2014 23:31:35 -0000 On Sat, Apr 5, 2014 at 12:03 PM, Viktor Dukhovni wrote: > On Fri, Apr 04, 2014 at 02:27:32PM -0400, Stephen Nightingale wrote: > >> https://www.had-pilot.com/dane/danelaw.html. > >> The three DANE clients based on TLSlite 0.4.6, GnuTLS 3.1.16 and OpenSSL >> 1.0.1e all now incorporate Viktor Dukhovni's 'C' language dane checker >> and return consistent - though not identical - results. > > To be precise, currently each of these: connects, dumps the server > certificate chain to a PEM chain file, and invokes my DANE verification > code in an "offline" mode to validate the chain against each of > the TLSA records. That way the verification code is independent > of the TLS toolkit used to complete the connection. > >> - Dougbarton.us works with GnuTLS, but generates handshake failures with >> TLSlite and OpenSSL. > > Something is not right with the above, at least with OpenSSL 1.0.1 > I get a working SSL connection with dougbarton.us. Now this server > presents a chain with just the leaf certificate, even though the > issuing CA is an intermediate CA. When I put both the intermediate > cert (attached) and its issuing root (attached) in a CAfile, I can > verify the dougbarton.us "1 0 2" TLSA record just fine. > >> - Kumari.net and Spodhuis.org both complete handshakes with TLSlite and >> GnuTLS, but fail against OpenSSL. > > OpenSSL succeeds for me with spodhuis.org. Same StartCom root and > intermediate as dougbarton.us, but spodhuis actually presents a > full chain. > > Likewise www.kumari.net works, and the "TLSA 1 0 1" record matches > with the PKIX root from Equifax. > > Do connections to these sites work for you with "openssl s_client"? Works for me with OpenSSL 1.0.1. > This warrants further investigation. > Yup. >> - Kumari.net returns 403 forbidden to TLSlite and GnuTLS, but works with the >> Browsers. I am guessing the 403 is generated because my clients do not send >> a certificate. I will be testing for bi-directional verification sometime >> in the future. Actually the 403 was being returned because some stupid webscrawler script kept DoSing me, so I denied anything that didn't include an "accept: " header. I've now removed that and the TLSlite and GnuTLS tests now show a page instead of the 403. While looking into this I found: [Sat Apr 05 19:12:50 2014] [error] [client 66.84.81.58] script not found or unable to stat: /usr/lib/cgi-bin/dane, referer: https://www.had-pilot.com/dane/yourdane.html in my log, which made me giggle... W > That's an application layer issue, that is not really relevant for > testing DANE. Once the TLS session is up, you can just disconnect, > without even sending an HTTP request. > >> GnuTLS is running all 0xx and 1xx certificate uses, serving a single end >> certificate per use. It runs 24/7 robustly. It can only be configured to >> take a single end certificate for the server handshake. When presented with >> a concatenation of PEM certs, it will send only the end cert in the server >> side handshake. > > That does not sound right, are you sure about that? RFC 2246, 4346 > and 5246 all require servers to present a chain with more than just > the leaf certificate unless directly issued by a root CA. So it > would be rather surprising of GnuTLS were not capable of presenting > a complete chain. Almost certainly you just need to invoke it > differently to load a complete chain. > >> The OpenSSL DANE server is running all 3xx certificate uses, with a single >> wild card end certificate. Whether it can serve a full PEM concatenated >> certificate chain is a question still to be investigated. > > OpenSSL definitely supports presenting a complete chain. > >> The near-future course of the DANE project at NIST will now focus on SMTP >> uses, for both MUAs and MTAs. > > I think the issues with the HTTP use case are not protocol-specific > and will crop up again with SMTP. So they should be addressed. > > -- > Viktor. > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > From nobody Tue Apr 8 10:19:40 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E5391A065D for ; Tue, 8 Apr 2014 10:19:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.172 X-Spam-Level: X-Spam-Status: No, score=-0.172 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EYoRh8oFcygy for ; Tue, 8 Apr 2014 10:19:34 -0700 (PDT) Received: from mail.hardakers.net (mail.hardakers.net [168.150.236.43]) by ietfa.amsl.com (Postfix) with ESMTP id 7E4CE1A065B for ; Tue, 8 Apr 2014 10:19:33 -0700 (PDT) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id 6D2642206E; Tue, 8 Apr 2014 10:19:33 -0700 (PDT) From: Wes Hardaker To: Petr Spacek References: <533EB433.5060204@redhat.com> Date: Tue, 08 Apr 2014 10:19:33 -0700 In-Reply-To: <533EB433.5060204@redhat.com> (Petr Spacek's message of "Fri, 04 Apr 2014 15:31:31 +0200") Message-ID: <0lha63rb6i.fsf@wjh.hardakers.net> User-Agent: Gnus/5.13001 (Ma Gnus v0.10) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/dane/O21dSJ26IRBL_a6zzzWoLMb7pmM Cc: dane@ietf.org Subject: Re: [dane] AD bit handling in stub-resolvers: conclusions and compromises X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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 Apr 2014 17:19:36 -0000 Petr Spacek writes: > It seems that almost everyone agree that local validating resolver is the > best option. I failed to pipe up before, unfortunately. But, no I don't agree that's the best solution. The reality is that in some cases we're making *security decisions* based on the results of a flag that we're not 100% sure of the source. Without doing something like replacing the system library's notion of even looking at resolv.conf and only looking for 127.0.0.1, then you can't be 100% sure that the bit you get back is actually trustable. If the default install of the OS does the right thing, who's to say it'll stay that way. As an application author who might want absolute assurance that DNSSEC was done (because I'm bootstrapping TLS or SSH or ... off of it), then my ideal situation is to have a local resolver for caching purposes, but to actually do validation in-application. -- Wes Hardaker Parsons From nobody Tue Apr 8 10:49:43 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60E851A0667 for ; Tue, 8 Apr 2014 10:49:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W2K8yfSB5DPB for ; Tue, 8 Apr 2014 10:49:38 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 5A9361A0488 for ; Tue, 8 Apr 2014 10:49:38 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 1A3FA2AABDF; Tue, 8 Apr 2014 17:49:37 +0000 (UTC) Date: Tue, 8 Apr 2014 17:49:37 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140408174936.GL12559@mournblade.imrryr.org> References: <533EB433.5060204@redhat.com> <0lha63rb6i.fsf@wjh.hardakers.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0lha63rb6i.fsf@wjh.hardakers.net> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/f7cllIUB4LV_dN0K_gtvAy-CMKA Subject: Re: [dane] AD bit handling in stub-resolvers: conclusions and compromises X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 17:49:40 -0000 On Tue, Apr 08, 2014 at 10:19:33AM -0700, Wes Hardaker wrote: > Petr Spacek writes: > > > It seems that almost everyone agree that local validating resolver is the > > best option. > > I failed to pipe up before, unfortunately. > > But, no I don't agree that's the best solution. The reality is that in > some cases we're making *security decisions* based on the results of a > flag that we're not 100% sure of the source. Without doing something > like replacing the system library's notion of even looking at > resolv.conf and only looking for 127.0.0.1, then you can't be 100% sure > that the bit you get back is actually trustable. If the default install > of the OS does the right thing, who's to say it'll stay that way. This is where Wes and I part ways somewhat, but fortunately, this issue is not an impediment to the SMTP DANE draft. > As an application author who might want absolute assurance that DNSSEC > was done (because I'm bootstrapping TLS or SSH or ... off of it), then > my ideal situation is to have a local resolver for caching purposes, but > to actually do validation in-application. For me doing it in application, means costly integration of complex code into the application that will add considerable latency because the application will have a cold DNSSEC cache (and will now need a cache where one was not needed before... The Plan-9 approach of moving security features into system services is I think far preferable. The intersection of the position Wes takes and mine is some sort of 'assured' AD bit, which I am not opposed to in principle, provided this is in fact a reasonable plan of action. So for example, extending libresolv to match long-established BSD semantics to improve thread safety and provide more application control would suffice, res_ninit(), res_setservers(), ... plus ideally the ability to set the "AD" bit in the request (rather than "DO", reducing the quantity of unnecessary bloat in the reply). That way applications that want a local resolver can be configured to use one, and can make appropriate fallback decisions if one is not available. As for *censoring* the AD bit, that approach is likely more problematic and I think is where Paul Wouters and Petr part ways... So please make it possible in all the various DNS APIs (that don't already do this) for the stub resolver to override the default nameserver list (static or insecurely obtained from DHCP). Give the stub resolver more control over the "AD" and "DO" bits, and think long and hard about whether censoring is a viable approach it may well be a bad idea. -- Viktor. From nobody Tue Apr 8 16:50:49 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D5181A0710 for ; Tue, 8 Apr 2014 16:50:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.273 X-Spam-Level: X-Spam-Status: No, score=-3.273 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_25=0.6, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hVu1OVVn4Ajr for ; Tue, 8 Apr 2014 16:50:42 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) by ietfa.amsl.com (Postfix) with ESMTP id CC20A1A02F6 for ; Tue, 8 Apr 2014 16:50:41 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.ams1.isc.org (Postfix) with ESMTP id 4A2B42383DD for ; Tue, 8 Apr 2014 23:50:29 +0000 (UTC) (envelope-from marka@isc.org) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 0DC4C160068 for ; Tue, 8 Apr 2014 23:52:05 +0000 (UTC) Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 034D5160066 for ; Tue, 8 Apr 2014 23:52:04 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 757001343582 for ; Wed, 9 Apr 2014 09:50:25 +1000 (EST) To: dane@ietf.org From: Mark Andrews References: <533EB433.5060204@redhat.com> <0lha63rb6i.fsf@wjh.hardakers.net> <20140408174936.GL12559@mournblade.imrryr.org> In-reply-to: Your message of "Tue, 08 Apr 2014 17:49:37 +0000." <20140408174936.GL12559@mournblade.imrryr.org> Date: Wed, 09 Apr 2014 09:50:25 +1000 Message-Id: <20140408235025.757001343582@rock.dv.isc.org> Archived-At: http://mailarchive.ietf.org/arch/msg/dane/qqF0dC_c89VyMOocyJGWcKdOgC4 Subject: Re: [dane] AD bit handling in stub-resolvers: conclusions and compromises X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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 Apr 2014 23:50:47 -0000 In message <20140408174936.GL12559@mournblade.imrryr.org>, Viktor Dukhovni write s: > On Tue, Apr 08, 2014 at 10:19:33AM -0700, Wes Hardaker wrote: > > > Petr Spacek writes: > > > > > It seems that almost everyone agree that local validating resolver is the > > > best option. > > > > I failed to pipe up before, unfortunately. > > > > But, no I don't agree that's the best solution. The reality is that in > > some cases we're making *security decisions* based on the results of a > > flag that we're not 100% sure of the source. Without doing something > > like replacing the system library's notion of even looking at > > resolv.conf and only looking for 127.0.0.1, then you can't be 100% sure > > that the bit you get back is actually trustable. If the default install > > of the OS does the right thing, who's to say it'll stay that way. > > This is where Wes and I part ways somewhat, but fortunately, this > issue is not an impediment to the SMTP DANE draft. > > > As an application author who might want absolute assurance that DNSSEC > > was done (because I'm bootstrapping TLS or SSH or ... off of it), then > > my ideal situation is to have a local resolver for caching purposes, but > > to actually do validation in-application. > > For me doing it in application, means costly integration of complex > code into the application that will add considerable latency because > the application will have a cold DNSSEC cache (and will now need > a cache where one was not needed before... The Plan-9 approach of > moving security features into system services is I think far > preferable. What latency? This is the output of delve (see BIND 9.10) which is a is standalone stub validator talking to a local validating resolver doing a full validation from the root. This uses exactly the same code that named uses to validate its answers. The only difference is a slightly different cache implementation is used. 28.321 - 28.298 = 00.023 from start to finish. The only change I made was to make the logging print out timestamps. 09-Apr-2014 09:41:28.298 ;; res 0x11076f000: create 09-Apr-2014 09:41:28.300 ;; adb: task-exclusive mode unavailable, intializing table sizes to 49193 09-Apr-2014 09:41:28.306 ;; dns_requestmgr_create 09-Apr-2014 09:41:28.306 ;; dns_requestmgr_create: 0x110774000 09-Apr-2014 09:41:28.306 ;; dns_requestmgr_whenshutdown 09-Apr-2014 09:41:28.307 ;; adding DLV trust anchor dlv.isc.org 09-Apr-2014 09:41:28.307 ;; adding trust anchor . 09-Apr-2014 09:41:28.307 ;; fetch: dv.isc.org/SOA 09-Apr-2014 09:41:28.307 ;; fctx 0x111529000(dv.isc.org/SOA): create 09-Apr-2014 09:41:28.307 ;; log_ns_ttl: fctx 0x111529000: fctx_create: dv.isc.org (in '.'?): 0 0 09-Apr-2014 09:41:28.307 ;; fctx 0x111529000(dv.isc.org/SOA): join 09-Apr-2014 09:41:28.307 ;; fetch 0x11075a0a8 (fctx 0x111529000(dv.isc.org/SOA)): created 09-Apr-2014 09:41:28.307 ;; fctx 0x111529000(dv.isc.org/SOA): start 09-Apr-2014 09:41:28.307 ;; fctx 0x111529000(dv.isc.org/SOA): try 09-Apr-2014 09:41:28.307 ;; fctx 0x111529000(dv.isc.org/SOA): cancelqueries 09-Apr-2014 09:41:28.307 ;; fctx 0x111529000(dv.isc.org/SOA): getaddresses 09-Apr-2014 09:41:28.307 ;; fctx 0x111529000(dv.isc.org/SOA): query 09-Apr-2014 09:41:28.307 ;; resquery 0x11152f000 (fctx 0x111529000(dv.isc.org/SOA)): send 09-Apr-2014 09:41:28.307 ;; resquery 0x11152f000 (fctx 0x111529000(dv.isc.org/SOA)): sent 09-Apr-2014 09:41:28.307 ;; resquery 0x11152f000 (fctx 0x111529000(dv.isc.org/SOA)): senddone 09-Apr-2014 09:41:28.308 ;; resquery 0x11152f000 (fctx 0x111529000(dv.isc.org/SOA)): response 09-Apr-2014 09:41:28.308 ;; received packet: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4409 ;; flags: qr rd ra ad; QUESTION: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ; SIT: 2d8cf3496b58375c57ed3b5b53448928f199cb69a8065b4d ;; QUESTION SECTION: ;dv.isc.org. IN SOA ;; ANSWER SECTION: ;Dv.isc.org. 3532 IN SOA bsdi.dv.isc.org. marka.isc.org. ( ; 2007111528 ; serial ; 86400 ; refresh (1 day) ; 21600 ; retry (6 hours) ; 2419200 ; expire (4 weeks) ; 86400 ; minimum (1 day) ; ) ;Dv.isc.org. 3532 IN RRSIG SOA 5 3 3600 ( ; 20140606234902 20140407224902 14436 dv.isc.org. ; i8fBym000/fiC3XrQ1B0spgppClO ; yQfdQiPq3p2228bSYR86NzxOqpUL ; 2YBya9120KctdiLBOpeUEIf285Tz ; xA== ) ;; AUTHORITY SECTION: ;Dv.isc.org. 5842 IN NS bsdi1.dv.isc.org. ;Dv.isc.org. 5842 IN NS drugs.dv.isc.org. ;Dv.isc.org. 5842 IN RRSIG NS 5 3 86400 ( ; 20140520164117 20140321164013 14436 dv.isc.org. ; uRGZe6K+C3wzVaOscR/+Cf1xwimw ; TuPim/lW/q/lzPzLx1B39IQXEc1Y ; Jl6zkARqafYXstPBDrLvHmV1x0FE ; jQ== ) 09-Apr-2014 09:41:28.308 ;; fctx 0x111529000(dv.isc.org/SOA): answer_response 09-Apr-2014 09:41:28.308 ;; log_ns_ttl: fctx 0x111529000: answer_response: dv.isc.org (in '.'?): 0 0 09-Apr-2014 09:41:28.308 ;; fctx 0x111529000(dv.isc.org/SOA): cache_message 09-Apr-2014 09:41:28.308 ;; decrement_reference: delete from rbt: 0x11077e078 Dv.isc.org 09-Apr-2014 09:41:28.308 ;; fctx 0x111529000(dv.isc.org/SOA): cancelquery 09-Apr-2014 09:41:28.308 ;; fctx 0x111529000(dv.isc.org/SOA): wait for validator 09-Apr-2014 09:41:28.308 ;; fctx 0x111529000(dv.isc.org/SOA): cancelqueries 09-Apr-2014 09:41:28.308 ;; validating Dv.isc.org/SOA: starting 09-Apr-2014 09:41:28.308 ;; validating Dv.isc.org/SOA: attempting positive response validation 09-Apr-2014 09:41:28.308 ;; validating Dv.isc.org/SOA: get_key: creating fetch for dv.isc.org DNSKEY 09-Apr-2014 09:41:28.308 ;; fetch: dv.isc.org/DNSKEY 09-Apr-2014 09:41:28.308 ;; fctx 0x111529430(dv.isc.org/DNSKEY): create 09-Apr-2014 09:41:28.308 ;; log_ns_ttl: fctx 0x111529430: fctx_create: dv.isc.org (in '.'?): 0 0 09-Apr-2014 09:41:28.308 ;; fctx 0x111529430(dv.isc.org/DNSKEY): join 09-Apr-2014 09:41:28.308 ;; fetch 0x11075a120 (fctx 0x111529430(dv.isc.org/DNSKEY)): created 09-Apr-2014 09:41:28.308 ;; fctx 0x111529430(dv.isc.org/DNSKEY): start 09-Apr-2014 09:41:28.308 ;; fctx 0x111529430(dv.isc.org/DNSKEY): try 09-Apr-2014 09:41:28.308 ;; fctx 0x111529430(dv.isc.org/DNSKEY): cancelqueries 09-Apr-2014 09:41:28.308 ;; fctx 0x111529430(dv.isc.org/DNSKEY): getaddresses 09-Apr-2014 09:41:28.308 ;; fctx 0x111529430(dv.isc.org/DNSKEY): query 09-Apr-2014 09:41:28.308 ;; resquery 0x11152f000 (fctx 0x111529430(dv.isc.org/DNSKEY)): send 09-Apr-2014 09:41:28.308 ;; resquery 0x11152f000 (fctx 0x111529430(dv.isc.org/DNSKEY)): sent 09-Apr-2014 09:41:28.308 ;; resquery 0x11152f000 (fctx 0x111529430(dv.isc.org/DNSKEY)): senddone 09-Apr-2014 09:41:28.308 ;; resquery 0x11152f000 (fctx 0x111529430(dv.isc.org/DNSKEY)): response 09-Apr-2014 09:41:28.308 ;; received packet: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17780 ;; flags: qr rd ra ad; QUESTION: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ; SIT: 2d8cf3496b58375c71d56ac853448928ef24558c8085c830 ;; QUESTION SECTION: ;dv.isc.org. IN DNSKEY ;; ANSWER SECTION: ;Dv.isc.org. 5842 IN DNSKEY 257 3 5 ( ; AwEAAbatyuBZQjJB6WnkeFMGIDNU ; UMHDSFOsvcjVarCYaN5c5lg56SAL ; PpvkbauGnt2S6coHqKG6o36hwoNm ; J4Qjc94FU9Bzsg60pyviSrnFJT3l ; 13W+jTEoXU3pRk9f4182ffL/aKdI ; wW0dDuMphPyjqaomSeBfjnojhD+Q ; Li144lOl ; ) ; KSK; alg = RSASHA1; key id = 10288 ;Dv.isc.org. 5842 IN DNSKEY 256 3 5 ( ; AwEAAePX2qjqzu9uE79fDAwb99GH ; 1xnF6b+dsRqHOnmKldHWTb3KX2Yp ; WzuDKQZpISkakn0mf32FHp5iuu8H ; 5VOkcf0= ; ) ; ZSK; alg = RSASHA1; key id = 14436 ;Dv.isc.org. 5842 IN RRSIG DNSKEY 5 3 86400 ( ; 20140520204428 20140321202107 10288 dv.isc.org. ; imsRQCYCmv6yf6viAO+lfp1bEKfK ; VKD1BmZEfrmE1cTaW9k8mEjgNmhM ; nt7XdZ1XQslygbl1VRl1hBntp/kA ; Rqwq3s+Hd84hIZjt2ThXji3uBWoE ; jmzuhqq3mJufle8CXUR68Jrp04Pd ; jSIeXVsYm8JIlVlnTWzXj505IGG7 ; Uh0= ) ;Dv.isc.org. 5842 IN RRSIG DNSKEY 5 3 86400 ( ; 20140520204428 20140321202107 14436 dv.isc.org. ; axyw6FZGW+HlGLTQP8yhG+DHdefK ; 42nZCWX4Gv3sQtovUOkS0NaucJF1 ; 65nZR4s5qWj+/yGVgjKw/zco7RLu ; pg== ) 09-Apr-2014 09:41:28.308 ;; fctx 0x111529430(dv.isc.org/DNSKEY): answer_response 09-Apr-2014 09:41:28.308 ;; log_ns_ttl: fctx 0x111529430: answer_response: dv.isc.org (in '.'?): 0 0 09-Apr-2014 09:41:28.308 ;; fctx 0x111529430(dv.isc.org/DNSKEY): cache_message 09-Apr-2014 09:41:28.308 ;; fctx 0x111529430(dv.isc.org/DNSKEY): cancelquery 09-Apr-2014 09:41:28.308 ;; fctx 0x111529430(dv.isc.org/DNSKEY): wait for validator 09-Apr-2014 09:41:28.308 ;; fctx 0x111529430(dv.isc.org/DNSKEY): cancelqueries 09-Apr-2014 09:41:28.308 ;; validating Dv.isc.org/DNSKEY: starting 09-Apr-2014 09:41:28.308 ;; validating Dv.isc.org/DNSKEY: attempting positive response validation 09-Apr-2014 09:41:28.308 ;; validating Dv.isc.org/DNSKEY: validatezonekey: creating fetch for Dv.isc.org DS 09-Apr-2014 09:41:28.308 ;; fetch: Dv.isc.org/DS 09-Apr-2014 09:41:28.308 ;; fctx 0x111529860(Dv.isc.org/DS): create 09-Apr-2014 09:41:28.308 ;; log_ns_ttl: fctx 0x111529860: fctx_create: Dv.isc.org (in '.'?): 0 0 09-Apr-2014 09:41:28.308 ;; fctx 0x111529860(Dv.isc.org/DS): join 09-Apr-2014 09:41:28.308 ;; fetch 0x11075a138 (fctx 0x111529860(Dv.isc.org/DS)): created 09-Apr-2014 09:41:28.308 ;; fctx 0x111529860(Dv.isc.org/DS): start 09-Apr-2014 09:41:28.308 ;; fctx 0x111529860(Dv.isc.org/DS): try 09-Apr-2014 09:41:28.308 ;; fctx 0x111529860(Dv.isc.org/DS): cancelqueries 09-Apr-2014 09:41:28.309 ;; fctx 0x111529860(Dv.isc.org/DS): getaddresses 09-Apr-2014 09:41:28.309 ;; fctx 0x111529860(Dv.isc.org/DS): query 09-Apr-2014 09:41:28.309 ;; resquery 0x11152f000 (fctx 0x111529860(Dv.isc.org/DS)): send 09-Apr-2014 09:41:28.309 ;; resquery 0x11152f000 (fctx 0x111529860(Dv.isc.org/DS)): sent 09-Apr-2014 09:41:28.309 ;; resquery 0x11152f000 (fctx 0x111529860(Dv.isc.org/DS)): senddone 09-Apr-2014 09:41:28.309 ;; resquery 0x11152f000 (fctx 0x111529860(Dv.isc.org/DS)): response 09-Apr-2014 09:41:28.309 ;; received packet: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16583 ;; flags: qr rd ra ad; QUESTION: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ; SIT: 2d8cf3496b58375c42f44fcf53448928f6f346b94566391e ;; QUESTION SECTION: ;Dv.isc.org. IN DS ;; ANSWER SECTION: ;Dv.isc.org. 6130 IN DS 10288 5 2 ( ; 6D9CD532BC5E7EE6404EB019048F ; C9727A970854EF0375364F8F6ED5 ; 4A8DA73B ) ;Dv.isc.org. 6130 IN DS 10288 5 1 ( ; 22F103696F795206A7373850444C ; 6F4DA61D0076 ) ;Dv.isc.org. 6130 IN RRSIG DS 5 3 7200 ( ; 20140507233241 20140407233241 4521 isc.org. ; pmz1rcVQRr3lbnBDp36ew3oz44gT ; GJgI4RvyyAapOyGP8Fa1flG5BKYQ ; Fo5G68OhMLVupXhys2mo9BQoEx/z ; ydbVkHuciBK3qKEvHUiq69e/iGuv ; dRjWopgv0uY8o0rSPabVpoa07I1P ; Hj8+682Ku9TGLmyNelpNuhz7bgq7 ; GBE= ) 09-Apr-2014 09:41:28.309 ;; fctx 0x111529860(Dv.isc.org/DS): answer_response 09-Apr-2014 09:41:28.309 ;; log_ns_ttl: fctx 0x111529860: answer_response: Dv.isc.org (in '.'?): 0 0 09-Apr-2014 09:41:28.309 ;; fctx 0x111529860(Dv.isc.org/DS): cache_message 09-Apr-2014 09:41:28.309 ;; fctx 0x111529860(Dv.isc.org/DS): cancelquery 09-Apr-2014 09:41:28.309 ;; fctx 0x111529860(Dv.isc.org/DS): wait for validator 09-Apr-2014 09:41:28.309 ;; fctx 0x111529860(Dv.isc.org/DS): cancelqueries 09-Apr-2014 09:41:28.309 ;; validating Dv.isc.org/DS: starting 09-Apr-2014 09:41:28.309 ;; validating Dv.isc.org/DS: attempting positive response validation 09-Apr-2014 09:41:28.309 ;; validating Dv.isc.org/DS: get_key: creating fetch for isc.org DNSKEY 09-Apr-2014 09:41:28.309 ;; fetch: isc.org/DNSKEY 09-Apr-2014 09:41:28.309 ;; fctx 0x111569000(isc.org/DNSKEY): create 09-Apr-2014 09:41:28.309 ;; log_ns_ttl: fctx 0x111569000: fctx_create: isc.org (in '.'?): 0 0 09-Apr-2014 09:41:28.309 ;; fctx 0x111569000(isc.org/DNSKEY): join 09-Apr-2014 09:41:28.309 ;; fetch 0x11075a150 (fctx 0x111569000(isc.org/DNSKEY)): created 09-Apr-2014 09:41:28.309 ;; fctx 0x111569000(isc.org/DNSKEY): start 09-Apr-2014 09:41:28.309 ;; fctx 0x111569000(isc.org/DNSKEY): try 09-Apr-2014 09:41:28.309 ;; fctx 0x111569000(isc.org/DNSKEY): cancelqueries 09-Apr-2014 09:41:28.309 ;; fctx 0x111569000(isc.org/DNSKEY): getaddresses 09-Apr-2014 09:41:28.309 ;; fctx 0x111569000(isc.org/DNSKEY): query 09-Apr-2014 09:41:28.309 ;; resquery 0x11156f000 (fctx 0x111569000(isc.org/DNSKEY)): send 09-Apr-2014 09:41:28.309 ;; resquery 0x11156f000 (fctx 0x111569000(isc.org/DNSKEY)): sent 09-Apr-2014 09:41:28.309 ;; resquery 0x11156f000 (fctx 0x111569000(isc.org/DNSKEY)): senddone 09-Apr-2014 09:41:28.309 ;; resquery 0x11156f000 (fctx 0x111569000(isc.org/DNSKEY)): response 09-Apr-2014 09:41:28.309 ;; received packet: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15856 ;; flags: qr rd ra ad; QUESTION: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ; SIT: 2d8cf3496b58375ca839dce553448928545eebc5e1402641 ;; QUESTION SECTION: ;isc.org. IN DNSKEY ;; ANSWER SECTION: ;isc.org. 5395 IN DNSKEY 256 3 5 ( ; AwEAAbJpDF4RemdHHE/HrJJhR3zp ; zAQ6zsHqFv0i4lCWTUf4sX+cq3vS ; u7fKO4QJtm97S1sbcnmHonVE3QPz ; LOsqsY630Wy5JzrPK3gUvQLgfIso ; vo2v+dosITL8WbvjU1mEXhIwfuuB ; hYmYSKySZ0X9gpHGhdxRd+J8M7ri ; PfN7kHLP ; ) ; ZSK; alg = RSASHA1; key id = 4521 ;isc.org. 5395 IN DNSKEY 257 3 5 ( ; BEAAAAOhHQDBrhQbtphgq2wQUpEQ ; 5t4DtUHxoMVFu2hWLDMvoOMRXjGr ; hhCeFvAZih7yJHf8ZGfW6hd38hXG ; /xylYCO6Krpbdojwx8YMXLA5/kA+ ; u50WIL8ZR1R6KTbsYVMf/Qx5RiNb ; PClw+vT+U8eXEJmO20jIS1ULgqy3 ; 47cBB1zMnnz/4LJpA0da9CbKj3A2 ; 54T515sNIMcwsB8/2+2E63/zZrQz ; Bkj0BrN/9Bexjpiks3jRhZatEsXn ; 3dTy47R09Uix5WcJt+xzqZ7+ysyL ; KOOedS39Z7SDmsn2eA0FKtQpwA6L ; XeG2w+jxmw3oA8lVUgEf/rzeC/bB ; yBNsO70aEFTd ; ) ; KSK; alg = RSASHA1; key id = 12892 ;isc.org. 5395 IN RRSIG DNSKEY 5 2 7200 ( ; 20140507230126 20140407230126 4521 isc.org. ; dcmQwSpa00DJ8pd2PBKJxRyZ+ax4 ; r/VBliEh2x5v/CUurfQfGIbnn+ZW ; Pz4EnRkDkiComnwEQo4jfMRjv3S3 ; ltz9L0Xi5XVlr+bhyc7OeDdGhdG6 ; SsEgyLvQ92Jg1wFeVLIkIieTnqps ; O3EvjR6eY83Rc266ubk8MvnFcpJg ; 0m0= ) ;isc.org. 5395 IN RRSIG DNSKEY 5 2 7200 ( ; 20140507230126 20140407230126 12892 isc.org. ; j4k8SwlG6sibrmqhe810xEWxqf4p ; AuBRkDTOcZM4j5CFdffOjwt01Uhp ; tiQ7mMfOPQcygD3WzQz5oC8J+BYe ; mCH4cSwj/pprX/7VLuxeIp/NnD7A ; vBfc884aoLDFMWFzLq7f98eHhfnK ; ui1LY568G67n9rKF1TFk3TIcEoQS ; oRt5U02ATgkF59fpVQZYg5B1dBIp ; CAm2puOWuAHy4nXINYBjItqfNEtg ; 1cbJBa7IRQWaaZY9+CVHKShs3GYg ; 6/1WMwgWwadl4/6ySy0/m71H3aCx ; fBETFZ5pY4VpjvMOghbioGrpse9E ; +C3wRAU9NGkJMSESwIez/YpE72NO ; u470Og== ) 09-Apr-2014 09:41:28.309 ;; fctx 0x111569000(isc.org/DNSKEY): answer_response 09-Apr-2014 09:41:28.309 ;; log_ns_ttl: fctx 0x111569000: answer_response: isc.org (in '.'?): 0 0 09-Apr-2014 09:41:28.309 ;; fctx 0x111569000(isc.org/DNSKEY): cache_message 09-Apr-2014 09:41:28.309 ;; fctx 0x111569000(isc.org/DNSKEY): cancelquery 09-Apr-2014 09:41:28.309 ;; fctx 0x111569000(isc.org/DNSKEY): wait for validator 09-Apr-2014 09:41:28.309 ;; fctx 0x111569000(isc.org/DNSKEY): cancelqueries 09-Apr-2014 09:41:28.309 ;; validating isc.org/DNSKEY: starting 09-Apr-2014 09:41:28.309 ;; validating isc.org/DNSKEY: attempting positive response validation 09-Apr-2014 09:41:28.310 ;; validating isc.org/DNSKEY: validatezonekey: creating fetch for isc.org DS 09-Apr-2014 09:41:28.310 ;; fetch: isc.org/DS 09-Apr-2014 09:41:28.310 ;; fctx 0x111569430(isc.org/DS): create 09-Apr-2014 09:41:28.310 ;; log_ns_ttl: fctx 0x111569430: fctx_create: isc.org (in '.'?): 0 0 09-Apr-2014 09:41:28.310 ;; fctx 0x111569430(isc.org/DS): join 09-Apr-2014 09:41:28.310 ;; fetch 0x11075a168 (fctx 0x111569430(isc.org/DS)): created 09-Apr-2014 09:41:28.310 ;; fctx 0x111569430(isc.org/DS): start 09-Apr-2014 09:41:28.310 ;; fctx 0x111569430(isc.org/DS): try 09-Apr-2014 09:41:28.310 ;; fctx 0x111569430(isc.org/DS): cancelqueries 09-Apr-2014 09:41:28.310 ;; fctx 0x111569430(isc.org/DS): getaddresses 09-Apr-2014 09:41:28.310 ;; fctx 0x111569430(isc.org/DS): query 09-Apr-2014 09:41:28.310 ;; resquery 0x11156f000 (fctx 0x111569430(isc.org/DS)): send 09-Apr-2014 09:41:28.310 ;; resquery 0x11156f000 (fctx 0x111569430(isc.org/DS)): sent 09-Apr-2014 09:41:28.310 ;; resquery 0x11156f000 (fctx 0x111569430(isc.org/DS)): senddone 09-Apr-2014 09:41:28.310 ;; resquery 0x11156f000 (fctx 0x111569430(isc.org/DS)): response 09-Apr-2014 09:41:28.310 ;; received packet: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31640 ;; flags: qr rd ra ad; QUESTION: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ; SIT: 2d8cf3496b58375cda8ad76953448928e7787e67a66486d6 ;; QUESTION SECTION: ;isc.org. IN DS ;; ANSWER SECTION: ;isc.org. 5504 IN DS 12892 5 2 ( ; F1E184C0E1D615D20EB3C223ACED ; 3B03C773DD952D5F0EB5C777586D ; E18DA6B5 ) ;isc.org. 5504 IN DS 12892 5 1 ( ; 982113D08B4C6A1D9F6AEE1E2237 ; AEF69F3F9759 ) ;isc.org. 5504 IN RRSIG DS 7 2 86400 ( ; 20140422155313 20140401145313 28794 org. ; FoLFvxVMRXkdLg5wumU9Lf9uIFT9 ; lknz1zQPRAjNZlc/3Nq2hZMIELGT ; K26uQwFbAj/04XNJCnm34FVdYSWF ; P/y8V+4MimPpKLC3rt7sNKJlIhbH ; LLuIVr1l70WaaJ2NyKk6AgnRYY3D ; LSahHXXk/3sG+WWqI8UHBWTdi0up ; oqk= ) 09-Apr-2014 09:41:28.310 ;; fctx 0x111569430(isc.org/DS): answer_response 09-Apr-2014 09:41:28.310 ;; log_ns_ttl: fctx 0x111569430: answer_response: isc.org (in '.'?): 0 0 09-Apr-2014 09:41:28.310 ;; fctx 0x111569430(isc.org/DS): cache_message 09-Apr-2014 09:41:28.310 ;; fctx 0x111569430(isc.org/DS): cancelquery 09-Apr-2014 09:41:28.310 ;; fctx 0x111569430(isc.org/DS): wait for validator 09-Apr-2014 09:41:28.310 ;; fctx 0x111569430(isc.org/DS): cancelqueries 09-Apr-2014 09:41:28.310 ;; validating isc.org/DS: starting 09-Apr-2014 09:41:28.310 ;; validating isc.org/DS: attempting positive response validation 09-Apr-2014 09:41:28.310 ;; validating isc.org/DS: get_key: creating fetch for org DNSKEY 09-Apr-2014 09:41:28.310 ;; fetch: org/DNSKEY 09-Apr-2014 09:41:28.310 ;; fctx 0x1115a9000(org/DNSKEY): create 09-Apr-2014 09:41:28.310 ;; log_ns_ttl: fctx 0x1115a9000: fctx_create: org (in '.'?): 0 0 09-Apr-2014 09:41:28.310 ;; fctx 0x1115a9000(org/DNSKEY): join 09-Apr-2014 09:41:28.310 ;; fetch 0x11075a180 (fctx 0x1115a9000(org/DNSKEY)): created 09-Apr-2014 09:41:28.310 ;; fctx 0x1115a9000(org/DNSKEY): start 09-Apr-2014 09:41:28.310 ;; fctx 0x1115a9000(org/DNSKEY): try 09-Apr-2014 09:41:28.310 ;; fctx 0x1115a9000(org/DNSKEY): cancelqueries 09-Apr-2014 09:41:28.310 ;; fctx 0x1115a9000(org/DNSKEY): getaddresses 09-Apr-2014 09:41:28.310 ;; fctx 0x1115a9000(org/DNSKEY): query 09-Apr-2014 09:41:28.310 ;; resquery 0x1115af000 (fctx 0x1115a9000(org/DNSKEY)): send 09-Apr-2014 09:41:28.310 ;; resquery 0x1115af000 (fctx 0x1115a9000(org/DNSKEY)): sent 09-Apr-2014 09:41:28.310 ;; resquery 0x1115af000 (fctx 0x1115a9000(org/DNSKEY)): senddone 09-Apr-2014 09:41:28.310 ;; resquery 0x1115af000 (fctx 0x1115a9000(org/DNSKEY)): response 09-Apr-2014 09:41:28.310 ;; received packet: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57451 ;; flags: qr rd ra ad; QUESTION: 1, ANSWER: 7, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ; SIT: 2d8cf3496b58375c277da90653448928b346e9460f9b5cbb ;; QUESTION SECTION: ;org. IN DNSKEY ;; ANSWER SECTION: ;org. 832 IN DNSKEY 256 3 7 ( ; AwEAAYhrCBtYGnFviZ921MUyk5MD ; 1Ywzz9fLytgGY6enAgn9fFKjlhNp ; KFDCLxrzrFkPV8OCA2DtefVzIqaw ; TuHV1zjYgYZgx0nUn4zXVnxFSl4X ; 1CyXPT/AMPOrAw+cN38oxVQs2FDL ; aLwwmcxXmk3mBwTgu3fGHpmjdA5D ; /3TPeAjX ; ) ; ZSK; alg = NSEC3RSASHA1; key id = 28794 ;org. 832 IN DNSKEY 256 3 7 ( ; AwEAAa+yHvpOo3f7XS1vtKPGH6AD ; 1OkmYUtnRlkkCO9BKJ0OCCvYSWh5 ; NWLJjIMXRzVpituqoLtiYfhdDYQH ; 5JzRVW6lCtT+2SiWmEx+7GnSyMT4 ; 8858uC02AYlJVfbitCpoGGdzyLTi ; MxtMlztpRyCAvaDujnx+2GBo7zgb ; 50f5gQJp ; ) ; ZSK; alg = NSEC3RSASHA1; key id = 1829 ;org. 832 IN DNSKEY 257 3 7 ( ; AwEAAZTjbIO5kIpxWUtyXc8avsKy ; HIIZ+LjC2Dv8naO+Tz6X2fqzDC1b ; dq7HlZwtkaqTkMVVJ+8gE9FIreGJ ; 4c8G1GdbjQgbP1OyYIG7OHTc4hv5 ; T2NlyWr6k6QFz98Q4zwFIGTFVvwB ; hmrMDYsOTtXakK6QwHovA1+83BsU ; ACxlidpwB0hQacbD6x+I2RCDzYuT ; zj64Jv0/9XsX6AYV3ebcgn4hL1jI ; R2eJYyXlrAoWxdzxcW//5yeL5RVW ; uhRxejmnSVnCuxkfS4AQ485KH2tp ; dbWcCopLJZs6tw8q3jWcpTGzdh/v ; 3xdYfNpQNcPImFlxAun3BtORPA2r ; 8ti6MNoJEHU= ; ) ; KSK; alg = NSEC3RSASHA1; key id = 9795 ;org. 832 IN DNSKEY 257 3 7 ( ; AwEAAYpYfj3aaRzzkxWQqMdl7YEx ; Y81NdYSv+qayuZDodnZ9IMh0bwMc ; YaVUdzNAbVeJ8gd6jq1sR3VvP/SR ; 36mmGssbV4Udl5ORDtqiZP2TDNDH ; xEnKKTX+jWfytZeT7d3AbSzBKC0v ; 7uZrM6M2eoJnl6id66rEUmQC2p9D ; rrDg9F6tXC9CD/zC7/y+BNNpiOdn ; M5DXk7HhZm7ra9E7ltL13h2mx7kE ; gU8e6npJlCoXjraIBgUDthYs48W/ ; sdTDLu7N59rjCG+bpil+c8oZ9f7N ; R3qmSTpTP1m86RqUQnVErifrH8Kj ; DqL+3wzUdF5ACkYwt1XhPVPU+wSI ; lzbaAQN49PU= ; ) ; KSK; alg = NSEC3RSASHA1; key id = 21366 ;org. 832 IN RRSIG DNSKEY 7 1 900 ( ; 20140422155313 20140401145313 9795 org. ; U5EosaoqM0jPBPVdL08D5wilaHoH ; gcOHM3RNP0hwzv5lQg8JBtq6wZGA ; YUHstIDTD6LGxR3vLmZGeEHobtxk ; aNIp/TW1W/zB9SOySTK1DrnMKjYd ; yi64LbP/XvSv/Fpa29DVkIbU1REs ; dPSwWyurw1nKiAGUld1AYeGwU1Zi ; wwqHk6SB+ohZPmv7J9BgIjvSwswr ; PudynzIbyb1Y7bmI82nEo/FmX3qa ; YwLXkjsH50BYwAYH1C8CoAeg/fpg ; P+3b8JRx1M55EzAJNQqVL4nHtqdW ; 4FSV8h3t5pFzLwVpo3lLiKXQj8Di ; QVTT2JkHqOTnnhlvHG5BDZVykLn2 ; YNxXNQ== ) ;org. 832 IN RRSIG DNSKEY 7 1 900 ( ; 20140422155313 20140401145313 21366 org. ; JXhlQLDrtfK2ZdXQzdoygZnXNFfa ; 7/lPubNgrUmL46dYo1K07UL0yDkn ; fhKYrBd7WhES9koX8gR8m3sb4RJj ; MvtDi0VOOaxI8kCO6ltNQ5h8NKgw ; WEur+w25EwRjWRychohiIchXLXyK ; X7mTqUolhVCIfSJGShKLLW8ffYTV ; eNHP/3FdSu37RNqLsOn+pfaLbhK+ ; MNnwbb/UQbxCPFAkuZCy5JDaUsW0 ; JuqrhMei0EdzGb6qYPk9ZDtCWqZG ; T+yIdypqWOhM4Eqm8KnHsLbzQlnf ; ON7gi1ZOIIXoaX+Apo2I8venXqFw ; xuLTmhvJAkPCqA06oYvkHWf0/yxO ; x+JkVQ== ) ;org. 832 IN RRSIG DNSKEY 7 1 900 ( ; 20140422155313 20140401145313 28794 org. ; aHnCxEKmD9y/ZTBnrSu6ZDIhF+hB ; usJ3XKtBf8ubDrVZcvz8KUT812cL ; Se16T9pqVOMSoBp5ywGWrieaEsip ; XXcNjuzuL+5xbxLmnhnv2aiuapNk ; 0siZxvMPs+LV1Gw7Je2wj0o1qRgt ; TwoFVREPLDkbkEMdXqxrdWmTwVna ; OK8= ) 09-Apr-2014 09:41:28.311 ;; fctx 0x1115a9000(org/DNSKEY): answer_response 09-Apr-2014 09:41:28.311 ;; log_ns_ttl: fctx 0x1115a9000: answer_response: org (in '.'?): 0 0 09-Apr-2014 09:41:28.311 ;; fctx 0x1115a9000(org/DNSKEY): cache_message 09-Apr-2014 09:41:28.311 ;; fctx 0x1115a9000(org/DNSKEY): cancelquery 09-Apr-2014 09:41:28.311 ;; fctx 0x1115a9000(org/DNSKEY): wait for validator 09-Apr-2014 09:41:28.311 ;; fctx 0x1115a9000(org/DNSKEY): cancelqueries 09-Apr-2014 09:41:28.311 ;; validating org/DNSKEY: starting 09-Apr-2014 09:41:28.311 ;; validating org/DNSKEY: attempting positive response validation 09-Apr-2014 09:41:28.311 ;; validating org/DNSKEY: validatezonekey: creating fetch for org DS 09-Apr-2014 09:41:28.311 ;; fetch: org/DS 09-Apr-2014 09:41:28.311 ;; fctx 0x1115a9430(org/DS): create 09-Apr-2014 09:41:28.311 ;; log_ns_ttl: fctx 0x1115a9430: fctx_create: org (in '.'?): 0 0 09-Apr-2014 09:41:28.311 ;; fctx 0x1115a9430(org/DS): join 09-Apr-2014 09:41:28.311 ;; fetch 0x11075a198 (fctx 0x1115a9430(org/DS)): created 09-Apr-2014 09:41:28.311 ;; fctx 0x1115a9430(org/DS): start 09-Apr-2014 09:41:28.311 ;; fctx 0x1115a9430(org/DS): try 09-Apr-2014 09:41:28.311 ;; fctx 0x1115a9430(org/DS): cancelqueries 09-Apr-2014 09:41:28.311 ;; fctx 0x1115a9430(org/DS): getaddresses 09-Apr-2014 09:41:28.311 ;; fctx 0x1115a9430(org/DS): query 09-Apr-2014 09:41:28.311 ;; resquery 0x1115af000 (fctx 0x1115a9430(org/DS)): send 09-Apr-2014 09:41:28.311 ;; resquery 0x1115af000 (fctx 0x1115a9430(org/DS)): sent 09-Apr-2014 09:41:28.311 ;; resquery 0x1115af000 (fctx 0x1115a9430(org/DS)): senddone 09-Apr-2014 09:41:28.311 ;; resquery 0x1115af000 (fctx 0x1115a9430(org/DS)): response 09-Apr-2014 09:41:28.311 ;; received packet: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33728 ;; flags: qr rd ra ad; QUESTION: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ; SIT: 2d8cf3496b58375c3ca580375344892853012c63813507b5 ;; QUESTION SECTION: ;org. IN DS ;; ANSWER SECTION: ;org. 5504 IN DS 21366 7 1 ( ; E6C1716CFB6BDC84E84CE1AB5510 ; DAC69173B5B2 ) ;org. 5504 IN DS 21366 7 2 ( ; 96EEB2FFD9B00CD4694E78278B5E ; FDAB0A80446567B69F634DA078F0 ; D90F01BA ) ;org. 5504 IN RRSIG DS 8 1 86400 ( ; 20140414000000 20140406230000 40926 . ; hfVkPJGvRpXmvforixrVo77PO1/W ; Ipaa4cnp/XPrwk9csyo64zAWaCZL ; +kt5jBCSDlAfpX6cDASN4ueGXajm ; q8nVyrCT5QvuyHgWJQG0CjtcFgtC ; DxnWQHAaHdq9IwsuRYCAutjJo9yQ ; G8PdlUlTZWE8Rzn9UmRlw6KE212y ; CgI= ) 09-Apr-2014 09:41:28.311 ;; fctx 0x1115a9430(org/DS): answer_response 09-Apr-2014 09:41:28.311 ;; log_ns_ttl: fctx 0x1115a9430: answer_response: org (in '.'?): 0 0 09-Apr-2014 09:41:28.311 ;; fctx 0x1115a9430(org/DS): cache_message 09-Apr-2014 09:41:28.311 ;; fctx 0x1115a9430(org/DS): cancelquery 09-Apr-2014 09:41:28.311 ;; fctx 0x1115a9430(org/DS): wait for validator 09-Apr-2014 09:41:28.311 ;; fctx 0x1115a9430(org/DS): cancelqueries 09-Apr-2014 09:41:28.311 ;; validating org/DS: starting 09-Apr-2014 09:41:28.311 ;; validating org/DS: attempting positive response validation 09-Apr-2014 09:41:28.311 ;; validating org/DS: get_key: creating fetch for . DNSKEY 09-Apr-2014 09:41:28.311 ;; fetch: ./DNSKEY 09-Apr-2014 09:41:28.311 ;; fctx 0x1115e9000(./DNSKEY): create 09-Apr-2014 09:41:28.311 ;; log_ns_ttl: fctx 0x1115e9000: fctx_create: . (in '.'?): 0 0 09-Apr-2014 09:41:28.311 ;; fctx 0x1115e9000(./DNSKEY): join 09-Apr-2014 09:41:28.311 ;; fetch 0x11075a1b0 (fctx 0x1115e9000(./DNSKEY)): created 09-Apr-2014 09:41:28.311 ;; fctx 0x1115e9000(./DNSKEY): start 09-Apr-2014 09:41:28.311 ;; fctx 0x1115e9000(./DNSKEY): try 09-Apr-2014 09:41:28.311 ;; fctx 0x1115e9000(./DNSKEY): cancelqueries 09-Apr-2014 09:41:28.311 ;; fctx 0x1115e9000(./DNSKEY): getaddresses 09-Apr-2014 09:41:28.311 ;; fctx 0x1115e9000(./DNSKEY): query 09-Apr-2014 09:41:28.311 ;; resquery 0x1115ef000 (fctx 0x1115e9000(./DNSKEY)): send 09-Apr-2014 09:41:28.311 ;; resquery 0x1115ef000 (fctx 0x1115e9000(./DNSKEY)): sent 09-Apr-2014 09:41:28.311 ;; resquery 0x1115ef000 (fctx 0x1115e9000(./DNSKEY)): senddone 09-Apr-2014 09:41:28.312 ;; resquery 0x1115ef000 (fctx 0x1115e9000(./DNSKEY)): response 09-Apr-2014 09:41:28.312 ;; received packet: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62200 ;; flags: qr rd ra ad; QUESTION: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ; SIT: 2d8cf3496b58375cd01f4d7f5344892884b20fcd0bb5cd1e ;; QUESTION SECTION: ;. IN DNSKEY ;; ANSWER SECTION: ;. 91894 IN DNSKEY 256 3 8 ( ; AwEAAb8sU6pbYMWRbkRnEuEZw9NS ; ir707TkOcF+UL1XiK4NDJOvXRyX1 ; 95Am5dQ7bRnnuySZ3daf37vvjUUh ; uIWUAQ4stht8nJfYxVQXDYjSpGH5 ; I6Hf/0CZEoNP6cNvrQ7AFmKkmv00 ; xWExKQjbvnRPI4bqpMwtHVzn6Wyb ; BZ6kuqED ; ) ; ZSK; alg = RSASHA256; key id = 33655 ;. 91894 IN DNSKEY 257 3 8 ( ; AwEAAagAIKlVZrpC6Ia7gEzahOR+ ; 9W29euxhJhVVLOyQbSEW0O8gcCjF ; FVQUTf6v58fLjwBd0YI0EzrAcQqB ; GCzh/RStIoO8g0NfnfL2MTJRkxoX ; bfDaUeVPQuYEhg37NZWAJQ9VnMVD ; xP/VHL496M/QZxkjf5/Efucp2gaD ; X6RS6CXpoY68LsvPVjR0ZSwzz1ap ; AzvN9dlzEheX7ICJBBtuA6G3LQpz ; W5hOA2hzCTMjJPJ8LbqF6dsV6DoB ; Qzgul0sGIcGOYl7OyQdXfZ57relS ; Qageu+ipAdTTJ25AsRTAoub8ONGc ; LmqrAmRLKBP1dfwhYB4N7knNnulq ; QxA+Uk1ihz0= ; ) ; KSK; alg = RSASHA256; key id = 19036 ;. 91894 IN DNSKEY 256 3 8 ( ; AwEAAZvJd8ORk+jmZ41QMYbQ1XCp ; f60l6YJuHtnxn0VSh5a5vqwEjTST ; 3/PZ4xhUFu2YcTfRNWxs9WTiGZl3 ; MY/UlBIvzpLhKgKnf9Vk8sEU3q0n ; mOGFgE6jTi/cU95ATU/2dTQovMDv ; 9XyWvrmj8KIG2brj6mF4S8GTae6G ; 2GwbMF5v ; ) ; ZSK; alg = RSASHA256; key id = 40926 ;. 91894 IN RRSIG DNSKEY 8 0 172800 ( ; 20140415235959 20140401000000 19036 . ; PttXGhd/RiRQDhz9002k/gYVU2c2 ; +YjuW+xv2jczlIuLacXET3ZExT3X ; kZCTtXiveS+vJtYQPVPCUXZcYb+4 ; VjovysRQ1BedFYrRC/n9scSgm1UO ; zxDXRKk7tvBgHiyTwONNvogw/SBJ ; YJ/z9n5cpCY2taEvy5aL2h+vrnwH ; 7WvVT8NR4VJ/ZKJ4GdSxyrEiESm2 ; +d1dUuKOd/XeZbF15XMdDPBH8Ghx ; eZY5ISbZfDSV3vISQIA1B/VF9Dq/ ; 6dxoyMbdPhcpvly3QfzN6brVla2o ; 3FLAcDMyFmSvEcSOgtMntSm0usIs ; Z7eQiQOfejohFSbFFNcivXXwIlXF ; qgJXLA== ) 09-Apr-2014 09:41:28.312 ;; fctx 0x1115e9000(./DNSKEY): answer_response 09-Apr-2014 09:41:28.312 ;; log_ns_ttl: fctx 0x1115e9000: answer_response: . (in '.'?): 0 0 09-Apr-2014 09:41:28.312 ;; fctx 0x1115e9000(./DNSKEY): cache_message 09-Apr-2014 09:41:28.312 ;; fctx 0x1115e9000(./DNSKEY): cancelquery 09-Apr-2014 09:41:28.312 ;; fctx 0x1115e9000(./DNSKEY): wait for validator 09-Apr-2014 09:41:28.312 ;; fctx 0x1115e9000(./DNSKEY): cancelqueries 09-Apr-2014 09:41:28.312 ;; validating ./DNSKEY: starting 09-Apr-2014 09:41:28.312 ;; validating ./DNSKEY: attempting positive response validation 09-Apr-2014 09:41:28.312 ;; validating ./DNSKEY: verify rdataset (keyid=19036): success 09-Apr-2014 09:41:28.312 ;; validating ./DNSKEY: signed by trusted key; marking as secure 09-Apr-2014 09:41:28.312 ;; fctx 0x1115e9000(./DNSKEY): received validation completion event 09-Apr-2014 09:41:28.312 ;; validator @0x7f818409a000: dns_validator_destroy 09-Apr-2014 09:41:28.312 ;; fctx 0x1115e9000(./DNSKEY): validation OK 09-Apr-2014 09:41:28.312 ;; fctx 0x1115e9000(./DNSKEY): clone_results 09-Apr-2014 09:41:28.312 ;; fctx 0x1115e9000(./DNSKEY): done 09-Apr-2014 09:41:28.312 ;; fctx 0x1115e9000(./DNSKEY): stopeverything 09-Apr-2014 09:41:28.312 ;; fctx 0x1115e9000(./DNSKEY): cancelqueries 09-Apr-2014 09:41:28.312 ;; fctx 0x1115e9000(./DNSKEY): sendevents 09-Apr-2014 09:41:28.312 ;; validating org/DS: in fetch_callback_validator 09-Apr-2014 09:41:28.312 ;; validating org/DS: keyset with trust secure 09-Apr-2014 09:41:28.312 ;; validating org/DS: resuming validate 09-Apr-2014 09:41:28.312 ;; validating org/DS: verify rdataset (keyid=40926): success 09-Apr-2014 09:41:28.312 ;; validating org/DS: marking as secure, noqname proof not needed 09-Apr-2014 09:41:28.312 ;; fetch 0x11075a1b0 (fctx 0x1115e9000(./DNSKEY)): destroyfetch 09-Apr-2014 09:41:28.312 ;; fctx 0x1115e9000(./DNSKEY): shutdown 09-Apr-2014 09:41:28.312 ;; fctx 0x1115a9430(org/DS): received validation completion event 09-Apr-2014 09:41:28.312 ;; validator @0x7f8186000000: dns_validator_destroy 09-Apr-2014 09:41:28.312 ;; fctx 0x1115a9430(org/DS): validation OK 09-Apr-2014 09:41:28.312 ;; fctx 0x1115a9430(org/DS): clone_results 09-Apr-2014 09:41:28.312 ;; fctx 0x1115a9430(org/DS): done 09-Apr-2014 09:41:28.312 ;; fctx 0x1115a9430(org/DS): stopeverything 09-Apr-2014 09:41:28.312 ;; fctx 0x1115a9430(org/DS): cancelqueries 09-Apr-2014 09:41:28.312 ;; fctx 0x1115a9430(org/DS): sendevents 09-Apr-2014 09:41:28.312 ;; validating org/DNSKEY: in dsfetched 09-Apr-2014 09:41:28.312 ;; validating org/DNSKEY: dsset with trust secure 09-Apr-2014 09:41:28.312 ;; validating org/DNSKEY: verify rdataset (keyid=21366): success 09-Apr-2014 09:41:28.312 ;; validating org/DNSKEY: marking as secure (DS) 09-Apr-2014 09:41:28.312 ;; fetch 0x11075a198 (fctx 0x1115a9430(org/DS)): destroyfetch 09-Apr-2014 09:41:28.312 ;; fctx 0x1115a9430(org/DS): shutdown 09-Apr-2014 09:41:28.312 ;; fctx 0x1115a9000(org/DNSKEY): received validation completion event 09-Apr-2014 09:41:28.312 ;; validator @0x7f8185800000: dns_validator_destroy 09-Apr-2014 09:41:28.312 ;; fctx 0x1115a9000(org/DNSKEY): validation OK 09-Apr-2014 09:41:28.312 ;; fctx 0x1115a9000(org/DNSKEY): clone_results 09-Apr-2014 09:41:28.312 ;; fctx 0x1115a9000(org/DNSKEY): done 09-Apr-2014 09:41:28.312 ;; fctx 0x1115a9000(org/DNSKEY): stopeverything 09-Apr-2014 09:41:28.312 ;; fctx 0x1115a9000(org/DNSKEY): cancelqueries 09-Apr-2014 09:41:28.312 ;; fctx 0x1115a9000(org/DNSKEY): sendevents 09-Apr-2014 09:41:28.312 ;; fctx 0x1115a9430(org/DS): doshutdown 09-Apr-2014 09:41:28.312 ;; fctx 0x1115a9430(org/DS): stopeverything 09-Apr-2014 09:41:28.312 ;; fctx 0x1115a9430(org/DS): cancelqueries 09-Apr-2014 09:41:28.312 ;; fctx 0x1115a9430(org/DS): unlink 09-Apr-2014 09:41:28.312 ;; fctx 0x1115a9430(org/DS): destroy 09-Apr-2014 09:41:28.312 ;; fctx 0x1115e9000(./DNSKEY): doshutdown 09-Apr-2014 09:41:28.312 ;; fctx 0x1115e9000(./DNSKEY): stopeverything 09-Apr-2014 09:41:28.312 ;; fctx 0x1115e9000(./DNSKEY): cancelqueries 09-Apr-2014 09:41:28.312 ;; fctx 0x1115e9000(./DNSKEY): unlink 09-Apr-2014 09:41:28.312 ;; fctx 0x1115e9000(./DNSKEY): destroy 09-Apr-2014 09:41:28.312 ;; validating isc.org/DS: in fetch_callback_validator 09-Apr-2014 09:41:28.312 ;; validating isc.org/DS: keyset with trust secure 09-Apr-2014 09:41:28.312 ;; validating isc.org/DS: resuming validate 09-Apr-2014 09:41:28.313 ;; validating isc.org/DS: verify rdataset (keyid=28794): success 09-Apr-2014 09:41:28.313 ;; validating isc.org/DS: marking as secure, noqname proof not needed 09-Apr-2014 09:41:28.313 ;; fetch 0x11075a180 (fctx 0x1115a9000(org/DNSKEY)): destroyfetch 09-Apr-2014 09:41:28.313 ;; fctx 0x1115a9000(org/DNSKEY): shutdown 09-Apr-2014 09:41:28.313 ;; fctx 0x111569430(isc.org/DS): received validation completion event 09-Apr-2014 09:41:28.313 ;; validator @0x7f8185000000: dns_validator_destroy 09-Apr-2014 09:41:28.313 ;; fctx 0x111569430(isc.org/DS): validation OK 09-Apr-2014 09:41:28.313 ;; fctx 0x111569430(isc.org/DS): clone_results 09-Apr-2014 09:41:28.313 ;; fctx 0x111569430(isc.org/DS): done 09-Apr-2014 09:41:28.313 ;; fctx 0x111569430(isc.org/DS): stopeverything 09-Apr-2014 09:41:28.313 ;; fctx 0x111569430(isc.org/DS): cancelqueries 09-Apr-2014 09:41:28.313 ;; fctx 0x111569430(isc.org/DS): sendevents 09-Apr-2014 09:41:28.313 ;; validating isc.org/DNSKEY: in dsfetched 09-Apr-2014 09:41:28.313 ;; validating isc.org/DNSKEY: dsset with trust secure 09-Apr-2014 09:41:28.313 ;; validating isc.org/DNSKEY: verify rdataset (keyid=12892): success 09-Apr-2014 09:41:28.313 ;; validating isc.org/DNSKEY: marking as secure (DS) 09-Apr-2014 09:41:28.313 ;; fetch 0x11075a168 (fctx 0x111569430(isc.org/DS)): destroyfetch 09-Apr-2014 09:41:28.313 ;; fctx 0x111569430(isc.org/DS): shutdown 09-Apr-2014 09:41:28.313 ;; fctx 0x111569000(isc.org/DNSKEY): received validation completion event 09-Apr-2014 09:41:28.313 ;; validator @0x7f818399fc00: dns_validator_destroy 09-Apr-2014 09:41:28.313 ;; fctx 0x111569000(isc.org/DNSKEY): validation OK 09-Apr-2014 09:41:28.313 ;; fctx 0x111569000(isc.org/DNSKEY): clone_results 09-Apr-2014 09:41:28.313 ;; fctx 0x111569000(isc.org/DNSKEY): done 09-Apr-2014 09:41:28.313 ;; fctx 0x111569000(isc.org/DNSKEY): stopeverything 09-Apr-2014 09:41:28.313 ;; fctx 0x111569000(isc.org/DNSKEY): cancelqueries 09-Apr-2014 09:41:28.313 ;; fctx 0x111569000(isc.org/DNSKEY): sendevents 09-Apr-2014 09:41:28.313 ;; fctx 0x111569430(isc.org/DS): doshutdown 09-Apr-2014 09:41:28.313 ;; fctx 0x111569430(isc.org/DS): stopeverything 09-Apr-2014 09:41:28.313 ;; fctx 0x111569430(isc.org/DS): cancelqueries 09-Apr-2014 09:41:28.313 ;; fctx 0x111569430(isc.org/DS): unlink 09-Apr-2014 09:41:28.313 ;; fctx 0x111569430(isc.org/DS): destroy 09-Apr-2014 09:41:28.313 ;; fctx 0x1115a9000(org/DNSKEY): doshutdown 09-Apr-2014 09:41:28.313 ;; fctx 0x1115a9000(org/DNSKEY): stopeverything 09-Apr-2014 09:41:28.313 ;; fctx 0x1115a9000(org/DNSKEY): cancelqueries 09-Apr-2014 09:41:28.313 ;; fctx 0x1115a9000(org/DNSKEY): unlink 09-Apr-2014 09:41:28.313 ;; fctx 0x1115a9000(org/DNSKEY): destroy 09-Apr-2014 09:41:28.313 ;; validating Dv.isc.org/DS: in fetch_callback_validator 09-Apr-2014 09:41:28.313 ;; validating Dv.isc.org/DS: keyset with trust secure 09-Apr-2014 09:41:28.313 ;; validating Dv.isc.org/DS: resuming validate 09-Apr-2014 09:41:28.313 ;; validating Dv.isc.org/DS: verify rdataset (keyid=4521): success 09-Apr-2014 09:41:28.313 ;; validating Dv.isc.org/DS: marking as secure, noqname proof not needed 09-Apr-2014 09:41:28.313 ;; fetch 0x11075a150 (fctx 0x111569000(isc.org/DNSKEY)): destroyfetch 09-Apr-2014 09:41:28.313 ;; fctx 0x111569000(isc.org/DNSKEY): shutdown 09-Apr-2014 09:41:28.313 ;; fctx 0x111529860(Dv.isc.org/DS): received validation completion event 09-Apr-2014 09:41:28.313 ;; validator @0x7f8184021800: dns_validator_destroy 09-Apr-2014 09:41:28.313 ;; fctx 0x111529860(Dv.isc.org/DS): validation OK 09-Apr-2014 09:41:28.313 ;; fctx 0x111529860(Dv.isc.org/DS): clone_results 09-Apr-2014 09:41:28.313 ;; fctx 0x111529860(Dv.isc.org/DS): done 09-Apr-2014 09:41:28.313 ;; fctx 0x111529860(Dv.isc.org/DS): stopeverything 09-Apr-2014 09:41:28.313 ;; fctx 0x111529860(Dv.isc.org/DS): cancelqueries 09-Apr-2014 09:41:28.313 ;; fctx 0x111529860(Dv.isc.org/DS): sendevents 09-Apr-2014 09:41:28.313 ;; validating Dv.isc.org/DNSKEY: in dsfetched 09-Apr-2014 09:41:28.313 ;; validating Dv.isc.org/DNSKEY: dsset with trust secure 09-Apr-2014 09:41:28.313 ;; validating Dv.isc.org/DNSKEY: verify rdataset (keyid=10288): success 09-Apr-2014 09:41:28.313 ;; validating Dv.isc.org/DNSKEY: marking as secure (DS) 09-Apr-2014 09:41:28.313 ;; fetch 0x11075a138 (fctx 0x111529860(Dv.isc.org/DS)): destroyfetch 09-Apr-2014 09:41:28.313 ;; fctx 0x111529860(Dv.isc.org/DS): shutdown 09-Apr-2014 09:41:28.313 ;; fctx 0x111529430(dv.isc.org/DNSKEY): received validation completion event 09-Apr-2014 09:41:28.313 ;; validator @0x7f818399ee00: dns_validator_destroy 09-Apr-2014 09:41:28.313 ;; fctx 0x111529430(dv.isc.org/DNSKEY): validation OK 09-Apr-2014 09:41:28.313 ;; fctx 0x111529430(dv.isc.org/DNSKEY): clone_results 09-Apr-2014 09:41:28.313 ;; fctx 0x111529430(dv.isc.org/DNSKEY): done 09-Apr-2014 09:41:28.313 ;; fctx 0x111529430(dv.isc.org/DNSKEY): stopeverything 09-Apr-2014 09:41:28.313 ;; fctx 0x111529430(dv.isc.org/DNSKEY): cancelqueries 09-Apr-2014 09:41:28.313 ;; fctx 0x111529430(dv.isc.org/DNSKEY): sendevents 09-Apr-2014 09:41:28.313 ;; fctx 0x111529860(Dv.isc.org/DS): doshutdown 09-Apr-2014 09:41:28.313 ;; fctx 0x111529860(Dv.isc.org/DS): stopeverything 09-Apr-2014 09:41:28.313 ;; fctx 0x111529860(Dv.isc.org/DS): cancelqueries 09-Apr-2014 09:41:28.313 ;; fctx 0x111529860(Dv.isc.org/DS): unlink 09-Apr-2014 09:41:28.313 ;; fctx 0x111529860(Dv.isc.org/DS): destroy 09-Apr-2014 09:41:28.313 ;; fctx 0x111569000(isc.org/DNSKEY): doshutdown 09-Apr-2014 09:41:28.313 ;; fctx 0x111569000(isc.org/DNSKEY): stopeverything 09-Apr-2014 09:41:28.313 ;; fctx 0x111569000(isc.org/DNSKEY): cancelqueries 09-Apr-2014 09:41:28.313 ;; fctx 0x111569000(isc.org/DNSKEY): unlink 09-Apr-2014 09:41:28.313 ;; fctx 0x111569000(isc.org/DNSKEY): destroy 09-Apr-2014 09:41:28.313 ;; validating Dv.isc.org/SOA: in fetch_callback_validator 09-Apr-2014 09:41:28.313 ;; validating Dv.isc.org/SOA: keyset with trust secure 09-Apr-2014 09:41:28.313 ;; validating Dv.isc.org/SOA: resuming validate 09-Apr-2014 09:41:28.313 ;; validating Dv.isc.org/SOA: verify rdataset (keyid=14436): success 09-Apr-2014 09:41:28.313 ;; validating Dv.isc.org/SOA: marking as secure, noqname proof not needed 09-Apr-2014 09:41:28.313 ;; fetch 0x11075a120 (fctx 0x111529430(dv.isc.org/DNSKEY)): destroyfetch 09-Apr-2014 09:41:28.313 ;; fctx 0x111529430(dv.isc.org/DNSKEY): shutdown 09-Apr-2014 09:41:28.313 ;; fctx 0x111529000(dv.isc.org/SOA): received validation completion event 09-Apr-2014 09:41:28.313 ;; validator @0x7f8184020a00: dns_validator_destroy 09-Apr-2014 09:41:28.313 ;; fctx 0x111529000(dv.isc.org/SOA): validation OK 09-Apr-2014 09:41:28.313 ;; fctx 0x111529000(dv.isc.org/SOA): clone_results 09-Apr-2014 09:41:28.313 ;; fctx 0x111529000(dv.isc.org/SOA): done 09-Apr-2014 09:41:28.313 ;; fctx 0x111529000(dv.isc.org/SOA): stopeverything 09-Apr-2014 09:41:28.313 ;; fctx 0x111529000(dv.isc.org/SOA): cancelqueries 09-Apr-2014 09:41:28.313 ;; fctx 0x111529000(dv.isc.org/SOA): sendevents 09-Apr-2014 09:41:28.313 ;; fctx 0x111529430(dv.isc.org/DNSKEY): doshutdown 09-Apr-2014 09:41:28.313 ;; fctx 0x111529430(dv.isc.org/DNSKEY): stopeverything 09-Apr-2014 09:41:28.313 ;; fctx 0x111529430(dv.isc.org/DNSKEY): cancelqueries 09-Apr-2014 09:41:28.313 ;; fctx 0x111529430(dv.isc.org/DNSKEY): unlink 09-Apr-2014 09:41:28.313 ;; fctx 0x111529430(dv.isc.org/DNSKEY): destroy 09-Apr-2014 09:41:28.313 ;; fetch 0x11075a0a8 (fctx 0x111529000(dv.isc.org/SOA)): destroyfetch 09-Apr-2014 09:41:28.313 ;; fctx 0x111529000(dv.isc.org/SOA): shutdown 09-Apr-2014 09:41:28.313 ;; fctx 0x111529000(dv.isc.org/SOA): doshutdown 09-Apr-2014 09:41:28.313 ;; fctx 0x111529000(dv.isc.org/SOA): stopeverything 09-Apr-2014 09:41:28.313 ;; fctx 0x111529000(dv.isc.org/SOA): cancelqueries 09-Apr-2014 09:41:28.313 ;; fctx 0x111529000(dv.isc.org/SOA): unlink 09-Apr-2014 09:41:28.313 ;; fctx 0x111529000(dv.isc.org/SOA): destroy 09-Apr-2014 09:41:28.313 ;; res 0x11076f000: shutdown 09-Apr-2014 09:41:28.313 ;; res 0x11076f000: exiting 09-Apr-2014 09:41:28.320 ;; dns_requestmgr_shutdown: 0x110774000 09-Apr-2014 09:41:28.320 ;; send_shutdown_events: 0x110774000 09-Apr-2014 09:41:28.320 ;; res 0x11076f000: detach 09-Apr-2014 09:41:28.321 ;; res 0x11076f000: destroy 09-Apr-2014 09:41:28.321 ;; dns_requestmgr_detach: 0x110774000: eref 0 iref 0 09-Apr-2014 09:41:28.321 ;; mgr_destroy 09-Apr-2014 09:41:28.321 ;; calling free_rbtdb(.) 09-Apr-2014 09:41:28.321 ;; done free_rbtdb(.) ; fully validated dv.isc.org. 3532 IN SOA bsdi.dv.isc.org. marka.isc.org. 2007111528 86400 21600 2419200 86400 dv.isc.org. 3532 IN RRSIG SOA 5 3 3600 20140606234902 20140407224902 14436 dv.isc.org. i8fBym000/fiC3XrQ1B0spgppClOyQfdQiPq3p2228bSYR86NzxOqpUL 2YBya9120KctdiLBOpeUEIf285TzxA== > The intersection of the position Wes takes and mine is some sort > of 'assured' AD bit, which I am not opposed to in principle, provided > this is in fact a reasonable plan of action. > > So for example, extending libresolv to match long-established BSD > semantics to improve thread safety and provide more application > control would suffice, res_ninit(), res_setservers(), ... plus > ideally the ability to set the "AD" bit in the request (rather than > "DO", reducing the quantity of unnecessary bloat in the reply). > > That way applications that want a local resolver can be configured > to use one, and can make appropriate fallback decisions if one is > not available. > > As for *censoring* the AD bit, that approach is likely more > problematic and I think is where Paul Wouters and Petr part ways... > > So please make it possible in all the various DNS APIs (that don't > already do this) for the stub resolver to override the default > nameserver list (static or insecurely obtained from DHCP). Give > the stub resolver more control over the "AD" and "DO" bits, and > think long and hard about whether censoring is a viable approach > it may well be a bad idea. > > -- > Viktor. > > _______________________________________________ > 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 nobody Tue Apr 8 18:35:31 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A62461A0005 for ; Tue, 8 Apr 2014 18:35:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.656 X-Spam-Level: * X-Spam-Status: No, score=1.656 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uyNP_6X43P-I for ; Tue, 8 Apr 2014 18:35:26 -0700 (PDT) Received: from homiemail-a30.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 02CD51A0004 for ; Tue, 8 Apr 2014 18:35:26 -0700 (PDT) Received: from homiemail-a30.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTP id 8C54A21DE57 for ; Tue, 8 Apr 2014 18:35:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=fk+U23GtHMXOH0EktsoE pNnViCk=; b=ii/1Apd+YdipynPuXCCFvOrx8fwNbteZPS7nFVilm7GKTbm/HOA7 PKrmQhLonCaN61Iz0QpSaHGmqXzHN7TuwT1x9SWUEPRf2ojcLXOt73V93nI1NzEk c+aVn5SbU2wJsg6WN8+zvKJo3l4PSXdO/OezHYWcAbdEWQJLyTRFr9Q= Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTPSA id 3E63221DE55 for ; Tue, 8 Apr 2014 18:35:25 -0700 (PDT) Received: by mail-wi0-f170.google.com with SMTP id bs8so8774736wib.1 for ; Tue, 08 Apr 2014 18:35:24 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.97.72 with SMTP id dy8mr7101065wib.5.1397007324008; Tue, 08 Apr 2014 18:35:24 -0700 (PDT) Received: by 10.217.129.197 with HTTP; Tue, 8 Apr 2014 18:35:23 -0700 (PDT) In-Reply-To: <533EB433.5060204@redhat.com> References: <533EB433.5060204@redhat.com> Date: Tue, 8 Apr 2014 20:35:23 -0500 Message-ID: From: Nico Williams To: Petr Spacek Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/EGSFp15rkwlnzDDgLJQw9hG8Xtk Cc: dane@ietf.org Subject: Re: [dane] AD bit handling in stub-resolvers: conclusions and compromises X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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 Apr 2014 01:35:29 -0000 On Fri, Apr 4, 2014 at 8:31 AM, Petr Spacek wrote: > Hello, > > Let me sum up the discussion and document the compromise for archaeologists: Thanks. > Approach A > ========== > One approach is to do nothing in stub resolvers and rely on validating > resolvers or application logic. > This approach was mentioned by Paul Wouters , Prasad > Pandit , Carlos O'Donell , Olafur > Gudmundsson . Also, Michael Richardson had some comments about uninformative error/timeout handling when the application doesn't do its own DNSSEC validation. There are solutions to Michael's problem, such as running an in-app resolver when the user wants detailed error information. > It seems that the main concern about AD bit stripping in stub resolvers is > compatibility with existing applications which rely on AD bit: We should want fail-closed semantics. I very much prefer having a caching validating local server. I don't mind making people (and configuration apps) explicitly set a global in /etc/resolv.conf to disable AD stripping. I'd provide two settings, one to disable AD stripping IFF the only nameserver is ::1, and another to disable AD stripping in all other cases. > After further discussion, it seems that pwouters is okay with AD bit > stripping in stub resolver if it is explicitly requested by a calling > application. (E.g. by special resolver initialization.) Again, we need fail-closed semantics. > Approach B > ========== > The other approach is to do AD bit stripping in stub resolvers by default. > It was proposed to add system-wide setting for this (e.g. to resolv.conf) > and default to "strip AD bit unless admin configured something else". > > This approach was mentioned by Petr Spacek , Simo Sorce > , Viktor Dukhovni , Tony Finch > , James Cloos . > > Naturally, application has to be able to do run-time check that it is using > a library with this new behavior to avoid running in unsafe environment. This might be done at install time, or first-run time if we commit to never removing this feature once it's added and/or if we provide an interface for notifying applications of removal of this feature. This approach means not having to extend APIs. However extending APIs is probably OK enough I think, given that we have relatively few DNSSEC-capable apps today. > Next Steps > ========== > Define what is yet not defined: > - System-wide configuration format (e.g. modify resolv.conf vs. add a new > file) The former. > - Propose specific API changes for major DNS libraries (glibc, maybe ldns > and co.) See below. > - Prepare recommendation for application developers how and when to use a > new API Sure. > Further discussion about implementation details will happen on mailing lists > related to the particular DNS libraries. For the res_init() API it'd be nice to have an agreed-upon extension. Where is that to be discussed, if at all? Nico -- From nobody Tue Apr 8 18:37:18 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C20ED1A0004 for ; Tue, 8 Apr 2014 18:37:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IZLA08dHlSiL for ; Tue, 8 Apr 2014 18:37:14 -0700 (PDT) Received: from homiemail-a27.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 48B021A0002 for ; Tue, 8 Apr 2014 18:37:14 -0700 (PDT) Received: from homiemail-a27.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTP id 2E9A5598058 for ; Tue, 8 Apr 2014 18:37:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=iPmRAsLZYUk80hqafxF9 TQhxc+c=; b=sRUwrcwXp35SFDhQxGFkDXx31VPeZ706JDWkG7/mf/HbpT/Uq1fE BcRP+fU42lx6sa2CB0Qoc8wh0UZdfKbDU33dAsmilIu1Dt6Gy7kVwg3VE3TqnfMb KCQNC+H/Pc4AFPDexOp6gU8du3rBsy0akBCi9SOpila7Qhtoa0wMByU= Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTPSA id D5F86598057 for ; Tue, 8 Apr 2014 18:37:13 -0700 (PDT) Received: by mail-wi0-f170.google.com with SMTP id bs8so8777190wib.5 for ; Tue, 08 Apr 2014 18:37:12 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.105.132 with SMTP id gm4mr9444539wib.39.1397007432868; Tue, 08 Apr 2014 18:37:12 -0700 (PDT) Received: by 10.217.129.197 with HTTP; Tue, 8 Apr 2014 18:37:12 -0700 (PDT) In-Reply-To: <20140408235025.757001343582@rock.dv.isc.org> References: <533EB433.5060204@redhat.com> <0lha63rb6i.fsf@wjh.hardakers.net> <20140408174936.GL12559@mournblade.imrryr.org> <20140408235025.757001343582@rock.dv.isc.org> Date: Tue, 8 Apr 2014 20:37:12 -0500 Message-ID: From: Nico Williams To: Mark Andrews Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/R2apRhJIQnX8v_wQBUGDJjp5Aeo Cc: dane@ietf.org Subject: Re: [dane] AD bit handling in stub-resolvers: conclusions and compromises X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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 Apr 2014 01:37:16 -0000 On Tue, Apr 8, 2014 at 6:50 PM, Mark Andrews wrote: > In message <20140408174936.GL12559@mournblade.imrryr.org>, Viktor Dukhovni writes: >> For me doing it in application, means costly integration of complex >> code into the application that will add considerable latency because >> the application will have a cold DNSSEC cache (and will now need >> a cache where one was not needed before... The Plan-9 approach of >> moving security features into system services is I think far >> preferable. > > What latency? This is the output of delve (see BIND 9.10) which > is a is standalone stub validator talking to a local validating resolver > doing a full validation from the root. This uses exactly the same > code that named uses to validate its answers. The only difference > is a slightly different cache implementation is used. > > 28.321 - 28.298 = 00.023 > > from start to finish. 23ms is a lot in some contexts... Single run performance numbers are not that enough. The more interesting question is how the system performs under load with and without a local caching validating server. Nico -- From nobody Tue Apr 8 18:42:39 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8397E1A0004 for ; Tue, 8 Apr 2014 18:42:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.272 X-Spam-Level: X-Spam-Status: No, score=-2.272 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v_njqmVvH12w for ; Tue, 8 Apr 2014 18:42:35 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id AE7841A0002 for ; Tue, 8 Apr 2014 18:42:35 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 12DFF800C0; Tue, 8 Apr 2014 21:42:34 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1397007754; bh=yRu1lFXZGSl4lW9RWzg3+hFe9PKbSeUwKaOymQwzcW8=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=Mx37A07cOgaATeKC8jOYhdW3QMM20I8MDSi5R45IWd6IiM63Rhz1Zl5hBnvz3eqOg jmK7g8oNmlJ92CblDcoNDLAN86e9B9MQBRdQ6K7j4GTO3IWiBxqpBBv8CygwP+R4sM IfgNtb2xc23dBsTFf52ZC3w3hk35tF3ZPMUQpb+A= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s391gXfX014448; Tue, 8 Apr 2014 21:42:33 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Tue, 8 Apr 2014 21:42:33 -0400 (EDT) From: Paul Wouters To: Nico Williams In-Reply-To: Message-ID: References: <533EB433.5060204@redhat.com> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/dane/h0YjXm2w1PBaPufgdIEC_SE2mko Cc: dane WG list Subject: Re: [dane] AD bit handling in stub-resolvers: conclusions and compromises X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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 Apr 2014 01:42:37 -0000 On Tue, 8 Apr 2014, Nico Williams wrote: > We should want fail-closed semantics. I very much prefer having a > caching validating local server. I don't mind making people (and > configuration apps) explicitly set a global in /etc/resolv.conf to > disable AD stripping. >> After further discussion, it seems that pwouters is okay with AD bit >> stripping in stub resolver if it is explicitly requested by a calling >> application. (E.g. by special resolver initialization.) > > Again, we need fail-closed semantics. You do if you are _asking_ for it. But you need to ask or else you break backwards compatibility with a rack of servers using a nearby trusted resolver. Paul From nobody Tue Apr 8 18:46:11 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B921F1A0584 for ; Tue, 8 Apr 2014 18:46:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.272 X-Spam-Level: X-Spam-Status: No, score=-2.272 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IPmbs189NA5m for ; Tue, 8 Apr 2014 18:46:08 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id B206D1A000A for ; Tue, 8 Apr 2014 18:46:08 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 5599B800C0; Tue, 8 Apr 2014 21:46:08 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1397007968; bh=PfPBEiL8oY2Zk+DPy7i2BNSIAPLk6InBijfyf2yclnU=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=qe7qXJ19DjCTRCf9fyFzKMnJpt5oNEABjQ59dpajcSmsAcOwE3dXzmLM1yjWQFkoS wSSP05RgNvWN08z4Zh5IRNSsQUzUwUXduxKQA4Mfh6WEu/5fxKXc6P2xHKw++1DF9a sztiiV1L5nFyXg8abKwV3vOkysPmtshtZPHMLd0s= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s391k8IH014811; Tue, 8 Apr 2014 21:46:08 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Tue, 8 Apr 2014 21:46:08 -0400 (EDT) From: Paul Wouters To: Nico Williams In-Reply-To: Message-ID: References: <533EB433.5060204@redhat.com> <0lha63rb6i.fsf@wjh.hardakers.net> <20140408174936.GL12559@mournblade.imrryr.org> <20140408235025.757001343582@rock.dv.isc.org> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/dane/TtPo000mmJaE5gTR2LICaCyVll8 Cc: dane WG list Subject: Re: [dane] AD bit handling in stub-resolvers: conclusions and compromises X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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 Apr 2014 01:46:09 -0000 On Tue, 8 Apr 2014, Nico Williams wrote: > The more interesting question is how the system > performs under load with and without a local caching validating > server. Sorry I can't hear you because my phone is blasting 1136x640 resolution 326 ppi MP4 video right now while I'm downloading my facebook/twitter feed and updating all my apps at once. Paul From nobody Thu Apr 10 10:56:32 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C058C1A0309; Thu, 10 Apr 2014 10:56:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KN3rm778pjOc; Thu, 10 Apr 2014 10:56:23 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 93A251A02FD; Thu, 10 Apr 2014 10:56:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.2.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140410175623.1767.25701.idtracker@ietfa.amsl.com> Date: Thu, 10 Apr 2014 10:56:23 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/W1O5a6vHf6pLOtqJf0cKGTUOJZQ Cc: dane@ietf.org Subject: [dane] I-D Action: draft-ietf-dane-openpgpkey-00.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2014 17:56:26 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS-based Authentication of Named Entities Working Group of the IETF. Title : Using DANE to Associate OpenPGP public keys with email addresses Author : Paul Wouters Filename : draft-ietf-dane-openpgpkey-00.txt Pages : 8 Date : 2014-04-10 Abstract: OpenPGP is a message format for email (and file) encryption, that lacks a standarized lookup mechanism to obtain OpenPGP public keys. This document specifies a standarized method for securely publishing and locating OpenPGP public keys in DNS using a new OPENPGPKEY DNS Resource Record. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dane-openpgpkey/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dane-openpgpkey-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Apr 10 10:56:52 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA8BD1A0323; Thu, 10 Apr 2014 10:56:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g7jLpSvEvBg6; Thu, 10 Apr 2014 10:56:45 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D8341A039B; Thu, 10 Apr 2014 10:56:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.2.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140410175640.5322.22034.idtracker@ietfa.amsl.com> Date: Thu, 10 Apr 2014 10:56:40 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/B1ew-PXV15JtaVG6GmIoAFSRSqU Cc: dane@ietf.org Subject: [dane] I-D Action: draft-ietf-dane-openpgpkey-usage-00.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2014 17:56:47 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS-based Authentication of Named Entities Working Group of the IETF. Title : Best Common Practise for using OPENPGPKEY records Author : Paul Wouters Filename : draft-ietf-dane-openpgpkey-usage-00.txt Pages : 8 Date : 2014-04-10 Abstract: The OPENPGPKEY DNS Resource Record can be used to match an email address to an OpenPGP key. This document specifies a Best Common Practise ("BCP") for email clients, MUA's and MTA's for using the OPENPGPKEY DNS Resource Record. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dane-openpgpkey-usage/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dane-openpgpkey-usage-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Apr 22 01:43:32 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 973AD1A0152 for ; Tue, 22 Apr 2014 01:43:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.275 X-Spam-Level: X-Spam-Status: No, score=-5.275 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CY6dXvLOoi3j for ; Tue, 22 Apr 2014 01:43:26 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 7A6F61A0167 for ; Tue, 22 Apr 2014 01:43:25 -0700 (PDT) Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s3M8hK4q015201 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 22 Apr 2014 04:43:20 -0400 Received: from pspacek.brq.redhat.com (pspacek.brq.redhat.com [10.34.4.156]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s3M8hIcX023183 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Tue, 22 Apr 2014 04:43:19 -0400 Message-ID: <53562BA6.6010808@redhat.com> Date: Tue, 22 Apr 2014 10:43:18 +0200 From: Petr Spacek Organization: Red Hat User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: dane@ietf.org References: <20140410175623.1767.25701.idtracker@ietfa.amsl.com> In-Reply-To: <20140410175623.1767.25701.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/6kiymeC-Cj3lJ--fv4W2fsXIAls Subject: [dane] draft-ietf-dane-openpgpkey-00 comments X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 22 Apr 2014 08:43:30 -0000 Hello! I would like to comment on > http://tools.ietf.org/html/draft-ietf-dane-openpgpkey-00 > 3. Location of the OpenPGPKEY record > > Email addresses are mapped into DNS using the following method: > > 1. The user name (the "left-hand side" of the email address, called > the "local-part" in the mail message format definition [RFC2822] > and the "local part" in the specification for internationalized > email [RFC6530]), is hashed using the SHA2-224 [RFC5754] > algorithm to become the left-most label in the prepared domain > name. This does not include the at symbol ("@") that separates > the left and right sides of the email address. > > 2. The DNS does not allow the use of all characters that are > supported in "local-part" of email addresses as defined in > [RFC2822] and [RFC6530] . The SHA2-224 hashing of the user name > ensures that none of these characters would need to be placed > directly in the DNS. 1) SHA-224 result representation: IMHO this section should state that SHA2-224 result has to be encoded to hexadecimal representation. I know that hexadecimal is a common representation for user interfaces but please keep in mind that SHA2-224 produces 224 bites of "noise" and hexadecimal representation is not the only possible. 2) Multiple OPENPGPKEY records for one owner name: I didn't see a note if OPENPGPKEY is supposed to be singleton or not (and how it should be processed if it isn't singleton). I'm sorry if I missed the note. 3) Algorithm agility: It is clear to me that SHA2-224 hashing is there "just" for privacy and nothing else. Still, I think it would be beneficial to have algorithm agility built-in. What about 8d[..]b7.sha224._openpgpkey.example.com. IN OPENPGPKEY ? Of course, the client need to know where to look for keys. I can see two approaches: - "Dumb" clients will try all supported algorithms starting with the strongest. - List of available algorithms can be published under _openpgpkey.example.com. Note that I'm perfectly fine with defining only SHA-224 for now. Basically this is the same situation as with SSHFP fingerprint types. They started with SHA-1 only but with the alg. agility built-in. Maybe we could have yet another IANA registry for this... A new registry would allow us to do fancy things in future. E.g. to define "salted-sha-224" algorithm and store salt under ssha224._openpgpkey.example.com. That still allows you to share _openphpkey sub-tree between domains... Or to define "clear" algorithm if deemed. Or to define a clever way how to cut hash into several labels if we need to do so ... Have a nice day! -- Petr^2 Spacek From nobody Tue Apr 22 04:16:02 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5CD31A0380 for ; Tue, 22 Apr 2014 04:16:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.174 X-Spam-Level: X-Spam-Status: No, score=-7.174 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oKpkJai7R3Ia for ; Tue, 22 Apr 2014 04:15:56 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id EF9701A038E for ; Tue, 22 Apr 2014 04:15:55 -0700 (PDT) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s3MBFomY006065 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Tue, 22 Apr 2014 07:15:50 -0400 Received: from pspacek.brq.redhat.com (pspacek.brq.redhat.com [10.34.4.156]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s3MBFmHY025974 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Tue, 22 Apr 2014 07:15:49 -0400 Message-ID: <53564F63.2010008@redhat.com> Date: Tue, 22 Apr 2014 13:15:47 +0200 From: Petr Spacek Organization: Red Hat User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: dane@ietf.org References: <20140410175623.1767.25701.idtracker@ietfa.amsl.com> <53562BA6.6010808@redhat.com> In-Reply-To: <53562BA6.6010808@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/Ekowq1MjrScs0v4igzF4exESQ4o Subject: Re: [dane] draft-ietf-dane-openpgpkey-00 comments X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 22 Apr 2014 11:16:00 -0000 On 22.4.2014 10:43, Petr Spacek wrote: > Hello! > > I would like to comment on >> http://tools.ietf.org/html/draft-ietf-dane-openpgpkey-00 > >> 3. Location of the OpenPGPKEY record >> >> Email addresses are mapped into DNS using the following method: >> >> 1. The user name (the "left-hand side" of the email address, called >> the "local-part" in the mail message format definition [RFC2822] >> and the "local part" in the specification for internationalized >> email [RFC6530]), is hashed using the SHA2-224 [RFC5754] >> algorithm to become the left-most label in the prepared domain >> name. This does not include the at symbol ("@") that separates >> the left and right sides of the email address. >> >> 2. The DNS does not allow the use of all characters that are >> supported in "local-part" of email addresses as defined in >> [RFC2822] and [RFC6530] . The SHA2-224 hashing of the user name >> ensures that none of these characters would need to be placed >> directly in the DNS. > 1) SHA-224 result representation: > IMHO this section should state that SHA2-224 result has to be encoded to > hexadecimal representation. > > I know that hexadecimal is a common representation for user interfaces but > please keep in mind that SHA2-224 produces 224 bites of "noise" and > hexadecimal representation is not the only possible. > > > 2) Multiple OPENPGPKEY records for one owner name: > I didn't see a note if OPENPGPKEY is supposed to be singleton or not (and how > it should be processed if it isn't singleton). I'm sorry if I missed the note. > > > 3) Algorithm agility: > It is clear to me that SHA2-224 hashing is there "just" for privacy and > nothing else. Still, I think it would be beneficial to have algorithm agility > built-in. > > What about > 8d[..]b7.sha224._openpgpkey.example.com. IN OPENPGPKEY > ? > > Of course, the client need to know where to look for keys. > > I can see two approaches: > - "Dumb" clients will try all supported algorithms starting with the strongest. > - List of available algorithms can be published under _openpgpkey.example.com. > > Note that I'm perfectly fine with defining only SHA-224 for now. Basically > this is the same situation as with SSHFP fingerprint types. They started with > SHA-1 only but with the alg. agility built-in. > > Maybe we could have yet another IANA registry for this... > > A new registry would allow us to do fancy things in future. > > E.g. to define "salted-sha-224" algorithm and store salt under > ssha224._openpgpkey.example.com. That still allows you to share _openphpkey > sub-tree between domains... > > Or to define "clear" algorithm if deemed. > > Or to define a clever way how to cut hash into several labels if we need to do > so ... Hmm, I have even more controversial idea: What about CERT RR? http://tools.ietf.org/html/rfc4398#section-2.1 contains this (beside others): 2.1. Certificate Type Values The following values are defined or reserved: Value Mnemonic Certificate Type ----- -------- ---------------- 3 PGP OpenPGP packet I wasn't around when CERT was designed and I haven't seen it in wild, so please bear with me if I'm totally wrong :-) http://tools.ietf.org/html/rfc4398#section-3.3 seems to define basically the same thing as draft-ietf-dane-openpgpkey-00 - except usage of hashing for owner name derivation. What is the advantage of using OPENPGPKEY RR instead of CERT RR? Can we use CERT and drop OPENPGPKEY RR definition from draft-ietf-dane-openpgpkey and define "Location of the OpenPGPKEY record"? Also, RFC 4398 mentions OpenPGP revocation certificates. It sounds like an interesting idea... I can imagine using DNS for key revocation in the same way as for key distribution. -- Petr^2 Spacek From nobody Tue Apr 22 05:50:06 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4DE51A0416 for ; Tue, 22 Apr 2014 05:50:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Run02t1PIhir for ; Tue, 22 Apr 2014 05:50:03 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 8B07D1A0418 for ; Tue, 22 Apr 2014 05:50:01 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 778542AAB20; Tue, 22 Apr 2014 12:49:54 +0000 (UTC) Date: Tue, 22 Apr 2014 12:49:54 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140422124954.GZ18879@mournblade.imrryr.org> References: <20140410175623.1767.25701.idtracker@ietfa.amsl.com> <53562BA6.6010808@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53562BA6.6010808@redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/EEwwO-9J_lZxm6enXqQQAFPrHuk Subject: Re: [dane] draft-ietf-dane-openpgpkey-00 comments X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2014 12:50:04 -0000 On Tue, Apr 22, 2014 at 10:43:18AM +0200, Petr Spacek wrote: > 3) Algorithm agility: > It is clear to me that SHA2-224 hashing is there "just" for privacy and > nothing else. Still, I think it would be beneficial to have algorithm > agility built-in. In this specification sha2-224 does not play a security role. It is used not for privacy but rather as a short-enough and yet strongly collision resistant representation of potentially longer email addresses that would not fit into a DNS label. It is expected that the number of email addresses with SMIMEA or OPENPGP keys in any one domain will be substantially less than 2^{112} (~ 10^{34}). A domain with 10^9 users will have two users with the same lookup key with probability roughly 2^{-62} or ~10^{-16}. There is no need for "algorithm agility" here. This is a lookup key construct, not a tamper-resistant signature. In fact multiple algorithms would be entirely counter-productive in this context. -- Viktor. From nobody Tue Apr 22 06:51:32 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E34321A048C; Tue, 22 Apr 2014 06:51:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.275 X-Spam-Level: X-Spam-Status: No, score=-100.275 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LtTP5ocjtKOx; Tue, 22 Apr 2014 06:51:25 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id 15E591A0473; Tue, 22 Apr 2014 06:51:25 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id B584C1801A3; Tue, 22 Apr 2014 06:50:35 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 6000:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20140422135035.B584C1801A3@rfc-editor.org> Date: Tue, 22 Apr 2014 06:50:35 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/CAd8lxG7YKPd4rU5li4lgMHC1Og Cc: drafts-update-ref@iana.org, dane@ietf.org, rfc-editor@rfc-editor.org Subject: [dane] RFC 7218 on Adding Acronyms to Simplify Conversations about DNS-Based Authentication of Named Entities (DANE) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 22 Apr 2014 13:51:30 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7218 Title: Adding Acronyms to Simplify Conversations about DNS-Based Authentication of Named Entities (DANE) Author: O. Gudmundsson Status: Standards Track Stream: IETF Date: April 2014 Mailbox: ogud@ogud.com Pages: 5 Characters: 8907 Updates: RFC 6698 I-D Tag: draft-ietf-dane-registry-acronyms-04.txt URL: http://www.rfc-editor.org/rfc/rfc7218.txt Experience has shown that people get confused when discussing the three numeric fields of the TLSA record. This document specifies descriptive acronyms for the three numeric fields in TLSA records. This document updates the format of the IANA registry created by RFC 6698. This document is a product of the DNS-based Authentication of Named Entities Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/search For downloading RFCs, see http://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Tue Apr 22 07:34:19 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B1781A0494 for ; Tue, 22 Apr 2014 07:34:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.174 X-Spam-Level: X-Spam-Status: No, score=-7.174 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H_xi0nymfvZt for ; Tue, 22 Apr 2014 07:34:15 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 2713F1A0424 for ; Tue, 22 Apr 2014 07:34:14 -0700 (PDT) Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s3MEY8Dl031132 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Tue, 22 Apr 2014 10:34:09 -0400 Received: from pspacek.brq.redhat.com (pspacek.brq.redhat.com [10.34.4.156]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s3MEY7l8028063 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Tue, 22 Apr 2014 10:34:08 -0400 Message-ID: <53567DDE.3080902@redhat.com> Date: Tue, 22 Apr 2014 16:34:06 +0200 From: Petr Spacek Organization: Red Hat User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: dane@ietf.org References: <20140410175623.1767.25701.idtracker@ietfa.amsl.com> <53562BA6.6010808@redhat.com> <20140422124954.GZ18879@mournblade.imrryr.org> In-Reply-To: <20140422124954.GZ18879@mournblade.imrryr.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/TPqzp9iKp6ehxePf_AvNP2gK1tk Subject: Re: [dane] draft-ietf-dane-openpgpkey-00 comments X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 22 Apr 2014 14:34:17 -0000 On 22.4.2014 14:49, Viktor Dukhovni wrote: > On Tue, Apr 22, 2014 at 10:43:18AM +0200, Petr Spacek wrote: > >> 3) Algorithm agility: >> It is clear to me that SHA2-224 hashing is there "just" for privacy and >> nothing else. Still, I think it would be beneficial to have algorithm >> agility built-in. > > In this specification sha2-224 does not play a security role. It Hmm, I should have read section 5.1 more than once :-) > is used not for privacy but rather as a short-enough and yet strongly > collision resistant representation of potentially longer email > addresses that would not fit into a DNS label. It is expected that > There is no need for "algorithm agility" here. This is a lookup > key construct, not a tamper-resistant signature. In fact multiple Just to be clear - I have never used term "tamper-resistant" in this context. > algorithms would be entirely counter-productive in this context. I agree. I'm sorry for the noise created by my comment (3). My comments (1), (2) and the second e-mail with question about CERT RR still apply. -- Petr^2 Spacek From nobody Tue Apr 22 15:08:03 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 395441A025D for ; Tue, 22 Apr 2014 15:07:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.273 X-Spam-Level: X-Spam-Status: No, score=-2.273 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xdW1VmwzAjz6 for ; Tue, 22 Apr 2014 15:07:54 -0700 (PDT) Received: from ore.jhcloos.com (ore.jhcloos.com [198.147.23.85]) by ietfa.amsl.com (Postfix) with ESMTP id CAF251A028E for ; Tue, 22 Apr 2014 15:07:54 -0700 (PDT) Received: by ore.jhcloos.com (Postfix, from userid 10) id 09D371DDCB; Tue, 22 Apr 2014 22:07:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore14; t=1398204467; bh=YXvlZG2zcS6gnSfohZE3I1dgaqQe6O/SlN7hwMEw8X8=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=OZtMjo0KPUK/U7iINxJyUJ9rD6LXUjYFhRAb0nFVlTN5yRKjmrp4r5yfzS9B+/BSe QgoX9QOFTPta1bZtYwhl51AYOv8GlVw+m6Ys24Y6fWs3Ja5IPO3W9CEuD/Ru2DfyKI vs4LkNXzwg0M7r/tlfiRfHyYhI9GQ/AcpOyHhZoY= Received: by carbon.jhcloos.org (Postfix, from userid 500) id 42A886001D; Tue, 22 Apr 2014 22:02:40 +0000 (UTC) From: James Cloos To: Petr Spacek In-Reply-To: <53564F63.2010008@redhat.com> (Petr Spacek's message of "Tue, 22 Apr 2014 13:15:47 +0200") References: <20140410175623.1767.25701.idtracker@ietfa.amsl.com> <53562BA6.6010808@redhat.com> <53564F63.2010008@redhat.com> User-Agent: Gnus/5.13001 (Ma Gnus v0.10) Emacs/24.4.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2014 James Cloos OpenPGP: 0x997A9F17ED7DAEA6; url=https://jhcloos.com/public_key/0x997A9F17ED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Tue, 22 Apr 2014 18:02:39 -0400 Message-ID: Lines: 13 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:140422:pspacek@redhat.com::HzyXfXCQ0wQ2T1zE:000000000000000000000000000000000000000000O1fZL X-Hashcash: 1:30:140422:dane@ietf.org::IuLdYfRfy69eWMcZ:000DyAiN Archived-At: http://mailarchive.ietf.org/arch/msg/dane/k8IoKZT_llt2XWkmkdvTJlOdbVo Cc: dane@ietf.org Subject: Re: [dane] draft-ietf-dane-openpgpkey-00 comments X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 22 Apr 2014 22:07:59 -0000 >>>>> "PS" == Petr Spacek writes: PS> What about CERT RR? PS> http://tools.ietf.org/html/rfc4398#section-2.1 contains this (beside others): Cert uses the user portion of the email address as-is, and therefor only supports usernames which fit unalterred in dns. Some aspects of the rfc are a bit terse. Can you tell, for IPGP, whether the length octet is a bit-lenght or an octet-length? Or which data, exactly, is digested to create the key tag? James Cloos OpenPGP: 0x997A9F17ED7DAEA6 From nobody Tue Apr 22 15:42:56 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8B0A1A02A4 for ; Tue, 22 Apr 2014 15:42:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.272 X-Spam-Level: X-Spam-Status: No, score=-2.272 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jUQFo53Os4Oc for ; Tue, 22 Apr 2014 15:42:50 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 9FCA91A0283 for ; Tue, 22 Apr 2014 15:42:50 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 3BC508009A; Tue, 22 Apr 2014 18:42:44 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1398206564; bh=VhfDY4uTIuBot6Aw6rEc/as0e2AS3YbaXD8DaNRB8Fc=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=lJJWNHYsMTP3GKtGYedVGWVRaa+IXL+9niJ0N0O3LSRv7jnllEtLEt5VRTSp2QzID XXJD25VjuRz12FGHZR7u7V3Joev9oQBgwtFn3pHzQXp0PWaA2HsRmXSlJH/bKY2Z42 gUMu07AiIh+P73JvD0iJ8/1TSEEVwKxOVVuAzq6w= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s3MMggFf010374; Tue, 22 Apr 2014 18:42:43 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Tue, 22 Apr 2014 18:42:42 -0400 (EDT) From: Paul Wouters To: James Cloos In-Reply-To: Message-ID: References: <20140410175623.1767.25701.idtracker@ietfa.amsl.com> <53562BA6.6010808@redhat.com> <53564F63.2010008@redhat.com> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/dane/lLBn7XsHvPh9_ynzhIUNg_6cz0w Cc: dane@ietf.org Subject: Re: [dane] draft-ietf-dane-openpgpkey-00 comments X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 22 Apr 2014 22:42:55 -0000 On Tue, 22 Apr 2014, James Cloos wrote: > PS> What about CERT RR? > PS> http://tools.ietf.org/html/rfc4398#section-2.1 contains this (beside others): > > Cert uses the user portion of the email address as-is, and therefor only > supports usernames which fit unalterred in dns. Correct. Although we could have used the openpgpkey style _prefix to avoid that, there were more issues with the CERT record type. CERT also uses sub-typing, so you might end up getting all kind of types of certificates (like a PKIX cert) that you don't want or need. Granted, the _openpgpkey. prefix would at least prevent the non-malicious contamination, but you might still get all kinds of weird stuff. From what I understood, sub-typing was what really killed the CERT record, and everyone since has been strongly urged to stay away from sub-typing, and told to use _prefix. instead. The CERT record also does not offer a nice presentation format for the zone file. The RFC states: smith IN CERT PGP 0 0 Having binary in a zone is really a non-starter. Which is why OPENPGPKEY uses base64 as the presentation format and the raw binary as the wire format. > Some aspects of the rfc are a bit terse. Can you tell, for IPGP, > whether the length octet is a bit-lenght or an octet-length? Or > which data, exactly, is digested to create the key tag? IPGP specifies a URL, so now that url becomes another security hurdle. What do you do when it is on https and you don't trust the CA, ignore. What do you do when the URL is unreachable - is that censorship/attack? With the full key in DNSSEC, you get the entire key using only one DNS query without any followup HTTP(S) queries that you might not be able to do for various (security/monitoring) reasons. It seemed much more desirable to start a fresh dedicated RRTYPE over fixing up the CERT RRTYPE and then needing to deal with servers that only support the "old CERT type" versus ones that support the "new CERT type". In other words, the pain of recycling was worse than just starting fresh. Paul From nobody Tue Apr 22 16:41:41 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36F371A02AC for ; Tue, 22 Apr 2014 16:41:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.173 X-Spam-Level: X-Spam-Status: No, score=-7.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A1g7WhanQwV6 for ; Tue, 22 Apr 2014 16:41:33 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) by ietfa.amsl.com (Postfix) with ESMTP id EDBC51A0283 for ; Tue, 22 Apr 2014 16:41:32 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.ams1.isc.org (Postfix) with ESMTP id 1A009238400; Tue, 22 Apr 2014 23:41:15 +0000 (UTC) (envelope-from marka@isc.org) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id B1D92160064; Tue, 22 Apr 2014 23:43:51 +0000 (UTC) Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 814DB160056; Tue, 22 Apr 2014 23:43:51 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 7C239143C8CC; Wed, 23 Apr 2014 09:41:12 +1000 (EST) To: Paul Wouters From: Mark Andrews References: <20140410175623.1767.25701.idtracker@ietfa.amsl.com> <53562BA6.6010808@redhat.com> <53564F63.2010008@redhat.com> In-reply-to: Your message of "Tue, 22 Apr 2014 18:42:42 -0400." Date: Wed, 23 Apr 2014 09:41:12 +1000 Message-Id: <20140422234112.7C239143C8CC@rock.dv.isc.org> Archived-At: http://mailarchive.ietf.org/arch/msg/dane/3WKs0nIiCd8feXLjV4cPXZVH3Bs Cc: dane@ietf.org Subject: Re: [dane] draft-ietf-dane-openpgpkey-00 comments X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 22 Apr 2014 23:41:38 -0000 In message , Paul Wouters writes: > On Tue, 22 Apr 2014, James Cloos wrote: > > > PS> What about CERT RR? > > PS> http://tools.ietf.org/html/rfc4398#section-2.1 contains this (beside others): > > > > Cert uses the user portion of the email address as-is, and therefor only > > supports usernames which fit unalterred in dns. > > Correct. Although we could have used the openpgpkey style _prefix to > avoid that, there were more issues with the CERT record type. > > CERT also uses sub-typing, so you might end up getting all kind of types > of certificates (like a PKIX cert) that you don't want or need. Granted, > the _openpgpkey. prefix would at least prevent the non-malicious > contamination, but you might still get all kinds of weird stuff. From > what I understood, sub-typing was what really killed the CERT record, > and everyone since has been strongly urged to stay away from sub-typing, > and told to use _prefix. instead. Then you have failed to understand RFC 5507. > The CERT record also does not offer a nice presentation format for the > zone file. The RFC states: > > smith IN CERT PGP 0 0 CERT records have base64 as the presentation format of the binary blob. This is independent of the type of certificate being encoded. See RFC 4398 2.2 Text Representation of CERT RRs. I think you are confusing wire format and presentation format. > Having binary in a zone is really a non-starter. Which is why OPENPGPKEY > uses base64 as the presentation format and the raw binary as the wire > format. > > > Some aspects of the rfc are a bit terse. Can you tell, for IPGP, > > whether the length octet is a bit-lenght or an octet-length? Or > > which data, exactly, is digested to create the key tag? > > IPGP specifies a URL, so now that url becomes another security hurdle. > What do you do when it is on https and you don't trust the CA, ignore. > What do you do when the URL is unreachable - is that censorship/attack? > With the full key in DNSSEC, you get the entire key using only one DNS > query without any followup HTTP(S) queries that you might not be able to > do for various (security/monitoring) reasons. > > It seemed much more desirable to start a fresh dedicated RRTYPE over > fixing up the CERT RRTYPE and then needing to deal with servers that > only support the "old CERT type" versus ones that support the "new CERT > type". In other words, the pain of recycling was worse than just > starting fresh. > > Paul > > _______________________________________________ > 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 nobody Tue Apr 22 18:45:21 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 432371A02EE for ; Tue, 22 Apr 2014 18:45:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.272 X-Spam-Level: X-Spam-Status: No, score=-2.272 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZUmuV6_3Bst6 for ; Tue, 22 Apr 2014 18:44:54 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id E2BA01A02D9 for ; Tue, 22 Apr 2014 18:44:53 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 853BC8009A; Tue, 22 Apr 2014 21:44:46 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1398217487; bh=jUpZPU/YHo6yqG5A+8e1NW+uZbEovAo+hZS4dgSVzjc=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=ckuMlYw5M9DG78Hlo7q75CWsp3RACvr/NlZcKaEVdGB6a5PTNEtazGZQ0DDRKeSvc jIfjjCPifNfr52ADjYt94WxkrHon3eny6scBVCrkdhb1JpE7FGC02TKED1CSCWqE5f 4M2Z9uKZLRF0+phMQ2XPUOeHd7vOFsTtL5BNg7WE= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s3N1ihqS017484; Tue, 22 Apr 2014 21:44:44 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Tue, 22 Apr 2014 21:44:43 -0400 (EDT) From: Paul Wouters To: Mark Andrews In-Reply-To: <20140422234112.7C239143C8CC@rock.dv.isc.org> Message-ID: References: <20140410175623.1767.25701.idtracker@ietfa.amsl.com> <53562BA6.6010808@redhat.com> <53564F63.2010008@redhat.com> <20140422234112.7C239143C8CC@rock.dv.isc.org> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/dane/1w41yWV9K57Rsjm24Wjv-Q4xqKA Cc: dane@ietf.org Subject: Re: [dane] draft-ietf-dane-openpgpkey-00 comments X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 23 Apr 2014 01:45:13 -0000 On Wed, 23 Apr 2014, Mark Andrews wrote: >> CERT also uses sub-typing, so you might end up getting all kind of types >> of certificates (like a PKIX cert) that you don't want or need. Granted, >> the _openpgpkey. prefix would at least prevent the non-malicious >> contamination, but you might still get all kinds of weird stuff. From >> what I understood, sub-typing was what really killed the CERT record, >> and everyone since has been strongly urged to stay away from sub-typing, >> and told to use _prefix. instead. > > Then you have failed to understand RFC 5507. Hmm, I read from RFC 5507" When storing data in the DNS for a new application, the goal must be to store data in such a way that the application can query for the data it wants, while minimizing both the impact on existing applications and the amount of extra data transferred to the client. This implies that a number of design choices have to be made, where the most important is to ensure that a precise selection of what data to return must be made already in the query. To me that reads as "don't do sub-typing" because the query cannot request the single type it is interested it, and can only get the full list. >> The CERT record also does not offer a nice presentation format for the >> zone file. The RFC states: >> >> smith IN CERT PGP 0 0 > > CERT records have base64 as the presentation format of the > binary blob. The line above here containing "smith" comes straight from that same RFC, so that's a little confusing then :P I did not read "" as "base64" :P Maybe we should file an errata (if people cared about CERT) Paul From nobody Tue Apr 22 19:45:42 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A96761A02C5 for ; Tue, 22 Apr 2014 19:45:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Duqk2xVRPmnk for ; Tue, 22 Apr 2014 19:45:35 -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 3C6391A012A for ; Tue, 22 Apr 2014 19:45:35 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.ams1.isc.org (Postfix) with ESMTP id 496B42383B1; Wed, 23 Apr 2014 02:45:16 +0000 (UTC) (envelope-from marka@isc.org) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 770B1160056; Wed, 23 Apr 2014 02:47:53 +0000 (UTC) Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 4538616004A; Wed, 23 Apr 2014 02:47:53 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id DADFA143DC9F; Wed, 23 Apr 2014 12:45:11 +1000 (EST) To: Paul Wouters From: Mark Andrews References: <20140410175623.1767.25701.idtracker@ietfa.amsl.com> <53562BA6.6010808@redhat.com> <53564F63.2010008@redhat.com> <20140422234112.7C239143C8CC@rock.dv.isc.org> In-reply-to: Your message of "Tue, 22 Apr 2014 21:44:43 -0400." Date: Wed, 23 Apr 2014 12:45:11 +1000 Message-Id: <20140423024511.DADFA143DC9F@rock.dv.isc.org> Archived-At: http://mailarchive.ietf.org/arch/msg/dane/R_odUiWK8yAAv84eT32BxYRWcaY Cc: dane@ietf.org Subject: Re: [dane] draft-ietf-dane-openpgpkey-00 comments X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 23 Apr 2014 02:45:40 -0000 In message , Paul Wouters writes: > On Wed, 23 Apr 2014, Mark Andrews wrote: > > >> CERT also uses sub-typing, so you might end up getting all kind of types > >> of certificates (like a PKIX cert) that you don't want or need. Granted, > >> the _openpgpkey. prefix would at least prevent the non-malicious > >> contamination, but you might still get all kinds of weird stuff. From > >> what I understood, sub-typing was what really killed the CERT record, > >> and everyone since has been strongly urged to stay away from sub-typing, > >> and told to use _prefix. instead. > > > > Then you have failed to understand RFC 5507. > > Hmm, I read from RFC 5507" > > When storing data in the DNS for a new application, the goal must be > to store data in such a way that the application can query for the > data it wants, while minimizing both the impact on existing > applications and the amount of extra data transferred to the client. > This implies that a number of design choices have to be made, where > the most important is to ensure that a precise selection of what data > to return must be made already in the query. > > To me that reads as "don't do sub-typing" because the query cannot > request the single type it is interested it, and can only get the full > list. > > >> The CERT record also does not offer a nice presentation format for the > >> zone file. The RFC states: > >> > >> smith IN CERT PGP 0 0 > > CERT records have base64 as the presentation format of the > > binary blob. > > The line above here containing "smith" comes straight from that same > RFC, so that's a little confusing then :P I did not read "" > as "base64" :P > > Maybe we should file an errata (if people cared about CERT) > > Paul As far as I can see you want a new type to save 5 bytes per record. There is no need for a new type especially as you are using a prefix to seperate usage. CERT is quite capable of holding the data. I can see some use in encoding local part as we don't want case insensitve local parts. We also don't want to be able to just list out the PI data. Additionally a prefix is useful for seperating name spaces (people vs machines). Standard mbox encoding (RFC 1034) doesn't seperate the name spaces which has always been a problem. I would recommend changing the draft to focus on why mbox is not a good format for the DNS keys for email addresses for and just encode the data using CERTs. Note ":" + base32hexnp(sha1(utf8(local))) would be sufficient without the _openpgpkey label to seperate namespaces. (':' could be replaced with any non LDH character) Reserve all strings which match that format for the new mbox format. base32hexnp = base32hex with no padding as used in NSEC3. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Wed Apr 23 20:12:36 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D76EC1A02FE; Wed, 23 Apr 2014 20:12:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ckJ4EWE2sDu; Wed, 23 Apr 2014 20:12:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DCC871A078C; Wed, 23 Apr 2014 20:12:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140424031228.11005.56596.idtracker@ietfa.amsl.com> Date: Wed, 23 Apr 2014 20:12:28 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/o4zYZzu4e9NAKlE2hSxXLMiB_eg Cc: dane@ietf.org Subject: [dane] I-D Action: draft-ietf-dane-smtp-with-dane-08.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 03:12:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS-based Authentication of Named Entities Working Group of the IETF. Title : SMTP security via opportunistic DANE TLS Authors : Viktor Dukhovni Wes Hardaker Filename : draft-ietf-dane-smtp-with-dane-08.txt Pages : 32 Date : 2014-04-23 Abstract: This memo describes a downgrade-resistant protocol for SMTP transport security between Mail Transfer Agents (MTAs) based on the DNS-Based Authentication of Named Entities (DANE) TLSA DNS record. Adoption of this protocol enables an incremental transition of the Internet email backbone to one using encrypted and authenticated Transport Layer Security (TLS). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dane-smtp-with-dane/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-dane-smtp-with-dane-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Apr 23 20:38:38 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF7A71A064F for ; Wed, 23 Apr 2014 20:38:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hVGz1nPxnMKv for ; Wed, 23 Apr 2014 20:38:32 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 8D1281A0564 for ; Wed, 23 Apr 2014 20:38:32 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 5324B2AB05D; Thu, 24 Apr 2014 03:38:25 +0000 (UTC) Date: Thu, 24 Apr 2014 03:38:25 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140424033825.GO18879@mournblade.imrryr.org> References: <20140424031228.11005.56596.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140424031228.11005.56596.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/xOcE37TH4Sfs3mMLEUP-1Xtv7do Subject: Re: [dane] I-D Action: draft-ietf-dane-smtp-with-dane-08.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@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, 24 Apr 2014 03:38:34 -0000 On Wed, Apr 23, 2014 at 08:12:28PM -0700, internet-drafts@ietf.org wrote: > Title : SMTP security via opportunistic DANE TLS > Authors : Viktor Dukhovni > Wes Hardaker > Filename : draft-ietf-dane-smtp-with-dane-08.txt > Pages : 32 > Date : 2014-04-23 > > http://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-08 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-dane-smtp-with-dane-08 I've updated to the document to add text that describes in more detail name checks (RFC 6125 requirements) for SMTP with opportunistic DANE TLS. - Presence of DNS-IDs preempts CN-ID processing, but CN-ID is supported in the absence of DNS-IDs. - No partial-label wildcards. - Single label wildcards are supported in both DNS-IDs and CN-IDs. - Multi-label wildcards are a local policy option for the client, servers should not expect this to be supported. In addition I clarified the DANE-TA(3) matching rules (no name checks, no expiration checks). For DANE-TA(2), servers are encouraged to stick to selector Cert(0), because SPKI(1) does not cover potentially important TA certificate elements. Use of matching type Full(0) is discouraged. Note, digest algorithm agility remains unchanged, though we may not yet have "rough consensus" for it, we have some significant support. Please review the diffs. This is also a good time to read the entire document if you have not done that yet. Any remaining changes should be minor. Spelling, grammar, clarity suggestions appreciated. Github pull requests would be great: https://github.com/vdukhovni/ietf I'll update the HTML periodically at: http://vdukhovni.github.io/ietf/draft-ietf-dane-smtp-with-dane-08.html -- Viktor. From nobody Fri Apr 25 14:57:55 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A752E1A050E for ; Fri, 25 Apr 2014 14:57:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zdz-u2-ETvD6 for ; Fri, 25 Apr 2014 14:57:51 -0700 (PDT) Received: from mail-ve0-x231.google.com (mail-ve0-x231.google.com [IPv6:2607:f8b0:400c:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id C023F1A0680 for ; Fri, 25 Apr 2014 14:57:50 -0700 (PDT) Received: by mail-ve0-f177.google.com with SMTP id sa20so5385445veb.36 for ; Fri, 25 Apr 2014 14:57:44 -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 :content-type; bh=ONzUgDbxN/Cf3lo/RrOgz2tWPNYHHsYxag/UMcpxAWU=; b=tkXbPRCNItEhchoaLEwvGslT07JAtxND595VKYAoLAl9ojYE+QGTfeyAGjpvG7ii5e 4EnrcYw7N3T2ApNHWJsjeviybUZhr4KLieBPpoMjUvVRj5LayrN53DZV1BZVaL89/sdr ULj4F/kPCfpgBg47FGqhzJqLQ2cFTvBh7636w= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=ONzUgDbxN/Cf3lo/RrOgz2tWPNYHHsYxag/UMcpxAWU=; b=a0PlgKWL0gEZPH9yRhO95A2ePJjMLKJgOuD2hD/3SAfo5i9ousoBy/HHPr8qBFnUW2 4lW7gA1UC6o7mjA5F7Ivjy6zbTHhWj+KLLhEU+8iTZ5hy+pDwHBhqnD3gsK/pwP/sN3m W1Q1S9Yvq/GsMlWX3fPNrGmZL84/O9+wTJ3JXyWcfTbLn+zxBQ6p7qrr7462DIvj5ifq UA7AGqfSMFHdbCAzNBDuuueqWRKURHTzVrnZGysjH0bVv1sJ86mm0V/3Yswwd6NoKf3F om7KtgdWs4a0Bn4dHdH0q8UKqEwhXT4BVr+tRpDmxfk8C8K6lzFLY/CUZ+S5qSam2EYo lLdw== X-Gm-Message-State: ALoCoQmyoc4Zj3Sfzb9fGXfc8SRVKoTMRn1JApgN0AW/PK07VRAKd8MiIimapWsWtn9t/czgIaMx X-Received: by 10.52.183.228 with SMTP id ep4mr7244186vdc.30.1398463064106; Fri, 25 Apr 2014 14:57:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.88.101 with HTTP; Fri, 25 Apr 2014 14:57:24 -0700 (PDT) In-Reply-To: <20140424033825.GO18879@mournblade.imrryr.org> References: <20140424031228.11005.56596.idtracker@ietfa.amsl.com> <20140424033825.GO18879@mournblade.imrryr.org> From: Tom Ritter Date: Fri, 25 Apr 2014 17:57:24 -0400 Message-ID: To: IETF DANE WG list Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/__WWEtOMRSDPCfspuCrEYEg9S6I Subject: Re: [dane] I-D Action: draft-ietf-dane-smtp-with-dane-08.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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 Apr 2014 21:57:53 -0000 That's a long one. I have a few comments, most of them minor. I found only one typo. ------------------- Section 2.2.2, Regarding the problem nameservers for largeemailprovider.com: If an insecure MX record is returned pointing to largeemailprovider.com, skip TLSA lookup, because even if we got a signed response, the insecure MX to the domain could have been MITM-ed. Makes sense. But I wonder if there might be a scenario where the insecure MX record appears to be insecure, but is not actually. In which case the TLSA lookup would provide security. For example, if an admin specifically configures a mapping inside the smtpd (I think this is transport_maps in postfix?) - this type of mapping _could_ be labeled as 'secure' inside the data structures, because of it's origination, but this would be more state to track through more functions. Another example would be locally configured DNS names (smtp_host_lookup with 'native' in postfix?) - maybe a .local domain that resolve to public IP space or overrides in /etc/hosts. These are securely delivered even though they're not DNSSEC. I agree that skipping the TLSA record after getting a public insecure MX record cannot increase security. But I don't think it decreases it either. I think it mainly affects latency. And there may be situations where the smtpd cannot distinguish between 'no DNSSEC and insecure' and 'no DNSSEC but I can trust anyway.' So I would suggest a SHOULD proceed with TLSA lookup instead of a SHOULD NOT, noting that it in _most_ cases it won't actually increase security but we'll give it a shot because it won't _hurt_ security either. If there were mechanisms in a MTA to somehow flag a message as 'securely delivered', which I don't believe there are, they would not apply. ------------------- example.com. IN MX 0 mx1.example.com. example.com. IN MX 0 mx2.example.com. Forgive my ignorance, but these are MX records each with a 0 priority, right? If so, maybe make it '10' and '20' as it would be more apparent to people like me. There are at least two places this is used. ------------------- These paragraphs are spread around, but say the same thing. The SMTP client SHOULD NOT deliver mail via the corresponding host unless a TLS session is negotiated via STARTTLS. This is required to avoid MITM STARTTLS downgrade attacks. ... When at least one usable "secure" TLSA record is found, the SMTP client SHOULD use TLSA records to authenticate the SMTP server. Messages SHOULD NOT be delivered via the SMTP server if authentication fails, otherwise the SMTP client is vulnerable to MITM attacks. Perhaps the first should say behavior is defined in Section 2.3.2 (the second)? It also seems to contradict the later paragraph in 6.1: Unless local policy specifies "audit only" or that opportunistic DANE TLS is not to be used for a particular destination, an SMTP client MUST NOT deliver mail via a server whose certificate chain fails to match at least one TLSA record when usable TLSA records are found for that server. ------------------- It took me a good long time, but I finally found a typo (missing period). This was the only typo I found. name is based entirely on the TLSA record association The server MUST ------------------- Section 2.3.1.3 Strong disagree with this paragraph: SMTP client treatment of TLSA RRs with certificate usages "PKIX- TA(0)" or "PKIX-EE(1)" is undefined. For example, clients MAY (will likely) treat such TLSA records as unusable. First off, I think it's inappropriate to use capital MAY in an example about how clients might behave, immediately after saying it's undefined. Lowercase 'may', sure, but capital implies something else. Second off, I think it's inappropriate to suggest that clients ignore these settings. I agree with the sentiment that it has no increase in security. I also bet you some large corporation or government agency somewhere has some requirement to publish CA-validated certs only, and thus would need to publish these usages anyway. I think it is better said that clients SHOULD process these TLSA records and MAY treat them as the corresponding PKIX-less variants. (And leaving it stated that servers SHOULD NOT publish these variants.) ------------------- Is it really necessary to include the Reference Identifier Matching in 2.3.2.3? It can't be referenced in another document? The behavior seems different from what is actually valid in other contexts, and omits some restricts as I understand them. ------------------- Suppose that a DANE TLS client authenticating a TLS server considers digest algorithm BETTER stronger than digest algorithm WORSE. I would suggest renaming these algorithms to something like "AlgoBetter" and rephasing it "considers a digest algorithm named AlgoBetter to be stronger than...". This avoids the backtracking needed to realize that BETTER is a name, and not an emphasized adjective. ------------------- If the client sends no SNI extension, or sends an SNI extension for an unsupported domain, the server MUST simply send its default certificate chain. To me it seems it would be more appropriate to say that the server MUST send some certificate chain, and the choice of which certificate chain to send is left undefined. ------------------- I can submit github PRs for these sometime next week if desired. -tom From nobody Fri Apr 25 20:34:40 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C412E1A044A for ; Fri, 25 Apr 2014 20:34:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lupN6xC9N6Bz for ; Fri, 25 Apr 2014 20:34:35 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 9153A1A0443 for ; Fri, 25 Apr 2014 20:34:35 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 437952AAA21; Sat, 26 Apr 2014 03:34:27 +0000 (UTC) Date: Sat, 26 Apr 2014 03:34:27 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140426033426.GZ18879@mournblade.imrryr.org> References: <20140424031228.11005.56596.idtracker@ietfa.amsl.com> <20140424033825.GO18879@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/eMJRdOBoXU7oNgQKXwhdWhgKW9k Subject: Re: [dane] smtp-with-dane-08 nameserver work-around section 2.2.2 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Apr 2014 03:34:38 -0000 On Fri, Apr 25, 2014 at 05:57:24PM -0400, Tom Ritter wrote: > Section 2.2.2, Regarding the problem nameservers for > largeemailprovider.com: If an insecure MX record is returned pointing > to largeemailprovider.com, skip TLSA lookup, because even if we got a > signed response, the insecure MX to the domain could have been > MITM-ed. Makes sense. That's not the point of 2.2.2, the specific provider dealt with in 2.2.2, which does not get named in the RFC, but was mentioned in prior list discussion so the issue is more concrete is: $ dig +adflag +noall +comment +ans -t mx nist.gov ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16582 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; ANSWER SECTION: nist.gov. IN MX 0 nist-gov.mail.protection.outlook.com. The MX record is in fact in a DNSSEC signed zone, and is secure, what is not DNSSEC signed is: $ dig +adflag +noall +comment +ans -t a nist-gov.mail.protection.outlook.com ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48597 ;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0 ;; ANSWER SECTION: nist-gov.mail.protection.outlook.com. 10 IN A 207.46.163.215 nist-gov.mail.protection.outlook.com. 10 IN A 207.46.163.247 nist-gov.mail.protection.outlook.com. 10 IN A 207.46.163.138 nist-gov.mail.protection.outlook.com. 10 IN A 207.46.163.170 Furthermore, TLSA lookups via recursive resolvers SERVFAIL: $ dig +adflag +noall +comment +ans -t tlsa _25._tcp.nist-gov.mail.protection.outlook.com ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 36237 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 because, the authoritative nameservers are broken: $ dig +norecur +adflag +noall +comment +ans -t tlsa _25._tcp.nist-gov.mail.protection.outlook.com @ns1-proddns.glbdns.o365filtering.com ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOTIMP, id: 54501 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 > But I wonder if there might be a scenario where the insecure MX record > appears to be insecure, but is not actually. No, there is not. > For example, if an admin specifically > configures a mapping inside the smtpd (I think this is transport_maps > in postfix?) - this type of mapping _could_ be labeled as 'secure' A nexthop override is NOT an MX record and is considered secure, it is locally specificied. Such a nexthop (with many MTAs) might still be subject to MX records, and in that case, the security of those MX records is what matters. I'm afraid you've got yourself somewhat confused here... This case is handled correctly both in Postfix and in the draft. -- Viktor. From nobody Fri Apr 25 20:57:01 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F1871A044B for ; Fri, 25 Apr 2014 20:57:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h_HiSPmLP9WC for ; Fri, 25 Apr 2014 20:56:57 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 7A90F1A02E0 for ; Fri, 25 Apr 2014 20:56:57 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id D643D2AAA21; Sat, 26 Apr 2014 03:56:50 +0000 (UTC) Date: Sat, 26 Apr 2014 03:56:50 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140426035650.GA18879@mournblade.imrryr.org> References: <20140424031228.11005.56596.idtracker@ietfa.amsl.com> <20140424033825.GO18879@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/0QKcOI4J8RZTqZ3w5BfnAMvzN6A Subject: Re: [dane] Feedback: opportunistic DANE TLS post insecure SSR. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Apr 2014 03:57:00 -0000 On Fri, Apr 25, 2014 at 05:57:24PM -0400, Tom Ritter wrote: > Another example > would be locally configured DNS names (smtp_host_lookup with 'native' > in postfix?) - maybe a .local domain that resolve to public IP space > or overrides in /etc/hosts. These are securely delivered even though > they're not DNSSEC. Names not found via DNS at all, or found via DNS, but not in DNSSEC signed zones are out scope for DANE. > So I would suggest a SHOULD > proceed with TLSA lookup instead of a SHOULD NOT, noting that it in > _most_ cases it won't actually increase security but we'll give it a > shot because it won't _hurt_ security either. For common vocabulary it may be helpful to read: http://tools.ietf.org/html/draft-ogud-dane-vocabulary-02 Attempting to do DANE post insecurely obtained DNS Navigation (NS, CNAME, DNAME) or Service Specification Records (MX, SRV, ...) seems futile. In such a scenario is largely sufficient to just do unauthenticated opportunistic TLS. If there is no MiTM the outcome is the same, and if there is an active attack, you've likely lost by the time you've followed the insecure MX records. Yes, if the MX hostname is a secure zone and TLSA records exist, you're arguably "half-secure" if you use them, in that if the MX record was not forged, then DANE TLSA closes the rest of the gap. I cannot with a straight face log such email connections as "verified" when they are not in fact verified. Such a security chain that consists of cast-iron links on one end and a piece of dental floss on the other is certainly NOT suitable for mandatory DANE TLS (the Postfix "dane-only" security level). One might argue that with *opportunistic* DANE TLS, striving for as much security as one can get might hypothetically include securing the connection to a server that has TLSA records in a signed zone, despite the fact that the Server Specification (MX) Records were not secured. In such a case, one would have to not consider any resulting connection as secure (logging, user interface, ...), and yet one would hypotheticall still refuse to use the connection when DANE TLSA authentication fails. Would this be a sensible extension of *opportunistic* TLS in the presence of TLSA records? About the most compelling use-case for this would be various unsigned mom/pop domains hosted by a large provider (say Gmail). If Gmail's MX RRset is some day in a signed zone, and TLSA records exist, is there sufficient value in enforced authentication of connections to Gmail when delivering email to a domain whose MX records are not signed? Note, the MiTM attacker can easily divert the connection to some unsigned MX host of his choice. > If there were mechanisms in a MTA to somehow flag a message as > 'securely delivered', which I don't believe there are, they would not > apply. The Postfix SMTP client logs DANE authenticated connections as "Verified". http://www.postfix.org/FORWARD_SECRECY_README.html#status -- Viktor. From nobody Fri Apr 25 21:32:11 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 191061A06DC for ; Fri, 25 Apr 2014 21:32:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NfD28B9DMtMc for ; Fri, 25 Apr 2014 21:32:06 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id AEDC31A0452 for ; Fri, 25 Apr 2014 21:32:06 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id CBF062AAA21; Sat, 26 Apr 2014 04:31:58 +0000 (UTC) Date: Sat, 26 Apr 2014 04:31:58 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140426043158.GB18879@mournblade.imrryr.org> References: <20140424031228.11005.56596.idtracker@ietfa.amsl.com> <20140424033825.GO18879@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/z3sAVThpoYew0M0shdBeL_w35KQ Subject: Re: [dane] I-D Action: draft-ietf-dane-smtp-with-dane-08.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Apr 2014 04:32:09 -0000 On Fri, Apr 25, 2014 at 05:57:24PM -0400, Tom Ritter wrote: > ------------------- > > These paragraphs are spread around, but say the same thing. > > The SMTP client SHOULD NOT deliver > mail via the corresponding host unless a TLS session is negotiated > via STARTTLS. This is required to avoid MITM STARTTLS downgrade > attacks. > > ... > > When at least one usable "secure" TLSA record is found, the SMTP > client SHOULD use TLSA records to authenticate the SMTP server. > Messages SHOULD NOT be delivered via the SMTP server if > authentication fails, otherwise the SMTP client is vulnerable to MITM > attacks. These cover different protocol stages, the first STARTTLS downgrade, the second certificate verification. > It also seems to contradict the later paragraph in 6.1: > > Unless > local policy specifies "audit only" or that opportunistic DANE TLS is > not to be used for a particular destination, an SMTP client MUST NOT > deliver mail via a server whose certificate chain fails to match at > least one TLSA record when usable TLSA records are found for that > server. Thanks, here, there is indeed a MUST/SHOULD inconsistency. I will change 6.1 to SHOULD. Explicit local policy always wins. > ------------------- > > It took me a good long time, but I finally found a typo (missing > period). This was the only typo I found. > > name is based entirely on the TLSA record association The server MUST Fixed, staged for next update. > ------------------- > > Section 2.3.1.3 > > Strong disagree with this paragraph: > > SMTP client treatment of TLSA RRs with certificate usages "PKIX- > TA(0)" or "PKIX-EE(1)" is undefined. For example, clients MAY (will > likely) treat such TLSA records as unusable. In that case you need to re-read sections 1.3, and 1.3.1--1.3.4, which explain why PKIX *cannot* work for SMTP. Wishing it otherwise does not make it true. > First off, I think it's inappropriate to use capital MAY in an example > about how clients might behave, immediately after saying it's > undefined. Lowercase 'may', sure, but capital implies something else. I don't have a strong opinion about MAY vs. may in this context. Anyone else care to comment? > Second off, I think it's inappropriate to suggest that clients ignore > these settings. I agree with the sentiment that it has no increase in > security. No, the real problem is that these cannot be implemented interoperably. Honouring such records will break email deliverability and nobody will use opportunistic DANE TLS with SMTP. An opportunistic protocol has to be interoperable first, and secure second. We're working on a definition of "opportunistic security" on the "saag" mailing list. And while some of the discussion has been a bit heated, naturally over rather small issues, there is little contorversy with respect to the idea that "opportunistic security" is first and foremost highly interoperable, it is expected to just work at whatever security level is possible with each peer. Now "opportunistic DANE TLS" is an attempt to provide stronger security for peers that publish DANE TLSA records, but not to the point of supporting parameters that lead to widespread breakage. Since PKIX & SMTP are oil and water, the opportunistic DANE TLS protocol has to define PKIX out of scope, because PKIX only works for sites that coordinate their settings, while opportunistic DANE TLS kicks-in automatically on the fly. > I also bet you some large corporation or government agency > somewhere has some requirement to publish CA-validated certs only, and > thus would need to publish these usages anyway. That's nice, and yet they too send unecrypted email to most of the world, and unauthenticated email to sites with self-signed certs, ... Their hypothetical policies don't match the reality of SMTP. They can cut off their nose to spite their face, and refuse to do DANE because DANE does not support PKIX, but they get no authentication at all. They can still do PKIX by hand with specific peers, just like they've been doing (and I did for a decade at Morgan Stanley). DANE does not trump local policy. However SMTP TLS at Internet scale cannot tolerate PKIX. That's a fact I cannot legislate away. > I think it is better said that clients SHOULD process these TLSA > records and MAY treat them as the corresponding PKIX-less variants. > (And leaving it stated that servers SHOULD NOT publish these > variants.) No, clients SHOULD NOT process these records, as they will lead to widespread email outages and much disappointment for publishers of such records. > ------------------- > > Is it really necessary to include the Reference Identifier Matching in > 2.3.2.3? It can't be referenced in another document? The behavior > seems different from what is actually valid in other contexts, and > omits some restricts as I understand them. Yes, it is necessary to describe RFC 6125-style semantics for this new SMTP with TLS protocol. And yes it needs to be different from prior documents which only ever covered MUA to MTA submission at best. > Suppose that a DANE TLS client authenticating a TLS server considers > digest algorithm BETTER stronger than digest algorithm WORSE. > > I would suggest renaming these algorithms to something like > "AlgoBetter" and rephasing it "considers a digest algorithm named > AlgoBetter to be stronger than...". This avoids the backtracking > needed to realize that BETTER is a name, and not an emphasized > adjective. Sure, makes sense, staging for next update. > ------------------- > > If the client sends no SNI extension, > or sends an SNI extension for an unsupported domain, the server MUST > simply send its default certificate chain. > > To me it seems it would be more appropriate to say that the server > MUST send some certificate chain, and the choice of which certificate > chain to send is left undefined. I guess that makes sense, staging for next update. > I can submit github PRs for these sometime next week if desired. I'll take of it. Thanks. -- Viktor. From nobody Fri Apr 25 22:33:03 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9CB61A0673 for ; Fri, 25 Apr 2014 22:33:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.552 X-Spam-Level: X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id isfoK83RFBNO for ; Fri, 25 Apr 2014 22:32: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 30E001A044F for ; Fri, 25 Apr 2014 22:32:58 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id s3Q5WokI009357 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sat, 26 Apr 2014 07:32:50 +0200 (MEST) In-Reply-To: <20140426033426.GZ18879@mournblade.imrryr.org> To: dane@ietf.org Date: Sat, 26 Apr 2014 07:32:50 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20140426053250.6BCEB1ACE0@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Archived-At: http://mailarchive.ietf.org/arch/msg/dane/nFvCiUfTxUkBHNd6rxnlhw5JfQk Subject: Re: [dane] smtp-with-dane-08 nameserver work-around section 2.2.2 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 26 Apr 2014 05:33:00 -0000 Viktor Dukhovni wrote: > On Fri, Apr 25, 2014 at 05:57:24PM -0400, Tom Ritter wrote: > > Furthermore, TLSA lookups via recursive resolvers SERVFAIL: > > $ dig +adflag +noall +comment +ans -t tlsa _25._tcp.nist-gov.mail.protection.outlook.com > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 36237 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 > > because, the authoritative nameservers are broken: > > $ dig +norecur +adflag +noall +comment +ans -t tlsa _25._tcp.nist-gov.mail.protection.outlook.com @ns1-proddns.glbdns.o365filtering.com > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOTIMP, id: 54501 > ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 The authoritative nameservers return a perfectly valid and reasonable response, in full conformance with STD13. But in case that _all_ authoritative nameserver do return NOTIMP, then the recursive resolver is broken, because it is erroneously turning a crystal-clear STD13-compliant permanent failure into a temporary failure. -Martin From nobody Sat Apr 26 06:46:41 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0610F1A047E for ; Sat, 26 Apr 2014 06:46:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.273 X-Spam-Level: X-Spam-Status: No, score=-2.273 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YYnl-cgJl-9y for ; Sat, 26 Apr 2014 06:46:29 -0700 (PDT) Received: from ore.jhcloos.com (ore.jhcloos.com [198.147.23.85]) by ietfa.amsl.com (Postfix) with ESMTP id E09F11A04B1 for ; Sat, 26 Apr 2014 06:46:29 -0700 (PDT) Received: by ore.jhcloos.com (Postfix, from userid 10) id F17D91DDE9; Sat, 26 Apr 2014 13:46:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore14; t=1398519980; bh=7UQOzo9jApsCk0eA/Uivz6j2Y49vfIAywxp3jM6byO8=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=BzAiqFxLrwDKu0YjSQuvP9+Ye8yRvge8KgRu9GUv0L+6qfRpKCAN6571jnSr4Viur ZI/e0wVeDPWYXlkeQWR1Cgl86wen5LX39HUIzoA85ljDaKtFrUXH0uvbOWSCsGVop8 G4Xjdq06dWo+NHntO7Vxh96mvZnI8ZLPd1PXT+FU= Received: by carbon.jhcloos.org (Postfix, from userid 500) id 4156360023; Sat, 26 Apr 2014 13:39:19 +0000 (UTC) From: James Cloos To: dane@ietf.org In-Reply-To: <20140426043158.GB18879@mournblade.imrryr.org> (Viktor Dukhovni's message of "Sat, 26 Apr 2014 04:31:58 +0000") References: <20140424031228.11005.56596.idtracker@ietfa.amsl.com> <20140424033825.GO18879@mournblade.imrryr.org> <20140426043158.GB18879@mournblade.imrryr.org> User-Agent: Gnus/5.13001 (Ma Gnus v0.10) Emacs/24.4.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2014 James Cloos OpenPGP: 0x997A9F17ED7DAEA6; url=https://jhcloos.com/public_key/0x997A9F17ED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Sat, 26 Apr 2014 09:39:19 -0400 Message-ID: Lines: 10 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:140426:dane@ietf.org::tkDStjNZ0MhpYr3r:000GrNX1 X-Hashcash: 1:30:140426:viktor1dane@dukhovni.org::PHkco1Xt32iT4aO4:0000000000000000000000000000000000004zPbn Archived-At: http://mailarchive.ietf.org/arch/msg/dane/UOSJ9kEG7L4grDsr1SIitR8Lo9I Subject: Re: [dane] I-D Action: draft-ietf-dane-smtp-with-dane-08.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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 Apr 2014 13:46:34 -0000 >>>>> "VD" == Viktor Dukhovni writes: VD> I don't have a strong opinion about MAY vs. may in this context. VD> Anyone else care to comment? His reasoning for may is sound. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 From nobody Sat Apr 26 11:46:57 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD0A61A0386 for ; Sat, 26 Apr 2014 11:46:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gHa1HjZSNWEM for ; Sat, 26 Apr 2014 11:46:54 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 056531A02CC for ; Sat, 26 Apr 2014 11:46:53 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id A61172AB05D; Sat, 26 Apr 2014 18:46:44 +0000 (UTC) Date: Sat, 26 Apr 2014 18:46:44 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140426184644.GB27883@mournblade.imrryr.org> References: <20140426033426.GZ18879@mournblade.imrryr.org> <20140426053250.6BCEB1ACE0@ld9781.wdf.sap.corp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140426053250.6BCEB1ACE0@ld9781.wdf.sap.corp> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/rOmB_4zJ8IReMN6DUFCmkjCML8Q Subject: Re: [dane] smtp-with-dane-08 nameserver work-around section 2.2.2 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Apr 2014 18:46:56 -0000 On Sat, Apr 26, 2014 at 07:32:50AM +0200, Martin Rex wrote: > > because, the authoritative nameservers are broken: > > > > $ dig +norecur +adflag +noall +comment +ans -t tlsa _25._tcp.nist-gov.mail.protection.outlook.com @ns1-proddns.glbdns.o365filtering.com > > ;; Got answer: > > ;; ->>HEADER<<- opcode: QUERY, status: NOTIMP, id: 54501 > > ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 > > The authoritative nameservers return a perfectly valid and reasonable > response, in full conformance with STD13. [ This particular nit-pick sub-thread is of no practical consequence, just a bit of pontification by all concerned, including me. Whether the authoritative nameservers are broken, or every resolver is broken is immaterial, the TLSA query needs to be suppressed either way. ] And yet they're broken. The query domain does not in fact exist, and the right response is NXDOMAIN. Had it existed, since the servers are authoritative, the right response would be "NODATA" (no error code and an empty answer section). > But in case that _all_ authoritative nameserver do return NOTIMP, > then the recursive resolver is broken, because it is erroneously > turning a crystal-clear STD13-compliant permanent failure into a > temporary failure. We've been through this before: http://www.ietf.org/mail-archive/web/dane/current/msg06199.html and containing thread. I only brought it up again to bring Tom Ritter up to speed. -- Viktor. From nobody Sun Apr 27 13:13:02 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C96251A03C5 for ; Sun, 27 Apr 2014 13:13:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.286 X-Spam-Level: ** X-Spam-Status: No, score=2.286 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FAKE_REPLY_C=1.486] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j5Mse_wZlqEm for ; Sun, 27 Apr 2014 13:12:59 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 958601A03B1 for ; Sun, 27 Apr 2014 13:12:59 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 1DA062AAA21; Sun, 27 Apr 2014 20:12:58 +0000 (UTC) Date: Sun, 27 Apr 2014 20:12:58 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140427201258.GM27883@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140426035650.GA18879@mournblade.imrryr.org> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/A_XTU4X1dG2rEUT9U3xBqDsiJ34 Subject: Re: [dane] Feedback: opportunistic DANE TLS post insecure SSR. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Apr 2014 20:13:01 -0000 On Thu, Sep 05, 2013 at 02:57:24PM -0700, Ian Fette (????????) wrote: > Let's say that you want to know a-priori if an email will be sent over TLS. > Three german companies are doing this already ("Email made in germany" > campaign between web.de, gmx, and t-online) where they show their users > distinguishing UI if the mail is being sent "securely". It's an interesting > to see how that would work out, and personally I find it a very difficult > UI challenge to communicate something meaningful that won't be > misinterpreted, but anyhow... (2) gives you a signal that you could > potentially pass on to a user, and then the user can potentially make a > decision about whether or not they want to send the email. I think it needs > a bit more thinking and UX studies as to whether or not this is a good > idea, but having a signal like that does enable such use cases. > > It also provides a signal that services can potentially cache as to whether > the recipient believes their STARTTLS support is reliable or not. E.g. if > we see such a record and don't see STARTTLS, we may decide to bounce (or > hold) the message until we see STARTTLS again. If we've seen that record > and it disappears as well as STARTTLS support disappearing, that might be a > stronger signal that there's a potential MITM attack or strangeness than > simply seeing STARTTLS disappear alone. > > Basically, it's extra information, which opens up a few possibilities, and > although it doesn't itself prevent an active MITM who is capable of DNS > cache poisoning, it does provide extra information for use in heuristics > and doesn't "hurt". I am reconsidering this issue, see below: On Sat, Apr 26, 2014 at 03:56:50AM +0000, Viktor Dukhovni wrote: > For common vocabulary it may be helpful to read: > > http://tools.ietf.org/html/draft-ogud-dane-vocabulary-02 > > Attempting to do DANE post insecurely obtained DNS Navigation (NS, > CNAME, DNAME) or Service Specification Records (MX, SRV, ...) seems > futile. In such a scenario is largely sufficient to just do > unauthenticated opportunistic TLS. If there is no MiTM the outcome > is the same, and if there is an active attack, you've likely lost > by the time you've followed the insecure MX records. > > Yes, if the MX hostname is a secure zone and TLSA records exist, > you're arguably "half-secure" if you use them, in that if the MX > record was not forged, then DANE TLSA closes the rest of the gap. > > [...] > > About the most compelling use-case for this would be various unsigned > mom/pop domains hosted by a large provider (say Gmail). If Gmail's > MX RRset is some day in a signed zone, and TLSA records exist, is > there sufficient value in enforced authentication of connections > to Gmail when delivering email to a domain whose MX records are > not signed? So given that with SMTP we have an "opportunistic DANE TLS" protocol, and that opportunistic security strives to connect to each peer with at the advertised security capabilities of that peer, perhaps indeed opportunistic DANE TLS with SMTP should attemt to pick up the pieces and perform DANE authenticated delivery to MX hosts with DNSSEC validated TLSA records, even when the MX (SSR) records were "insecure". We don't have enough operational experience with opportunistic DANE TLS to determine whether such a policy would be a net gain. We could add a "SHOULD" to encourage implementations to employ DANE with MX hosts that "happen to have" signed TLSA RRs, even after "insecure" MX RRs. Provided we state that this should be configurable, and may be revised if operational experience proves it to be a mistake. The resulting connection should not be represented as a secure delivery to the next-hop domain, but may be *unambiguously* represented as a secure connection to the MX host in question. Anyone wish to support or oppose such a change in draft? -- Viktor. From nobody Tue Apr 29 16:23:02 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 486DD1A0A08 for ; Tue, 29 Apr 2014 16:23:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uNonvmu8CDtk for ; Tue, 29 Apr 2014 16:22:57 -0700 (PDT) Received: from mail-ve0-x234.google.com (mail-ve0-x234.google.com [IPv6:2607:f8b0:400c:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id 3AB131A09FC for ; Tue, 29 Apr 2014 16:22:57 -0700 (PDT) Received: by mail-ve0-f180.google.com with SMTP id jz11so1184793veb.11 for ; Tue, 29 Apr 2014 16:22:55 -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 :content-type; bh=1d0/vhT/SGaYoSwsdiRbMP8H6FA3ib5OqZmbo7ojVlg=; b=U7QjS9jkp71A2o/3I8SJD2AmcNNLP6jn+dglQ5g+fnzhp0DDlmU6Y/3iumONPGpXmK 0GucFUZRQCLDJWEMJ/cLsFuNuj08hf9/denmpJ+nBARqyMtRg3EMw7+knombIXMi4qKs JvR0TMstey8PpuiyuEu/YTi6Soy3k9DVOw1FI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=1d0/vhT/SGaYoSwsdiRbMP8H6FA3ib5OqZmbo7ojVlg=; b=cpsPxiK+n7q4Jo9XkaWGXNG1b31dr0HvhxBuDveBGQKqoHmHKzpV9POS64U9/sTu6/ 48mWcEa3uqfn/xM8vZ4wH045NQv48vrImj63hfb+QyqCVwfhtKvjFcxsRrp9IEoq3bZF S80sLb2iDRsf7gSJmZkUf6ekKEGO4B+h12AtsEVG8gm9d5F1jh8y48RCVuCfEOOT6oQN EaseGXEe2Pi6JjhHWT1ezi+MgBpcVmBbXwRQgB75j3zGLVEb3Vohwi5KOHVXjiACSykA hYpWbu2kxsjanXD1YAB5aLqRQ2iZoflu0rq/K0OwuUMV6+WkVtuzqabA5p4MrOwQ5Kjj NU5A== X-Gm-Message-State: ALoCoQk2qu/JOCPn7hqM52eBcvYm3iULDkWiHRZ2ZFhKRWJMuiagnGptSK7KF5tpR7mWNCJ2nWRD X-Received: by 10.58.49.10 with SMTP id q10mr642176ven.5.1398813775661; Tue, 29 Apr 2014 16:22:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.88.101 with HTTP; Tue, 29 Apr 2014 16:22:35 -0700 (PDT) In-Reply-To: <20140427201258.GM27883@mournblade.imrryr.org> References: <20140426035650.GA18879@mournblade.imrryr.org> <20140427201258.GM27883@mournblade.imrryr.org> From: Tom Ritter Date: Tue, 29 Apr 2014 19:22:35 -0400 Message-ID: To: IETF DANE WG list Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/fAQHcdvdx9LkCUmfDNt8fdwoQmk Subject: Re: [dane] Feedback: opportunistic DANE TLS post insecure SSR. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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 Apr 2014 23:23:00 -0000 On 27 April 2014 16:12, Viktor Dukhovni wrote: > Anyone wish to support or oppose such a change in draft? I support, obviously. -tom