From eosterweil@verisign.com Wed Feb 5 07:17: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 E252A1A01F3 for ; Wed, 5 Feb 2014 07:17:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.601 X-Spam-Level: X-Spam-Status: No, score=-3.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_26=0.6, RCVD_IN_DNSWL_MED=-2.3, 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 RzjnjpZnWIll for ; Wed, 5 Feb 2014 07:17:29 -0800 (PST) Received: from exprod6og107.obsmtp.com (exprod6og107.obsmtp.com [64.18.1.208]) by ietfa.amsl.com (Postfix) with ESMTP id 4F0AD1A0189 for ; Wed, 5 Feb 2014 07:17:28 -0800 (PST) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob107.postini.com ([64.18.5.12]) with SMTP ID DSNKUvJWB4m7QYTOszbcI64Fv/waRG+HZYLb@postini.com; Wed, 05 Feb 2014 07:17:28 PST Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02.vcorp.ad.vrsn.com [10.173.152.206]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id s15FHQX4004087 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Feb 2014 10:17:27 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Wed, 5 Feb 2014 10:17:26 -0500 From: "Osterweil, Eric" To: Scott Rose Thread-Topic: [dane] I-D Action: draft-ietf-dane-smime-03.txt Thread-Index: AQHPCyZe4iLhCQLcdU6kJvU3W3pU85p7QbWAgCwGwgA= Date: Wed, 5 Feb 2014 15:17:26 +0000 Message-ID: <5DEFF47F-6533-4F1B-8D23-216108989787@verisign.com> References: <20140106212911.12960.24322.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-ID: <32574C912DFB314C905BFB50F848FEA4@verisign.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [dane] I-D Action: draft-ietf-dane-smime-03.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: Wed, 05 Feb 2014 15:17:32 -0000 Hey all, Sorry this response is so delayed. I think the suggestions made in the pro= posed text ( http://www.ietf.org/mail-archive/web/dane/current/msg06180.htm= l ) make quite a bit of sense. In particular, I think the proposal to add = the Usage #4 (reject) is likely to be very important. Specifically, DANE i= s (imho) excellent example of a standard architecture for certificate disco= very using DNS. From this perspective it seems opportune for it to capital= ize on the nuanced difference between saying, ``don't use this cert for thi= s operation,'' and ``this cert is universally revoked.'' These really are = fundamentally different, and DANE lets us express them that way. Also, I think the certificate access field (Section 2.1.4, which enables al= ternate discovery mechanisms) could actually be a great facility for increm= ental deployment and transition schemes. It seems to me that the flexibili= ty added could be crucial as would-be adopters incrementally roll their con= stituency off of (say) an AD solution and onto a DANE solution. =20 Finally, I think the ``_encr'' and ``_sign'' labels are excellent additions= to the _discovery_ mechanism that DANE enables. Viewing DANE as a discove= ry mechanism for certs, I can't help but feel that the process of trying to= discover a signing key vs.trying to discover an encryption key a first cla= ss element of the protocol. Rather than asking for all keys and then selec= ting from them, I (as an RP) likely already know which of these I want, and= I should be able to discover them separately in DANE (and owners should be= able to manage them separately in DANE). Based on that, these changes rea= lly seems like great fodder for being encoded in the domain name, imho. I noticed that the current (-04?) draft doesn't seem to have taken these re= commendations, but I think they should be incorporated. Eric On Jan 8, 2014, at 9:58 AM, Scott Rose wrote: > I support this work and would like to see more discussion on the list. S= ome of us have even proposed text with additions (http://www.ietf.org/mail-= archive/web/dane/current/msg06180.html). =20 >=20 > Haven't seen much discussion on the list, and missed the informal DANE lu= nch at the last IETF. Is there enough interest in having the SMIMEA RR? S= ome of the changes we offered: >=20 > 1. naming convention to help distinguish between signing and encryption k= ey certs (for enterprises that use separate certs for encrypting and signin= g). It helps reduce the size of the SMIMEA RRset a bit, but admittedly min= or compared to the size of an X.509 cert. >=20 > 2. a new CU value for "revoked" to indicate that this user's certificates= have been revoked. =20 >=20 > There are some signed/encrypted email projects rolling out now that are u= sing CERT RR's or combinations of SRV RR's and LDAP servers. Having someth= ing like SMIME would be an improvement, but the spec needs to be finalized.= =20 >=20 > Scott >=20 >=20 > On Jan 6, 2014, at 4:29 PM, internet-drafts@ietf.org wrote: >=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts direc= tories. >> This draft is a work item of the DNS-based Authentication of Named Entit= ies Working Group of the IETF. >>=20 >> Title : Using Secure DNS to Associate Certificates with = Domain Names For S/MIME >> Authors : Paul Hoffman >> Jakob Schlyter >> Filename : draft-ietf-dane-smime-03.txt >> Pages : 6 >> Date : 2014-01-06 >>=20 >> Abstract: >> This document describes how to use secure DNS to associate an S/MIME >> user's certificate with the intended domain name, similar to the way >> that DANE (RFC 6698) does for TLS. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-dane-smime/ >>=20 >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-dane-smime-03 >>=20 >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dane-smime-03 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of submis= sion >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> dane mailing list >> dane@ietf.org >> https://www.ietf.org/mailman/listinfo/dane >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From jakob@kirei.se Wed Feb 5 11:12:25 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 39A711A0140 for ; Wed, 5 Feb 2014 11:12:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.186 X-Spam-Level: X-Spam-Status: No, score=-2.186 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, RP_MATCHES_RCVD=-0.535, 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 9bCAnhgfX8z3 for ; Wed, 5 Feb 2014 11:12:23 -0800 (PST) Received: from spg.kirei.se (spg.kirei.se [IPv6:2001:67c:394:15::9]) by ietfa.amsl.com (Postfix) with ESMTP id C21C61A0159 for ; Wed, 5 Feb 2014 11:12:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kirei.se; s=spg20100524; h=received:content-type:mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to:x-mailer; bh=5V6edyCPNYR2M1i6XzOmyHTKvy0avQzHH/+vqLDluWQ=; b=YuBpAHeld9VJA8V862ShOmf2Zr7mSERV1j1OycEVyAb715hckUuT6hqEN4kGMBUDP+/tbWrLphWZM XSgplmH/9r6dqRhewSQ8cyTNMVLDr34aozX0sF+dWp5qAzNnv+AuMythXTLqZgCS8qJXRskhq5usWZ koe99C8ZJgpqQtbY= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg-relay.kirei.se (Halon Mail Gateway) with ESMTPS; Wed, 5 Feb 2014 20:12:20 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Jakob Schlyter In-Reply-To: <5DEFF47F-6533-4F1B-8D23-216108989787@verisign.com> Date: Wed, 5 Feb 2014 20:12:14 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <6FAFCB1E-AB35-405D-A954-FCD36A00C2A7@kirei.se> References: <20140106212911.12960.24322.idtracker@ietfa.amsl.com> <5DEFF47F-6533-4F1B-8D23-216108989787@verisign.com> To: "Osterweil, Eric" X-Mailer: Apple Mail (2.1827) Cc: "" Subject: Re: [dane] I-D Action: draft-ietf-dane-smime-03.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: Wed, 05 Feb 2014 19:12:25 -0000 On 5 feb 2014, at 16:17, Osterweil, Eric = wrote: > I noticed that the current (-04?) draft doesn't seem to have taken = these recommendations, but I think they should be incorporated. As per Paul's reply Jan 8th, we've had no consensus on adding these = features as both was (at least by Paul and me) of questionable value. = Scott seemed to somewhat agree in a followup mail. However, I do welcome = a more elaborate discussion on the pros _and_ cons so we can close these = issues. jakob From eosterweil@verisign.com Wed Feb 5 12:48: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 21D411A020E for ; Wed, 5 Feb 2014 12:48:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.601 X-Spam-Level: X-Spam-Status: No, score=-3.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_26=0.6, RCVD_IN_DNSWL_MED=-2.3, 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 mE3sNb0gDtvD for ; Wed, 5 Feb 2014 12:48:30 -0800 (PST) Received: from exprod6og116.obsmtp.com (exprod6og116.obsmtp.com [64.18.1.37]) by ietfa.amsl.com (Postfix) with ESMTP id 9FEAD1A01CC for ; Wed, 5 Feb 2014 12:48:25 -0800 (PST) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob116.postini.com ([64.18.5.12]) with SMTP ID DSNKUvKjmAoP+Qn6x+sMYvOW3sTTIT4vbCeE@postini.com; Wed, 05 Feb 2014 12:48:29 PST Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01.vcorp.ad.vrsn.com [10.173.152.255]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id s15KmOlB014984 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Feb 2014 15:48:24 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Wed, 5 Feb 2014 15:48:23 -0500 From: "Osterweil, Eric" To: Jakob Schlyter Thread-Topic: [dane] I-D Action: draft-ietf-dane-smime-03.txt Thread-Index: AQHPCyZe4iLhCQLcdU6kJvU3W3pU85p7QbWAgCwGwgCAAEFoAIAAGtwA Date: Wed, 5 Feb 2014 20:48:22 +0000 Message-ID: References: <20140106212911.12960.24322.idtracker@ietfa.amsl.com> <5DEFF47F-6533-4F1B-8D23-216108989787@verisign.com> <6FAFCB1E-AB35-405D-A954-FCD36A00C2A7@kirei.se> In-Reply-To: <6FAFCB1E-AB35-405D-A954-FCD36A00C2A7@kirei.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="Windows-1252" Content-ID: <6A72502FED707D4EA04715458E81973B@verisign.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [dane] I-D Action: draft-ietf-dane-smime-03.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: Wed, 05 Feb 2014 20:48:32 -0000 On Feb 5, 2014, at 2:12 PM, Jakob Schlyter wrote: > On 5 feb 2014, at 16:17, Osterweil, Eric wrote: >=20 >> I noticed that the current (-04?) draft doesn't seem to have taken these= recommendations, but I think they should be incorporated. >=20 > As per Paul's reply Jan 8th, we've had no consensus on adding these featu= res as both was (at least by Paul and me) of questionable value. Scott seem= ed to somewhat agree in a followup mail. However, I do welcome a more elabo= rate discussion on the pros _and_ cons so we can close these issues. Hey Jakob, Indeed, I was adding in support for Scott's proposal because I agreed with = at least three of his points. I'd be happy to elaborate on any of the issu= es I pointed out, though I did think the comments I initially made were rea= sonably detailed, no? Actually, to that point, I don't recall seeing subst= antive a rebuttal to Scott's suggestions on Jan 8? I actually did read Paul's response ( http://www.ietf.org/mail-archive/web/= dane/current/msg06281.html ), and I felt it didn't present a very in-depth = response to the detailed suggestions that Scott made. That's why I felt it= was important to express my support for Scott's suggestions. For example, Paul responded: ``The slight saving of space also introduces a new, significant failure m= ode =85 I'd say "no" on this one.'' I don't agree that this is a failure mode that invalidates the cert learnin= g, and disagree with its dismissal. Moreover, I elaborated on other reason= s why I think these labels are important, ``Finally, I think the `_encr' an= d `_sign' labels are excellent additions to the _discovery_ mechanism that = DANE enables. Viewing DANE as a discovery mechanism for certs, I can't hel= p but feel that the process of trying to discover a signing key vs.trying t= o discover an encryption key a first class element of the protocol. Rather= than asking for all keys and then selecting from them, I (as an RP) likely= already know which of these I want, and I should be able to discover them = separately in DANE (and owners should be able to manage them separately in = DANE). Based on that, these changes really seems like great fodder for bei= ng encoded in the domain name, imho.'' Paul also said, ``We considered things like this for TLSA, and the WG seemed very hesitan= t=85'' I also don't agree with this, which I noted in my response: ``difference b= etween saying, `don't use this cert for this operation,' and `this cert is = universally revoked.' These really are fundamentally different, and DANE l= ets us express them that way.'' I also think Scott's suggestion for the certificate access field is a very = good one, and I'd very much like to see his suggested text incorporated. Eric= From viktor1dane@dukhovni.org Wed Feb 5 13:05: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 EEA061A021C for ; Wed, 5 Feb 2014 13:05:20 -0800 (PST) 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 qOByDyLNYvmK for ; Wed, 5 Feb 2014 13:05:18 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 4771B1A020E for ; Wed, 5 Feb 2014 13:05:18 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 204052AAD0D; Wed, 5 Feb 2014 21:05:17 +0000 (UTC) Date: Wed, 5 Feb 2014 21:05:17 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140205210516.GN278@mournblade.imrryr.org> References: <20140106212911.12960.24322.idtracker@ietfa.amsl.com> <58D91468-4295-4AEB-A5F4-3C796CBF047A@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <58D91468-4295-4AEB-A5F4-3C796CBF047A@vpnc.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] I-D Action: draft-ietf-dane-smime-03.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: Wed, 05 Feb 2014 21:05:21 -0000 On Wed, Jan 08, 2014 at 07:54:26AM -0800, Paul Hoffman wrote: > > 2. a new CU value for "revoked" to indicate that this user's > > certificates have been revoked. > > We considered things like this for TLSA, and the WG seemed very > hesitant to have the DNS be used as a second, unofficial revocation > mechanism. For instance, what would it mean for the DNS to say that > an S/MIME cert is revoked, but when the user pulls a fresh CRL, > the cert isn't there? The best we might do is to have a signal for > "go refresh your revocation view" in the DNS, but that seems like > very marginal value. I strongly support Paul's comment. Unlike stale on-disk certificates held by third-parties, published DANE records (SMIMEA, TLSA, ...) are maintained by the subject's domain and can be presumed *current* when the publishing domain is not negligent. Therefore, there is no need for a fragile blacklist mechanism. The DANE data in DNSSEC is a comprehensive whitelist. Every certificate not listed in DANE is the wrong certificate, unlike CRLs DANE fails closed. When the DANE associated data published for a user is a CA that signs multiple EE certs and a particular user's keys need to be revoked, the simplest solution is to publish an EE association for that user until the revoked certificate expires. Either way there is a special EE DANE record for the user in question, but one or more valid EE certs are more useful than a list of invalid EE certs. -- Viktor. From paul.hoffman@vpnc.org Wed Feb 5 13:06:20 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 EFAB91A020A for ; Wed, 5 Feb 2014 13:06:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] 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 vRpjdZshw7sG for ; Wed, 5 Feb 2014 13:06:18 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 817771A01FC for ; Wed, 5 Feb 2014 13:06:18 -0800 (PST) Received: from [165.227.249.247] (sn80.proper.com [75.101.18.80]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.7) with ESMTP id s15KkDMe035145 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 5 Feb 2014 13:46:15 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host sn80.proper.com [75.101.18.80] claimed to be [165.227.249.247] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Paul Hoffman In-Reply-To: <5DEFF47F-6533-4F1B-8D23-216108989787@verisign.com> Date: Wed, 5 Feb 2014 13:06:15 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <03FF6C3C-0542-4D0F-97D5-1785F55D2CEF@vpnc.org> References: <20140106212911.12960.24322.idtracker@ietfa.amsl.com> <5DEFF47F-6533-4F1B-8D23-216108989787@verisign.com> To: Eric Osterweil X-Mailer: Apple Mail (2.1827) Cc: "" Subject: [dane] draft-ietf-dane-smime and certificate discovery 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, 05 Feb 2014 21:06:20 -0000 On Feb 5, 2014, at 7:17 AM, Osterweil, Eric = wrote: > Specifically, DANE is (imho) excellent example of a standard = architecture for certificate discovery using DNS. =20 As has been noted in many places over the past few decades, using the = DNS for information deliver vs. information discover are very different = things. Jakob and I have chosen to go with the standard assumption that = the DNS is for information delivery, and other protocols (these days, = mostly HTTP) can be used for information discovery. If the DANE WG wants to change this, and the IETF at large agrees, we = can certainly walk down that path, both with this document and with TLSA = itself. --Paul Hoffman= From eosterweil@verisign.com Wed Feb 5 13:19:35 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 426D71A022B for ; Wed, 5 Feb 2014 13:19:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 H3wKivzXzR1f for ; Wed, 5 Feb 2014 13:19:33 -0800 (PST) Received: from exprod6og124.obsmtp.com (exprod6og124.obsmtp.com [64.18.1.242]) by ietfa.amsl.com (Postfix) with ESMTP id 6E36E1A0234 for ; Wed, 5 Feb 2014 13:19:27 -0800 (PST) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob124.postini.com ([64.18.5.12]) with SMTP ID DSNKUvKq3pJhcG0M2IBT/T7QKyYfpJRE/HuF@postini.com; Wed, 05 Feb 2014 13:19:27 PST Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01.vcorp.ad.vrsn.com [10.173.152.255]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id s15LJP9t021375 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Feb 2014 16:19:26 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Wed, 5 Feb 2014 16:19:25 -0500 From: "Osterweil, Eric" To: Paul Hoffman Thread-Topic: draft-ietf-dane-smime and certificate discovery Thread-Index: AQHPIrYeUFxijq0eb0qd3oWTI9ga7ZqnfkgA Date: Wed, 5 Feb 2014 21:19:24 +0000 Message-ID: References: <20140106212911.12960.24322.idtracker@ietfa.amsl.com> <5DEFF47F-6533-4F1B-8D23-216108989787@verisign.com> <03FF6C3C-0542-4D0F-97D5-1785F55D2CEF@vpnc.org> In-Reply-To: <03FF6C3C-0542-4D0F-97D5-1785F55D2CEF@vpnc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-ID: <7D1EFE64C8A38C40A3AB617B70553AD5@verisign.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [dane] draft-ietf-dane-smime and certificate discovery 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, 05 Feb 2014 21:19:35 -0000 On Feb 5, 2014, at 4:06 PM, Paul Hoffman wrote: > On Feb 5, 2014, at 7:17 AM, Osterweil, Eric wro= te: >=20 >> Specifically, DANE is (imho) excellent example of a standard architectur= e for certificate discovery using DNS. =20 >=20 > As has been noted in many places over the past few decades, using the DNS= for information deliver vs. information discover are very different things= . Jakob and I have chosen to go with the standard assumption that the DNS i= s for information delivery, and other protocols (these days, mostly HTTP) c= an be used for information discovery. >=20 > If the DANE WG wants to change this, and the IETF at large agrees, we can= certainly walk down that path, both with this document and with TLSA itsel= f. Hey Paul, Thanks for the quick response. I am, however, a little puzzled by it. So,= is there some reason why these discussions here (on the WG list) are not t= he actual substance of determining what the DANE WG wants? As I understand= it (perhaps incorrectly?), we are discussing a working group document, so = discussion of its contents should be inbounds and any resulting rough WG co= nsensus should help direct its contents, no? As for the broader statement of what DNS is for, and what the IETF at large= thinks, I think perhaps you have expressed your own opinion here, and I (p= ersonally) do not agree. In my view, DNS is (very much) a resource mapping= (i.e. learning) mechanism. That's how we find routable endpoints for HTTP= . ;) Content delivery aside. I suspect you and I may actually be on the s= ame page on that one, but apparently not on the learning issue. Back to the main issue, I am following up on Scott's solicitation for discu= ssion about his proposed changes, and expressing my support for them. I ha= ve read your response to those and responded to it, and I am happy to discu= ss the technical details further. Eric= From eosterweil@verisign.com Wed Feb 5 13:30: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 D079D1A020D for ; Wed, 5 Feb 2014 13:30:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 YvEAIk6fmyZJ for ; Wed, 5 Feb 2014 13:30:36 -0800 (PST) Received: from exprod6og105.obsmtp.com (exprod6og105.obsmtp.com [64.18.1.189]) by ietfa.amsl.com (Postfix) with ESMTP id 8F81F1A01D1 for ; Wed, 5 Feb 2014 13:30:36 -0800 (PST) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob105.postini.com ([64.18.5.12]) with SMTP ID DSNKUvKteySefFyvY9NbDd2m7ra4LxJbaPzZ@postini.com; Wed, 05 Feb 2014 13:30:36 PST Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01.vcorp.ad.vrsn.com [10.173.152.255]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id s15LUZp2016187 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 5 Feb 2014 16:30:35 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Wed, 5 Feb 2014 16:30:34 -0500 From: "Osterweil, Eric" To: "" Thread-Topic: [dane] I-D Action: draft-ietf-dane-smime-03.txt Thread-Index: AQHPCyZe4iLhCQLcdU6kJvU3W3pU85p7QbWAgAAPoACALFgggIAABxEA Date: Wed, 5 Feb 2014 21:30:34 +0000 Message-ID: <24074206-D8A9-48FE-AE80-46E8C21E684A@verisign.com> References: <20140106212911.12960.24322.idtracker@ietfa.amsl.com> <58D91468-4295-4AEB-A5F4-3C796CBF047A@vpnc.org> <20140205210516.GN278@mournblade.imrryr.org> In-Reply-To: <20140205210516.GN278@mournblade.imrryr.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dane] I-D Action: draft-ietf-dane-smime-03.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: Wed, 05 Feb 2014 21:30:40 -0000 On Feb 5, 2014, at 4:05 PM, Viktor Dukhovni wrot= e: > On Wed, Jan 08, 2014 at 07:54:26AM -0800, Paul Hoffman wrote: >=20 >>> 2. a new CU value for "revoked" to indicate that this user's >>> certificates have been revoked. >>=20 >> We considered things like this for TLSA, and the WG seemed very >> hesitant to have the DNS be used as a second, unofficial revocation >> mechanism. For instance, what would it mean for the DNS to say that >> an S/MIME cert is revoked, but when the user pulls a fresh CRL, >> the cert isn't there? The best we might do is to have a signal for >> "go refresh your revocation view" in the DNS, but that seems like >> very marginal value. >=20 > I strongly support Paul's comment. Unlike stale on-disk certificates > held by third-parties, published DANE records (SMIMEA, TLSA, ...) > are maintained by the subject's domain and can be presumed *current* > when the publishing domain is not negligent. >=20 > Therefore, there is no need for a fragile blacklist mechanism. > The DANE data in DNSSEC is a comprehensive whitelist. Every > certificate not listed in DANE is the wrong certificate, unlike > CRLs DANE fails closed. Hey Viktor, So, I worry that this relies on implicit assumptions being made about proce= ssing being done on the MUA (RP) side. If something is not available in DN= S, does that mean I shouldn't use a cert I may already have in hand, I shou= ldn't fall back to AD, I shouldn't use a previously seen value, etc=85 How = do I know the domain was ever serving SMIMEA if there is nothing in there n= ow? I suppose we could conflate deauthorization of certs with revocation o= f certs. However, I was suggesting that we _could_ use this opportunity to= express an unambiguous piece of evidence that clients should use SMIMEA-pr= ocessing, and should _not_ use a specific cert (even though it may not be u= niversally revoked). > When the DANE associated data published for a user is a CA that > signs multiple EE certs and a particular user's keys need to be > revoked, the simplest solution is to publish an EE association for > that user until the revoked certificate expires. Either way there > is a special EE DANE record for the user in question, but one or > more valid EE certs are more useful than a list of invalid EE certs. As I think you said above, ``DANE records (SMIMEA, TLSA, =85) are maintaine= d by the subject's domain and can be presumed *current* when the publishing= domain is not negligent.'' I think it's a nice option to give DNS provisio= ning systems to set a flag in an RR that deauthorizes a cert w/o having to = have the CA issue a new association. Perhaps I'm off here, but it seems fa= r more complicated from an operational perspective to have to hop through a= CA and get something issued in order to deauthorize a cert rather than jus= t updating the RR, no? Eric= From viktor1dane@dukhovni.org Wed Feb 5 15:23: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 E86C41A02A1 for ; Wed, 5 Feb 2014 15:23:40 -0800 (PST) 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 0nEcxwM0p1Vj for ; Wed, 5 Feb 2014 15:23:38 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 6066B1A0275 for ; Wed, 5 Feb 2014 15:23:38 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 76DE62AAD0D; Wed, 5 Feb 2014 23:23:36 +0000 (UTC) Date: Wed, 5 Feb 2014 23:23:36 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140205232336.GO278@mournblade.imrryr.org> References: <20140106212911.12960.24322.idtracker@ietfa.amsl.com> <58D91468-4295-4AEB-A5F4-3C796CBF047A@vpnc.org> <20140205210516.GN278@mournblade.imrryr.org> <24074206-D8A9-48FE-AE80-46E8C21E684A@verisign.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <24074206-D8A9-48FE-AE80-46E8C21E684A@verisign.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] I-D Action: draft-ietf-dane-smime-03.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: Wed, 05 Feb 2014 23:23:41 -0000 On Wed, Feb 05, 2014 at 09:30:34PM +0000, Osterweil, Eric wrote: > So, I worry that this relies on implicit assumptions being made > about processing being done on the MUA (RP) side. If something is > not available in DNS, does that mean I shouldn't use a cert I may > already have in hand, I shouldn't fall back to AD, I shouldn't use > a previously seen value, etc? How do I know the domain was ever > serving SMIMEA if there is nothing in there now? I suppose we > could conflate deauthorization of certs with revocation of certs. > However, I was suggesting that we _could_ use this opportunity to > express an unambiguous piece of evidence that clients should use > SMIMEA-processing, and should _not_ use a specific cert (even though > it may not be universally revoked). Well if the DNS is not available, you won't see the DNS revocation either. So I think you're imagining a situation were a client is often disconnected, and caches certificates. In that case, I would suggest the following strategy for an SMIMEA capable MUA: Each signed message received by the MUA is initially in an unknown verificaiton state. When an SMIMEA lookup is successful, and returns a usable certificate the message is marked permanently valid (certificate valid at time of message receipt). The certificate can be cached for the shortest of the TTL of the SMIMEA RRset, the RRSIG expiration time and a configurable local cache limit (suggested default 7 days). Each new message received generates a new background attempt to determine the SMIMEA records, but if cached data is available, a cached certificate can be used (lies within RRSIG lifetime). Likewise, outgoing mail can be encrypted to a cached certificate only within its DNSSEC validity interval, but otherwise requires a new SMIMEA lookup. Basically the MUA operates with a stored (rather than in-memory) DANE RRset cache. > > When the DANE associated data published for a user is a CA that > > signs multiple EE certs and a particular user's keys need to be > > revoked, the simplest solution is to publish an EE association for > > that user until the revoked certificate expires. Either way there > > is a special EE DANE record for the user in question, but one or > > more valid EE certs are more useful than a list of invalid EE certs. > > As I think you said above, ``DANE records (SMIMEA, TLSA, ?) are > maintained by the subject's domain and can be presumed *current* > when the publishing domain is not negligent.'' I think it's a nice > option to give DNS provisioning systems to set a flag in an RR that > deauthorizes a cert w/o having to have the CA issue a new association. > Perhaps I'm off here, but it seems far more complicated from an > operational perspective to have to hop through a CA and get something > issued in order to deauthorize a cert rather than just updating > the RR, no? I don't see any reason to de-authorize by publishing a blacklist, when one can just simply stop publishing the record or replace a TA record with an EE record. -- Viktor. From paul.hoffman@vpnc.org Wed Feb 5 15:29:34 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 663C41A02D1 for ; Wed, 5 Feb 2014 15:29:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] 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 l9HUZLh4fYfq for ; Wed, 5 Feb 2014 15:29:33 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id EAF291A02C7 for ; Wed, 5 Feb 2014 15:29:32 -0800 (PST) Received: from [10.20.30.90] (50-1-98-67.dsl.dynamic.sonic.net [50.1.98.67]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.7) with ESMTP id s15N9SJ9039411 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 5 Feb 2014 16:09:29 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-67.dsl.dynamic.sonic.net [50.1.98.67] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Paul Hoffman In-Reply-To: Date: Wed, 5 Feb 2014 15:29:29 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <6F632081-95C9-4E61-831D-EAEF2ECCE08C@vpnc.org> References: <20140106212911.12960.24322.idtracker@ietfa.amsl.com> <5DEFF47F-6533-4F1B-8D23-216108989787@verisign.com> <03FF6C3C-0542-4D0F-97D5-1785F55D2CEF@vpnc.org> To: Eric Osterweil X-Mailer: Apple Mail (2.1827) Cc: "" Subject: Re: [dane] draft-ietf-dane-smime and certificate discovery 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, 05 Feb 2014 23:29:34 -0000 On Feb 5, 2014, at 1:19 PM, Osterweil, Eric = wrote: > Thanks for the quick response. I am, however, a little puzzled by it. = So, is there some reason why these discussions here (on the WG list) = are not the actual substance of determining what the DANE WG wants? As = I understand it (perhaps incorrectly?), we are discussing a working = group document, so discussion of its contents should be inbounds and any = resulting rough WG consensus should help direct its contents, no? It is often better if a WG decides on a direction, not just a specific = technology. During the TLSA discussions, there were many threads about = delivery vs. discovery, and the WG early on went for "delivery, not = discovery". As I said in the previous message, if the WG wants to = revisit that decision and goes towards "discovery", there are lots of = ways we can make TLSA and SMIMEA records have some interesting new = properties. > As for the broader statement of what DNS is for, and what the IETF at = large thinks, I think perhaps you have expressed your own opinion here, = and I (personally) do not agree. In my view, DNS is (very much) a = resource mapping (i.e. learning) mechanism. That's how we find routable = endpoints for HTTP. ;) Content delivery aside. I suspect you and I may = actually be on the same page on that one, but apparently not on the = learning issue. I'm agnostic, and am happy for this document and TLSA go whichever way = the IETF wants. However, I'm not in favor of trying to cross the line = and see if the IETF notices. > Back to the main issue, I am following up on Scott's solicitation for = discussion about his proposed changes, and expressing my support for = them. I have read your response to those and responded to it, and I am = happy to discuss the technical details further. It's not the technical issues that are important, however. So, WG: is "DNS for delivery vs. DNS for delivery and discovery" a topic = people want to revisit? --Paul Hoffman= From viktor1dane@dukhovni.org Wed Feb 5 15:50:07 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 385EF1A0220 for ; Wed, 5 Feb 2014 15:50:07 -0800 (PST) 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 FtRYNgVgT6UM for ; Wed, 5 Feb 2014 15:50:04 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 2D6E51A015A for ; Wed, 5 Feb 2014 15:50:04 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id DA0362AAD0D; Wed, 5 Feb 2014 23:50:02 +0000 (UTC) Date: Wed, 5 Feb 2014 23:50:02 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140205235002.GP278@mournblade.imrryr.org> References: <20140106212911.12960.24322.idtracker@ietfa.amsl.com> <5DEFF47F-6533-4F1B-8D23-216108989787@verisign.com> <03FF6C3C-0542-4D0F-97D5-1785F55D2CEF@vpnc.org> <6F632081-95C9-4E61-831D-EAEF2ECCE08C@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6F632081-95C9-4E61-831D-EAEF2ECCE08C@vpnc.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] draft-ietf-dane-smime and certificate discovery 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: Wed, 05 Feb 2014 23:50:07 -0000 On Wed, Feb 05, 2014 at 03:29:29PM -0800, Paul Hoffman wrote: > So, WG: is "DNS for delivery vs. DNS for delivery and discovery" > a topic people want to revisit? Since I am relatively new here, I'll ask: What is the distinction? My best guess is: - Discovery, one time lookup of data that is retained indefinitely and refreshed infrequently, in particular potentially beyond the shorter of the DNS TTL and the RRSIG expiration. - Delivery, lookup as needed with optional caching bounded by the shorter of the record TTL, the RRSIG expiration and any applicable local policy. Is that about right? If so, since TLSA in an online protocol, it seems clear that TLSA should be "delivery". For SMIMEA, the case is a bit less clear-cut. Whenever one is capable of receiving new email one is presumably online, and so receipt of associated SMIMEA records should be feasible. When composing encrypted replies one would often, but not always have a cached copy of the sender's encryption cert and one may not be online. The MUA could defer the encryption step until it is back online, but then an unencrypted copy of the message sits in the local outbox until network connectivity is restored. Otherwise, the user would have to accept the risk that the most recently cached cert is no longer valid (no way to check SMIME for a revocation either). I don't see much of a role for SMIMEA revocations in either case. Any time one can look-up a blacklist one can lookup a (possibly empty) whitelist instead. So it is not clear how "discovery" is a better protocol than delivery. Feels like printed credit card black-lists in the 70's before credit card verification went online. -- Viktor. From paul.hoffman@vpnc.org Wed Feb 5 16:34: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 72F191A0280 for ; Wed, 5 Feb 2014 16:34:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] 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 gB7p-l5AcTGP for ; Wed, 5 Feb 2014 16:34:45 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id DEA7C1A022C for ; Wed, 5 Feb 2014 16:34:44 -0800 (PST) Received: from [10.20.30.90] (50-1-98-67.dsl.dynamic.sonic.net [50.1.98.67]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.7) with ESMTP id s160Edor040904 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 5 Feb 2014 17:14:40 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-67.dsl.dynamic.sonic.net [50.1.98.67] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Paul Hoffman In-Reply-To: <20140205235002.GP278@mournblade.imrryr.org> Date: Wed, 5 Feb 2014 16:34:41 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140106212911.12960.24322.idtracker@ietfa.amsl.com> <5DEFF47F-6533-4F1B-8D23-216108989787@verisign.com> <03FF6C3C-0542-4D0F-97D5-1785F55D2CEF@vpnc.org> <6F632081-95C9-4E61-831D-EAEF2ECCE08C@vpnc.org> <20140205235002.GP278@mournblade.imrryr.org> To: "" X-Mailer: Apple Mail (2.1827) Subject: Re: [dane] draft-ietf-dane-smime and certificate discovery 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: Thu, 06 Feb 2014 00:34:46 -0000 On Feb 5, 2014, at 3:50 PM, Viktor Dukhovni = wrote: > Since I am relatively new here, I'll ask: What is the distinction? Well, that's a hard one because different people slice and dice = differently. The summary I often use is: Delivery: tell me how to use X at domain name Y Discovery: tell me whether there is service X at domain name Y Another way to do this is: Delivery: I'm pretty sure domain name Y does X: tell me what I need to = know Discovery: I want to findo out if domain name Y does X --Paul Hoffman= From viktor1dane@dukhovni.org Wed Feb 5 16:48: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 8EDDE1A0280 for ; Wed, 5 Feb 2014 16:48:38 -0800 (PST) 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 c2YD3wStU9rN for ; Wed, 5 Feb 2014 16:48:36 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 3805F1A0234 for ; Wed, 5 Feb 2014 16:48:36 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 4629C2AB20D; Thu, 6 Feb 2014 00:48:35 +0000 (UTC) Date: Thu, 6 Feb 2014 00:48:35 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140206004834.GR278@mournblade.imrryr.org> References: <20140106212911.12960.24322.idtracker@ietfa.amsl.com> <5DEFF47F-6533-4F1B-8D23-216108989787@verisign.com> <03FF6C3C-0542-4D0F-97D5-1785F55D2CEF@vpnc.org> <6F632081-95C9-4E61-831D-EAEF2ECCE08C@vpnc.org> <20140205235002.GP278@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.21 (2010-09-15) Subject: Re: [dane] draft-ietf-dane-smime and certificate discovery 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, 06 Feb 2014 00:48:38 -0000 On Wed, Feb 05, 2014 at 04:34:41PM -0800, Paul Hoffman wrote: > On Feb 5, 2014, at 3:50 PM, Viktor Dukhovni wrote: > > > Since I am relatively new here, I'll ask: What is the distinction? > > Well, that's a hard one because different people slice and dice differently. The summary I often use is: > > Delivery: tell me how to use X at domain name Y > Discovery: tell me whether there is service X at domain name Y > > Another way to do this is: > > Delivery: I'm pretty sure domain name Y does X: tell me what I need to know > Discovery: I want to findo out if domain name Y does X Hmm, ... neither of these formulations talk about future behaviour. The SMTP draft I've been working on for most of the past year (with Wes) is in essence doing downgrade-resistant discovery of STARTTLS support and getting usable authentication parameters in the process. This "discovery" is performed for each and every SMTP connection. So it is "delivery" per my guess at a definition, but seemingly "discovery" under yours. So I am at a bit of a loss how the above definition of the dichotomy bears on the question of certificate revocation. If "discovery" means locate once and cache indefinitely, then revocation rears its ugly head. Otherwise, it is just about whether some bit of policy or behaviour is a-priori or based on DNS lookup and I don't see why revocation support or non-support is related to "discovery" vs. "delivery". Or is the request for CU 4 not the reason for this tangent? Are we talking about discovery vs. delivery because of the request to separate signing vs. encryption certs? If so, how does the request cross the line from "delivery" to "discovery"? -- Viktor. From paul.hoffman@vpnc.org Wed Feb 5 17:16:29 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 D41891A02E5 for ; Wed, 5 Feb 2014 17:16:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] 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 SyfLACPT1PJS for ; Wed, 5 Feb 2014 17:16:28 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id AAB581A01BC for ; Wed, 5 Feb 2014 17:16:28 -0800 (PST) Received: from [10.20.30.90] (50-1-98-67.dsl.dynamic.sonic.net [50.1.98.67]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.7) with ESMTP id s160uNwp042425 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 5 Feb 2014 17:56:25 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-67.dsl.dynamic.sonic.net [50.1.98.67] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Paul Hoffman In-Reply-To: <20140206004834.GR278@mournblade.imrryr.org> Date: Wed, 5 Feb 2014 17:16:25 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140106212911.12960.24322.idtracker@ietfa.amsl.com> <5DEFF47F-6533-4F1B-8D23-216108989787@verisign.com> <03FF6C3C-0542-4D0F-97D5-1785F55D2CEF@vpnc.org> <6F632081-95C9-4E61-831D-EAEF2ECCE08C@vpnc.org> <20140205235002.GP278@mournblade.imrryr.org> <20140206004834.GR278@mournblade.imrryr.org> To: "" X-Mailer: Apple Mail (2.1827) Subject: Re: [dane] draft-ietf-dane-smime and certificate discovery 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: Thu, 06 Feb 2014 01:16:30 -0000 On Feb 5, 2014, at 4:48 PM, Viktor Dukhovni = wrote: > On Wed, Feb 05, 2014 at 04:34:41PM -0800, Paul Hoffman wrote: >> On Feb 5, 2014, at 3:50 PM, Viktor Dukhovni = wrote: >>=20 >>> Since I am relatively new here, I'll ask: What is the distinction? >>=20 >> Well, that's a hard one because different people slice and dice = differently. The summary I often use is: >>=20 >> Delivery: tell me how to use X at domain name Y >> Discovery: tell me whether there is service X at domain name Y >>=20 >> Another way to do this is: >>=20 >> Delivery: I'm pretty sure domain name Y does X: tell me what I need = to know >> Discovery: I want to findo out if domain name Y does X >=20 > Hmm, ... neither of these formulations talk about future behaviour. >=20 > The SMTP draft I've been working on for most of the past year (with > Wes) is in essence doing downgrade-resistant discovery of STARTTLS > support and getting usable authentication parameters in the process. > This "discovery" is performed for each and every SMTP connection. > So it is "delivery" per my guess at a definition, but seemingly > "discovery" under yours. I bet others will say the same. However, I looked at it as "I believe = that SMTP server at domain name Y does TLS, give me its certificate". = This is the same as "I believe that HTTP server at domain name Y does = TLS, give me its certificate". This is quite different than using the DNS to determine if domain name Y = does SMTP/TLS or HTTP/TLS. That's why there are no semantics associated = with the TLSA records that say "if DANE says there is a TLS server and = you can't reach it, there is something wrong". (And, yes, my TRYTLS record proposal definitely slides right into the = discovery zone. And that's why it has gotten roundly ignored.) --Paul Hoffman= From eosterweil@verisign.com Wed Feb 5 17:50: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 B26FB1A01E0 for ; Wed, 5 Feb 2014 17:50:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 LcOsoaymql9e for ; Wed, 5 Feb 2014 17:50:41 -0800 (PST) Received: from exprod6og118.obsmtp.com (exprod6og118.obsmtp.com [64.18.1.233]) by ietfa.amsl.com (Postfix) with ESMTP id 809471A0194 for ; Wed, 5 Feb 2014 17:50:40 -0800 (PST) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob118.postini.com ([64.18.5.12]) with SMTP ID DSNKUvLqb4Ed9q+xJqKaiPLxTF63ZXZ2H0dP@postini.com; Wed, 05 Feb 2014 17:50:40 PST Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02.vcorp.ad.vrsn.com [10.173.152.206]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id s161oc30028562 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Feb 2014 20:50:38 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Wed, 5 Feb 2014 20:50:38 -0500 From: "Osterweil, Eric" To: Paul Hoffman Thread-Topic: [dane] draft-ietf-dane-smime and certificate discovery Thread-Index: AQHPIrYeUFxijq0eb0qd3oWTI9ga7ZqnfkgAgAAkWICAACdtAA== Date: Thu, 6 Feb 2014 01:50:37 +0000 Message-ID: <3DF5DF99-1550-4E69-AC0E-4E207433626B@verisign.com> References: <20140106212911.12960.24322.idtracker@ietfa.amsl.com> <5DEFF47F-6533-4F1B-8D23-216108989787@verisign.com> <03FF6C3C-0542-4D0F-97D5-1785F55D2CEF@vpnc.org> <6F632081-95C9-4E61-831D-EAEF2ECCE08C@vpnc.org> In-Reply-To: <6F632081-95C9-4E61-831D-EAEF2ECCE08C@vpnc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-ID: <2BD19E260720334AAC7B01FBEB6883D0@verisign.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [dane] draft-ietf-dane-smime and certificate discovery 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: Thu, 06 Feb 2014 01:50:43 -0000 On Feb 5, 2014, at 6:29 PM, Paul Hoffman wrote: > On Feb 5, 2014, at 1:19 PM, Osterweil, Eric wro= te: >=20 >> Thanks for the quick response. I am, however, a little puzzled by it. = So, is there some reason why these discussions here (on the WG list) are no= t the actual substance of determining what the DANE WG wants? As I underst= and it (perhaps incorrectly?), we are discussing a working group document, = so discussion of its contents should be inbounds and any resulting rough WG= consensus should help direct its contents, no? >=20 > It is often better if a WG decides on a direction, not just a specific te= chnology. During the TLSA discussions, there were many threads about delive= ry vs. discovery, and the WG early on went for "delivery, not discovery". A= s I said in the previous message, if the WG wants to revisit that decision = and goes towards "discovery", there are lots of ways we can make TLSA and S= MIMEA records have some interesting new properties. Paul, I don't think we have nearly enough data points to prescribe the gene= ral principles of all DANE protocols. We have TLSA, and that is great. I = sincerely mean that, I think the TLSA work is a great step forward. Howeve= r, I also think that a starting assumption that prescribes that all DANE pr= otocols should be executed under the same pre-computed discussions as the T= LSA work is very bad for DANE. S/MIME's semantics, requirements, and usage= are different than TLS'. How different? I don't even claim to know that.= I think this line of discussion (disc vs. deliv) marginalizes the very sp= ecific issues that Scott raised and the subsequent issues that I raised. C= an we try to stay on point? >> As for the broader statement of what DNS is for, and what the IETF at la= rge thinks, I think perhaps you have expressed your own opinion here, and I= (personally) do not agree. In my view, DNS is (very much) a resource mapp= ing (i.e. learning) mechanism. That's how we find routable endpoints for H= TTP. ;) Content delivery aside. I suspect you and I may actually be on th= e same page on that one, but apparently not on the learning issue. >=20 > I'm agnostic, and am happy for this document and TLSA go whichever way th= e IETF wants. However, I'm not in favor of trying to cross the line and see= if the IETF notices. I see you keying in on words, and I worry you're objecting to phraseology r= ather than the technical issues. Would you prefer to reboot the conversati= on with more specific terminology? These issues are important, so how abou= t ``key learning.'' That is, imho, a more accurate description anyway. >> Back to the main issue, I am following up on Scott's solicitation for di= scussion about his proposed changes, and expressing my support for them. I= have read your response to those and responded to it, and I am happy to di= scuss the technical details further. >=20 > It's not the technical issues that are important, however. >=20 > So, WG: is "DNS for delivery vs. DNS for delivery and discovery" a topic = people want to revisit? No, sorry, this is not the question that I raised. I offered very specific= technical justifications for technical suggestions. Any answer to the abo= ve is not something I have raised or am discussing. Eric= From eosterweil@verisign.com Wed Feb 5 18:00: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 D9E8A1A0137 for ; Wed, 5 Feb 2014 18:00:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 hlocfXebKNgc for ; Wed, 5 Feb 2014 18:00:35 -0800 (PST) Received: from exprod6og107.obsmtp.com (exprod6og107.obsmtp.com [64.18.1.208]) by ietfa.amsl.com (Postfix) with ESMTP id 92F5F1A0207 for ; Wed, 5 Feb 2014 18:00:33 -0800 (PST) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob107.postini.com ([64.18.5.12]) with SMTP ID DSNKUvLswIDhM4Nz2QfC4Atu//PYWb8Dearv@postini.com; Wed, 05 Feb 2014 18:00:33 PST Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01.vcorp.ad.vrsn.com [10.173.152.255]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id s1620Wmj023860 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Feb 2014 21:00:32 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Wed, 5 Feb 2014 21:00:31 -0500 From: "Osterweil, Eric" To: Paul Hoffman Thread-Topic: [dane] draft-ietf-dane-smime and certificate discovery Thread-Index: AQHPIrYeUFxijq0eb0qd3oWTI9ga7ZqnfkgAgAAkWICAAAW+AIAADHmAgAAD44CAAAfGgIAADFOA Date: Thu, 6 Feb 2014 02:00:31 +0000 Message-ID: <80773717-0B0C-4D1F-BEFF-7A373A88D362@verisign.com> References: <20140106212911.12960.24322.idtracker@ietfa.amsl.com> <5DEFF47F-6533-4F1B-8D23-216108989787@verisign.com> <03FF6C3C-0542-4D0F-97D5-1785F55D2CEF@vpnc.org> <6F632081-95C9-4E61-831D-EAEF2ECCE08C@vpnc.org> <20140205235002.GP278@mournblade.imrryr.org> <20140206004834.GR278@mournblade.imrryr.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="Windows-1252" Content-ID: <19B90540FC834F4F90045BB5B840FCC4@verisign.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [dane] draft-ietf-dane-smime and certificate discovery 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: Thu, 06 Feb 2014 02:00:37 -0000 On Feb 5, 2014, at 8:16 PM, Paul Hoffman wrote: > On Feb 5, 2014, at 4:48 PM, Viktor Dukhovni wr= ote: >=20 >> On Wed, Feb 05, 2014 at 04:34:41PM -0800, Paul Hoffman wrote: >>> On Feb 5, 2014, at 3:50 PM, Viktor Dukhovni = wrote: >> Hmm, ... neither of these formulations talk about future behaviour. >>=20 >> The SMTP draft I've been working on for most of the past year (with >> Wes) is in essence doing downgrade-resistant discovery of STARTTLS >> support and getting usable authentication parameters in the process. >> This "discovery" is performed for each and every SMTP connection. >> So it is "delivery" per my guess at a definition, but seemingly >> "discovery" under yours. >=20 > I bet others will say the same. However, I looked at it as "I believe tha= t SMTP server at domain name Y does TLS, give me its certificate". This is = the same as "I believe that HTTP server at domain name Y does TLS, give me = its certificate". >=20 > This is quite different than using the DNS to determine if domain name Y = does SMTP/TLS or HTTP/TLS. That's why there are no semantics associated wit= h the TLSA records that say "if DANE says there is a TLS server and you can= 't reach it, there is something wrong". >=20 > (And, yes, my TRYTLS record proposal definitely slides right into the dis= covery zone. And that's why it has gotten roundly ignored.) I am only chiming in here to illustrate that there is unneeded polarization= in this thread: Indeed, the above conversation (which I truncated for those who may still b= e keeping an eye on this) perfectly illustrates the misalignments of my mes= sage and the subsequent messages. I never outlined discovery this way and = if that is the working definition of the word here, then a better descripti= on is needed. Key learning: how one learns the authorized key for a servic= e domain, would be more illustrative, imho. Eric PS - I hope using the term ``meta comment'' doesn't run afoul of IETF sensi= bilities=85 too soon? ;)= From eosterweil@verisign.com Wed Feb 5 18:20: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 4E5041A0266 for ; Wed, 5 Feb 2014 18:20:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 FXl7PkBGuPwB for ; Wed, 5 Feb 2014 18:20:50 -0800 (PST) Received: from exprod6og126.obsmtp.com (exprod6og126.obsmtp.com [64.18.1.77]) by ietfa.amsl.com (Postfix) with ESMTP id 4BF331A0207 for ; Wed, 5 Feb 2014 18:20:50 -0800 (PST) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob126.postini.com ([64.18.5.12]) with SMTP ID DSNKUvLxgUsj01JGWbVY6KvjsOte5hnNRG0z@postini.com; Wed, 05 Feb 2014 18:20:49 PST Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01.vcorp.ad.vrsn.com [10.173.152.255]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id s162KmcC024415 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 5 Feb 2014 21:20:48 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Wed, 5 Feb 2014 21:20:48 -0500 From: "Osterweil, Eric" To: "" Thread-Topic: [dane] I-D Action: draft-ietf-dane-smime-03.txt Thread-Index: AQHPCyZe4iLhCQLcdU6kJvU3W3pU85p7QbWAgAAPoACALFgggIAABxEAgAAflQCAADGBgA== Date: Thu, 6 Feb 2014 02:20:47 +0000 Message-ID: <19493552-CDFD-44D6-866A-74B3305073F1@verisign.com> References: <20140106212911.12960.24322.idtracker@ietfa.amsl.com> <58D91468-4295-4AEB-A5F4-3C796CBF047A@vpnc.org> <20140205210516.GN278@mournblade.imrryr.org> <24074206-D8A9-48FE-AE80-46E8C21E684A@verisign.com> <20140205232336.GO278@mournblade.imrryr.org> In-Reply-To: <20140205232336.GO278@mournblade.imrryr.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-ID: <2F0042F570DCC34C93330B4DB87475BD@verisign.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dane] I-D Action: draft-ietf-dane-smime-03.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: Thu, 06 Feb 2014 02:20:52 -0000 On Feb 5, 2014, at 6:23 PM, Viktor Dukhovni wrot= e: > On Wed, Feb 05, 2014 at 09:30:34PM +0000, Osterweil, Eric wrote: >=20 >> So, I worry that this relies on implicit assumptions being made >> about processing being done on the MUA (RP) side. If something is >> not available in DNS, does that mean I shouldn't use a cert I may >> already have in hand, I shouldn't fall back to AD, I shouldn't use >> a previously seen value, etc? How do I know the domain was ever >> serving SMIMEA if there is nothing in there now? I suppose we >> could conflate deauthorization of certs with revocation of certs. >> However, I was suggesting that we _could_ use this opportunity to >> express an unambiguous piece of evidence that clients should use >> SMIMEA-processing, and should _not_ use a specific cert (even though >> it may not be universally revoked). >=20 > Well if the DNS is not available, you won't see the DNS revocation > either. So I think you're imagining a situation were a client is > often disconnected, and caches certificates. I didn't say DNS was unavailable. I said the RR was not available ``in DNS= .'' This is a _big_ difference, as service #3 of DNSSEC is secure denial o= f existence. > In that case, I would suggest the following strategy for an SMIMEA > capable MUA: >=20 > Each signed message received by the MUA is initially in an > unknown verificaiton state. When an SMIMEA lookup is successful, > and returns a usable certificate the message is marked permanently > valid (certificate valid at time of message receipt). The > certificate can be cached for the shortest of the TTL of the > SMIMEA RRset, the RRSIG expiration time and a configurable > local cache limit (suggested default 7 days). >=20 > Each new message received generates a new background attempt > to determine the SMIMEA records, but if cached data is available, > a cached certificate can be used (lies within RRSIG lifetime). >=20 > Likewise, outgoing mail can be encrypted to a cached certificate > only within its DNSSEC validity interval, but otherwise requires > a new SMIMEA lookup. >=20 > Basically the MUA operates with a stored (rather than in-memory) > DANE RRset cache. I think the above starts to address some concerns, but I think it sidesteps= the initial comments I made. There is a clear semantic we can relay w/ th= is new flag: ``don't use this cert for this email.'' The above seems like = it is trying to address the case where we rush to use certs while they exis= t, and restrict use after. I'm ok w/ that, but I think it leaves us with a= n inference problem instead of being specific. >> As I think you said above, ``DANE records (SMIMEA, TLSA, ?) are >> maintained by the subject's domain and can be presumed *current* >> when the publishing domain is not negligent.'' I think it's a nice >> option to give DNS provisioning systems to set a flag in an RR that >> deauthorizes a cert w/o having to have the CA issue a new association. >> Perhaps I'm off here, but it seems far more complicated from an >> operational perspective to have to hop through a CA and get something >> issued in order to deauthorize a cert rather than just updating >> the RR, no? >=20 > I don't see any reason to de-authorize by publishing a blacklist, > when one can just simply stop publishing the record or replace a > TA record with an EE record. Well, what about if I run a mail domain, I issue usage type 3 certs, I don'= t want to run a CRL or OCSP service, and I want to remove a user account fr= om my domain? =20 To be honest, I think usage type 4 would be useful, but I'll only press mor= e illustrative examples if the group wants more discussion? If no one else= thinks it's useful, so be it. However, (at a high level) I do think it is= important to point out that deauthorization is fundamentally different tha= n revocation, and OCSP/CRL services have their own warts too. Eric From viktor1dane@dukhovni.org Wed Feb 5 18:32: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 716C21A0277 for ; Wed, 5 Feb 2014 18:32:37 -0800 (PST) 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 P2ZFnhOsJPpo for ; Wed, 5 Feb 2014 18:32:35 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 923011A0207 for ; Wed, 5 Feb 2014 18:32:35 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 94D0F2AB20D; Thu, 6 Feb 2014 02:32:34 +0000 (UTC) Date: Thu, 6 Feb 2014 02:32:34 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140206023234.GS278@mournblade.imrryr.org> References: <20140106212911.12960.24322.idtracker@ietfa.amsl.com> <58D91468-4295-4AEB-A5F4-3C796CBF047A@vpnc.org> <20140205210516.GN278@mournblade.imrryr.org> <24074206-D8A9-48FE-AE80-46E8C21E684A@verisign.com> <20140205232336.GO278@mournblade.imrryr.org> <19493552-CDFD-44D6-866A-74B3305073F1@verisign.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <19493552-CDFD-44D6-866A-74B3305073F1@verisign.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] I-D Action: draft-ietf-dane-smime-03.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, 06 Feb 2014 02:32:37 -0000 On Thu, Feb 06, 2014 at 02:20:47AM +0000, Osterweil, Eric wrote: > > I don't see any reason to de-authorize by publishing a blacklist, > > when one can just simply stop publishing the record or replace a > > TA record with an EE record. > > Well, what about if I run a mail domain, I issue usage type 3 > certs, I don't want to run a CRL or OCSP service, and I want to > remove a user account from my domain? An EE cert per user is fine. Just remove the EE cert in question from the list of certificates associated with the user. The certificate is then no longer valid for signing new mail or for encrypting new mail addressed to the user. You're getting at a basic semantic question. Does an SMIMEA record publish ALL presently valid certificates for a user (a white-list that fails closed, so blacklists are redundant), or only SOME of the valid certificates, in which case one might conceivably want explicit revocation... My vote is for ALL. -- Viktor. From paul@cypherpunks.ca Wed Feb 5 19:56: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 800001A036E for ; Wed, 5 Feb 2014 19:56:56 -0800 (PST) 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 ZKGSjc4qqaVW for ; Wed, 5 Feb 2014 19:56:54 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id CD4A11A036D for ; Wed, 5 Feb 2014 19:56:54 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id A32A780091 for ; Wed, 5 Feb 2014 22:56:52 -0500 (EST) Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s163uqZL006026 for ; Wed, 5 Feb 2014 22:56:52 -0500 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Wed, 5 Feb 2014 22:56:52 -0500 (EST) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: dane WG list In-Reply-To: <20140205210516.GN278@mournblade.imrryr.org> Message-ID: References: <20140106212911.12960.24322.idtracker@ietfa.amsl.com> <58D91468-4295-4AEB-A5F4-3C796CBF047A@vpnc.org> <20140205210516.GN278@mournblade.imrryr.org> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Subject: Re: [dane] I-D Action: draft-ietf-dane-smime-03.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: Thu, 06 Feb 2014 03:56:56 -0000 On Wed, 5 Feb 2014, Viktor Dukhovni wrote: > I strongly support Paul's comment. Unlike stale on-disk certificates > held by third-parties, published DANE records (SMIMEA, TLSA, ...) > are maintained by the subject's domain and can be presumed *current* > when the publishing domain is not negligent. > > Therefore, there is no need for a fragile blacklist mechanism. > The DANE data in DNSSEC is a comprehensive whitelist. Every > certificate not listed in DANE is the wrong certificate, unlike > CRLs DANE fails closed. +1 Any application caching DNS data beyond the TTL should either forget the data, or prompt the user. Adding more bells and whistles in DNS to emulate X.509 offline properties are not appropriate for DNS. Paul From ajs@anvilwalrusden.com Wed Feb 5 20:23:15 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 84A741A0277 for ; Wed, 5 Feb 2014 20:23:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.141 X-Spam-Level: X-Spam-Status: No, score=-0.141 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] 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 elj8xKYkGpsx for ; Wed, 5 Feb 2014 20:23:14 -0800 (PST) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 9EFDD1A0022 for ; Wed, 5 Feb 2014 20:23:14 -0800 (PST) Received: from mx1.yitter.info (c-75-69-155-67.hsd1.nh.comcast.net [75.69.155.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 7ACEB8A031 for ; Thu, 6 Feb 2014 04:23:13 +0000 (UTC) Date: Wed, 5 Feb 2014 23:23:11 -0500 From: Andrew Sullivan To: dane@ietf.org Message-ID: <20140206042311.GF21114@mx1.yitter.info> References: <20140106212911.12960.24322.idtracker@ietfa.amsl.com> <58D91468-4295-4AEB-A5F4-3C796CBF047A@vpnc.org> <20140205210516.GN278@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.21 (2010-09-15) Subject: Re: [dane] I-D Action: draft-ietf-dane-smime-03.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: Thu, 06 Feb 2014 04:23:15 -0000 On Wed, Feb 05, 2014 at 10:56:52PM -0500, Paul Wouters wrote: > Any application caching DNS data beyond the TTL should either forget the > data, or prompt the user. Pray tell, how does the application learn the TTL? What if it doesn't, and guesses wrong? A -- Andrew Sullivan ajs@anvilwalrusden.com From viktor1dane@dukhovni.org Wed Feb 5 20:31: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 419EB1A0277 for ; Wed, 5 Feb 2014 20:31:42 -0800 (PST) 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 pMGJGcmmj0eO for ; Wed, 5 Feb 2014 20:31:40 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 4C8A11A022B for ; Wed, 5 Feb 2014 20:31:40 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 935452AB243; Thu, 6 Feb 2014 04:31:38 +0000 (UTC) Date: Thu, 6 Feb 2014 04:31:38 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140206043138.GT278@mournblade.imrryr.org> References: <20140106212911.12960.24322.idtracker@ietfa.amsl.com> <58D91468-4295-4AEB-A5F4-3C796CBF047A@vpnc.org> <20140205210516.GN278@mournblade.imrryr.org> <20140206042311.GF21114@mx1.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140206042311.GF21114@mx1.yitter.info> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] I-D Action: draft-ietf-dane-smime-03.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, 06 Feb 2014 04:31:42 -0000 On Wed, Feb 05, 2014 at 11:23:11PM -0500, Andrew Sullivan wrote: > Pray tell, how does the application learn the TTL? What if it > doesn't, and guesses wrong? I must plead ignorance of the obstacle, what do you have in mind? If learning DNS TTLs along with the RRset data is problematic, application caches should have reasonably short maximum lifetimes. For an MUA caching an SMIMEA certificate, probably on the order of 7days or less. This is substantially shorter than typical PKIX certificate lifetimes and commensurate with say typical Kerberos ticket renewal lifetimes (another form of short term cached credentials). -- Viktor. From ajs@anvilwalrusden.com Wed Feb 5 20:44:45 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 C22B81A0367 for ; Wed, 5 Feb 2014 20:44:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.141 X-Spam-Level: X-Spam-Status: No, score=-0.141 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] 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 Z3k8m6TKfS0J for ; Wed, 5 Feb 2014 20:44:44 -0800 (PST) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 7410D1A0365 for ; Wed, 5 Feb 2014 20:44:44 -0800 (PST) Received: from mx1.yitter.info (c-75-69-155-67.hsd1.nh.comcast.net [75.69.155.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 22BE08A031 for ; Thu, 6 Feb 2014 04:44:43 +0000 (UTC) Date: Wed, 5 Feb 2014 23:44:40 -0500 From: Andrew Sullivan To: dane@ietf.org Message-ID: <20140206044440.GI21114@mx1.yitter.info> References: <20140106212911.12960.24322.idtracker@ietfa.amsl.com> <58D91468-4295-4AEB-A5F4-3C796CBF047A@vpnc.org> <20140205210516.GN278@mournblade.imrryr.org> <20140206042311.GF21114@mx1.yitter.info> <20140206043138.GT278@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140206043138.GT278@mournblade.imrryr.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] I-D Action: draft-ietf-dane-smime-03.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: Thu, 06 Feb 2014 04:44:46 -0000 On Thu, Feb 06, 2014 at 04:31:38AM +0000, Viktor Dukhovni wrote: > I must plead ignorance of the obstacle, what do you have in mind? I am repeatedly informed by my man pages, RFC 3493, and every web browser implementer I've ever spoken to that getting the TTL on an RR coming to you from the system resolver is hard. I'd be more delighted than I can express to be misinformed, so if you know otherwise please say so. There is a new API (more a meta-api) that Paul Hoffman worked on (http://www.vpnc.org/getdns-api/) that I think we should all embrace partly for the above reason, but we're not even at 0-day with that yet AFAICT. > If learning DNS TTLs along with the RRset data is problematic, > application caches should have reasonably short maximum lifetimes. I recognise the basic impulse in what you're saying, but it gives me pause. Timing attacks involving DNS and the browser "pinning" policy have always struck me as plausible (and ISTR a demonstration, but I'm darned if I can come up with it now). But using this sort of trick for actual certificate stuff appears to make the target of any pinning-timing attack more valuable. Is that a problem? (That's not a rhetorical question. I'm an idiot.) [I get your other argument about lifetimes. Not trying to ignore, just accepting.] A -- Andrew Sullivan ajs@anvilwalrusden.com From viktor1dane@dukhovni.org Wed Feb 5 20:55:28 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 2A9841A029D for ; Wed, 5 Feb 2014 20:55:28 -0800 (PST) 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 NVTNwzOGqb2g for ; Wed, 5 Feb 2014 20:55:26 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id F2E941A0277 for ; Wed, 5 Feb 2014 20:55:25 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id F0D6C2AB243; Thu, 6 Feb 2014 04:55:24 +0000 (UTC) Date: Thu, 6 Feb 2014 04:55:24 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140206045524.GU278@mournblade.imrryr.org> References: <20140106212911.12960.24322.idtracker@ietfa.amsl.com> <58D91468-4295-4AEB-A5F4-3C796CBF047A@vpnc.org> <20140205210516.GN278@mournblade.imrryr.org> <20140206042311.GF21114@mx1.yitter.info> <20140206043138.GT278@mournblade.imrryr.org> <20140206044440.GI21114@mx1.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140206044440.GI21114@mx1.yitter.info> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] I-D Action: draft-ietf-dane-smime-03.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, 06 Feb 2014 04:55:28 -0000 On Wed, Feb 05, 2014 at 11:44:40PM -0500, Andrew Sullivan wrote: > On Thu, Feb 06, 2014 at 04:31:38AM +0000, Viktor Dukhovni wrote: > > I must plead ignorance of the obstacle, what do you have in mind? > > I am repeatedly informed by my man pages, RFC 3493, and every web > browser implementer I've ever spoken to that getting the TTL on an RR > coming to you from the system resolver is hard. I'd be more delighted > than I can express to be misinformed, so if you know otherwise please > say so. All I know is that libresolv (used in Postfix) returns the TTL with each RR. This is only a single data point, so I would not be at all shocked to discover that other stub resolvers are different in this regard, just very mildly surprised. Thanks for the eye-opener. > There is a new API (more a meta-api) that Paul Hoffman worked on > (http://www.vpnc.org/getdns-api/) that I think we should all embrace > partly for the above reason, but we're not even at 0-day with that yet > AFAICT. I'll endeavor to take a look once I am not swamped trying to get the SMTP draft out the door. > > If learning DNS TTLs along with the RRset data is problematic, > > application caches should have reasonably short maximum lifetimes. > > I recognise the basic impulse in what you're saying, but it gives me > pause. Timing attacks involving DNS and the browser "pinning" policy > have always struck me as plausible (and ISTR a demonstration, but I'm > darned if I can come up with it now). But using this sort of trick > for actual certificate stuff appears to make the target of any > pinning-timing attack more valuable. Is that a problem? (That's not > a rhetorical question. I'm an idiot.) > > [I get your other argument about lifetimes. Not trying to ignore, > just accepting.] Agreed, somewheere underneath all of our security models there are basic questions like the security of a system clock aggressively synced with remote NTP servers. Ensuring integrity at boot time requires care to seed the PRNG properly, avoid clock rollback attacks, ... When designing reusable components, we can only try to do the right thing at each layer, and hope it all fits together. Building a complete secure system requires a separate big-picture analysis. -- Viktor. From marka@isc.org Wed Feb 5 21:24: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 46F2A1A0365 for ; Wed, 5 Feb 2014 21:24:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, 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 fRHGZyoO4GJS for ; Wed, 5 Feb 2014 21:23:59 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id C587A1A029D for ; Wed, 5 Feb 2014 21:23:59 -0800 (PST) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.ams1.isc.org (Postfix) with ESMTP id BA27B2383BF; Thu, 6 Feb 2014 05:23:46 +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 F0E6916000C; Thu, 6 Feb 2014 05:24:25 +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 B91C3160008; Thu, 6 Feb 2014 05:24:25 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 108C7E872C0; Thu, 6 Feb 2014 16:23:43 +1100 (EST) To: Andrew Sullivan From: Mark Andrews References: <20140106212911.12960.24322.idtracker@ietfa.amsl.com> <58D91468-4295-4AEB-A5F4-3C796CBF047A@vpnc.org> <20140205210516.GN278@mournblade.imrryr.org> <20140206042311.GF21114@mx1.yitter.info> <20140206043138.GT278@mournblade.imrryr.org> <20140206044440.GI21114@mx1.yitter.info> In-reply-to: Your message of "Wed, 05 Feb 2014 23:44:40 -0500." <20140206044440.GI21114@mx1.yitter.info> Date: Thu, 06 Feb 2014 16:23:43 +1100 Message-Id: <20140206052343.108C7E872C0@rock.dv.isc.org> Cc: dane@ietf.org Subject: Re: [dane] I-D Action: draft-ietf-dane-smime-03.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: Thu, 06 Feb 2014 05:24:01 -0000 In message <20140206044440.GI21114@mx1.yitter.info>, Andrew Sullivan writes: > On Thu, Feb 06, 2014 at 04:31:38AM +0000, Viktor Dukhovni wrote: > > I must plead ignorance of the obstacle, what do you have in mind? > > I am repeatedly informed by my man pages, RFC 3493, and every web > browser implementer I've ever spoken to that getting the TTL on an RR > coming to you from the system resolver is hard. I'd be more delighted > than I can express to be misinformed, so if you know otherwise please > say so. And I say BS. If you are using a layer above the resolver (gethostbyname, getaddrinfo) yes it may be hard but for TLSA *there is no layer above the resolver*. libresolv/libbind have provided access to the TTL since the 1980's. Even Microsoft Windows programmers don't have a excuse as DnsQuery returns the ttl in its results. http://msdn.microsoft.com/en-us/library/windows/desktop/ms682016(v=vs.85).aspx > There is a new API (more a meta-api) that Paul Hoffman worked on > (http://www.vpnc.org/getdns-api/) that I think we should all embrace > partly for the above reason, but we're not even at 0-day with that yet > AFAICT. > > > If learning DNS TTLs along with the RRset data is problematic, > > application caches should have reasonably short maximum lifetimes. > > I recognise the basic impulse in what you're saying, but it gives me > pause. Timing attacks involving DNS and the browser "pinning" policy > have always struck me as plausible (and ISTR a demonstration, but I'm > darned if I can come up with it now). But using this sort of trick > for actual certificate stuff appears to make the target of any > pinning-timing attack more valuable. Is that a problem? (That's not > a rhetorical question. I'm an idiot.) > > [I get your other argument about lifetimes. Not trying to ignore, > just accepting.] > > A > > -- > Andrew Sullivan > ajs@anvilwalrusden.com > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From marka@isc.org Wed Feb 5 21:44: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 38FDD1A02B2 for ; Wed, 5 Feb 2014 21:44:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.515 X-Spam-Level: X-Spam-Status: No, score=-1.515 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MISSING_HEADERS=1.021, RP_MATCHES_RCVD=-0.535, 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 6XuWrW9RNX2Q for ; Wed, 5 Feb 2014 21:44:29 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 063BF1A01A9 for ; Wed, 5 Feb 2014 21:44:29 -0800 (PST) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id DE0B9C94AC; Thu, 6 Feb 2014 05:44:15 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1391665468; bh=etCakLgonVhJq4h/kc+Xuac4kKQNzT38TUx/diXhmwI=; h=Cc:From:Subject:In-reply-to:Date; b=UnVC6Whhdz0mAoz7sHjH21nRZBYsj+J0BECb4MkClvas9f2TEMMtNIH+FFcQ5IgpE AcEAcuSCjJXHZ9xy4sBOzzE/A4WRj3sTk7b+hlpmvXNh2PHQQ/dJN+HRNNq57zDSEs ctvwOlFK8R/1mY3O50CH9QzAvVwFAXI86lXtcjLg= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Thu, 6 Feb 2014 05:44: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 A3F9E16000C; Thu, 6 Feb 2014 05:44:55 +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 71133160008; Thu, 6 Feb 2014 05:44:55 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 84BC0E8798A; Thu, 6 Feb 2014 16:44:13 +1100 (EST) From: Mark Andrews In-reply-to: Your message of "Thu, 06 Feb 2014 16:23:43 +1100." Date: Thu, 06 Feb 2014 16:44:13 +1100 Message-Id: <20140206054413.84BC0E8798A@rock.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: dane@ietf.org Subject: Re: [dane] I-D Action: draft-ietf-dane-smime-03.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: Thu, 06 Feb 2014 05:44:30 -0000 Mark Andrews writes: > > In message <20140206044440.GI21114@mx1.yitter.info>, Andrew Sullivan writes: > > On Thu, Feb 06, 2014 at 04:31:38AM +0000, Viktor Dukhovni wrote: > > > I must plead ignorance of the obstacle, what do you have in mind? > > > > I am repeatedly informed by my man pages, RFC 3493, and every web > > browser implementer I've ever spoken to that getting the TTL on an RR > > coming to you from the system resolver is hard. I'd be more delighted > > than I can express to be misinformed, so if you know otherwise please > > say so. > > And I say BS. If you are using a layer above the resolver > (gethostbyname, getaddrinfo) yes it may be hard but for TLSA *there > is no layer above the resolver*. > > libresolv/libbind have provided access to the TTL since the 1980's. > > Even Microsoft Windows programmers don't have a excuse as DnsQuery > returns the ttl in its results. > > http://msdn.microsoft.com/en-us/library/windows/desktop/ms682016(v=vs.85).asp > x And as for getaddrinfo/RFC 3493, the api was designed to be extendable. We should just extend it to return the ttl. Something like the following would do. e.g. In struct addrinfo { int ai_flags; /* AI_PASSIVE, AI_CANONNAME, AI_NUMERICHOST, .. */ int ai_family; /* AF_xxx */ int ai_socktype; /* SOCK_xxx */ int ai_protocol; /* 0 or IPPROTO_xxx for IPv4 and IPv6 */ socklen_t ai_addrlen; /* length of ai_addr */ char *ai_canonname; /* canonical name for nodename */ struct sockaddr *ai_addr; /* binary address */ struct addrinfo *ai_next; /* next structure in linked list */ /* RFC XXXX */ #define AI_TTL 1 #define AI_NOTTL 0xffffffffu /* No TTL available */ unsigned int ai_ttl; /* DNS TTL */ }; In the application unsigned int ttl; #ifdef AI_TTL if (addrinfo->ai_ttl == AI_NOTTL) ttl = addrinfo->ai_ttl; else #else ttl = 0; #endif Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From viktor1dane@dukhovni.org Thu Feb 6 06:16:23 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 97C651A0116 for ; Thu, 6 Feb 2014 06:16:22 -0800 (PST) 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 l8QITCIfKNld for ; Thu, 6 Feb 2014 06:16:18 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id AD3921A012E for ; Thu, 6 Feb 2014 06:16:18 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 869EA2AB23D; Thu, 6 Feb 2014 14:16:15 +0000 (UTC) Date: Thu, 6 Feb 2014 14:16:15 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140206141615.GW278@mournblade.imrryr.org> References: <20140106212911.12960.24322.idtracker@ietfa.amsl.com> <58D91468-4295-4AEB-A5F4-3C796CBF047A@vpnc.org> <20140205210516.GN278@mournblade.imrryr.org> <20140206042311.GF21114@mx1.yitter.info> <20140206043138.GT278@mournblade.imrryr.org> <20140206044440.GI21114@mx1.yitter.info> <20140206045524.GU278@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140206045524.GU278@mournblade.imrryr.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] I-D Action: draft-ietf-dane-smime-03.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, 06 Feb 2014 14:16:23 -0000 On Thu, Feb 06, 2014 at 04:55:24AM +0000, Viktor Dukhovni wrote: > All I know is that libresolv (used in Postfix) returns the TTL with > each RR. This is only a single data point, so I would not be at all > shocked to discover that other stub resolvers are different in this > regard, just very mildly surprised. OK, I also used the DNS client library in Python once for SRV record lookups, and this too returned TTLs. Independently of Mark (who beat me to the punch with a more foreceful objection), I was also wondering whether perhaps you're misremembering the issue. Without DANE, browsers have no need for explicit DNS lookups, they just lookup network address information via getaddrinfo() and friends. So perhaps the issue you had in mind was that getaddrinfo() returns no TTLs and no validation status. This is a well known limitation. Once applications are doing explicit DNS lookups (SRV, TLSA, ...) perhaps TTLs are generally available along with the RRDATA. -- Viktor. From todd.larsen@nist.gov Thu Feb 6 07:37: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 B07D41A03CE for ; Thu, 6 Feb 2014 07:37:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_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 LpHHsyZ0xzJK for ; Thu, 6 Feb 2014 07:37:01 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0235.outbound.protection.outlook.com [207.46.163.235]) by ietfa.amsl.com (Postfix) with ESMTP id 19A5F1A01E8 for ; Thu, 6 Feb 2014 07:37:01 -0800 (PST) Received: from BY2PR09MB029.namprd09.prod.outlook.com (10.242.35.139) by BY2PR09MB030.namprd09.prod.outlook.com (10.242.35.148) with Microsoft SMTP Server (TLS) id 15.0.868.8; Thu, 6 Feb 2014 15:36:58 +0000 Received: from BY2PR09MB029.namprd09.prod.outlook.com ([169.254.8.238]) by BY2PR09MB029.namprd09.prod.outlook.com ([169.254.8.162]) with mapi id 15.00.0868.013; Thu, 6 Feb 2014 15:36:58 +0000 From: "Larsen, Todd" To: "'dane@ietf.org'" Thread-Topic: [dane] I-D Action: draft-ietf-dane-smime-03.txt Thread-Index: Ac8jTSO8J4xVpEb8T/+4Q1spSDEIzA== Date: Thu, 6 Feb 2014 15:36:57 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.6.140.15] x-forefront-prvs: 0114FF88F6 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(377454003)(199002)(189002)(51704005)(24454002)(13464003)(56776001)(54356001)(31966008)(54316002)(94316002)(49866001)(46102001)(74876001)(53806001)(50986001)(47976001)(66066001)(74706001)(81342001)(51856001)(47736001)(94946001)(69226001)(74502001)(47446002)(76482001)(74662001)(4396001)(86362001)(93136001)(76176001)(80976001)(81816001)(15975445006)(90146001)(59766001)(77982001)(2656002)(74366001)(93516002)(76786001)(65816001)(19580395003)(19580405001)(85306002)(81686001)(81542001)(80022001)(76796001)(56816005)(74316001)(63696002)(77096001)(79102001)(85852003)(76576001)(92566001)(87936001)(83322001)(33646001)(95416001)(87266001)(83072002)(24736002)(491001); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR09MB030; H:BY2PR09MB029.namprd09.prod.outlook.com; CLIP:129.6.140.15; FPR:2E57F107.A3F6974A.7E5DBDA7.46E4C94D.2057D; InfoNoRecordsA:1; MX:1; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-Mailman-Approved-At: Thu, 06 Feb 2014 08:02:36 -0800 Subject: Re: [dane] I-D Action: draft-ietf-dane-smime-03.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: Thu, 06 Feb 2014 15:38:01 -0000 QWdyZWVpbmcgd2l0aCBFcmljJ3MgcG9pbnQgdG8gZW5zdXJlIHRoZSBVQyA0IGRpc2N1c3Npb24g ZG9lc24ndCBmb2N1cyBvbiBjZXJ0aWZpY2F0ZSByZXZvY2F0aW9uLiANCg0KVXNlIGNhc2UgNCBm b3IgU01JTUVBIGRvZXMgbm90IHJldm9rZSBhIGNlcnRpZmljYXRlLiBSYXRoZXIsIHRoZSBkb21h aW4gcmV2b2tlcyBhbiBTL01JTUUgdXNlci4gSW4gY29udHJhc3QgdG8gYW55IGV2aWRlbmNlIHRo ZSB1c2VyIGhhcyB0byBjbGFpbSBhc3NvY2lhdGlvbiwgdGhlIGRvbWFpbiBpcyBwb3NpdGl2ZWx5 IHN0YXRpbmcgdGhhdCB1c2VyIFggaXMgbm90IHZhbGlkIGZvciBTTUlNRSBhcHBsaWNhdGlvbnMu IEkgY29uc2lkZXIgdGhhdCBzdWJzdGFudGlhbGx5IGRpZmZlcmVudCBmcm9tIHRoZSBhYnNlbmNl IG9mIGEgREFORSByZWNvcmQgKG9yIGFkZGl0aW9uIG9mIGEgYm9ndXMgcmVjb3JkIHRvIGZvcmNl IHZhbGlkYXRpb24gZmFpbHVyZSkuIA0KDQpXRyBjYW4gZGVjaWRlIG9uIHRoZSBtZXJpdHMuDQoN ClRvZGQNCg0KLS0tLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLS0tLQ0KU3ViamVjdDogUmU6 IFtkYW5lXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWRhbmUtc21pbWUtMDMudHh0DQpGcm9tOiAi T3N0ZXJ3ZWlsLCBFcmljIiA8ZW9zdGVyd2VpbEB2ZXJpc2lnbi5jb20+DQpEYXRlOiBXZWQsIEZl YnJ1YXJ5IDA1LCAyMDE0IDk6MjAgcG0NClRvOiAiPGRhbmVAaWV0Zi5vcmc+IiA8ZGFuZUBpZXRm Lm9yZz4NCg0KDQpPbiBGZWIgNSwgMjAxNCwgYXQgNjoyMyBQTSwgVmlrdG9yIER1a2hvdm5pIDx2 aWt0b3IxZGFuZUBkdWtob3ZuaS5vcmc+DQp3cm90ZToNCg0KPiBPbiBXZWQsIEZlYiAwNSwgMjAx NCBhdCAwOTozMDozNFBNICswMDAwLCBPc3RlcndlaWwsIEVyaWMgd3JvdGU6DQo+IA0KPj4gU28s IEkgd29ycnkgdGhhdCB0aGlzIHJlbGllcyBvbiBpbXBsaWNpdCBhc3N1bXB0aW9ucyBiZWluZyBt YWRlIGFib3V0IA0KPj4gcHJvY2Vzc2luZyBiZWluZyBkb25lIG9uIHRoZSBNVUEgKFJQKSBzaWRl LiBJZiBzb21ldGhpbmcgaXMgbm90IA0KPj4gYXZhaWxhYmxlIGluIEROUywgZG9lcyB0aGF0IG1l YW4gSSBzaG91bGRuJ3QgdXNlIGEgY2VydCBJIG1heSBhbHJlYWR5IA0KPj4gaGF2ZSBpbiBoYW5k LCBJIHNob3VsZG4ndCBmYWxsIGJhY2sgdG8gQUQsIEkgc2hvdWxkbid0IHVzZSBhIA0KPj4gcHJl dmlvdXNseSBzZWVuIHZhbHVlLCBldGM/IEhvdyBkbyBJIGtub3cgdGhlIGRvbWFpbiB3YXMgZXZl ciBzZXJ2aW5nIA0KPj4gU01JTUVBIGlmIHRoZXJlIGlzIG5vdGhpbmcgaW4gdGhlcmUgbm93PyBJ IHN1cHBvc2Ugd2UgY291bGQgY29uZmxhdGUgDQo+PiBkZWF1dGhvcml6YXRpb24gb2YgY2VydHMg d2l0aCByZXZvY2F0aW9uIG9mIGNlcnRzLg0KPj4gSG93ZXZlciwgSSB3YXMgc3VnZ2VzdGluZyB0 aGF0IHdlIF9jb3VsZF8gdXNlIHRoaXMgb3Bwb3J0dW5pdHkgdG8gDQo+PiBleHByZXNzIGFuIHVu YW1iaWd1b3VzIHBpZWNlIG9mIGV2aWRlbmNlIHRoYXQgY2xpZW50cyBzaG91bGQgdXNlIA0KPj4g U01JTUVBLXByb2Nlc3NpbmcsIGFuZCBzaG91bGQgX25vdF8gdXNlIGEgc3BlY2lmaWMgY2VydCAo ZXZlbiB0aG91Z2ggDQo+PiBpdCBtYXkgbm90IGJlIHVuaXZlcnNhbGx5IHJldm9rZWQpLg0KPiAN Cj4gV2VsbCBpZiB0aGUgRE5TIGlzIG5vdCBhdmFpbGFibGUsIHlvdSB3b24ndCBzZWUgdGhlIERO UyByZXZvY2F0aW9uIA0KPiBlaXRoZXIuIFNvIEkgdGhpbmsgeW91J3JlIGltYWdpbmluZyBhIHNp dHVhdGlvbiB3ZXJlIGEgY2xpZW50IGlzIG9mdGVuIA0KPiBkaXNjb25uZWN0ZWQsIGFuZCBjYWNo ZXMgY2VydGlmaWNhdGVzLg0KDQpJIGRpZG4ndCBzYXkgRE5TIHdhcyB1bmF2YWlsYWJsZS4gSSBz YWlkIHRoZSBSUiB3YXMgbm90IGF2YWlsYWJsZSBgYGluIEROUy4nJyBUaGlzIGlzIGEgX2JpZ18g ZGlmZmVyZW5jZSwgYXMgc2VydmljZSAjMyBvZiBETlNTRUMgaXMgc2VjdXJlIGRlbmlhbCBvZiBl eGlzdGVuY2UuDQoNCj4gSW4gdGhhdCBjYXNlLCBJIHdvdWxkIHN1Z2dlc3QgdGhlIGZvbGxvd2lu ZyBzdHJhdGVneSBmb3IgYW4gU01JTUVBIA0KPiBjYXBhYmxlIE1VQToNCj4gDQo+IEVhY2ggc2ln bmVkIG1lc3NhZ2UgcmVjZWl2ZWQgYnkgdGhlIE1VQSBpcyBpbml0aWFsbHkgaW4gYW4gdW5rbm93 biANCj4gdmVyaWZpY2FpdG9uIHN0YXRlLiBXaGVuIGFuIFNNSU1FQSBsb29rdXAgaXMgc3VjY2Vz c2Z1bCwgYW5kIHJldHVybnMgYSANCj4gdXNhYmxlIGNlcnRpZmljYXRlIHRoZSBtZXNzYWdlIGlz IG1hcmtlZCBwZXJtYW5lbnRseSB2YWxpZCANCj4gKGNlcnRpZmljYXRlIHZhbGlkIGF0IHRpbWUg b2YgbWVzc2FnZSByZWNlaXB0KS4gVGhlIGNlcnRpZmljYXRlIGNhbiBiZSANCj4gY2FjaGVkIGZv ciB0aGUgc2hvcnRlc3Qgb2YgdGhlIFRUTCBvZiB0aGUgU01JTUVBIFJSc2V0LCB0aGUgUlJTSUcg DQo+IGV4cGlyYXRpb24gdGltZSBhbmQgYSBjb25maWd1cmFibGUgbG9jYWwgY2FjaGUgbGltaXQg KHN1Z2dlc3RlZCANCj4gZGVmYXVsdCA3IGRheXMpLg0KPiANCj4gRWFjaCBuZXcgbWVzc2FnZSBy ZWNlaXZlZCBnZW5lcmF0ZXMgYSBuZXcgYmFja2dyb3VuZCBhdHRlbXB0IHRvIA0KPiBkZXRlcm1p bmUgdGhlIFNNSU1FQSByZWNvcmRzLCBidXQgaWYgY2FjaGVkIGRhdGEgaXMgYXZhaWxhYmxlLCBh IA0KPiBjYWNoZWQgY2VydGlmaWNhdGUgY2FuIGJlIHVzZWQgKGxpZXMgd2l0aGluIFJSU0lHIGxp ZmV0aW1lKS4NCj4gDQo+IExpa2V3aXNlLCBvdXRnb2luZyBtYWlsIGNhbiBiZSBlbmNyeXB0ZWQg dG8gYSBjYWNoZWQgY2VydGlmaWNhdGUgb25seSANCj4gd2l0aGluIGl0cyBETlNTRUMgdmFsaWRp dHkgaW50ZXJ2YWwsIGJ1dCBvdGhlcndpc2UgcmVxdWlyZXMgYSBuZXcgDQo+IFNNSU1FQSBsb29r dXAuDQo+IA0KPiBCYXNpY2FsbHkgdGhlIE1VQSBvcGVyYXRlcyB3aXRoIGEgc3RvcmVkIChyYXRo ZXIgdGhhbiBpbi1tZW1vcnkpIERBTkUgDQo+IFJSc2V0IGNhY2hlLg0KDQpJIHRoaW5rIHRoZSBh Ym92ZSBzdGFydHMgdG8gYWRkcmVzcyBzb21lIGNvbmNlcm5zLCBidXQgSSB0aGluayBpdCBzaWRl c3RlcHMgdGhlIGluaXRpYWwgY29tbWVudHMgSSBtYWRlLiBUaGVyZSBpcyBhIGNsZWFyIHNlbWFu dGljIHdlIGNhbiByZWxheSB3LyB0aGlzIG5ldyBmbGFnOiBgYGRvbid0IHVzZSB0aGlzIGNlcnQg Zm9yIHRoaXMgZW1haWwuJycgVGhlIGFib3ZlIHNlZW1zIGxpa2UgaXQgaXMgdHJ5aW5nIHRvIGFk ZHJlc3MgdGhlIGNhc2Ugd2hlcmUgd2UgcnVzaCB0byB1c2UgY2VydHMgd2hpbGUgdGhleSBleGlz dCwgYW5kIHJlc3RyaWN0IHVzZSBhZnRlci4gSSdtIG9rIHcvIHRoYXQsIGJ1dCBJIHRoaW5rIGl0 IGxlYXZlcyB1cyB3aXRoIGFuIGluZmVyZW5jZSBwcm9ibGVtIGluc3RlYWQgb2YgYmVpbmcgc3Bl Y2lmaWMuDQoNCjxzbmlwPg0KDQo+PiBBcyBJIHRoaW5rIHlvdSBzYWlkIGFib3ZlLCBgYERBTkUg cmVjb3JkcyAoU01JTUVBLCBUTFNBLCA/KSBhcmUgDQo+PiBtYWludGFpbmVkIGJ5IHRoZSBzdWJq ZWN0J3MgZG9tYWluIGFuZCBjYW4gYmUgcHJlc3VtZWQgKmN1cnJlbnQqIHdoZW4gDQo+PiB0aGUg cHVibGlzaGluZyBkb21haW4gaXMgbm90IG5lZ2xpZ2VudC4nJyBJIHRoaW5rIGl0J3MgYSBuaWNl IG9wdGlvbiANCj4+IHRvIGdpdmUgRE5TIHByb3Zpc2lvbmluZyBzeXN0ZW1zIHRvIHNldCBhIGZs YWcgaW4gYW4gUlIgdGhhdCANCj4+IGRlYXV0aG9yaXplcyBhIGNlcnQgdy9vIGhhdmluZyB0byBo YXZlIHRoZSBDQSBpc3N1ZSBhIG5ldyBhc3NvY2lhdGlvbi4NCj4+IFBlcmhhcHMgSSdtIG9mZiBo ZXJlLCBidXQgaXQgc2VlbXMgZmFyIG1vcmUgY29tcGxpY2F0ZWQgZnJvbSBhbiANCj4+IG9wZXJh dGlvbmFsIHBlcnNwZWN0aXZlIHRvIGhhdmUgdG8gaG9wIHRocm91Z2ggYSBDQSBhbmQgZ2V0IHNv bWV0aGluZyANCj4+IGlzc3VlZCBpbiBvcmRlciB0byBkZWF1dGhvcml6ZSBhIGNlcnQgcmF0aGVy IHRoYW4ganVzdCB1cGRhdGluZyB0aGUgDQo+PiBSUiwgbm8/DQo+IA0KPiBJIGRvbid0IHNlZSBh bnkgcmVhc29uIHRvIGRlLWF1dGhvcml6ZSBieSBwdWJsaXNoaW5nIGEgYmxhY2tsaXN0LCB3aGVu IA0KPiBvbmUgY2FuIGp1c3Qgc2ltcGx5IHN0b3AgcHVibGlzaGluZyB0aGUgcmVjb3JkIG9yIHJl cGxhY2UgYSBUQSByZWNvcmQgDQo+IHdpdGggYW4gRUUgcmVjb3JkLg0KDQpXZWxsLCB3aGF0IGFi b3V0IGlmIEkgcnVuIGEgbWFpbCBkb21haW4sIEkgaXNzdWUgdXNhZ2UgdHlwZSAzIGNlcnRzLCBJ IGRvbid0IHdhbnQgdG8gcnVuIGEgQ1JMIG9yIE9DU1Agc2VydmljZSwgYW5kIEkgd2FudCB0byBy ZW1vdmUgYSB1c2VyIGFjY291bnQgZnJvbSBteSBkb21haW4/IA0KDQpUbyBiZSBob25lc3QsIEkg dGhpbmsgdXNhZ2UgdHlwZSA0IHdvdWxkIGJlIHVzZWZ1bCwgYnV0IEknbGwgb25seSBwcmVzcyBt b3JlIGlsbHVzdHJhdGl2ZSBleGFtcGxlcyBpZiB0aGUgZ3JvdXAgd2FudHMgbW9yZSBkaXNjdXNz aW9uPyBJZiBubyBvbmUgZWxzZSB0aGlua3MgaXQncyB1c2VmdWwsIHNvIGJlIGl0LiBIb3dldmVy LCAoYXQgYSBoaWdoIGxldmVsKSBJIGRvIHRoaW5rIGl0IGlzIGltcG9ydGFudCB0byBwb2ludCBv dXQgdGhhdCBkZWF1dGhvcml6YXRpb24gaXMgZnVuZGFtZW50YWxseSBkaWZmZXJlbnQgdGhhbiBy ZXZvY2F0aW9uLCBhbmQgT0NTUC9DUkwgc2VydmljZXMgaGF2ZSB0aGVpciBvd24gd2FydHMgdG9v Lg0KDQpFcmljDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQpkYW5lIG1haWxpbmcgbGlzdA0KZGFuZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9kYW5lDQo= From viktor1dane@dukhovni.org Thu Feb 6 08:14:27 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 0A08B1A03DC for ; Thu, 6 Feb 2014 08:14:27 -0800 (PST) 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 0jZKGiqkLglE for ; Thu, 6 Feb 2014 08:14:24 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 15CA01A03DB for ; Thu, 6 Feb 2014 08:14:23 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 5BCB62AB23D; Thu, 6 Feb 2014 16:14:22 +0000 (UTC) Date: Thu, 6 Feb 2014 16:14:22 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140206161422.GZ278@mournblade.imrryr.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] I-D Action: draft-ietf-dane-smime-03.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, 06 Feb 2014 16:14:27 -0000 On Thu, Feb 06, 2014 at 03:36:57PM +0000, Larsen, Todd wrote: > Agreeing with Eric's point to ensure the UC 4 discussion doesn't > focus on certificate revocation. > > Use case 4 for SMIMEA does not revoke a certificate. Rather, the > domain revokes an S/MIME user. In contrast to any evidence the user > has to claim association, the domain is positively stating that > user X is not valid for SMIME applications. I consider that > substantially different from the absence of a DANE record (or > addition of a bogus record to force validation failure). This is problematic because I expect that SMIMEA like TLSA generally yields an RRset, not a single record. What would be the semantics of an RRset with two RRs one with CU=4 and another with CU=2? It still seems simplest to list no RRs for a user to indicate that there are no keys for that user. If CU=4 is supposed to disavow all keys for a user, what is the meaning of the selector, matching type and associated data, ... -- Viktor. From eosterweil@verisign.com Thu Feb 6 09:27: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 1E0671A0176 for ; Thu, 6 Feb 2014 09:27:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 B40sdsamKzzh for ; Thu, 6 Feb 2014 09:27:43 -0800 (PST) Received: from exprod6og109.obsmtp.com (exprod6og109.obsmtp.com [64.18.1.23]) by ietfa.amsl.com (Postfix) with ESMTP id 1D58B1A03ED for ; Thu, 6 Feb 2014 09:27:43 -0800 (PST) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob109.postini.com ([64.18.5.12]) with SMTP ID DSNKUvPGDopUmUD5hgrsqGZgl19n+tY5ba5p@postini.com; Thu, 06 Feb 2014 09:27:42 PST Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id s16HRfMl026524 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 6 Feb 2014 12:27:41 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Thu, 6 Feb 2014 12:27:41 -0500 From: "Osterweil, Eric" To: "" Thread-Topic: [dane] I-D Action: draft-ietf-dane-smime-03.txt Thread-Index: AQHPCyZe4iLhCQLcdU6kJvU3W3pU85p7QbWAgAAPoACALFgggIAAcv8AgAAHWoCAAAJdAIAAA6QAgAADAACAAJyzgIAANXsA Date: Thu, 6 Feb 2014 17:27:40 +0000 Message-ID: References: <20140106212911.12960.24322.idtracker@ietfa.amsl.com> <58D91468-4295-4AEB-A5F4-3C796CBF047A@vpnc.org> <20140205210516.GN278@mournblade.imrryr.org> <20140206042311.GF21114@mx1.yitter.info> <20140206043138.GT278@mournblade.imrryr.org> <20140206044440.GI21114@mx1.yitter.info> <20140206045524.GU278@mournblade.imrryr.org> <20140206141615.GW278@mournblade.imrryr.org> In-Reply-To: <20140206141615.GW278@mournblade.imrryr.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dane] I-D Action: draft-ietf-dane-smime-03.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: Thu, 06 Feb 2014 17:27:46 -0000 On Feb 6, 2014, at 9:16 AM, Viktor Dukhovni wrot= e: > On Thu, Feb 06, 2014 at 04:55:24AM +0000, Viktor Dukhovni wrote: >=20 >> All I know is that libresolv (used in Postfix) returns the TTL with >> each RR. This is only a single data point, so I would not be at all >> shocked to discover that other stub resolvers are different in this >> regard, just very mildly surprised. >=20 > OK, I also used the DNS client library in Python once for SRV record > lookups, and this too returned TTLs. >=20 > Independently of Mark (who beat me to the punch with a more foreceful > objection), I was also wondering whether perhaps you're misremembering > the issue. Without DANE, browsers have no need for explicit DNS > lookups, they just lookup network address information via getaddrinfo() > and friends. So perhaps the issue you had in mind was that > getaddrinfo() returns no TTLs and no validation status. This is > a well known limitation. >=20 > Once applications are doing explicit DNS lookups (SRV, TLSA, ...) > perhaps TTLs are generally available along with the RRDATA. To follow all of this up: I think Andrew was illustrating a couple of impor= tant issues, and one of them is that we cannot always all rely on full know= ledge of how people will adopt DANE processing (look at the TTL, don't look= at AD, etc.). Even if we fully specify how it should be used (only look h= ere, don't look over there, etc.), we still have to be liberal in what we a= ccept. =20 Rather than focusing narrowly on how an RP might or might not find SMIMEA R= Rs, consider an incremental deployment case whereby someone rolls _SOME_ of= their constituency over to DANE, and leaves some of their clients on (say)= AD. Now, I need my RPs (the MUAs) to know the difference between ``DANE d= oesn't want you to use a cert,`` and ``you may go find the cert somewhere e= lse.''=20 IMHO, the TTL discussion is useful because it illustrates that not everyone= will even _know_ to go looking for it, but we might want to realize that t= here are other issues we will have to confront when people consider operati= onal rollouts of this. Eric= From todd.larsen@nist.gov Thu Feb 6 09:28:58 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 EE0BB1A0145 for ; Thu, 6 Feb 2014 09:28:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_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 oT85Zdn1WLvq for ; Thu, 6 Feb 2014 09:28:55 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0211.outbound.protection.outlook.com [207.46.163.211]) by ietfa.amsl.com (Postfix) with ESMTP id DC2AE1A00F0 for ; Thu, 6 Feb 2014 09:28:54 -0800 (PST) Received: from BY2PR09MB029.namprd09.prod.outlook.com (10.242.35.139) by BY2PR09MB031.namprd09.prod.outlook.com (10.242.35.151) with Microsoft SMTP Server (TLS) id 15.0.868.8; Thu, 6 Feb 2014 17:28:52 +0000 Received: from BY2PR09MB029.namprd09.prod.outlook.com ([169.254.8.238]) by BY2PR09MB029.namprd09.prod.outlook.com ([169.254.8.162]) with mapi id 15.00.0868.013; Thu, 6 Feb 2014 17:28:51 +0000 From: "Larsen, Todd" To: "'viktor1dane@dukhovni.org'" Thread-Topic: [dane] I-D Action: draft-ietf-dane-smime-03.txt Thread-Index: Ac8jWg0qKEAZ9sLQQESqk0FDFqbpnA== Date: Thu, 6 Feb 2014 17:28:51 +0000 Message-ID: <41938fd202ba460285b59132c29ac826@BY2PR09MB029.namprd09.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.6.140.15] x-forefront-prvs: 0114FF88F6 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(199002)(189002)(51704005)(24454002)(79102001)(85852003)(56776001)(80022001)(81342001)(81542001)(83072002)(87936001)(69226001)(46102001)(90146001)(54316002)(94316002)(2656002)(51856001)(47976001)(66066001)(49866001)(4396001)(50986001)(87266001)(47736001)(86362001)(56816005)(95416001)(53806001)(74366001)(80976001)(19580395003)(15975445006)(76176001)(81816001)(85306002)(47446002)(54356001)(92566001)(74662001)(76576001)(77982001)(76786001)(59766001)(74876001)(74316001)(63696002)(94946001)(74706001)(65816001)(77096001)(83322001)(93516002)(76482001)(33646001)(74502001)(31966008)(19580405001)(93136001)(76796001)(81686001)(24736002)(491001); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR09MB031; H:BY2PR09MB029.namprd09.prod.outlook.com; CLIP:129.6.140.15; FPR:5C9CF5B7.AF268441.6ECF7FB7.4EE552FD.20339; InfoNoRecordsA:1; MX:1; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nist.gov Cc: "'dane@ietf.org'" Subject: Re: [dane] I-D Action: draft-ietf-dane-smime-03.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: Thu, 06 Feb 2014 17:28:58 -0000 VmljdG9yLA0KDQpHb29kIHF1ZXN0aW9ucy4gSGVyZSBhcmUgbXkgYW5zd2Vycy4gDQpOb3QgYWR2 b2NhdGluZyBhIHBvc2l0aW9uLg0KDQo+IE9uIFRodSwgRmViIDA2LCAyMDE0IGF0IDAzOjM2OjU3 UE0gKzAwMDAsIExhcnNlbiwgVG9kZCB3cm90ZToNCj4NCj4+IEFncmVlaW5nIHdpdGggRXJpYydz IHBvaW50IHRvIGVuc3VyZSB0aGUgVUMgNCBkaXNjdXNzaW9uIGRvZXNuJ3QgZm9jdXMgDQo+PiBv biBjZXJ0aWZpY2F0ZSByZXZvY2F0aW9uLg0KPj4gDQo+PiBVc2UgY2FzZSA0IGZvciBTTUlNRUEg ZG9lcyBub3QgcmV2b2tlIGEgY2VydGlmaWNhdGUuIFJhdGhlciwgdGhlIA0KPj4gZG9tYWluIHJl dm9rZXMgYW4gUy9NSU1FIHVzZXIuIEluIGNvbnRyYXN0IHRvIGFueSBldmlkZW5jZSB0aGUgdXNl ciANCj4+IGhhcyB0byBjbGFpbSBhc3NvY2lhdGlvbiwgdGhlIGRvbWFpbiBpcyBwb3NpdGl2ZWx5 IHN0YXRpbmcgdGhhdCB1c2VyIFggDQo+PiBpcyBub3QgdmFsaWQgZm9yIFNNSU1FIGFwcGxpY2F0 aW9ucy4gSSBjb25zaWRlciB0aGF0IHN1YnN0YW50aWFsbHkgDQo+PiBkaWZmZXJlbnQgZnJvbSB0 aGUgYWJzZW5jZSBvZiBhIERBTkUgcmVjb3JkIChvciBhZGRpdGlvbiBvZiBhIGJvZ3VzIA0KPj4g cmVjb3JkIHRvIGZvcmNlIHZhbGlkYXRpb24gZmFpbHVyZSkuDQo+DQo+VGhpcyBpcyBwcm9ibGVt YXRpYyBiZWNhdXNlIEkgZXhwZWN0IHRoYXQgU01JTUVBIGxpa2UgVExTQSBnZW5lcmFsbHkgeWll bGRzIA0KPmFuIFJSc2V0LCBub3QgYSBzaW5nbGUgcmVjb3JkLiBXaGF0IHdvdWxkIGJlIHRoZSBz ZW1hbnRpY3Mgb2YgYW4gUlJzZXQgd2l0aCANCj50d28gUlJzIG9uZSB3aXRoIENVPTQgYW5kIGFu b3RoZXIgd2l0aCBDVT0yPw0KPg0KDQpDVT00IHRydW1wcyBDVT0yLiBPdGhlciByZWNvcmRzIHBy ZXNlbnQgd2l0aCBDVT00IHdvdWxkIGNsZWFybHkgDQppbmRpY2F0ZSBhIG1pc2NvbmZpZ3VyYXRp b24sIGJ1dCBtdXN0IGJlIGFjY291bnRlZC4NCg0KVGhpcyBjb21wbGljYXRlcyB2YWxpZGF0aW9u IGxvZ2ljLiBJdCBtZWFucyBjaGVja2luZyBmb3IgQ1U9NCBpbiBlbnRpcmUgUlJTRVQgDQppbnN0 ZWFkIG9mIGRlY2xhcmluZyB2YWxpZCBvbiBmaXJzdCBtYXRjaC4NCg0KT25lIGV4YW1wbGUgb2Yg dXNlIGNvdWxkIGJlIGZvciBhIGRvbWFpbiB0byB3aWxkY2FyZCBDVT0yIHJlY29yZCBzbw0KYWxs IGNlcnRpZmljYXRlcyBzaWduZWQgYnkgdGhlIG9yZ2FuaXphdGlvbiBhcmUgY29uc2lkZXJlZCB2 YWxpZCBieSBkZWZhdWx0LiANCkRpc2FsbG93ZWQgdXNlcnMgcmVjZWl2ZSBDVT00IGZvciBsaWZl dGltZSBvZiBUQSBjZXJ0LiBOU0VDMyBtYXkgbm90IGJlIA0KbmVjZXNzYXJ5IGFzIHB1YmxpYyBr bm93bGVkZ2Ugb2YgQ1U9NCBsaXN0IG1pZ2h0IGJlIGRlc2lyYWJsZS4gDQoNCihOb3Qgc3VnZ2Vz dGluZyB0aGlzIGluIGxpZXUgb2YgQ05BTUVzIHRvIENVPTIgcmVjb3JkKHMpLCBqdXN0IHByZXNl bnRpbmcgcG9zc2libGUgdXNlIGNhc2UpDQogDQoNCj5JdCBzdGlsbCBzZWVtcyBzaW1wbGVzdCB0 byBsaXN0IG5vIFJScyBmb3IgYSB1c2VyIHRvIGluZGljYXRlIHRoYXQgdGhlcmUgYXJlIG5vIA0K PmtleXMgZm9yIHRoYXQgdXNlci4NCj4NCj5JZiBDVT00IGlzIHN1cHBvc2VkIHRvIGRpc2F2b3cg YWxsIGtleXMgZm9yIGEgdXNlciwgd2hhdCBpcyB0aGUgbWVhbmluZyBvZiB0aGUgDQo+c2VsZWN0 b3IsIG1hdGNoaW5nIHR5cGUgYW5kIGFzc29jaWF0ZWQgZGF0YSwgLi4uDQoNCnNlbGVjdG9yLCBt YXRjaGluZyB0eXBlIGFuZCBhc3NvY2lhdGVkIGRhdGEgaGF2ZSBubyBtZWFuaW5nIGZvciBDVT00 LiBUaGUgZmllbGRzDQphcmUgcHJlc2VudCBzb2xlbHkgdG8gbWFpbnRhaW4gY29uc2lzdGVuY3kg d2l0aCB0aGUgU01JTUVBIGZvcm1hdA0KDQotLQ0KIFZpa3Rvci4NCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpkYW5lIG1haWxpbmcgbGlzdA0KZGFuZUBp ZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kYW5lDQo= From viktor1dane@dukhovni.org Thu Feb 6 11:53:27 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 677AF1A03F9 for ; Thu, 6 Feb 2014 11:53:27 -0800 (PST) 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 Lv9_KIXZyItD for ; Thu, 6 Feb 2014 11:53:25 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id C00471A03ED for ; Thu, 6 Feb 2014 11:53:25 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id D253F2AB23D; Thu, 6 Feb 2014 19:53:22 +0000 (UTC) Date: Thu, 6 Feb 2014 19:53:22 +0000 From: Viktor Dukhovni To: "'dane@ietf.org'" Message-ID: <20140206195322.GD278@mournblade.imrryr.org> References: <41938fd202ba460285b59132c29ac826@BY2PR09MB029.namprd09.prod.outlook.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41938fd202ba460285b59132c29ac826@BY2PR09MB029.namprd09.prod.outlook.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] I-D Action: draft-ietf-dane-smime-03.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, 06 Feb 2014 19:53:27 -0000 On Thu, Feb 06, 2014 at 05:28:51PM +0000, Larsen, Todd wrote: > >This is problematic because I expect that SMIMEA like TLSA generally yields > >an RRset, not a single record. What would be the semantics of an RRset with > >two RRs one with CU=4 and another with CU=2? > > CU=4 trumps CU=2. Other records present with CU=4 would clearly > indicate a misconfiguration, but must be accounted. > > This complicates validation logic. It means checking for CU=4 in entire RRSET > instead of declaring valid on first match. > > selector, matching type and associated data have no meaning for > CU=4. The fields are present solely to maintain consistency with > the SMIMEA format This is IMHO an unreasonable distortion of the SMIMEA semantics. Switching gears, was any consensus reached on the endoing of the query label? A truncated HMAC seems to offer better usability than base32. I think that the specification is in good shape, modulo the query label encoding. -- Viktor. From eosterweil@verisign.com Thu Feb 6 12:17:15 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 212C81A0492 for ; Thu, 6 Feb 2014 12:17:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 sgWfQi-TYu9U for ; Thu, 6 Feb 2014 12:17:13 -0800 (PST) Received: from exprod6og102.obsmtp.com (exprod6og102.obsmtp.com [64.18.1.183]) by ietfa.amsl.com (Postfix) with ESMTP id B49F91A0473 for ; Thu, 6 Feb 2014 12:17:12 -0800 (PST) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob102.postini.com ([64.18.5.12]) with SMTP ID DSNKUvPtx0AuUWTZgm4CfBLK56y0kZhGuZyl@postini.com; Thu, 06 Feb 2014 12:17:12 PST Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01.vcorp.ad.vrsn.com [10.173.152.255]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id s16KHBEJ007091 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 6 Feb 2014 15:17:11 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Thu, 6 Feb 2014 15:17:10 -0500 From: "Osterweil, Eric" To: "" Thread-Topic: [dane] I-D Action: draft-ietf-dane-smime-03.txt Thread-Index: Ac8jWg0q4iLhCQLcdU6kJvU3W3pU8wARPKYAAADUpIA= Date: Thu, 6 Feb 2014 20:17:10 +0000 Message-ID: <62C57F51-CDB7-4784-9348-91D073103F4F@verisign.com> References: <41938fd202ba460285b59132c29ac826@BY2PR09MB029.namprd09.prod.outlook.com> <20140206195322.GD278@mournblade.imrryr.org> In-Reply-To: <20140206195322.GD278@mournblade.imrryr.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-ID: <7C4C7592CCD1A147B7C3FE93945F20F4@verisign.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dane] I-D Action: draft-ietf-dane-smime-03.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: Thu, 06 Feb 2014 20:17:15 -0000 On Feb 6, 2014, at 2:53 PM, Viktor Dukhovni wrot= e: > Switching gears, was any consensus reached on the endoing of the > query label? A truncated HMAC seems to offer better usability than > base32. I think that the specification is in good shape, modulo > the query label encoding. =20 I actually have a question on this: is there some reason we are talking abo= ut HMAC instead of just straight-up using a hashing function? iirc, hashin= g accomplishes the same goal (for us) w/o needing any secret material (proj= ecting a variable length name to a fixed length label). I'm fully willing = to believe that I might just be missing something. I mean this just as a s= imple clarification question. Thanks, Eric= From viktor1dane@dukhovni.org Thu Feb 6 12:39:33 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 4CE771A01E3 for ; Thu, 6 Feb 2014 12:39:33 -0800 (PST) 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 9caZ3gIpMv0R for ; Thu, 6 Feb 2014 12:39:31 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 1541C1A03CA for ; Thu, 6 Feb 2014 12:39:30 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id C3A1D2AB23D; Thu, 6 Feb 2014 20:39:28 +0000 (UTC) Date: Thu, 6 Feb 2014 20:39:28 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140206203928.GE278@mournblade.imrryr.org> References: <41938fd202ba460285b59132c29ac826@BY2PR09MB029.namprd09.prod.outlook.com> <20140206195322.GD278@mournblade.imrryr.org> <62C57F51-CDB7-4784-9348-91D073103F4F@verisign.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <62C57F51-CDB7-4784-9348-91D073103F4F@verisign.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] I-D Action: draft-ietf-dane-smime-03.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, 06 Feb 2014 20:39:33 -0000 On Thu, Feb 06, 2014 at 08:17:10PM +0000, Osterweil, Eric wrote: > > Switching gears, was any consensus reached on the endoing of the > > query label? A truncated HMAC seems to offer better usability than > > base32. I think that the specification is in good shape, modulo > > the query label encoding. > > I actually have a question on this: is there some reason we are > talking about HMAC instead of just straight-up using a hashing > function? iirc, hashing accomplishes the same goal (for us) w/o > needing any secret material (projecting a variable length name to > a fixed length label). I'm fully willing to believe that I might > just be missing something. I mean this just as a simple clarification > question. HMAC was proposed to *salt* the hash with a domain-specific key (namely the domain itself). The key is NOT secret, but it is distinct for every domain (encoded in punycode for IDNA domains). The reason for salting the lookup keys is to make dictionary attacks on the set of email addresses more expensive. One could even NSEC3-style require some number of iterations, but this would arguably be going too far and there is not a good way to signal to the client what the iteration count should be. Clearly any kind of one-way function is harder to brute-force invert than the trivially reversible base32. And salting makes rainbow-tables less practical. Still Bitcoin mining has led to rather fast hash dictionary attack codes, and perhaps even salted HMAC is fast enough to make DNS lookup a viable directory harvesting (via DNS lookup) attack vehicle. -- Viktor. From jakob@kirei.se Thu Feb 6 13:51: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 00BF71A0427 for ; Thu, 6 Feb 2014 13:51:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.186 X-Spam-Level: X-Spam-Status: No, score=-2.186 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, RP_MATCHES_RCVD=-0.535, 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 UXSOQfSbrcUA for ; Thu, 6 Feb 2014 13:51:34 -0800 (PST) Received: from spg.kirei.se (spg.kirei.se [IPv6:2001:67c:394:15::9]) by ietfa.amsl.com (Postfix) with ESMTP id E91C81A044D for ; Thu, 6 Feb 2014 13:51:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kirei.se; s=spg20100524; h=received:content-type:mime-version:subject:from:in-reply-to:date: content-transfer-encoding:message-id:references:to:x-mailer; bh=26AxZMkquODf1QwDelDZ8WH8IzAwwtAULYaeA5qyYeI=; b=CXqv1d+rFNEaEmax+c6utaNsRl83xe+N6ytJHCbaROedYf/gvndvOXh4VcOb8rJ1rcu7JSneBziCh Dff9jVwx3bSezbIZYn1im0UFYE8pT8sd0FIHItfiKP4uUEAUQnQw+PSzXHbsb0crps2vQQMgc8xAqd MwI1TkSZT5dsxmeY= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg-relay.kirei.se (Halon Mail Gateway) with ESMTPS for ; Thu, 6 Feb 2014 22:51:30 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Jakob Schlyter In-Reply-To: <20140206195322.GD278@mournblade.imrryr.org> Date: Thu, 6 Feb 2014 22:51:28 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <11698F58-B554-4CC8-872F-D2A3BF08986C@kirei.se> References: <41938fd202ba460285b59132c29ac826@BY2PR09MB029.namprd09.prod.outlook.com> <20140206195322.GD278@mournblade.imrryr.org> To: "" X-Mailer: Apple Mail (2.1827) Subject: Re: [dane] I-D Action: draft-ietf-dane-smime-03.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: Thu, 06 Feb 2014 21:51:37 -0000 On 6 feb 2014, at 20:53, Viktor Dukhovni = wrote: > Switching gears, was any consensus reached on the endoing of the > query label? A truncated HMAC seems to offer better usability than > base32. I think that the specification is in good shape, modulo > the query label encoding. =20 Yes, we're looking at doing a plain sha224 for the LHS lookup instead of = base32. Paul Wouters will provide some draft text for both documents = (S/MIME & PGP). I would say we have consensus for HMAC-sha224 yet, but = that's something we can discuss further. jakob From viktor1dane@dukhovni.org Thu Feb 6 13:57: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 88F661A0424 for ; Thu, 6 Feb 2014 13:57:46 -0800 (PST) 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 xHPX26jGWs5G for ; Thu, 6 Feb 2014 13:57:43 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id A26761A0427 for ; Thu, 6 Feb 2014 13:57:43 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 2BA422AB23D; Thu, 6 Feb 2014 21:57:42 +0000 (UTC) Date: Thu, 6 Feb 2014 21:57:42 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140206215742.GF278@mournblade.imrryr.org> References: <41938fd202ba460285b59132c29ac826@BY2PR09MB029.namprd09.prod.outlook.com> <20140206195322.GD278@mournblade.imrryr.org> <11698F58-B554-4CC8-872F-D2A3BF08986C@kirei.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <11698F58-B554-4CC8-872F-D2A3BF08986C@kirei.se> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] I-D Action: draft-ietf-dane-smime-03.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, 06 Feb 2014 21:57:46 -0000 On Thu, Feb 06, 2014 at 10:51:28PM +0100, Jakob Schlyter wrote: > On 6 feb 2014, at 20:53, Viktor Dukhovni wrote: > > > Switching gears, was any consensus reached on the endoing of the > > query label? A truncated HMAC seems to offer better usability than > > base32. I think that the specification is in good shape, modulo > > the query label encoding. > > Yes, we're looking at doing a plain sha224 for the LHS lookup > instead of base32. Paul Wouters will provide some draft text for > both documents (S/MIME & PGP). I would [not] say we have consensus for > HMAC-sha224 yet, but that's something we can discuss further. I think that HMAC-sha224 would be wiser, since otherwise a single dictionary works for all domains. The key should be the domain name. The question is I think not whether HMAC is necessary, but rather whether it is sufficient, one might argue for iterated HMAC with a reasonably high iteration count (unfortunately fixed, but Moore's law will end any day now, ... promise! ) -- Viktor. From ietf@augustcellars.com Thu Feb 6 17:14: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 5F0A81A058E for ; Thu, 6 Feb 2014 17:14:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 uNiafuAA-x6H for ; Thu, 6 Feb 2014 17:13:59 -0800 (PST) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id 8FC171A0585 for ; Thu, 6 Feb 2014 17:13:59 -0800 (PST) Received: from Philemon (50-39-223-207.bvtn.or.frontiernet.net [50.39.223.207]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 2B2DA38EF3 for ; Thu, 6 Feb 2014 17:13:58 -0800 (PST) From: "Jim Schaad" To: References: <41938fd202ba460285b59132c29ac826@BY2PR09MB029.namprd09.prod.outlook.com> <20140206195322.GD278@mournblade.imrryr.org> <11698F58-B554-4CC8-872F-D2A3BF08986C@kirei.se> <20140206215742.GF278@mournblade.imrryr.org> In-Reply-To: <20140206215742.GF278@mournblade.imrryr.org> Date: Thu, 6 Feb 2014 17:12:18 -0800 Message-ID: <07a801cf23a1$a5b62c00$f1228400$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQG9BCk5y8KpLGv7J7/0RgkJHs14wAMI8/6lAgOPaNIB7rzTBpqVYLvg Content-Language: en-us Subject: Re: [dane] I-D Action: draft-ietf-dane-smime-03.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, 07 Feb 2014 01:14:01 -0000 > -----Original Message----- > From: dane [mailto:dane-bounces@ietf.org] On Behalf Of Viktor Dukhovni > Sent: Thursday, February 06, 2014 1:58 PM > To: dane@ietf.org > Subject: Re: [dane] I-D Action: draft-ietf-dane-smime-03.txt > > On Thu, Feb 06, 2014 at 10:51:28PM +0100, Jakob Schlyter wrote: > > > On 6 feb 2014, at 20:53, Viktor Dukhovni > wrote: > > > > > Switching gears, was any consensus reached on the endoing of the > > > query label? A truncated HMAC seems to offer better usability than > > > base32. I think that the specification is in good shape, modulo the > > > query label encoding. > > > > Yes, we're looking at doing a plain sha224 for the LHS lookup instead > > of base32. Paul Wouters will provide some draft text for both > > documents (S/MIME & PGP). I would [not] say we have consensus for > > HMAC-sha224 yet, but that's something we can discuss further. > > I think that HMAC-sha224 would be wiser, since otherwise a single dictionary > works for all domains. The key should be the domain name. The question is I > think not whether HMAC is necessary, but rather whether it is sufficient, one > might argue for iterated HMAC with a reasonably high iteration count > (unfortunately fixed, but Moore's law will end any day now, ... promise! ) A trivial way to avoid the global dictionary is to simply hash the email address - that is both the local part and the domain. This would make it unique for each domain. Jim > > -- > Viktor. > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From paul.hoffman@vpnc.org Thu Feb 6 17:27:00 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 9B0BD1A0587 for ; Thu, 6 Feb 2014 17:27:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] 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 Sya_sXI3rCKr for ; Thu, 6 Feb 2014 17:26:59 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id CD69C1A03FD for ; Thu, 6 Feb 2014 17:26:59 -0800 (PST) Received: from [10.20.30.90] (50-1-98-67.dsl.dynamic.sonic.net [50.1.98.67]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.7) with ESMTP id s1716rPC093052 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 6 Feb 2014 18:06:55 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-67.dsl.dynamic.sonic.net [50.1.98.67] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Paul Hoffman In-Reply-To: <07a801cf23a1$a5b62c00$f1228400$@augustcellars.com> Date: Thu, 6 Feb 2014 17:26:55 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <41938fd202ba460285b59132c29ac826@BY2PR09MB029.namprd09.prod.outlook.com> <20140206195322.GD278@mournblade.imrryr.org> <11698F58-B554-4CC8-872F-D2A3BF08986C@kirei.se> <20140206215742.GF278@mournblade.imrryr.org> <07a801cf23a1$a5b62c00$f1228400$@augustcellars.com> To: "" X-Mailer: Apple Mail (2.1827) Subject: [dane] Feature creep for draft-ietf-dane-smime 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, 07 Feb 2014 01:27:00 -0000 Why are we trying to make the names any more difficult to walk through = than they would be for SMTP? The use of the hash was *purely* to allow = longer LHSs, not to prevent enumeration. Enumeration has never been = considered a serious problem for SMTP, and we should not be complicating = our protocol to prevent it. Hash-of-LHS is simple and not prone to any = misunderstanding. --Paul Hoffman= From viktor1dane@dukhovni.org Thu Feb 6 17:48:14 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 E6D5E1A059D for ; Thu, 6 Feb 2014 17:48:13 -0800 (PST) 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 mRJd5YwtBd0H for ; Thu, 6 Feb 2014 17:48:11 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 82D8E1A058F for ; Thu, 6 Feb 2014 17:48:11 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 8D63B2AB23D; Fri, 7 Feb 2014 01:48:09 +0000 (UTC) Date: Fri, 7 Feb 2014 01:48:09 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140207014809.GI278@mournblade.imrryr.org> References: <41938fd202ba460285b59132c29ac826@BY2PR09MB029.namprd09.prod.outlook.com> <20140206195322.GD278@mournblade.imrryr.org> <11698F58-B554-4CC8-872F-D2A3BF08986C@kirei.se> <20140206215742.GF278@mournblade.imrryr.org> <07a801cf23a1$a5b62c00$f1228400$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <07a801cf23a1$a5b62c00$f1228400$@augustcellars.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] I-D Action: draft-ietf-dane-smime-03.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: Fri, 07 Feb 2014 01:48:14 -0000 On Thu, Feb 06, 2014 at 05:12:18PM -0800, Jim Schaad wrote: > A trivial way to avoid the global dictionary is to simply hash the email > address - that is both the local part and the domain. This would make it > unique for each domain. This also works, but is twice as fast as HMAC, where as my concern is that even HMAC is too fast. Of course a factor of 2 is not a real deterrent. So I must admit that there is no compelling reason to prefer HMAC over SHA2-224, provided the hash covers the domain. Perhaps I should mention the fact that in order to perform the off-line dictionary attack the attacker first has to discover a large fraction of the domain's NSEC3 records (assuming the domain does not provide NSEC records) and then dictionary attack the NSEC3 RRs. Thus he at least has to perform multiple NSEC3 hash iterations (far too few sadly to prevent off-line discovery of the most common user names). The iteration counts for NSEC3 are additive with respect to any iterations we might impose on the SMIMEA lookup key, rather than multiplicative because at any given time for a given zone all NSEC3 RRs have the same salt, and thus for each guess at a user name it is easy to compute the SMIMEA query domain, and thus the corresponding NSEC3 value for the current zone salt. -- Viktor. From viktor1dane@dukhovni.org Thu Feb 6 18:02:05 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 7AAE11A058F for ; Thu, 6 Feb 2014 18:02:05 -0800 (PST) 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 o-TLaTUw_9UM for ; Thu, 6 Feb 2014 18:02:03 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 7F2091A0587 for ; Thu, 6 Feb 2014 18:02:03 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id DD7012AB23D; Fri, 7 Feb 2014 02:02:01 +0000 (UTC) Date: Fri, 7 Feb 2014 02:02:01 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140207020201.GJ278@mournblade.imrryr.org> References: <41938fd202ba460285b59132c29ac826@BY2PR09MB029.namprd09.prod.outlook.com> <20140206195322.GD278@mournblade.imrryr.org> <11698F58-B554-4CC8-872F-D2A3BF08986C@kirei.se> <20140206215742.GF278@mournblade.imrryr.org> <07a801cf23a1$a5b62c00$f1228400$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Feature creep for draft-ietf-dane-smime 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: Fri, 07 Feb 2014 02:02:05 -0000 On Thu, Feb 06, 2014 at 05:26:55PM -0800, Paul Hoffman wrote: > Why are we trying to make the names any more difficult to walk > through than they would be for SMTP? The use of the hash was *purely* > to allow longer LHSs, not to prevent enumeration. Enumeration has > never been considered a serious problem for SMTP, and we should > not be complicating our protocol to prevent it. Hash-of-LHS is > simple and not prone to any misunderstanding. SMTP does not yield an efficient offline attack. There exist popular milters that attempt to thwart "directory harvesting attacks". Once there's a hash, it should at least (at no extra cost) include the domain, to make the attack require per-domain computations. However, what I forgot to take into account is that with DNSSEC what the attacker learns are the NSEC3 hashes of the email address query domain, so a single dictionary is already not an option because the NSEC3 RRs need to be cracked and these are already salted with the domain and additional salt value. So the offline attack is already a per-domain attack even without salting of the hashed label. Thus perhaps including the domain is not essential (but no reason not to). What could offer much better protection is O(100,000) iterations (i.e., O(0.1) CPU second to compute a lookup key). An interactive user may not notice, but a legititmate bulk email engine sending encrypted mail may run into noticeable latency. I am not strongly advocating for this, more thinking out loud, in case the issue resonates with the group. -- Viktor. From gwiley@verisign.com Thu Feb 6 18:12: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 034E61A059A for ; Thu, 6 Feb 2014 18:12:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 HMSYPnr_kAbj for ; Thu, 6 Feb 2014 18:12:30 -0800 (PST) Received: from exprod6og116.obsmtp.com (exprod6og116.obsmtp.com [64.18.1.37]) by ietfa.amsl.com (Postfix) with ESMTP id AD0281A0598 for ; Thu, 6 Feb 2014 18:12:28 -0800 (PST) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob116.postini.com ([64.18.5.12]) with SMTP ID DSNKUvRBCzdz1d/etgE6tlxHw5HBEJIlqd6A@postini.com; Thu, 06 Feb 2014 18:12:28 PST Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id s172CQnq008226 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Feb 2014 21:12:26 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Thu, 6 Feb 2014 21:12:26 -0500 From: "Wiley, Glen" To: Andrew Sullivan , "dane@ietf.org" Thread-Topic: [dane] I-D Action: draft-ietf-dane-smime-03.txt Thread-Index: AQHPCyZpntlQewVS0Euo6EoCwtd7epp7QbWAgAAPnwCALFghgIAAcv8AgAAHWoCAAAJdAIAAA6QAgAET/IA= Date: Fri, 7 Feb 2014 02:12:26 +0000 Message-ID: References: <20140106212911.12960.24322.idtracker@ietfa.amsl.com> <58D91468-4295-4AEB-A5F4-3C796CBF047A@vpnc.org> <20140205210516.GN278@mournblade.imrryr.org> <20140206042311.GF21114@mx1.yitter.info> <20140206043138.GT278@mournblade.imrryr.org> <20140206044440.GI21114@mx1.yitter.info> In-Reply-To: <20140206044440.GI21114@mx1.yitter.info> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-ID: <27986BC63B2447479307ABA4A52C7A56@verisign.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dane] I-D Action: draft-ietf-dane-smime-03.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, 07 Feb 2014 02:12:32 -0000 On 2/5/14 11:44 PM, "Andrew Sullivan" wrote: >On Thu, Feb 06, 2014 at 04:31:38AM +0000, Viktor Dukhovni wrote: >> I must plead ignorance of the obstacle, what do you have in mind? > >I am repeatedly informed by my man pages, RFC 3493, and every web >browser implementer I've ever spoken to that getting the TTL on an RR >coming to you from the system resolver is hard. I'd be more delighted >than I can express to be misinformed, so if you know otherwise please >say so. > >There is a new API (more a meta-api) that Paul Hoffman worked on >(http://www.vpnc.org/getdns-api/) that I think we should all embrace >partly for the above reason, but we're not even at 0-day with that yet >AFAICT. =20 We are very close to "0-day" for getdns :) A few of us (NLNetLabs and Verisign) have been working on an open source Implementation of the specification that we are planning to release prior to IETF89. The API provides pretty complete access to the RR data and includes DNSSEC validation. Per the spec the API can be used as a stub Resolver (as with extant libc entry points) or as a recursive Resolver (the default behavior per the spec). > >> If learning DNS TTLs along with the RRset data is problematic, >> application caches should have reasonably short maximum lifetimes. > >I recognise the basic impulse in what you're saying, but it gives me >pause. Timing attacks involving DNS and the browser "pinning" policy >have always struck me as plausible (and ISTR a demonstration, but I'm >darned if I can come up with it now). But using this sort of trick >for actual certificate stuff appears to make the target of any >pinning-timing attack more valuable. Is that a problem? (That's not >a rhetorical question. I'm an idiot.) > >[I get your other argument about lifetimes. Not trying to ignore, >just accepting.] > >A > >--=20 >Andrew Sullivan >ajs@anvilwalrusden.com --=20 Glen Wiley KK4SFV Sr. Engineer The Hive, Verisign, Inc. From ietf@augustcellars.com Thu Feb 6 20:03: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 9ABB71A034B for ; Thu, 6 Feb 2014 20:03:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 llirba1B1K7V for ; Thu, 6 Feb 2014 20:03:16 -0800 (PST) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id AA4271A0346 for ; Thu, 6 Feb 2014 20:03:15 -0800 (PST) Received: from Philemon (50-39-223-207.bvtn.or.frontiernet.net [50.39.223.207]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id 754382CA51; Thu, 6 Feb 2014 20:03:14 -0800 (PST) From: "Jim Schaad" To: Date: Thu, 6 Feb 2014 20:01:34 -0800 Message-ID: <07ba01cf23b9$4b4e0540$e1ea0fc0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac8jpUDvnDpFqfeXTuqw0g8WYmGXPw== Content-Language: en-us Cc: dane@ietf.org Subject: [dane] Comments on draft-ietf-dane-smime-04 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, 07 Feb 2014 04:03:18 -0000 1. Section 1, para 1: The first two sentences imply that a single certificate is going to be present in a message. While this is true in a large number of cases, there are many times in which more than one certificate may be present. These include having different signing an encrypting keys or intermediate certificates for chain building. I would request that the first two sentences be modified to make certificate be plural. s/a certificate. This certificate assists/certificates. These certificates assist/ 2. Section 1, para 1: The last sentence is missing a step in the description of the process of validating that certificate is bound to a purported sender. The current text just looks at the validation process and does not talk about what is necessary to check the binding itself. In most cases, but not all, this involves looking for the senders email address in the certificate itself. (In other cases some type of external database would be required or one could say that the sender and the signer may not be the same person even though the signature itself validates.) One thing about this document that I don't remember having seen on the list is the question of doing the binding check between the senders address and the contents of a certificate. Is it going to be considered sufficient if one does the DNS look up for the certificates? Is it only a sufficient check for some types of SMIMEA records but not for others? I.e. EE certificate vs CA or TA certificate. The document needs to distinguish between the steps of validating and trusting a certificate and doing the binding between an email address and a certificate. While it is possible to both in some cases, in others these need to be distinct steps. 3. Section 2, para 1: First sentence - see the last item. It may be not an EE certificate that is being associated. 4. Section 3, step 1: It would be nice to be explicit that you are doing a UTF8 Unicode string to octet string transformation before doing the Base32 conversion. The referenced document says that this is the case for SMTP submission in one mode, but it is not clear that the SMTP submission format is what we are doing here. Being explicit would be helpful. There are two general problems that people are looking to solve with this document. A) I have an email address and a certificate, I want to validate the certificate and check the association between the certificate and the email address. B) I have an email address, I need to find a certificate. At present I believe that this document is addressing problem A and not problem B. It would be good to state that problem B is out of scope in the introduction if this is the case. If problem B is what the document is trying to solve, then there are a number of issues that need to be addressed: a) The set of certificate usages needs to be restricted to 1 and 3 so that one will get a certificate about the EE b) The set of certificates selectors needs to be restricted to 0 so that the certificate is always present c) The matching type needs to be restricted to 0 so that the certificate is always present. A mention, but problem not a solution, to the case folding problem for local parts in email addresses needs to stated so that people understand it exists. A quote from RFC 6530 is It has long been the case that the email syntax permits choices about mailbox names that are unwise in practice, if one actually intends the mailboxes to be accessible to a broad range of senders. The most often cited examples involve the use of case-sensitivity and tricky quoting of embedded characters in mailbox local parts. These deliberately unusual constructions are permitted by the protocols, and servers are expected to support them. Although they can provide value in special cases, taking advantage of them is almost always bad practice unless the intent is to create some form of security by obscurity. Which would seem to me to say, yes this is a legal thing to do. However if you do it you should be taken back of the wood shed and whipped. Thus although it is legal it is highly unadvisable. Thus one does case folding in the look up, one may be get a wrong security answer so one should not do it even if it is tempting. I.e. - this at a minimum is a security consideration because people are going to try and do it if we don't tell them not to do it and why they should not do it. From tom@ritter.vg Fri Feb 7 03:11:35 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 1521B1A1F5E for ; Fri, 7 Feb 2014 03:11:35 -0800 (PST) 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 Eszde9C5aDND for ; Fri, 7 Feb 2014 03:11:27 -0800 (PST) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 964671AC441 for ; Fri, 7 Feb 2014 03:04:30 -0800 (PST) Received: by mail-pa0-f52.google.com with SMTP id bj1so3043455pad.11 for ; Fri, 07 Feb 2014 03:04:30 -0800 (PST) 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=WQTjYiYU+UcgrJqw8lA1FlCvT9FFE4LVxgksM51Cb/o=; b=oSsQkEPUcCKlD7tVU0AxLJ4mdM4bOJtOPj3aLglXRjTMTwvpaaXk2IXpzzrJHHua7g lcZch3CzgUhneNHBVXythhDafKAUxavY4n8pvnIrSnWp4dkPeNr4NfnqiHgTomC86ODT ArXy6r3uh7UuNjVCdYDq2hEiX5Jlh1VJ7fzpE= 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=WQTjYiYU+UcgrJqw8lA1FlCvT9FFE4LVxgksM51Cb/o=; b=K8jGm1gBCRiSU+SmpFDJnxNUsw8XFfoCG+gZma9ALRlzeY0kr6Kcvt5c1txg3p6itu M4YTnhh+LI/puNZOhUOUuV7r0tQWyIX8sQ2iT8c60yALHB4QeBqSvbaEOM0uPzI5ES3R oEM1CBzBk6f3fGnShK02Hxqikdw3sqeguL3DMPGFk2I1fR8PGhjrpfjmKhuHUdvm8ULq wgpAn/u+1EB8EtaD1qJfQ5YRZyTrKIEtfiuvCHKoPA+PvUZfdtRHQjesvLPGmq7OTRxf ADVfajf3jmTnpgaNojXfFPJCmi0GrhCPoskIv1RSLB4p6uQ+EYnlQSOU9ljKl88vIcMa 8KYg== X-Gm-Message-State: ALoCoQl1/FS81o22bEtwfBvHNDv5CruOnMYqxjjcr65VoWkPtEpfJ32nMPe9/+6gxDukclUgfmeh X-Received: by 10.66.220.198 with SMTP id py6mr7033479pac.21.1391770592739; Fri, 07 Feb 2014 02:56:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.211.169 with HTTP; Fri, 7 Feb 2014 02:56:12 -0800 (PST) In-Reply-To: <20140207020201.GJ278@mournblade.imrryr.org> References: <41938fd202ba460285b59132c29ac826@BY2PR09MB029.namprd09.prod.outlook.com> <20140206195322.GD278@mournblade.imrryr.org> <11698F58-B554-4CC8-872F-D2A3BF08986C@kirei.se> <20140206215742.GF278@mournblade.imrryr.org> <07a801cf23a1$a5b62c00$f1228400$@augustcellars.com> <20140207020201.GJ278@mournblade.imrryr.org> From: Tom Ritter Date: Fri, 7 Feb 2014 05:56:12 -0500 Message-ID: To: IETF DANE WG list Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [dane] Feature creep for draft-ietf-dane-smime 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, 07 Feb 2014 11:11:35 -0000 On 6 February 2014 21:02, Viktor Dukhovni wrote: > I am not strongly advocating for this, more thinking out loud, in > case the issue resonates with the group. I saw it mentioned, but when I ran into a similar situation, I got hung up with the normalization/canonicalization process. Capitalization ('Mark' vs 'mark') and in other languages and Suffixes (tom-ietf@ritter.vg vs tom+ietf@ritter.vg and other configurable characters) being the foremost. No hashing allows a server to go to lengths to set up a DNS response that matches their implementation (e.g. perhaps my suffix character is 'G') - hashing either takes that ability away from servers or creates a way-too-complicated algorithm with unacceptable back-and-forth 'What is your suffix character' queries. I lean away from hashing, in favor of robust anti-spam solutions that take into account things like sender DKIM and SMIME. That said, I also recognize the value in trying not to decrease security (actual or perceived) from what is actually deployed milter software. -tom From paul@cypherpunks.ca Fri Feb 7 09:57: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 BA1221A03F1 for ; Fri, 7 Feb 2014 09:57:11 -0800 (PST) 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 fJ5iWTlnoRMq for ; Fri, 7 Feb 2014 09:57:10 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 797971A03E1 for ; Fri, 7 Feb 2014 09:57:10 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id CA3A9800AA for ; Fri, 7 Feb 2014 12:57:09 -0500 (EST) Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s17Hv9hK017564 for ; Fri, 7 Feb 2014 12:57:09 -0500 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Fri, 7 Feb 2014 12:57:09 -0500 (EST) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: dane WG list In-Reply-To: <20140206215742.GF278@mournblade.imrryr.org> Message-ID: References: <41938fd202ba460285b59132c29ac826@BY2PR09MB029.namprd09.prod.outlook.com> <20140206195322.GD278@mournblade.imrryr.org> <11698F58-B554-4CC8-872F-D2A3BF08986C@kirei.se> <20140206215742.GF278@mournblade.imrryr.org> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Subject: Re: [dane] I-D Action: draft-ietf-dane-smime-03.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, 07 Feb 2014 17:57:11 -0000 On Thu, 6 Feb 2014, Viktor Dukhovni wrote: > I think that HMAC-sha224 would be wiser, since otherwise a single > dictionary works for all domains. So what, telnet'ing to port 25 and issuing HELO and RCP TO: is cheaper already. As PaulH said, this is not a security feature - it's only meant as a method to be able to store any LHS username in DNS. Straight sha224, no hmac. Paul From paul@nohats.ca Fri Feb 7 10:00:09 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 994B51AC7F0 for ; Fri, 7 Feb 2014 10:00:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.535 X-Spam-Level: X-Spam-Status: No, score=-2.535 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.535] 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 TuEnalpYu58z for ; Fri, 7 Feb 2014 10:00:08 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 692C41A03F1 for ; Fri, 7 Feb 2014 10:00:08 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 30D38800AA for ; Fri, 7 Feb 2014 13:00:08 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1391796008; bh=voxfwSU9uyFb6awLpgj9bF06/qrCWvV7KVGEb2whLy4=; h=Date:From:To:Subject:In-Reply-To:References; b=XngO/WBd4oPfOUCNunQEygzyYcyCIDpD2YOFsnZrV/pCEERJO06Le9664MPNjC83K 8uIwL+Wljl4J5BGPui2QhQ5sUi1o3xmz/LCLJ06uSOE99Q1PbSkSNOUNl1e5Z30Vcm TUn55E2JqA9v3BHm1S2k76L1HITvWQMlyts7fkhw= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s17I07SA017813 for ; Fri, 7 Feb 2014 13:00:08 -0500 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Fri, 7 Feb 2014 13:00:07 -0500 (EST) From: Paul Wouters To: dane@ietf.org In-Reply-To: <20140207020201.GJ278@mournblade.imrryr.org> Message-ID: References: <41938fd202ba460285b59132c29ac826@BY2PR09MB029.namprd09.prod.outlook.com> <20140206195322.GD278@mournblade.imrryr.org> <11698F58-B554-4CC8-872F-D2A3BF08986C@kirei.se> <20140206215742.GF278@mournblade.imrryr.org> <07a801cf23a1$a5b62c00$f1228400$@augustcellars.com> <20140207020201.GJ278@mournblade.imrryr.org> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: [dane] Feature creep for draft-ietf-dane-smime 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, 07 Feb 2014 18:00:09 -0000 On Fri, 7 Feb 2014, Viktor Dukhovni wrote: > SMTP does not yield an efficient offline attack. Since when are spamming botnets interested in offline attacks to harvest email addresses? Botnets just sent to every random character combo @ domain. Paul From viktor1dane@dukhovni.org Fri Feb 7 10:11:34 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 88EC01A01B0 for ; Fri, 7 Feb 2014 10:11:34 -0800 (PST) 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 X9XqyZ981yZf for ; Fri, 7 Feb 2014 10:11:29 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id CF8A51A00F0 for ; Fri, 7 Feb 2014 10:11:29 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 40FB12AB245; Fri, 7 Feb 2014 18:11:29 +0000 (UTC) Date: Fri, 7 Feb 2014 18:11:29 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140207181129.GO278@mournblade.imrryr.org> References: <41938fd202ba460285b59132c29ac826@BY2PR09MB029.namprd09.prod.outlook.com> <20140206195322.GD278@mournblade.imrryr.org> <11698F58-B554-4CC8-872F-D2A3BF08986C@kirei.se> <20140206215742.GF278@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.21 (2010-09-15) Subject: Re: [dane] I-D Action: draft-ietf-dane-smime-03.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: Fri, 07 Feb 2014 18:11:34 -0000 On Fri, Feb 07, 2014 at 12:57:09PM -0500, Paul Wouters wrote: > On Thu, 6 Feb 2014, Viktor Dukhovni wrote: > > >I think that HMAC-sha224 would be wiser, since otherwise a single > >dictionary works for all domains. > > So what, telnet'ing to port 25 and issuing HELO and RCP TO: is cheaper > already. There's a difference between online and off-line attacks. For an NSEC zone, if the hash does not include the full address, the attacker can trivially perform a lookup in a pre-computed domain-indendent dictionary. Thus the usernames are easily recovered off-line. So if you don't do HMAC, you must hash the full address, not just the localpart. For an NSEC3 zone, the attacker gets lightly iterated salted hashes of the query fqdn, and needs to compute the same for each guess of a plausible user name. Bottom line, hash the full address, not just the localpart. -- Viktor. From viktor1dane@dukhovni.org Fri Feb 7 10:41:58 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 996D11A0422 for ; Fri, 7 Feb 2014 10:41:58 -0800 (PST) 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 ojs2seggEQct for ; Fri, 7 Feb 2014 10:41:56 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 4CF621A01B0 for ; Fri, 7 Feb 2014 10:41:56 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 68C0D2AB246; Fri, 7 Feb 2014 18:41:55 +0000 (UTC) Date: Fri, 7 Feb 2014 18:41:55 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140207184155.GQ278@mournblade.imrryr.org> References: <41938fd202ba460285b59132c29ac826@BY2PR09MB029.namprd09.prod.outlook.com> <20140206195322.GD278@mournblade.imrryr.org> <11698F58-B554-4CC8-872F-D2A3BF08986C@kirei.se> <20140206215742.GF278@mournblade.imrryr.org> <07a801cf23a1$a5b62c00$f1228400$@augustcellars.com> <20140207020201.GJ278@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.21 (2010-09-15) Subject: Re: [dane] Feature creep for draft-ietf-dane-smime 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: Fri, 07 Feb 2014 18:41:58 -0000 On Fri, Feb 07, 2014 at 01:00:07PM -0500, Paul Wouters wrote: > >SMTP does not yield an efficient offline attack. > > Since when are spamming botnets interested in offline attacks to harvest > email addresses? Botnets just sent to every random character combo @ > domain. Since a time in the future when it becomes possible. :-) There'll probably be a service selling the harvested addresses to spammers. -- Viktor. From paul.hoffman@vpnc.org Fri Feb 7 11:08:24 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 034A41AC7F1 for ; Fri, 7 Feb 2014 11:08:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] 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 C4AnDbXOYhfD for ; Fri, 7 Feb 2014 11:08:22 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id A20351A03CD for ; Fri, 7 Feb 2014 11:08:22 -0800 (PST) Received: from [10.20.30.90] (50-1-98-67.dsl.dynamic.sonic.net [50.1.98.67]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s17J8Kgd024864 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 7 Feb 2014 12:08:22 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-67.dsl.dynamic.sonic.net [50.1.98.67] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Paul Hoffman In-Reply-To: <20140207184155.GQ278@mournblade.imrryr.org> Date: Fri, 7 Feb 2014 11:08:20 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <66FEEA7D-D815-4536-A141-189F2CB705B9@vpnc.org> References: <41938fd202ba460285b59132c29ac826@BY2PR09MB029.namprd09.prod.outlook.com> <20140206195322.GD278@mournblade.imrryr.org> <11698F58-B554-4CC8-872F-D2A3BF08986C@kirei.se> <20140206215742.GF278@mournblade.imrryr.org> <07a801cf23a1$a5b62c00$f1228400$@augustcellars.com> <20140207020201.GJ278@mournblade.imrryr.org> <20140207184155.GQ278@mournblade.imrryr.org> To: "" X-Mailer: Apple Mail (2.1827) Subject: Re: [dane] Feature creep for draft-ietf-dane-smime 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, 07 Feb 2014 19:08:24 -0000 On Feb 7, 2014, at 10:41 AM, Viktor Dukhovni = wrote: > On Fri, Feb 07, 2014 at 01:00:07PM -0500, Paul Wouters wrote: >=20 >>> SMTP does not yield an efficient offline attack. >>=20 >> Since when are spamming botnets interested in offline attacks to = harvest >> email addresses? Botnets just sent to every random character combo @ >> domain. >=20 > Since a time in the future when it becomes possible. :-) >=20 > There'll probably be a service selling the harvested addresses to > spammers. Those existed 15 years ago, and still do. The proposal to make it = slightly harder for a harvester (and that's all we're suggesting) adds = complexity and no measurable value. --Paul Hoffman= From viktor1dane@dukhovni.org Fri Feb 7 11:49:35 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 B7D321A0459 for ; Fri, 7 Feb 2014 11:49:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_46=0.6] 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 V3_ZHgyWyPWQ for ; Fri, 7 Feb 2014 11:49:34 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 75E631A01D2 for ; Fri, 7 Feb 2014 11:49:34 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 5D56A2AB245; Fri, 7 Feb 2014 19:49:33 +0000 (UTC) Date: Fri, 7 Feb 2014 19:49:33 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140207194933.GS278@mournblade.imrryr.org> References: <41938fd202ba460285b59132c29ac826@BY2PR09MB029.namprd09.prod.outlook.com> <20140206195322.GD278@mournblade.imrryr.org> <11698F58-B554-4CC8-872F-D2A3BF08986C@kirei.se> <20140206215742.GF278@mournblade.imrryr.org> <07a801cf23a1$a5b62c00$f1228400$@augustcellars.com> <20140207020201.GJ278@mournblade.imrryr.org> <20140207184155.GQ278@mournblade.imrryr.org> <66FEEA7D-D815-4536-A141-189F2CB705B9@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <66FEEA7D-D815-4536-A141-189F2CB705B9@vpnc.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Feature creep for draft-ietf-dane-smime 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, 07 Feb 2014 19:49:35 -0000 On Fri, Feb 07, 2014 at 11:08:20AM -0800, Paul Hoffman wrote: > Those existed 15 years ago, and still do. The proposal to make > it slightly harder for a harvester (and that's all we're suggesting) > adds complexity and no measurable value. Yes, adding iterations would definitely add complexity. Arguably HMAC(domain, localpart) is more complex than SHA(localpart@domain), I don't care which is used. Either way of computing the hash of the full address, rather than just the local part adds no complexity, and makes off-line attacks more difficult (per site dictionaries, rather than global dictionaries). This is a free win. There's simply no reason not to. -- Viktor. From johnl@iecc.com Fri Feb 7 16:59:15 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 3F02B1AD8F1 for ; Fri, 7 Feb 2014 16:59:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.542 X-Spam-Level: * X-Spam-Status: No, score=1.542 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_NEUTRAL=0.779] 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 Np8vkQk1hTUC for ; Fri, 7 Feb 2014 16:59:14 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) by ietfa.amsl.com (Postfix) with ESMTP id C4D981AD8EE for ; Fri, 7 Feb 2014 16:59:13 -0800 (PST) Received: (qmail 88429 invoked from network); 8 Feb 2014 00:59:13 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 8 Feb 2014 00:59:13 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=52f58161.xn--i8sz2z.k1402; i=johnl@user.iecc.com; bh=er7bcmQ3MHhpKZ0etmMSAk8FnnoQxf09SU3L3pTuitE=; b=XbH3FJaufCuXSeBuYXwPsP6LGMh4/qMfRZJDtXiMmPm/o2rHa++lhjBXD5PLqOl8jJ5bxLDrWVe0XbdyutctWrmpLY7GaQSiOQ0oiYMYoiZVpHRFVLYdmUmZF2p0MTzCc8uABc/AC1aL2zkuZhUg+LxSYFalVfDvB3An5yZrmSEhNzuLMR+QOdxtaAMnqoSsmkjhgOkYCC+EgPlhNGRY2CJdU3V/WegxHxJSO/T81amoY+/ZOdPFNnmUuUprHUzD DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=52f58161.xn--i8sz2z.k1402; bh=er7bcmQ3MHhpKZ0etmMSAk8FnnoQxf09SU3L3pTuitE=; b=eE91oitlwdnkGf+deoSNKHnCEsDc5/NEq/kyQvYQ5wAvzl2z+utZEqBaungAeLSTBmTj4gLVXVzNxZIN7B6HP9hmy8KwChYCQzuaUSbvkmYJ1ivub/8DmTwQWD87652s9+wU4aghzAqa0ksm5eaTjmYB9OVj4N2I/QFlbRMhoR/Zy/lL1exi5aY+Tfk7qsQislaJo2rJjzc1SgR1sSwquDE7Xep5kcpA14TgMyXrxbPBLxR9h1segN9lvdpDSH3J Date: 8 Feb 2014 00:58:51 -0000 Message-ID: <20140208005851.14782.qmail@joyce.lan> From: "John Levine" To: dane@ietf.org Cc: dane@ietf.org In-Reply-To: <20140207184155.GQ278@mournblade.imrryr.org> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Subject: Re: [dane] Feature creep for draft-ietf-dane-smime 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, 08 Feb 2014 00:59:15 -0000 >> Since when are spamming botnets interested in offline attacks to harvest >> email addresses? Botnets just sent to every random character combo @ >> domain. > >Since a time in the future when it becomes possible. :-) > >There'll probably be a service selling the harvested addresses to >spammers. Harvesting off the web will always be easier. I have to say this feels like a solution in search of a problem. R's, John From johnl@iecc.com Fri Feb 7 16:59:15 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 3ED1A1AD8F0 for ; Fri, 7 Feb 2014 16:59:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.542 X-Spam-Level: * X-Spam-Status: No, score=1.542 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_NEUTRAL=0.779] 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 JclnST1M6rTG for ; Fri, 7 Feb 2014 16:59:14 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) by ietfa.amsl.com (Postfix) with ESMTP id C4D531A01E6 for ; Fri, 7 Feb 2014 16:59:13 -0800 (PST) Received: (qmail 88429 invoked from network); 8 Feb 2014 00:59:13 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 8 Feb 2014 00:59:13 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=52f58161.xn--i8sz2z.k1402; i=johnl@user.iecc.com; bh=er7bcmQ3MHhpKZ0etmMSAk8FnnoQxf09SU3L3pTuitE=; b=XbH3FJaufCuXSeBuYXwPsP6LGMh4/qMfRZJDtXiMmPm/o2rHa++lhjBXD5PLqOl8jJ5bxLDrWVe0XbdyutctWrmpLY7GaQSiOQ0oiYMYoiZVpHRFVLYdmUmZF2p0MTzCc8uABc/AC1aL2zkuZhUg+LxSYFalVfDvB3An5yZrmSEhNzuLMR+QOdxtaAMnqoSsmkjhgOkYCC+EgPlhNGRY2CJdU3V/WegxHxJSO/T81amoY+/ZOdPFNnmUuUprHUzD DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=52f58161.xn--i8sz2z.k1402; bh=er7bcmQ3MHhpKZ0etmMSAk8FnnoQxf09SU3L3pTuitE=; b=eE91oitlwdnkGf+deoSNKHnCEsDc5/NEq/kyQvYQ5wAvzl2z+utZEqBaungAeLSTBmTj4gLVXVzNxZIN7B6HP9hmy8KwChYCQzuaUSbvkmYJ1ivub/8DmTwQWD87652s9+wU4aghzAqa0ksm5eaTjmYB9OVj4N2I/QFlbRMhoR/Zy/lL1exi5aY+Tfk7qsQislaJo2rJjzc1SgR1sSwquDE7Xep5kcpA14TgMyXrxbPBLxR9h1segN9lvdpDSH3J Date: 8 Feb 2014 00:58:51 -0000 Message-ID: <20140208005851.14782.qmail@joyce.lan> From: "John Levine" To: dane@ietf.org Cc: dane@ietf.org In-Reply-To: <20140207184155.GQ278@mournblade.imrryr.org> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Subject: Re: [dane] Feature creep for draft-ietf-dane-smime 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, 08 Feb 2014 00:59:15 -0000 >> Since when are spamming botnets interested in offline attacks to harvest >> email addresses? Botnets just sent to every random character combo @ >> domain. > >Since a time in the future when it becomes possible. :-) > >There'll probably be a service selling the harvested addresses to >spammers. Harvesting off the web will always be easier. I have to say this feels like a solution in search of a problem. R's, John From paul@cypherpunks.ca Fri Feb 7 17:49:16 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 A87C81AD6BF for ; Fri, 7 Feb 2014 17:49:16 -0800 (PST) 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 Vw48TmZL9WZU for ; Fri, 7 Feb 2014 17:49:15 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id E848E1AD603 for ; Fri, 7 Feb 2014 17:49:14 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id CBF6D800AA for ; Fri, 7 Feb 2014 20:49:13 -0500 (EST) Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s181nDGk006330 for ; Fri, 7 Feb 2014 20:49:13 -0500 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Fri, 7 Feb 2014 20:49:13 -0500 (EST) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: dane WG list In-Reply-To: <20140207181129.GO278@mournblade.imrryr.org> Message-ID: References: <41938fd202ba460285b59132c29ac826@BY2PR09MB029.namprd09.prod.outlook.com> <20140206195322.GD278@mournblade.imrryr.org> <11698F58-B554-4CC8-872F-D2A3BF08986C@kirei.se> <20140206215742.GF278@mournblade.imrryr.org> <20140207181129.GO278@mournblade.imrryr.org> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Subject: Re: [dane] I-D Action: draft-ietf-dane-smime-03.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, 08 Feb 2014 01:49:16 -0000 On Fri, 7 Feb 2014, Viktor Dukhovni wrote: >>> I think that HMAC-sha224 would be wiser, since otherwise a single >>> dictionary works for all domains. >> >> So what, telnet'ing to port 25 and issuing HELO and RCP TO: is cheaper >> already. > > There's a difference between online and off-line attacks. $ wc -l /usr/share/dict/words 479828 /usr/share/dict/words $ head -100000 /usr/share/dict/words > /tmp/10k $ time (for word in `cat /tmp/10k`; do echo -n "$word.nohats.ca" | sha224sum; done > /dev/null) real 3m9.064s And that's using only 1 cpu, and a horrible shell kludge. I'm sure the spammers have awesome LHS dictionaries gathered over the years. Your proposal does not actually add any security. You'd have to also ratelimit DNS queries if you go down the path of the hash being a security feature. > For an NSEC zone, if the hash does not include the full address, > the attacker can trivially perform a lookup in a pre-computed > domain-indendent dictionary. Thus the usernames are easily recovered > off-line. So if you don't do HMAC, you must hash the full address, > not just the localpart. > > For an NSEC3 zone, the attacker gets lightly iterated salted hashes > of the query fqdn, and needs to compute the same for each guess of > a plausible user name. Why do i need to follow the hashes? I'll just brute force a dictionary list and sent queries. Whether I sha2-224 that once, or once per domain, is not that big of a difference. hashing is cheap. > Bottom line, hash the full address, not just the localpart. what's next? using scrypt? pbkdf2? The hashing is not a security feature. Hashing the domain brings in other problems, such as case sensitivity that changes hashes but not DNS names. Also, not using the domain name allows for CNAME/DNAME entries, so for example I can add the same record in my "libreswan.org" zone that is used as DNAME for libreswan.{net|com|ca|fi|nl}. Adding the domain into the hash would break this setup. Seriously, if spammers use the location of SMIME/OPENPGPKEYs to find email addreses's WE HAVE WON THE CRYPTO WARS! Paul From viktor1dane@dukhovni.org Fri Feb 7 19:03:50 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 65DF41ADBCC for ; Fri, 7 Feb 2014 19:03:50 -0800 (PST) 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 9-FGSJQivHZW for ; Fri, 7 Feb 2014 19:03:48 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 09F3A1AD945 for ; Fri, 7 Feb 2014 19:03:47 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 829CD2AB245; Sat, 8 Feb 2014 03:03:46 +0000 (UTC) Date: Sat, 8 Feb 2014 03:03:46 +0000 From: Viktor Dukhovni To: dane WG list Message-ID: <20140208030346.GV278@mournblade.imrryr.org> References: <41938fd202ba460285b59132c29ac826@BY2PR09MB029.namprd09.prod.outlook.com> <20140206195322.GD278@mournblade.imrryr.org> <11698F58-B554-4CC8-872F-D2A3BF08986C@kirei.se> <20140206215742.GF278@mournblade.imrryr.org> <20140207181129.GO278@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.21 (2010-09-15) Subject: Re: [dane] I-D Action: draft-ietf-dane-smime-03.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane WG list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Feb 2014 03:03:50 -0000 On Fri, Feb 07, 2014 at 08:49:13PM -0500, Paul Wouters wrote: > I'm sure the spammers have awesome LHS dictionaries gathered over the > years. Your proposal does not actually add any security. If that's the group consensus, fine. Though it seems to me that including the domain in the hash is essentially free, so why not? > >Bottom line, hash the full address, not just the localpart. > I just thought you'd do the simplest thing that costs nothing and turns the attack from a single dictionary into a per-sites attack. I did not see any downside. > The hashing is not a security feature. Hashing the domain brings in > other problems, such as case sensitivity that changes hashes but not > DNS names. Don't see how. The domain would be canonicalized to lower case before hashing, just as with NSEC3. > Also, not using the domain name allows for CNAME/DNAME entries, so for > example I can add the same record in my "libreswan.org" zone that is > used as DNAME for libreswan.{net|com|ca|fi|nl}. Adding the domain into > the hash would break this setup. Indeed hashing the domain would cause a problem with DNAMEs. -- Viktor. From viktor1dane@dukhovni.org Fri Feb 7 19:52: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 E5FC01ADBD7 for ; Fri, 7 Feb 2014 19:52:05 -0800 (PST) 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 ZsWYTGar05MW for ; Fri, 7 Feb 2014 19:52:04 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 0C5FE1A0342 for ; Fri, 7 Feb 2014 19:52:03 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 403922AB240; Sat, 8 Feb 2014 03:52:03 +0000 (UTC) Date: Sat, 8 Feb 2014 03:52:03 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140208035203.GX278@mournblade.imrryr.org> References: <41938fd202ba460285b59132c29ac826@BY2PR09MB029.namprd09.prod.outlook.com> <20140206195322.GD278@mournblade.imrryr.org> <11698F58-B554-4CC8-872F-D2A3BF08986C@kirei.se> <20140206215742.GF278@mournblade.imrryr.org> <20140207181129.GO278@mournblade.imrryr.org> <20140208030346.GV278@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140208030346.GV278@mournblade.imrryr.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] I-D Action: draft-ietf-dane-smime-03.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, 08 Feb 2014 03:52:06 -0000 On Sat, Feb 08, 2014 at 03:03:46AM +0000, Viktor Dukhovni wrote: > > Also, not using the domain name allows for CNAME/DNAME entries, so for > > example I can add the same record in my "libreswan.org" zone that is > > used as DNAME for libreswan.{net|com|ca|fi|nl}. Adding the domain into > > the hash would break this setup. > > Indeed hashing the domain would cause a problem with DNAMEs. Or not, note that just becase example.com is a CNAME for example.net does not mean that joe@example.com is the same *mailbox* (email recipient) as joe@exampl.net. Nothing in SMTP makes it so, and some people in fact use multiple domains hosted at the same target as independent namespaces. So from that perspective, hashing the domain actually better matches SMTP semantics. It avoids conflating addresses that are cannot be presumed to be equivalent. -- Viktor. From internet-drafts@ietf.org Sun Feb 9 18:09: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 8FAAD1A0669; Sun, 9 Feb 2014 18:09:19 -0800 (PST) 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 7851NDWNhwHd; Sun, 9 Feb 2014 18:09:18 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A99F1A066F; Sun, 9 Feb 2014 18:09:15 -0800 (PST) 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.0.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140210020915.29796.86929.idtracker@ietfa.amsl.com> Date: Sun, 09 Feb 2014 18:09:15 -0800 Cc: dane@ietf.org Subject: [dane] I-D Action: draft-ietf-dane-smtp-with-dane-05.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: Mon, 10 Feb 2014 02:09:19 -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-05.txt Pages : 29 Date : 2014-02-09 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-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-dane-smtp-with-dane-05 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 viktor1dane@dukhovni.org Sun Feb 9 18:16:58 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 91D7D1A0700 for ; Sun, 9 Feb 2014 18:16:58 -0800 (PST) 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 NwBoLdoknF1A for ; Sun, 9 Feb 2014 18:16:56 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id BE6E21A06E2 for ; Sun, 9 Feb 2014 18:16:54 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 495022AB24B; Mon, 10 Feb 2014 02:16:54 +0000 (UTC) Date: Mon, 10 Feb 2014 02:16:54 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140210021654.GZ278@mournblade.imrryr.org> References: <20140210020915.29796.86929.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140210020915.29796.86929.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] I-D Action: draft-ietf-dane-smtp-with-dane-05.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: Mon, 10 Feb 2014 02:16:58 -0000 On Sun, Feb 09, 2014 at 06:09:15PM -0800, internet-drafts@ietf.org wrote: > Title : SMTP security via opportunistic DANE TLS > Filename : draft-ietf-dane-smtp-with-dane-05.txt > Pages : 29 > Date : 2014-02-09 > > 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). Wes and I feel that this work is substantively ready for publication. If the chairs approve, we'd like to advance this draft to WG last call. This is also a good time for the working group to read the document, we've put a lot of work into the document structure between version 04 and version 05, so the differences are as large as the document. The main substantive change as that SMTP for MUAs has been dropped from this specification. It now specifies opportunistic DANE TLS only for MTA to MTA SMTP. -- Viktor. From stpeter@stpeter.im Tue Feb 11 09:20:53 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 E14AB1A0691 for ; Tue, 11 Feb 2014 09:20:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, 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 z7Z8G7wHM8xM for ; Tue, 11 Feb 2014 09:20:52 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 029A81A0685 for ; Tue, 11 Feb 2014 09:20:51 -0800 (PST) Received: from aither.local (unknown [24.8.129.242]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id D72464032A; Tue, 11 Feb 2014 10:20:50 -0700 (MST) Message-ID: <52FA5BF2.1040802@stpeter.im> Date: Tue, 11 Feb 2014 10:20:50 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: dane@ietf.org References: <20131219160710.8908.47958.idtracker@ietfa.amsl.com> <20131219173027.GB1285@mournblade.imrryr.org> In-Reply-To: <20131219173027.GB1285@mournblade.imrryr.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dane] draft-ietf-dane-srv-03.txt: name checks, ... 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, 11 Feb 2014 17:20:54 -0000 Hi Viktor, my apologies about the seriously delayed reply. On 12/19/13, 10:30 AM, Viktor Dukhovni wrote: > On Thu, Dec 19, 2013 at 08:07:10AM -0800, internet-drafts@ietf.org wrote: > >> Filename : draft-ietf-dane-srv-03.txt >> Date : 2013-12-13 > > Section 5 (no exception for usage 3): > Section 7 (MUST and SHOULD on server name are too strong): > Section 10.3 (no exception for usage 3): > > This still conflicts with the smtp-with-dane and ops drafts with > respect to name checks (server identity checks) in usage 3. In > the two conflicting documents usage 3 certificates are validated > exclusively by matching against DANE TLSA RRs. No name checks, > key usage checks, expiration checks, ... apply with usage 3. Rather, > the binding of the EE certificate to the service end-point is > entirely established by the DNSSEC TLSA record (also its validity > lifetime is the lifetime of the TLSA record). > > Correspondingly, all requirements on the content of the server > certificate are relaxed with usage 3, it may, if desired, contain > no identity information. You are right. We will update the document to properly account for usage 3 scenarios. Peter -- Peter Saint-Andre https://stpeter.im/ From internet-drafts@ietf.org Tue Feb 11 14:13:23 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 C632E1A0773; Tue, 11 Feb 2014 14:13:23 -0800 (PST) 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 0ScVWbgqcbXN; Tue, 11 Feb 2014 14:13:22 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B3A41A078F; Tue, 11 Feb 2014 14:13:20 -0800 (PST) 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.0.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140211221320.30490.31053.idtracker@ietfa.amsl.com> Date: Tue, 11 Feb 2014 14:13:20 -0800 Cc: dane@ietf.org Subject: [dane] I-D Action: draft-ietf-dane-srv-04.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: Tue, 11 Feb 2014 22:13:24 -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 DNS-Based Authentication of Named Entities (DANE) TLSA records with SRV and MX records. Authors : Tony Finch Matthew Miller Peter Saint-Andre Filename : draft-ietf-dane-srv-04.txt Pages : 13 Date : 2014-02-11 Abstract: The DANE specification (RFC 6698) describes how to use TLSA resource records in the DNS to associate a server's host name with its TLS certificate. The association is secured with DNSSEC. Some application protocols use SRV records (RFC 2782) to indirectly name the server hosts for a service domain (SMTP uses MX records for the same purpose). This specification gives generic instructions for how these application protocols locate and use TLSA records when technologies such as SRV records are used. Separate documents give the details that are specific to particular application protocols. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dane-srv/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dane-srv-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-dane-srv-04 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 mamille2@cisco.com Tue Feb 11 14:17: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 B1F4A1A0748 for ; Tue, 11 Feb 2014 14:17:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.028 X-Spam-Level: X-Spam-Status: No, score=-9.028 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MISSING_HEADERS=1.021, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 kUkUmODBOggt for ; Tue, 11 Feb 2014 14:17:36 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) by ietfa.amsl.com (Postfix) with ESMTP id AFFBE1A0738 for ; Tue, 11 Feb 2014 14:17:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3057; q=dns/txt; s=iport; t=1392157056; x=1393366656; h=message-id:date:from:mime-version:cc:subject:references: in-reply-to:content-transfer-encoding; bh=+htbKl7jkOZpef0FsxLUKecJyNwxgG0kmem/OAxcFdw=; b=UstEVM5ftrK3+DmplxJKM5OZeod1dfwkSE8JK9rSu27t2emVm4zhxeYe oCftnADilRUY7ZoOkoZzs2/TzfJukPuQM+J4S0KNiav7s4NYuFd5nySMY SJmNQTlYPpaTgm6a66OJaBtBsxtGDW1Dt3bnwL3BYv0SS0B+XehxjU3WR o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArYKAC+h+lKtJV2Z/2dsb2JhbABagww4UQanYJcvJHMWdIIdCAEBAQQBAQFrCgEQCxgJFg8JAwIBAgEVMBMBBQIBAQWFbYIPCAXJaheORjMHgn6BOgSJEDiOYoEyiy6FQINNggo X-IronPort-AV: E=Sophos;i="4.95,828,1384300800"; d="scan'208";a="19694855" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-6.cisco.com with ESMTP; 11 Feb 2014 22:17:36 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s1BMHZoR024769 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 11 Feb 2014 22:17:36 GMT Received: from jack.cisco.com (64.101.72.76) by xhc-rcd-x05.cisco.com (173.37.183.79) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 11 Feb 2014 16:17:35 -0600 Message-ID: <52FAA17F.3060703@cisco.com> Date: Tue, 11 Feb 2014 15:17:35 -0700 From: Matt Miller User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 CC: References: <20140211221320.30490.31053.idtracker@ietfa.amsl.com> In-Reply-To: <20140211221320.30490.31053.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [64.101.72.76] Subject: Re: [dane] I-D Action: draft-ietf-dane-srv-04.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: Tue, 11 Feb 2014 22:17:38 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Viktor (and DANE), Peter and I believe this revision addresses all of your feedback. Please let us if anything is missing or inconsistent. Also added an SRV example for the expected records, updated referenced, and author information. - -- - - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. On 2/11/14, 3:13 PM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the DNS-based > Authentication of Named Entities Working Group of the IETF. > > Title : Using DNS-Based Authentication of Named Entities > (DANE) TLSA records with SRV and MX records. Authors : Tony > Finch Matthew Miller Peter Saint-Andre Filename : > draft-ietf-dane-srv-04.txt Pages : 13 Date : > 2014-02-11 > > Abstract: The DANE specification (RFC 6698) describes how to use > TLSA resource records in the DNS to associate a server's host name > with its TLS certificate. The association is secured with DNSSEC. > Some application protocols use SRV records (RFC 2782) to indirectly > name the server hosts for a service domain (SMTP uses MX records > for the same purpose). This specification gives generic > instructions for how these application protocols locate and use > TLSA records when technologies such as SRV records are used. > Separate documents give the details that are specific to particular > application protocols. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dane-srv/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-dane-srv-04 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-dane-srv-04 > > > 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/ > > _______________________________________________ I-D-Announce > mailing list I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft > directories: http://www.ietf.org/shadow.html or > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJS+qF/AAoJEDWi+S0W7cO1xhgH/3TPIubid6u7F8xGIco1swTc bMWQfFVaMTddUOaLL0AsaZUSkTuGMPzYtIQK42f4H5IWQbavZMXmtTLKv8bQxfIG 2dGTr8BtstzoMxe4K5klO18owov0lnum8R9MN7AIPIiawL46HFJ4p9L3D8V1j1kR yEpP8AhyDijPUIBRcC38y3YTDtKAIpu1Cdh7f9n3PpdqVtF428dHZqU8J7sz+zrU o8AlQ9HMjFzxKE4SuLJxrMBMUmJsSvH2MHu7/FkI9FFFq05kHaxOkBfrkSxbRf3Q F0Da5Pp3p4maRGdxjJslA4PYYo/SSt1HyD2GqaR9GVPzUF/G/P2SPbCCNbLvt0E= =U/kn -----END PGP SIGNATURE----- From viktor1dane@dukhovni.org Tue Feb 11 15:34:08 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 96DA71A07AC for ; Tue, 11 Feb 2014 15:34:08 -0800 (PST) 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 RHKVjpAUxZvn for ; Tue, 11 Feb 2014 15:34:06 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id EF8511A0799 for ; Tue, 11 Feb 2014 15:34:05 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id E393E2AB24A; Tue, 11 Feb 2014 23:34:03 +0000 (UTC) Date: Tue, 11 Feb 2014 23:34:03 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140211233403.GV278@mournblade.imrryr.org> References: <20140211221320.30490.31053.idtracker@ietfa.amsl.com> <52FAA17F.3060703@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52FAA17F.3060703@cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] I-D Action: draft-ietf-dane-srv-04.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: Tue, 11 Feb 2014 23:34:08 -0000 On Tue, Feb 11, 2014 at 03:17:35PM -0700, Matt Miller wrote: > Viktor (and DANE), > > Peter and I believe this revision addresses all of your feedback. > Please let us if anything is missing or inconsistent. > > Also added an SRV example for the expected records, updated > referenced, and author information. The draft seems to use "indeterminate" in the sense of RFC 4033, where-in there is no trust-anchor for the domain or any of its ancestors. Unfortunately, there is a conflicting definition in RFC 4035, which I am told is more appropriate in this context. All 4035-style "indeterminate" results (and "bogus" results) are essentially lookup errors and must treated as such. See section 2.1 of the SMTP draft. As for 4033-style indeterminacy it is indeed to be treated as equivalent to "insecure". For DANE-EE(3) CU records to have meaningful semantics for the publisher. For example for a publisher to use the same certificate for many SRV hosts or without worrying about using a matching name, the use of non-use of name checks must be specified precisely. Therefore I would suggest that the "MAY be ignored" in the second paragraph of section 5, should be changed to "MUST be ignored". Otherwise, the published TLSA records have unknown semantics. When the service domain is the head of a CNAME chain, with the SRV record obtained after indirection via at least one CNAME RR, the SMTP and ops drafts specify that name checks must include both the service domain and its full CNAME expansion (in addition to any SRV target host name). The SMTP draft also specifies that servers MUST not refuse to complete the TLS handshake when no certificate matching the SNI name is present. Rather they must then present the default certificate, because clients may be willing to match other names in addition to that sent in the SNI extension. - In the first paragraph of 4.2, change "as describes" to "as described". - In the third paragraph of 5. change "the the 'to' address" to eliminate the duplicate "the". -- Viktor. From mamille2@cisco.com Wed Feb 12 09:32:08 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 6A5FB1A0601 for ; Wed, 12 Feb 2014 09:32:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.049 X-Spam-Level: X-Spam-Status: No, score=-10.049 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.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XZTaFJ5AwnEx for ; Wed, 12 Feb 2014 09:32:05 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) by ietfa.amsl.com (Postfix) with ESMTP id A4FEA1A05E5 for ; Wed, 12 Feb 2014 09:32:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3106; q=dns/txt; s=iport; t=1392226325; x=1393435925; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=KdRcRKphbUEkdTP3fIbfXqpJN/wtapOiLGfTI7pdths=; b=Zp0jLOoIRt67XymZI4FjlleR3QYPEHnfAquloq0n+sgsTSvfBQ8wTYom BVDvRh7qpXcj6KuACPwrXoT4Laut3wbqGjyjYGBDSDhTn1B1X9CDCAUcc wPq5IVj7JgTo4R8ZjqeEuJaV6Tg9touPv+mdxIcM0OUrdOZe8uqto8EmC c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmUJAFqv+1KtJXG8/2dsb2JhbABagww4V6gRA5cKCoEXFnSCJQEBAQR4EQsYCRYPCQMCAQIBRQYNBgIBAYgByVYXjhQyOoQ4BIkQOI5ikiGDTYIK X-IronPort-AV: E=Sophos;i="4.95,833,1384300800"; d="scan'208";a="19929711" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by alln-iport-5.cisco.com with ESMTP; 12 Feb 2014 17:32:04 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id s1CHW4h8023478 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 12 Feb 2014 17:32:04 GMT Received: from jack.cisco.com (64.101.72.76) by xhc-rcd-x05.cisco.com (173.37.183.79) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 12 Feb 2014 11:32:04 -0600 Message-ID: <52FBB013.2080502@cisco.com> Date: Wed, 12 Feb 2014 10:32:03 -0700 From: Matt Miller User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: References: <20140211221320.30490.31053.idtracker@ietfa.amsl.com> <52FAA17F.3060703@cisco.com> <20140211233403.GV278@mournblade.imrryr.org> In-Reply-To: <20140211233403.GV278@mournblade.imrryr.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [64.101.72.76] Subject: Re: [dane] I-D Action: draft-ietf-dane-srv-04.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: Wed, 12 Feb 2014 17:32:08 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 2/11/14, 4:34 PM, Viktor Dukhovni wrote: > On Tue, Feb 11, 2014 at 03:17:35PM -0700, Matt Miller wrote: > >> Viktor (and DANE), >> >> Peter and I believe this revision addresses all of your >> feedback. Please let us if anything is missing or inconsistent. >> >> Also added an SRV example for the expected records, updated >> referenced, and author information. > > The draft seems to use "indeterminate" in the sense of RFC 4033, > where-in there is no trust-anchor for the domain or any of its > ancestors. Unfortunately, there is a conflicting definition in RFC > 4035, which I am told is more appropriate in this context. > > All 4035-style "indeterminate" results (and "bogus" results) are > essentially lookup errors and must treated as such. See section 2.1 > of the SMTP draft. As for 4033-style indeterminacy it is indeed to > be treated as equivalent to "insecure". > > For DANE-EE(3) CU records to have meaningful semantics for the > publisher. For example for a publisher to use the same > certificate for many SRV hosts or without worrying about using a > matching name, the use of non-use of name checks must be specified > precisely. > > Therefore I would suggest that the "MAY be ignored" in the second > paragraph of section 5, should be changed to "MUST be ignored". > Otherwise, the published TLSA records have unknown semantics. > > When the service domain is the head of a CNAME chain, with the SRV > record obtained after indirection via at least one CNAME RR, the > SMTP and ops drafts specify that name checks must include both the > service domain and its full CNAME expansion (in addition to any SRV > target host name). > > The SMTP draft also specifies that servers MUST not refuse to > complete the TLS handshake when no certificate matching the SNI > name is present. Rather they must then present the default > certificate, because clients may be willing to match other names in > addition to that sent in the SNI extension. > > - In the first paragraph of 4.2, change "as describes" to "as > described". > > - In the third paragraph of 5. change "the the 'to' address" to > eliminate the duplicate "the". > Thank you for the feedback, Viktor. These comments make sense to me. We'll try to get an update out before the cutoff to address them. - -- - - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJS+7ATAAoJEDWi+S0W7cO1ZMIH/3BGTSq6xROIU3VODM0+JHuj Ygl7KsMYk2N9SA/LAE6Bf5RhxAYsGusvduVY5Xgh01hAmbGEJDDJBaM1zOtFaFs4 yZb3HVBr9bN9618i811+kIGEnP3noYKc2eo/np5lw3jay/18bPHbWfGICJW97nGx wmoQnUJp1LcUwHOAk4q6pIAbnvwTTXyAiczo4WMNYjWOPbGm2tIU4CWWZTVWEZWi qEr0nWiiD9Mzmz/d9qcEV/bs8T9SdJiN1LXnSv/DhQnE2MjRAa8XC/KNm93zyxSW M58pDT16vyGxA6dZQPC7/7flBuBX/oDNbGgbfW0dXnLaYGLm9vaC5vu3FCYXXBw= =geO4 -----END PGP SIGNATURE----- From viktor1dane@dukhovni.org Wed Feb 12 11:54: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 BF8041A06CA for ; Wed, 12 Feb 2014 11:54:19 -0800 (PST) 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 XHs8h0KiH4uC for ; Wed, 12 Feb 2014 11:54:17 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id F2A791A0685 for ; Wed, 12 Feb 2014 11:54:16 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 566E72AB245; Wed, 12 Feb 2014 19:54:13 +0000 (UTC) Date: Wed, 12 Feb 2014 19:54:13 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140212195413.GG278@mournblade.imrryr.org> References: <20140211221320.30490.31053.idtracker@ietfa.amsl.com> <52FAA17F.3060703@cisco.com> <20140211233403.GV278@mournblade.imrryr.org> <52FBB013.2080502@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52FBB013.2080502@cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] I-D Action: draft-ietf-dane-srv-04.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: Wed, 12 Feb 2014 19:54:20 -0000 On Wed, Feb 12, 2014 at 10:32:03AM -0700, Matt Miller wrote: > > DANE-EE(3) CU records need to have meaningful semantics for the > > publisher. For example for a publisher to use the same > > certificate for many SRV hosts or without worrying about using a > > matching name, the use of non-use of name checks must be specified > > precisely. > > Therefore I would suggest that the "MAY be ignored" in the second > > paragraph of section 5, should be changed to "MUST be ignored". > > Otherwise, the published TLSA records have unknown semantics. > > Thank you for the feedback, Viktor. These comments make sense to me. > We'll try to get an update out before the cutoff to address them. Thanks. You could mention that both name checks and key usage are effectively handled by the TLSA record for DANE-EE(3). The TLSA record binds the certificate or public key to the requested port and protocol at the TLSA base domain, the binding is clearly for a TLS server, so there is an implicit key usage of TLS server. Finally, the RRSIG expiration date sets the expiration time of the TLSA "pseudo-certificate". A requirement to ignore the certificate content gives the publisher flexibility (e.g. same certificate for multiple SRV hosts, ...). There will be some overlap between the SRV draft and the SMTP draft. I expect that's not a problem, provided they agree. -- Viktor. From oej@edvina.net Wed Feb 12 12:25:50 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 179DD1A06DC for ; Wed, 12 Feb 2014 12:25:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 8ZdDzej9zhgO for ; Wed, 12 Feb 2014 12:25:48 -0800 (PST) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id CE3DD1A06B7 for ; Wed, 12 Feb 2014 12:25:47 -0800 (PST) Received: from [192.168.40.13] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 0D08E93C2A2; Wed, 12 Feb 2014 20:25:45 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: "Olle E. Johansson" In-Reply-To: <20140212195413.GG278@mournblade.imrryr.org> Date: Wed, 12 Feb 2014 21:25:43 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140211221320.30490.31053.idtracker@ietfa.amsl.com> <52FAA17F.3060703@cisco.com> <20140211233403.GV278@mournblade.imrryr.org> <52FBB013.2080502@cisco.com> <20140212195413.GG278@mournblade.imrryr.org> To: "dane@ietf.org list" X-Mailer: Apple Mail (2.1827) Subject: Re: [dane] I-D Action: draft-ietf-dane-srv-04.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: Wed, 12 Feb 2014 20:25:50 -0000 On 12 Feb 2014, at 20:54, Viktor Dukhovni = wrote: > There will be some overlap between the SRV draft and the SMTP draft. > I expect that's not a problem, provided they agree. I got a complaint on that type of overlap in the dispatch wg on my = sip-dane draft. I haven't had time to look into it, but the feedback was that some of it = was copied, some of it actually belonged in the SRV draft. As I am new = to the draft-writing business I look for guidance here. /O= From mamille2@cisco.com Wed Feb 12 12:39:24 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 C34091A06D5 for ; Wed, 12 Feb 2014 12:39:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.049 X-Spam-Level: X-Spam-Status: No, score=-10.049 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.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id et8oCw3cOoTb for ; Wed, 12 Feb 2014 12:39:22 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) by ietfa.amsl.com (Postfix) with ESMTP id A2E981A06DE for ; Wed, 12 Feb 2014 12:39:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2628; q=dns/txt; s=iport; t=1392237560; x=1393447160; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=5RKQiqtmUa+hLV3A6nv5fceFISTU3bJlP+6IDDpIo5M=; b=L28B/iPv5859xw1QLJYXn3ewqvQw0vfyIC3Szf92DrPKYco/cM8wm/LA 1K6Ks2lkpemMVrBLl93oyEUmEy4IfWKenXeLC0l3lidZ+JZvjhq55uIi8 W2V0gxIMPAkpov7AWqi380TzF5ol3jGjWPL60OF7L0fPyBMmOtKqx0yJ5 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmQJALDb+1KtJV2Y/2dsb2JhbABagww4V6gXA5cUgRkWdIIlAQEBAwEyAUUGCwsYCRYPCQMCAQIBRQYNBgIBAYd5CMh0F44UMjoWhCIEiRA4jmKSIYNNggo X-IronPort-AV: E=Sophos;i="4.95,834,1384300800"; d="scan'208";a="19979348" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-6.cisco.com with ESMTP; 12 Feb 2014 20:39:19 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s1CKdJ1m008071 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 12 Feb 2014 20:39:19 GMT Received: from jack.cisco.com (64.101.72.76) by xhc-rcd-x05.cisco.com (173.37.183.79) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 12 Feb 2014 14:39:19 -0600 Message-ID: <52FBDBF6.5080309@cisco.com> Date: Wed, 12 Feb 2014 13:39:18 -0700 From: Matt Miller User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: References: <20140211221320.30490.31053.idtracker@ietfa.amsl.com> <52FAA17F.3060703@cisco.com> <20140211233403.GV278@mournblade.imrryr.org> <52FBB013.2080502@cisco.com> <20140212195413.GG278@mournblade.imrryr.org> In-Reply-To: <20140212195413.GG278@mournblade.imrryr.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Originating-IP: [64.101.72.76] Subject: Re: [dane] I-D Action: draft-ietf-dane-srv-04.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: Wed, 12 Feb 2014 20:39:25 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 2/12/14, 12:54 PM, Viktor Dukhovni wrote: > On Wed, Feb 12, 2014 at 10:32:03AM -0700, Matt Miller wrote: > >>> DANE-EE(3) CU records need to have meaningful semantics for the >>> publisher. For example for a publisher to use the same >>> certificate for many SRV hosts or without worrying about using >>> a matching name, the use of non-use of name checks must be >>> specified precisely. > >>> Therefore I would suggest that the "MAY be ignored" in the >>> second paragraph of section 5, should be changed to "MUST be >>> ignored". Otherwise, the published TLSA records have unknown >>> semantics. >> >> Thank you for the feedback, Viktor. These comments make sense to >> me. We'll try to get an update out before the cutoff to address >> them. > > Thanks. You could mention that both name checks and key usage are > effectively handled by the TLSA record for DANE-EE(3). The TLSA > record binds the certificate or public key to the requested port > and protocol at the TLSA base domain, the binding is clearly for a > TLS server, so there is an implicit key usage of TLS server. > Finally, the RRSIG expiration date sets the expiration time of the > TLSA "pseudo-certificate". A requirement to ignore the > certificate content gives the publisher flexibility (e.g. same > certificate for multiple SRV hosts, ...). > Section 5 (after I change the "MAY" to a "MUST") already states that matching a DANE-EE(3) TLSA bypasses the rest of the certificate checks (paragraph 2), but the current wording might be too clumsy. I'll see what I can wordsmith to make it more explicit. I could also add something about the RRSIG expiration, but isn't that already covered by RFC4035 § 5.3.1 (bullet 5)? > There will be some overlap between the SRV draft and the SMTP > draft. I expect that's not a problem, provided they agree. > - -- - - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJS+9v2AAoJEDWi+S0W7cO1vDcH/0JiXQus5YsClSbmhjT3/DbR ILJiUcKYY79yJ1bKDdcsTPF8TaNTuTDN/wtK/ABMfoggD76pJaQ0iCyQLTaL/J61 pkshzeWBKqm2kyfgrwV2hRMOxSsGBc7jWZlrBnHwkOcsxXspJCAFwYUI8X7gzbWc 1L1TCN2+7NCyPz00oj9V7fRN3mDkVFfHPwfI7X87ZihO3dbGA4HSm/DttAmrxbvY xgk7RUOznaW5SHXU6fRxeWb2DEXsYaPRmrxckauEuI8h52zjszBbAfyOr1XcRG3m eLHqpLs1yiNQ5x9cqdPHwvm/OhXqDc+BrAftsDrsgMq/Saqb47Q3w0a2vwp6cYM= =4HNk -----END PGP SIGNATURE----- From viktor1dane@dukhovni.org Wed Feb 12 13:08:22 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 B35331A06BC for ; Wed, 12 Feb 2014 13:08:22 -0800 (PST) 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 8bQWpf8q4wKg for ; Wed, 12 Feb 2014 13:08:20 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id BCE301A0620 for ; Wed, 12 Feb 2014 13:08:16 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id AA1A22AB23C; Wed, 12 Feb 2014 21:08:13 +0000 (UTC) Date: Wed, 12 Feb 2014 21:08:13 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140212210813.GI278@mournblade.imrryr.org> References: <20140211221320.30490.31053.idtracker@ietfa.amsl.com> <52FAA17F.3060703@cisco.com> <20140211233403.GV278@mournblade.imrryr.org> <52FBB013.2080502@cisco.com> <20140212195413.GG278@mournblade.imrryr.org> <52FBDBF6.5080309@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52FBDBF6.5080309@cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] I-D Action: draft-ietf-dane-srv-04.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: Wed, 12 Feb 2014 21:08:23 -0000 On Wed, Feb 12, 2014 at 01:39:18PM -0700, Matt Miller wrote: > >> Thank you for the feedback, Viktor. These comments make sense to > >> me. We'll try to get an update out before the cutoff to address > >> them. > > > > Thanks. You could mention that both name checks and key usage are > > effectively handled by the TLSA record for DANE-EE(3). The TLSA > > record binds the certificate or public key to the requested port > > and protocol at the TLSA base domain, the binding is clearly for a > > TLS server, so there is an implicit key usage of TLS server. > > Finally, the RRSIG expiration date sets the expiration time of the > > TLSA "pseudo-certificate". A requirement to ignore the > > certificate content gives the publisher flexibility (e.g. same > > certificate for multiple SRV hosts, ...). > > > > Section 5 (after I change the "MAY" to a "MUST") already states that > matching a DANE-EE(3) TLSA bypasses the rest of the certificate checks > (paragraph 2), but the current wording might be too clumsy. I'll see > what I can wordsmith to make it more explicit. It is only a question of how much you feel it is appropriate to provide a rationale for this requirement and in how much detail you want to provide it. > I could also add something about the RRSIG expiration, but isn't that > already covered by RFC4035 ? 5.3.1 (bullet 5)? I don't know that RFC 4035 specifically talks about imputing a TLS server key expiration time from a DNS RRSIG expiration time, but per the above comment, it is largely a question of whether you want to explain why it is OK to ignore the "3 X Y" certificate content and get everything you need from DNSSEC. -- Viktor. From mrex@sap.com Wed Feb 12 14:55:05 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 ED6451A0002 for ; Wed, 12 Feb 2014 14:55:04 -0800 (PST) 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 dEnFdr0iU2MB for ; Wed, 12 Feb 2014 14:54:59 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 73E091A0024 for ; Wed, 12 Feb 2014 14:54:58 -0800 (PST) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id s1CMsujN006489 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 12 Feb 2014 23:54:56 +0100 (MET) In-Reply-To: <20140212195413.GG278@mournblade.imrryr.org> To: dane@ietf.org Date: Wed, 12 Feb 2014 23:54:56 +0100 (CET) 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: <20140212225456.461B51AC03@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Subject: Re: [dane] I-D Action: draft-ietf-dane-srv-04.txt 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: Wed, 12 Feb 2014 22:55:05 -0000 Viktor Dukhovni wrote: > Matt Miller wrote: >> >>> DANE-EE(3) CU records need to have meaningful semantics for the >>> publisher. For example for a publisher to use the same >>> certificate for many SRV hosts or without worrying about using a >>> matching name, the use of non-use of name checks must be specified >>> precisely. >>> >>> Therefore I would suggest that the "MAY be ignored" in the second >>> paragraph of section 5, should be changed to "MUST be ignored". >>> Otherwise, the published TLSA records have unknown semantics. >> >> Thank you for the feedback, Viktor. These comments make sense to me. >> We'll try to get an update out before the cutoff to address them. > > Thanks. You could mention that both name checks and key usage are > effectively handled by the TLSA record for DANE-EE(3). I'm sorry, but this simply isn't true today, I do not believe that this is (nor should be) the intention of DANE, and I'm strongly opposed to changing that part of the implementations. DANE it self is about an alternative means to establish (a chain of) trust to a peer entity, and the usage type 3 only overrides the server endpoint identification that was originally described in rfc2818 section 3.1 http://tools.ietf.org/html/rfc2818#section-3 and is described in a more elaborate fashion in rfc6125 http://tools.ietf.org/html/rfc6125 DANE does NOT invalidate the keyUsage checks and requirements that are normally part of TLS itself and described here: http://tools.ietf.org/html/rfc5246#page-56 There are a number of TLS protocol stacks that will check the KeyUsage of X.509 certificates that are conveyed through TLS certificate handshake messages, independent of how the application caller decides to perform server endpoint identification and how the application caller determines its trust. -Martin From viktor1dane@dukhovni.org Wed Feb 12 15:28: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 ADD0D1A0022 for ; Wed, 12 Feb 2014 15:28:19 -0800 (PST) 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 J2b7OjQJL_tk for ; Wed, 12 Feb 2014 15:28:16 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 543111A002A for ; Wed, 12 Feb 2014 15:28:16 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 9F5C12AB245; Wed, 12 Feb 2014 23:28:14 +0000 (UTC) Date: Wed, 12 Feb 2014 23:28:14 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140212232814.GM278@mournblade.imrryr.org> References: <20140212195413.GG278@mournblade.imrryr.org> <20140212225456.461B51AC03@ld9781.wdf.sap.corp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140212225456.461B51AC03@ld9781.wdf.sap.corp> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] I-D Action: draft-ietf-dane-srv-04.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: Wed, 12 Feb 2014 23:28:19 -0000 On Wed, Feb 12, 2014 at 11:54:56PM +0100, Martin Rex wrote: > >> Thank you for the feedback, Viktor. These comments make sense to me. > >> We'll try to get an update out before the cutoff to address them. > > > > Thanks. You could mention that both name checks and key usage are > > effectively handled by the TLSA record for DANE-EE(3). > > I'm sorry, but this simply isn't true today, I do not believe that > this is (nor should be) the intention of DANE, and I'm strongly > opposed to changing that part of the implementations. No name checks for CU-3 IIRC was discussed and agreed many months ago. There is no "true today" for DANE, as there are in effect no "real" DANE implementations aside from the one in Postfix (I've looked at some experimental implementations, but they are all incomplete and often insecure). The requirement to not do name checks, EKU checks, date checks for DANE is satisfied by the Postfix DANE implementation, and will be satisfied by the OpenSSL implementation on which I'm collaborating with one of the OpenSSL developers. This requirement makes it possible to use a single certificate to work with multiple TLSA base domains, substantially simplifying virtual hosting. (See the ops draft). Thus it substantially enhances the usability of DANE. The effective chain of trust for a server public key with DANE CU-3 is the chain of DNSKEY and DS RRsets starting at the relevant DNSSEC trust anchor. There are no X.509v3 trusted parties with CU-3 whose signature on a leaf certificate validates the certificate content. In fact with "3 1 1" the holder of the public key is free to replace the certificate with any certificate for the same public key, setting new dates, new names, ... > DANE it self is about an alternative means to establish (a chain of) trust > to a peer entity, and the usage type 3 only overrides the server endpoint > identification that was originally described in rfc2818 section 3.1 I thought DANE stood for "DNS-Based Authentication of Named Entities". With CU-3 TLSA RRset binds a port/protocol at a named transport endpoint (the name is the TLSA base domain) to the corresponding public key or public-key certificate. Since this binding already takes care of naming the entity (with more specificity than one typically finds in X.509v3 certificates), establishes the validity interval of the binding, and via the DNS RR type (TLSA, SMIMEA, ...) implies a suitable usage, there is nothing left for the (untrusted content beside the public key with "3 1 X"!) certificate to specify. Since the certificate is redundant, and ignoring is a major improvement in the deployability of DANE, the only reasonable thing to do is to ignore the CU-3 certificate content (except to the extent required to compare it with the TLSA association data). > DANE does NOT invalidate the key Usage checks and requirements that are > normally part of TLS itself and described here: > > http://tools.ietf.org/html/rfc5246#page-56 Those other documents assume that the content of the certificate is from a trusted authority. This is true for CU in {0, 1, 2}, but false for CU=3. If the server operator wants to cease using a CU=3 certificate, he should publish new TLSA RRs and deploy a new certificate (with due care about key roll-over, see the ops draft). There is no need for clients to enforce expiration when the server is far better positioned to do so. > There are a number of TLS protocol stacks that will check the > Key Usage of X.509 certificates that are conveyed through TLS certificate > handshake messages, independent of how the application caller decides > to perform server endpoint identification and how the application caller > determines its trust. This is not relevant, they don't do DANE. When they do DANE, which needs to be supported by the TLS library, as application-only DANE support is actually rather difficult, they will handle CU=3 appropriately. The Postfix DANE implementation uses very low-level OpenSSL features, and essentially bypasses or duplicates or fools the existing OpenSSL verification code to accept DANE chains. Implementations will have to change to properly support DANE. Expecting application to correctly implement DANE support would lead to precisely the problems I've seen with every single current experimental DANE verifier I've seen. They're all flawed. -- Viktor. From internet-drafts@ietf.org Wed Feb 12 20:17:16 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 D04011A00D4; Wed, 12 Feb 2014 20:17:16 -0800 (PST) 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 2270u8k7HHZA; Wed, 12 Feb 2014 20:17:15 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DEBA81A00DD; Wed, 12 Feb 2014 20:17:13 -0800 (PST) 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.0.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140213041713.6669.30940.idtracker@ietfa.amsl.com> Date: Wed, 12 Feb 2014 20:17:13 -0800 Cc: dane@ietf.org Subject: [dane] I-D Action: draft-ietf-dane-smtp-with-dane-06.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, 13 Feb 2014 04:17:17 -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-06.txt Pages : 29 Date : 2014-02-12 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-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-dane-smtp-with-dane-06 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 viktor1dane@dukhovni.org Wed Feb 12 20:27:16 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 DBCB91A00DD for ; Wed, 12 Feb 2014 20:27:16 -0800 (PST) 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 sWvjxEBZuRUN for ; Wed, 12 Feb 2014 20:27:14 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 350EB1A00D4 for ; Wed, 12 Feb 2014 20:27:14 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id CF9982AB24A; Thu, 13 Feb 2014 04:27:12 +0000 (UTC) Date: Thu, 13 Feb 2014 04:27:12 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140213042712.GN278@mournblade.imrryr.org> References: <20140213041713.6669.30940.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140213041713.6669.30940.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: dane-chairs@tools.ietf.org Subject: Re: [dane] I-D Action: draft-ietf-dane-smtp-with-dane-06.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, 13 Feb 2014 04:27:17 -0000 On Wed, Feb 12, 2014 at 08:17:13PM -0800, internet-drafts@ietf.org wrote: > Title : SMTP security via opportunistic DANE TLS > Authors : Viktor Dukhovni > Wes Hardaker > Filename : draft-ietf-dane-smtp-with-dane-06.txt Copy-edit corrections from Peter Palfrader and Phill Pennock (thanks). This will save others the wear and tear of reporting the same problems. This version can be the basis for WGLC. -- Viktor. From nobody Thu Feb 13 09:43:12 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 189B81A02F5; Thu, 13 Feb 2014 09:43:07 -0800 (PST) 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 UYhQhKwqCrHt; Thu, 13 Feb 2014 09:43:04 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 399111A0382; Thu, 13 Feb 2014 09:43:00 -0800 (PST) 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.0.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140213174300.27511.9981.idtracker@ietfa.amsl.com> Date: Thu, 13 Feb 2014 09:43:00 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/Myl4XBh4BSUkHqYU7dBuohgCXQk Cc: dane@ietf.org Subject: [dane] I-D Action: draft-ietf-dane-srv-05.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, 13 Feb 2014 17:43:07 -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 DNS-Based Authentication of Named Entities (DANE) TLSA records with SRV and MX records. Authors : Tony Finch Matthew Miller Peter Saint-Andre Filename : draft-ietf-dane-srv-05.txt Pages : 14 Date : 2014-02-13 Abstract: The DANE specification (RFC 6698) describes how to use TLSA resource records in the DNS to associate a server's host name with its TLS certificate. The association is secured with DNSSEC. Some application protocols use SRV records (RFC 2782) to indirectly name the server hosts for a service domain (SMTP uses MX records for the same purpose). This specification gives generic instructions for how these application protocols locate and use TLSA records when technologies such as SRV records are used. Separate documents give the details that are specific to particular application protocols. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dane-srv/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dane-srv-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-dane-srv-05 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 Feb 13 10:19:25 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 7F1991A03DB for ; Thu, 13 Feb 2014 10:19:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.601 X-Spam-Level: X-Spam-Status: No, score=-3.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_MED=-2.3, 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 PTz7Pj45pPkr for ; Thu, 13 Feb 2014 10:19:22 -0800 (PST) Received: from exprod6og119.obsmtp.com (exprod6og119.obsmtp.com [64.18.1.234]) by ietfa.amsl.com (Postfix) with ESMTP id 3D3EB1A03CE for ; Thu, 13 Feb 2014 10:19:19 -0800 (PST) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob119.postini.com ([64.18.5.12]) with SMTP ID DSNKUv0MpozGIBEbiq2YbAa8UO6rVZGfhWLX@postini.com; Thu, 13 Feb 2014 10:19:21 PST Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01.vcorp.ad.vrsn.com [10.173.152.255]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id s1DIJGI9021238 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 13 Feb 2014 13:19:17 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Thu, 13 Feb 2014 13:19:16 -0500 From: "Osterweil, Eric" To: Viktor Dukhovni Thread-Topic: [dane] Feature creep for draft-ietf-dane-smime Thread-Index: AQHPI6O2uA3Qloe9vkKMC5bZifdAHJqpXbiAgAELsICAAAuugIAAB2EAgAALhICACVTDgA== Date: Thu, 13 Feb 2014 18:19:15 +0000 Message-ID: <0DCAEFBA-E9A6-4CC8-9D9D-DB03F309C0BC@verisign.com> References: <41938fd202ba460285b59132c29ac826@BY2PR09MB029.namprd09.prod.outlook.com> <20140206195322.GD278@mournblade.imrryr.org> <11698F58-B554-4CC8-872F-D2A3BF08986C@kirei.se> <20140206215742.GF278@mournblade.imrryr.org> <07a801cf23a1$a5b62c00$f1228400$@augustcellars.com> <20140207020201.GJ278@mournblade.imrryr.org> <20140207184155.GQ278@mournblade.imrryr.org> <66FEEA7D-D815-4536-A141-189F2CB705B9@vpnc.org> <20140207194933.GS278@mournblade.imrryr.org> In-Reply-To: <20140207194933.GS278@mournblade.imrryr.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/0EOymK9VhtMtSNBdEIrjQm2LrPY Cc: "" Subject: Re: [dane] Feature creep for draft-ietf-dane-smime 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: Thu, 13 Feb 2014 18:19:24 -0000 On Feb 7, 2014, at 2:49 PM, Viktor Dukhovni wrot= e: > On Fri, Feb 07, 2014 at 11:08:20AM -0800, Paul Hoffman wrote: >=20 >> Those existed 15 years ago, and still do. The proposal to make >> it slightly harder for a harvester (and that's all we're suggesting) >> adds complexity and no measurable value. >=20 > Yes, adding iterations would definitely add complexity. >=20 > Arguably HMAC(domain, localpart) is more complex than > SHA(localpart@domain), I don't care which is used. >=20 > Either way of computing the hash of the full address, rather than > just the local part adds no complexity, and makes off-line attacks > more difficult (per site dictionaries, rather than global dictionaries). > This is a free win. There's simply no reason not to. I have to say that I agree with Paul here. I think the epsilon increase in= security is nice, but not at the cost of the additional operational comple= xity. However, the hashing-only approach has the nice side effect of fixin= g the label length. That _does_ seem to solve a problem w/o some of the ad= ditional complexity. My vote would be hashing-only approach over Base32 an= d HMAC. Eric= From nobody Thu Feb 13 10:19: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 606FC1A03B1 for ; Thu, 13 Feb 2014 10:19:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 g-8_N9M2o6k8 for ; Thu, 13 Feb 2014 10:19:31 -0800 (PST) Received: from exprod6og116.obsmtp.com (exprod6og116.obsmtp.com [64.18.1.37]) by ietfa.amsl.com (Postfix) with ESMTP id A15CD1A03A7 for ; Thu, 13 Feb 2014 10:19:13 -0800 (PST) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob116.postini.com ([64.18.5.12]) with SMTP ID DSNKUv0MoP8X93vZ9P8Ay6m5EsriFf27N1pv@postini.com; Thu, 13 Feb 2014 10:19:30 PST Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id s1DIJBpe029637 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 13 Feb 2014 13:19:11 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Thu, 13 Feb 2014 13:19:11 -0500 From: "Osterweil, Eric" To: Jim Schaad Thread-Topic: [dane] Comments on draft-ietf-dane-smime-04 Thread-Index: Ac8jpUDvnDpFqfeXTuqw0g8WYmGXPwFbL7gA Date: Thu, 13 Feb 2014 18:19:10 +0000 Message-ID: References: <07ba01cf23b9$4b4e0540$e1ea0fc0$@augustcellars.com> In-Reply-To: <07ba01cf23b9$4b4e0540$e1ea0fc0$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-ID: <7C0FCEB881A7184CAAFD96C3DA75CA51@verisign.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/BovfsUYtOWMcq3BWBS8s82uBsww Cc: "" , "" Subject: Re: [dane] Comments on draft-ietf-dane-smime-04 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: Thu, 13 Feb 2014 18:19:36 -0000 On Feb 6, 2014, at 11:01 PM, Jim Schaad wrote: > 1. Section 1, para 1: The first two sentences imply that a single > certificate is going to be present in a message. While this is true in a > large number of cases, there are many times in which more than one > certificate may be present. These include having different signing an > encrypting keys or intermediate certificates for chain building. I would > request that the first two sentences be modified to make certificate be > plural. s/a certificate. This certificate assists/certificates. These > certificates assist/ +1 > 2. Section 1, para 1: The last sentence is missing a step in the descript= ion > of the process of validating that certificate is bound to a purported > sender. The current text just looks at the validation process and does n= ot > talk about what is necessary to check the binding itself. In most cases, > but not all, this involves looking for the senders email address in the > certificate itself. (In other cases some type of external database would= be > required or one could say that the sender and the signer may not be the s= ame > person even though the signature itself validates.) >=20 > One thing about this document that I don't remember having seen on the li= st > is the question of doing the binding check between the senders address an= d > the contents of a certificate. Is it going to be considered sufficient i= f > one does the DNS look up for the certificates? Is it only a sufficient > check for some types of SMIMEA records but not for others? I.e. EE > certificate vs CA or TA certificate. I agree that we should discuss this. With PGP, I can use a key with a diff= email than the account from which I send it (for ex, I can use my spam acc= ount and rely on my full name and friends who know me to make the logical l= eap), do we all want DANE to outlaw this for S/MIME? =20 > The document needs to distinguish between the steps of validating and > trusting a certificate and doing the binding between an email address and= a > certificate. While it is possible to both in some cases, in others these > need to be distinct steps. >=20 > 3. Section 2, para 1: First sentence - see the last item. It may be no= t > an EE certificate that is being associated. >=20 > 4. Section 3, step 1: It would be nice to be explicit that you are doin= g a > UTF8 Unicode string to octet string transformation before doing the Base3= 2 > conversion. The referenced document says that this is the case for SMTP > submission in one mode, but it is not clear that the SMTP submission form= at > is what we are doing here. Being explicit would be helpful. >=20 > There are two general problems that people are looking to solve with this > document. >=20 > A) I have an email address and a certificate, I want to validate the > certificate and check the association between the certificate and the ema= il > address. >=20 > B) I have an email address, I need to find a certificate. >=20 > At present I believe that this document is addressing problem A and not > problem B. It would be good to state that problem B is out of scope in t= he > introduction if this is the case. >=20 > If problem B is what the document is trying to solve, then there are a > number of issues that need to be addressed: >=20 > a) The set of certificate usages needs to be restricted to 1 and 3 so tha= t > one will get a certificate about the EE > b) The set of certificates selectors needs to be restricted to 0 so that = the > certificate is always present > c) The matching type needs to be restricted to 0 so that the certificate = is > always present. Actually, Scott Rose's suggestions on this draft cover a mechanism to overc= ome this, by pointing at a place to learn certs. I think this commentary h= elps to further underscore the utility of that. Eric= From nobody Thu Feb 13 10:24:59 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 1B80C1A03AB for ; Thu, 13 Feb 2014 10:24:57 -0800 (PST) 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 fIAf7PPbROxx for ; Thu, 13 Feb 2014 10:24:55 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 0762B1A03A7 for ; Thu, 13 Feb 2014 10:24:54 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 7445D2AB22D; Thu, 13 Feb 2014 18:24:53 +0000 (UTC) Date: Thu, 13 Feb 2014 18:24:53 +0000 From: Viktor Dukhovni To: "" Message-ID: <20140213182453.GP278@mournblade.imrryr.org> References: <11698F58-B554-4CC8-872F-D2A3BF08986C@kirei.se> <20140206215742.GF278@mournblade.imrryr.org> <07a801cf23a1$a5b62c00$f1228400$@augustcellars.com> <20140207020201.GJ278@mournblade.imrryr.org> <20140207184155.GQ278@mournblade.imrryr.org> <66FEEA7D-D815-4536-A141-189F2CB705B9@vpnc.org> <20140207194933.GS278@mournblade.imrryr.org> <0DCAEFBA-E9A6-4CC8-9D9D-DB03F309C0BC@verisign.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0DCAEFBA-E9A6-4CC8-9D9D-DB03F309C0BC@verisign.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/WANGS1IX6s77ZpsyXSAIMxfCQPc Subject: Re: [dane] Feature creep for draft-ietf-dane-smime 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, 13 Feb 2014 18:24:57 -0000 On Thu, Feb 13, 2014 at 06:19:15PM +0000, Osterweil, Eric wrote: > > Either way of computing the hash of the full address, rather than > > just the local part adds no complexity, and makes off-line attacks > > more difficult (per site dictionaries, rather than global dictionaries). > > This is a free win. There's simply no reason not to. > > I have to say that I agree with Paul here. I think the epsilon > increase in security is nice, but not at the cost of the additional > operational complexity. However, the hashing-only approach has > the nice side effect of fixing the label length. That _does_ seem > to solve a problem w/o some of the additional complexity. My vote > would be hashing-only approach over Base32 and HMAC. In an off-list IM discussion, Paul H. and I reached consensus on local-part only hashing. His argument is based on the introduction of root zone DNAME RRs that create equivalence between large subtrees of the DNS namespace. Users will likely expect these to result in equivalence of email addresses, ... so having SMIMEA lookup labels that work relative to multiple equivalent domain FQDNs is then a requirement. So I withdraw the suggestion to salt the lookup key with the domain. -- Viktor. From nobody Thu Feb 13 12:43:33 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 7669E1A0283 for ; Thu, 13 Feb 2014 12:43:31 -0800 (PST) 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 WZYwqpZSS8hX for ; Thu, 13 Feb 2014 12:43:29 -0800 (PST) Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) by ietfa.amsl.com (Postfix) with ESMTP id 1CF901A0456 for ; Thu, 13 Feb 2014 12:43:28 -0800 (PST) Received: by mail-wi0-f174.google.com with SMTP id f8so9241670wiw.13 for ; Thu, 13 Feb 2014 12:43:27 -0800 (PST) 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=nr5q6fOOKCyzPqz7Nx+hCUGcFXwdsRCiS3wWSU4qJKU=; b=lePsVY7AInX3UorOKqp4jDpxNfbCVMXSt8+mIXwaGIzOFgteooclfg77MkZQUPBP+R U1rkqSTrE1n2fL323JynDX8cyMYyzg0JD/3oz9RfcZQoUBXxw6vlk26TrBppcADLHRyf EiRYmtv1E4yUJXG9Xpk0TSy8BOp52XMhmbKQHYMZk1HQVKk5wsCVui+VGWQyC6OEyRa8 FGyeMCpIUasd4Up2AkqfeNPkrWoy2E6NOB8izBI/abGVojQeaGaqWukJNx4I1EhRy3Q8 T6nkdxhCb6U28o13E10k/ic0RDkT81hN4dfdbZbbk9s1GyMIbxcv75AwfIHhJyUapNIW IvBw== X-Gm-Message-State: ALoCoQmJ+GeabaHgCzo8RAzuNYOoEcNK2iA5SlpPc7O27Y1wW0wpOK7qoCCc/eEni13Vu6RTuaM/ MIME-Version: 1.0 X-Received: by 10.194.108.41 with SMTP id hh9mr109688wjb.89.1392324207124; Thu, 13 Feb 2014 12:43:27 -0800 (PST) Received: by 10.194.54.167 with HTTP; Thu, 13 Feb 2014 12:43:27 -0800 (PST) X-Originating-IP: [50.201.180.2] In-Reply-To: <20140213182453.GP278@mournblade.imrryr.org> References: <11698F58-B554-4CC8-872F-D2A3BF08986C@kirei.se> <20140206215742.GF278@mournblade.imrryr.org> <07a801cf23a1$a5b62c00$f1228400$@augustcellars.com> <20140207020201.GJ278@mournblade.imrryr.org> <20140207184155.GQ278@mournblade.imrryr.org> <66FEEA7D-D815-4536-A141-189F2CB705B9@vpnc.org> <20140207194933.GS278@mournblade.imrryr.org> <0DCAEFBA-E9A6-4CC8-9D9D-DB03F309C0BC@verisign.com> <20140213182453.GP278@mournblade.imrryr.org> Date: Thu, 13 Feb 2014 15:43:27 -0500 Message-ID: From: Warren Kumari To: dane@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/KvyxvDv-aU9Og8k_mCqTJzBi1Hg Subject: Re: [dane] Feature creep for draft-ietf-dane-smime 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: Thu, 13 Feb 2014 20:43:31 -0000 On Thu, Feb 13, 2014 at 1:24 PM, Viktor Dukhovni wrote: > On Thu, Feb 13, 2014 at 06:19:15PM +0000, Osterweil, Eric wrote: > >> > Either way of computing the hash of the full address, rather than >> > just the local part adds no complexity, and makes off-line attacks >> > more difficult (per site dictionaries, rather than global dictionaries). >> > This is a free win. There's simply no reason not to. >> >> I have to say that I agree with Paul here. I think the epsilon >> increase in security is nice, but not at the cost of the additional >> operational complexity. However, the hashing-only approach has >> the nice side effect of fixing the label length. That _does_ seem >> to solve a problem w/o some of the additional complexity. My vote >> would be hashing-only approach over Base32 and HMAC. > > In an off-list IM discussion, Paul H. and I reached consensus on > local-part only hashing. His argument is based on the introduction > of root zone DNAME RRs that create equivalence between large subtrees > of the DNS namespace. Doh! Yeah, that's a really good point -- there have been a number of similar discussions recently where DNAME has thrown a spanner into the works / hasn't been considered. W > Users will likely expect these to result in > equivalence of email addresses, ... so having SMIMEA lookup labels > that work relative to multiple equivalent domain FQDNs is then a > requirement. > > So I withdraw the suggestion to salt the lookup key with the domain. > > -- > Viktor. > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From nobody Thu Feb 13 13:43: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 3B2CB1A055D for ; Thu, 13 Feb 2014 13:43:40 -0800 (PST) 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 4XKY55V_r4aT for ; Thu, 13 Feb 2014 13:43:38 -0800 (PST) Received: from mail-we0-f181.google.com (mail-we0-f181.google.com [74.125.82.181]) by ietfa.amsl.com (Postfix) with ESMTP id 2D76A1A051C for ; Thu, 13 Feb 2014 13:43:37 -0800 (PST) Received: by mail-we0-f181.google.com with SMTP id w61so8185759wes.12 for ; Thu, 13 Feb 2014 13:43:36 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=XpUniNKTtCddqvw95KV+B+4CE2zsH+Z8Hzxw2xuAmbU=; b=B2V2LRSd4Zs1AJ+PTWbUSGcQ947VG2ezOGzqbr8OqhuNBOAqxHIm9gxmQzsa9J9dAx oHfXZDnkYoW5gORQEzxIeIbUPHI2bCQC+G+3qJ6DF6vOKOxmVAsHwzmP0rXMPbzADJmk WlTYW/LaZQxkc6FMy2HHReXimvy/LcwJovi5a0y8JiVubXGtISiS+EbXOOKWvorTPd/S yVcQ0Edu1uykVMYFgO7qzQ/Olf41IueX7MC4uh27ll6ARbvn8Us/sDrZQ0/U4eFflTTk ph+w5lWENhnLFk43eiuEXqsdoZhviMECcc7Csac8MH5wAOyH5tfpnuuwRxaKqs31Qf8x pJhA== X-Gm-Message-State: ALoCoQl1aQhUjT4CKDvcoqCx+UktAI2Vdq+5N+fZ8Tf26UxUIyP6E2yoTUUC1AX/0dw9m/8+LBMu MIME-Version: 1.0 X-Received: by 10.194.161.136 with SMTP id xs8mr3209590wjb.56.1392327816297; Thu, 13 Feb 2014 13:43:36 -0800 (PST) Received: by 10.194.54.167 with HTTP; Thu, 13 Feb 2014 13:43:36 -0800 (PST) X-Originating-IP: [50.201.180.2] Date: Thu, 13 Feb 2014 16:43:36 -0500 Message-ID: From: Warren Kumari To: dane@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/klPHXhUo6dUyn3qP0_Yw-mptQSM Subject: [dane] Preliminary agenda for London 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: Thu, 13 Feb 2014 21:43:40 -0000 Hi there all, Here is the preliminary agenda for the DANE session at IETF89 in London. We are really hoping that folk will have *read* the drafts, and be primed with questions / discussions.... Please let us know if there is anything you'd like to add to the below... Also, as a quick note, we will be starting WGLC for draft-ietf-dane-smtp-with-dane-06. This will be a longer than normal LC, so that we can discuss in London. W DANE ------------- Administrivia (Sit down, blue-sheets, agenda bashing) Warren / Ondrej - 5-15 minutes. Using DANE to Associate OpenPGP public keys with email addresses draft-wouters-dane-openpgp-01 Discuss draft updates / issues, quick demo Paul Wouters - 10 minutes IPSECKEY / Auth_none draft-smyslov-ipsecme-ikev2-null-auth-00 Paul Wouters - 20 minutes Using DNS-Based Authentication of Named Entities (DANE) TLSA records with SRV and MX records. draft-ietf-dane-srv-05 Peter Saint-Andre or Matt Miller - 20 min Harmonizing how applications specify DANE-like usage draft-ogud-dane-vocabulary-01 (Quick update) Olafur - 5 min SMTP security via opportunistic DANE TLS draft-ietf-dane-smtp-with-dane-06 (NOTE: This is in WGLC / will be real soon now.) Wes Hardaker - 20 minutes. DANE TLSA implementation and operational guidance draft-ietf-dane-ops-02 Wes Hardaker - 15 minutes. From nobody Thu Feb 13 13:57:47 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 73B511A027D for ; Thu, 13 Feb 2014 13:57:46 -0800 (PST) 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 bmzTBX4gaJKa for ; Thu, 13 Feb 2014 13:57:44 -0800 (PST) Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) by ietfa.amsl.com (Postfix) with ESMTP id 4595B1A0279 for ; Thu, 13 Feb 2014 13:57:44 -0800 (PST) Received: by mail-wi0-f179.google.com with SMTP id hn9so9284161wib.6 for ; Thu, 13 Feb 2014 13:57:42 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=u+RFJt+W96hkD7RlBpeiJkyB+obAmlfc+IRmoRwPMj0=; b=gL/t4PCU6ptnsueV7ok6xwEj+hGXi+GYQR73Az/Ah6wxS6/T0gfEHpjoXIUy6w/Ew/ O0wMB8RPqnbUSxT8AMpGdhTGm6VGKuPUnBKJYwGAErwn6jnj6MHhT+jH5ryIMmcUv5ao zMOfIipHTTTvV/6eCtfMTcF6gSPp5ygi3Tkvo3s4HduLOpZqKtBgF2IHFCnwvo8T+szy 5TEWKIfzwi2bvkmb1yCkwkGLUwK8mJx23RUrJIkGFAm8XBD6h5n0FyimPR1A2Y1F4oBS yZx5zI+gQ5knGYYl2Lx18UZFJxaus9kPtNnpdp6zrYrABVmr/EYH6LK9wEqdVM9RGjiT 9DGw== X-Gm-Message-State: ALoCoQn4hd/3cDWg/viEzdWinbrQnNXXV01ykNaVt9VFis0/uWIMIeSpsO/9OarzdW5V3pvjuX3D MIME-Version: 1.0 X-Received: by 10.194.170.133 with SMTP id am5mr3198697wjc.42.1392328662447; Thu, 13 Feb 2014 13:57:42 -0800 (PST) Received: by 10.194.54.167 with HTTP; Thu, 13 Feb 2014 13:57:42 -0800 (PST) X-Originating-IP: [50.201.180.2] Date: Thu, 13 Feb 2014 16:57:42 -0500 Message-ID: From: Warren Kumari To: dane@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/Me8L7uPwNzF-8XiWoK4sE_x3zWQ Subject: [dane] Start of WGLC for draft-ietf-dane-smtp-with-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: Thu, 13 Feb 2014 21:57:46 -0000 Dear DANE WG, The authors of draft-ietf-dane-smtp-with-dane have indicated that they believe that the document is ready, and have asked for Working Group Last Call. The draft is available here: https://datatracker.ietf.org/doc/draft-ietf-dane-smtp-with-dane/ Please review this draft to see if you think it is ready for publication and send comments to the list, clearly stating your view. This WGLC ends 10-March-2014. We are having a somewhat longer than normal WGLC because: A: folk are often really busy before meetings and we want to make sure they have time to carefully review the draft. B: if there are any issues we can discuss them in London. Thanks, Warren Kumari (as DANE WG co-chair) From nobody Thu Feb 13 13:58:22 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 7C05F1A02FF for ; Thu, 13 Feb 2014 13:58:20 -0800 (PST) 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 e-YhNBPnynOo for ; Thu, 13 Feb 2014 13:58:17 -0800 (PST) Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) by ietfa.amsl.com (Postfix) with ESMTP id 6F2C31A02F1 for ; Thu, 13 Feb 2014 13:58:17 -0800 (PST) Received: by mail-wi0-f181.google.com with SMTP id hi5so9278142wib.2 for ; Thu, 13 Feb 2014 13:58:15 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=0E30yH1JfytYevtCaCncdxWHjQKrpH+CJVwtz/pEb0g=; b=bvU9y2bYEXM7l1cIV0jsR3Vs7bMyUm3RlCpoVqgPQaNoszbGUR7w8KVMszuXpzlrlz vhmX186PzPTDGTzqwaIjpaawe3a1JQzjsS8LJU2GBz5zjuQNXKHWbmV9EbNDZ1HYV+MS 1uzo2Dzwqa1tlPCLcEUXNGT9w+F9B+EgWRF3FxevBqOFnKdwg26g4iRSi/yS79HGuL10 +39uYHOZMkt7/8S7gMzxOjd7elZoblO/xNWO9asPbKpi2jn2MejXj/sjFSCbbe7GVeTz I48mEmlQ3RdSKEVn0k+qiZseAaa4QQiE4Sgq7I2vpQ9KriGg43V2UzqTnFBHS1cRRtkh e8pg== X-Gm-Message-State: ALoCoQlmd+oyN2VNXEoF1NPLYpAZ8O/HYf7d7PP+h3GOEuAb6rjjEEBDUSdyP1g6lx+SMALXN8O3 MIME-Version: 1.0 X-Received: by 10.194.62.206 with SMTP id a14mr3339246wjs.26.1392328695648; Thu, 13 Feb 2014 13:58:15 -0800 (PST) Received: by 10.194.54.167 with HTTP; Thu, 13 Feb 2014 13:58:15 -0800 (PST) X-Originating-IP: [50.201.180.2] Date: Thu, 13 Feb 2014 16:58:15 -0500 Message-ID: From: Warren Kumari To: dane@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/A-32g8856YKX69ivqNx-SBxHLU0 Subject: [dane] Reminder about IPR relating to draft-ietf-dane-smtp-with-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: Thu, 13 Feb 2014 21:58:20 -0000 Subject: Reminder about IPR relating to draft-ietf-dane-smtp-with-dane Dear DANE WG, Be not alarmed. This email was created to satisfy RFC 6702 "Promoting Compliance with Intellectual Property Rights (IPR)" (http://tools.ietf.org/rfc/rfc6702.txt). The authors of draft-ietf-dane-smtp-with-dane have asked for a Working Group Last Call. Before issuing the Working Group Last Call, we would like to check whether any claims of Intellectual Property Rights (IPR) on the document have not yet been disclosed. Are you personally aware of any IPR that applies to draft-ietf-dane-smtp-with-dane? If so, has this IPR been disclosed in compliance with IETF IPR rules? (See RFCs 3979, 4879, 3669, and 5378 for more details.) If you are a document author or listed contributor on this document, please reply to this email regardless of whether or not you are personally aware of any relevant IPR. We might not be able to advance this document to the next stage until we have received a reply from each author and listed contributor. If you are on the DANE WG email list but are not an author or listed contributor for this document, you are reminded of your opportunity for a voluntary IPR disclosure under BCP 79. Please do not reply unless you want to make such a voluntary disclosure. Online tools for filing IPR disclosures can be found at . Thanks, Warren Kumari (as DANE WG co-chair) From nobody Thu Feb 13 15:27:45 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 EC74E1A0037 for ; Thu, 13 Feb 2014 15:27:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.548, 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 tckdw5lQ5onr for ; Thu, 13 Feb 2014 15:27:42 -0800 (PST) Received: from ore.jhcloos.com (ore.jhcloos.com [198.147.23.85]) by ietfa.amsl.com (Postfix) with ESMTP id 2A68E1A0023 for ; Thu, 13 Feb 2014 15:27:42 -0800 (PST) Received: by ore.jhcloos.com (Postfix, from userid 10) id 8EE761DFF4; Thu, 13 Feb 2014 23:27:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore13; t=1392334058; bh=SP46fwbso/qJiqS5Be4hN0QnePiH/Z+uTk2ZwLcrrRM=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=QQnrvUT7TzuxjAFTn1sZK+xuMvnachr6kTPXytDzR0zXLTJvrDMYxaeGN56Z9C0V3 lR9Tdb2irQIJry178xt3KKPW2f7yUegU2IFqWlGav4Yu7BTEbx6jEEZPKvaikpianK 2BG4bfJ+9H6stpZ6Ie9RdxIVVajfSfnBfYZuPBHSOPQ== Received: by carbon.jhcloos.org (Postfix, from userid 500) id 9E4A260021; Thu, 13 Feb 2014 23:05:20 +0000 (UTC) From: James Cloos To: In-Reply-To: (Eric Osterweil's message of "Thu, 13 Feb 2014 18:19:10 +0000") References: <07ba01cf23b9$4b4e0540$e1ea0fc0$@augustcellars.com> User-Agent: Gnus/5.13001 (Ma Gnus v0.10) Emacs/24.3.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2014 James Cloos OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Thu, 13 Feb 2014 18:05:20 -0500 Message-ID: Lines: 19 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:140213:dane@ietf.org::ZnkeC1KF5uYtCKLS:000Q41lJ X-Hashcash: 1:30:140213:eosterweil@verisign.com::YadfFe+opV2otP4b:0000000000000000000000000000000000000b/Sgv X-Hashcash: 1:30:140213:ietf@augustcellars.com::HhGm0GXaqI3f4kje:00000000000000000000000000000000000000tZ6ly X-Hashcash: 1:30:140213:draft-ietf-dane-smime\@tools.ietf.org\::dNwr7zePZPPrkKkE:0000000000000000000000V5KWK X-Hashcash: 1:30:140213:draft-ietf-dane-smime@tools.ietf.org::rlxwRp8Dgeov6mw8:000000000000000000000000j4Ku9 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/rHBZTpI_3SOA9yALWwPxOHe5efE Cc: "" Subject: Re: [dane] Comments on draft-ietf-dane-smime-04 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: Thu, 13 Feb 2014 23:27:44 -0000 >>>>> "OE" == Osterweil, Eric writes: OE> With PGP, I can use a key with a diff email than the account from OE> which I send it (for ex, I can use my spam account and rely on my OE> full name and friends who know me to make the logical leap), do we OE> all want DANE to outlaw this for S/MIME? Absolutely not. There is no value in forcing the sending email address to match the info in any signature over the message (or over any part of the message). (With emphasis on /forcing/.) Those details may be used as *part* of the trust equation, but only as part. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From nobody Thu Feb 13 16:00:13 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 5F3051A0045 for ; Thu, 13 Feb 2014 16:00:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 HdnhTEWnNqkp for ; Thu, 13 Feb 2014 16:00:10 -0800 (PST) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id B52D41A0015 for ; Thu, 13 Feb 2014 16:00:10 -0800 (PST) Received: from Philemon (c-24-17-142-118.hsd1.wa.comcast.net [24.17.142.118]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 362952CA5A; Thu, 13 Feb 2014 16:00:09 -0800 (PST) From: "Jim Schaad" To: "'James Cloos'" , References: <07ba01cf23b9$4b4e0540$e1ea0fc0$@augustcellars.com> In-Reply-To: Date: Thu, 13 Feb 2014 15:58:28 -0800 Message-ID: <031901cf2917$7e158580$7a409080$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJWZ2fdiOlqr2x3rpj6mp3NvfVHUQChrvVOAdDIm5eZkcwFIA== Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/dane/b3HepsmrtEmxKQezcaPOA_m750w Cc: draft-ietf-dane-smime@tools.ietf.org Subject: Re: [dane] Comments on draft-ietf-dane-smime-04 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, 14 Feb 2014 00:00:12 -0000 So what email address are you going to use to do the dane lookup? The one embedded in the PGP key (assuming one exists), the from address? Does this need to be spelled out in both of the drafts (S/MIME and PGP). Jim > -----Original Message----- > From: James Cloos [mailto:cloos@jhcloos.com] > Sent: Thursday, February 13, 2014 3:05 PM > To: dane@ietf.org > Cc: Osterweil, Eric; Jim Schaad; > Subject: Re: [dane] Comments on draft-ietf-dane-smime-04 > > >>>>> "OE" == Osterweil, Eric writes: > > OE> With PGP, I can use a key with a diff email than the account from > OE> which I send it (for ex, I can use my spam account and rely on my > OE> full name and friends who know me to make the logical leap), do we > OE> all want DANE to outlaw this for S/MIME? > > Absolutely not. > > There is no value in forcing the sending email address to match the info in > any signature over the message (or over any part of the message). > > (With emphasis on /forcing/.) > > Those details may be used as *part* of the trust equation, but only as part. > > -JimC > -- > James Cloos OpenPGP: 1024D/ED7DAEA6 From nobody Fri Feb 14 08:07:54 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 2C9441A02D6 for ; Fri, 14 Feb 2014 08:07:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.749 X-Spam-Level: X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, 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 r-3aTuPpqaLz for ; Fri, 14 Feb 2014 08:07:49 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id B100A1A0284 for ; Fri, 14 Feb 2014 08:07:45 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:50928 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1WELIl-000K28-OW for dane@ietf.org; Fri, 14 Feb 2014 11:07:43 -0500 Message-ID: <52FE3F4D.6020100@bbn.com> Date: Fri, 14 Feb 2014 11:07:41 -0500 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: dane@ietf.org References: <07ba01cf23b9$4b4e0540$e1ea0fc0$@augustcellars.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dane/dQj-LzVEzU2rFDHYag0q9k5u_oY Subject: Re: [dane] Comments on draft-ietf-dane-smime-04 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, 14 Feb 2014 16:07:51 -0000 James, >>>>>> "OE" == Osterweil, Eric writes: > OE> With PGP, I can use a key with a diff email than the account from > OE> which I send it (for ex, I can use my spam account and rely on my > OE> full name and friends who know me to make the logical leap), do we > OE> all want DANE to outlaw this for S/MIME? > > Absolutely not. > > There is no value in forcing the sending email address to match the info > in any signature over the message (or over any part of the message). > > (With emphasis on /forcing/.) From an OE perspective, I see your point. Form a general security perspective, I disagree. Folks receiving a signed message tend to assume that the "from" field has been checked against the Subject or SAN in the signer's cert. It's a reasonable expectation. When that reasonable assumption is not true, users are surprised, and surprise is a bad outcome wrt security :-). Steve From nobody Fri Feb 14 09:18: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 2CF891A02F6; Fri, 14 Feb 2014 09:18:39 -0800 (PST) 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 I_iTp_1WJDQ2; Fri, 14 Feb 2014 09:18:37 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DEB61A0307; Fri, 14 Feb 2014 09:18:36 -0800 (PST) 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.0.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140214171836.22671.11628.idtracker@ietfa.amsl.com> Date: Fri, 14 Feb 2014 09:18:36 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/uRPM_xA4ghuPCZ-REC8SQdAEPow Cc: dane@ietf.org Subject: [dane] I-D Action: draft-ietf-dane-smtp-with-dane-07.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: Fri, 14 Feb 2014 17:18:39 -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-07.txt Pages : 29 Date : 2014-02-14 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-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-dane-smtp-with-dane-07 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 Fri Feb 14 09:31: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 2C8DB1A034A for ; Fri, 14 Feb 2014 09:31:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.955 X-Spam-Level: X-Spam-Status: No, score=0.955 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.793] 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 lPOY5FcOZbPX for ; Fri, 14 Feb 2014 09:31:22 -0800 (PST) Received: from mail.hardakers.net (unknown [IPv6:2001:470:1f00:187::1]) by ietfa.amsl.com (Postfix) with ESMTP id 449291A0339 for ; Fri, 14 Feb 2014 09:31:19 -0800 (PST) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id 4646A25DE7 for ; Fri, 14 Feb 2014 09:31:16 -0800 (PST) From: Wes Hardaker To: dane@ietf.org References: <20140214171836.22671.11628.idtracker@ietfa.amsl.com> Date: Fri, 14 Feb 2014 09:31:16 -0800 In-Reply-To: <20140214171836.22671.11628.idtracker@ietfa.amsl.com> (internet-drafts@ietf.org's message of "Fri, 14 Feb 2014 09:18:36 -0800") Message-ID: <0l7g8xvbx7.fsf@wjh.hardakers.net> User-Agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/dane/v-UnUmQbd70SLRf1R5-L0Stxjh8 Subject: Re: [dane] I-D Action: draft-ietf-dane-smtp-with-dane-07.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, 14 Feb 2014 17:31:24 -0000 internet-drafts@ietf.org writes: > 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. The only changes in this version are fixes for idnits and cleaning up of the required references. -- Wes Hardaker Parsons From nobody Fri Feb 14 10:24: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 67D1C1A03CA; Fri, 14 Feb 2014 10:24:34 -0800 (PST) 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 fs1e7RDHpA6E; Fri, 14 Feb 2014 10:24:33 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EF831A03D6; Fri, 14 Feb 2014 10:24:30 -0800 (PST) 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.0.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140214182430.14035.4545.idtracker@ietfa.amsl.com> Date: Fri, 14 Feb 2014 10:24:30 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/t9ZkbRXk4VEC1ckVBzJMIe_htG8 Cc: dane@ietf.org Subject: [dane] I-D Action: draft-ietf-dane-registry-acronyms-04.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: Fri, 14 Feb 2014 18:24:34 -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 : Adding acronyms to simplify DANE conversations Author : Olafur Gudmundsson Filename : draft-ietf-dane-registry-acronyms-04.txt Pages : 5 Date : 2014-02-14 Abstract: Experience has shown that people get confused using the three numeric fields the TLSA record. This document specifies descriptive acronyms for the three numeric fields in the TLSA records. This document updates the format of the IANA registry created by RFC6698. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dane-registry-acronyms/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dane-registry-acronyms-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-dane-registry-acronyms-04 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 Fri Feb 14 11:16: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 A9AE71A0068 for ; Fri, 14 Feb 2014 11:16:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] 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 WZgWKx_qIaUd for ; Fri, 14 Feb 2014 11:16:33 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 278C11A02F7 for ; Fri, 14 Feb 2014 11:16:32 -0800 (PST) Received: from [10.20.30.90] (50-1-98-67.dsl.dynamic.sonic.net [50.1.98.67]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s1EJGS8w064953 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 14 Feb 2014 12:16:29 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-67.dsl.dynamic.sonic.net [50.1.98.67] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Paul Hoffman In-Reply-To: Date: Fri, 14 Feb 2014 11:16:27 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Warren Kumari X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/hiLmFeFt2la4MKOOKGngIhsZCsc Cc: "" Subject: Re: [dane] Preliminary agenda for London 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, 14 Feb 2014 19:16:35 -0000 On Feb 13, 2014, at 1:43 PM, Warren Kumari wrote: > Please let us know if there is anything you'd like to add to the = below... Yes, definitely. There needs to be discussion on whether DANE is for = acquisition of key assocation material, for discovering services that = use the keying material, for having assurance that a service that uses = the keying material should be available, or some combination of these. = The SMTP draft has a very different take on this than what the WG agreed = on for RFC 6698. And, before someone replies to this heated topic, please start a new = thread. It would be *really* useful for the London discussion if we have = a focused discussion on the list first. --Paul Hoffman= From nobody Fri Feb 14 11:18: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 CBD6E1A02E9 for ; Fri, 14 Feb 2014 11:18:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] 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 oPspNVp1iTjs for ; Fri, 14 Feb 2014 11:18:42 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 7203A1A0374 for ; Fri, 14 Feb 2014 11:18:36 -0800 (PST) Received: from [10.20.30.90] (50-1-98-67.dsl.dynamic.sonic.net [50.1.98.67]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s1EJGS8x064953 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 14 Feb 2014 12:17:17 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-67.dsl.dynamic.sonic.net [50.1.98.67] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Paul Hoffman In-Reply-To: <07ba01cf23b9$4b4e0540$e1ea0fc0$@augustcellars.com> Date: Fri, 14 Feb 2014 11:17:16 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <35DEAFB0-54C5-4E36-923D-36644F88CE7D@vpnc.org> References: <07ba01cf23b9$4b4e0540$e1ea0fc0$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/ksckwwTpC5jat2EujAVeKpT-7Vg Cc: "" Subject: Re: [dane] Comments on draft-ietf-dane-smime-04 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, 14 Feb 2014 19:18:44 -0000 On Feb 6, 2014, at 8:01 PM, Jim Schaad wrote: > 1. Section 1, para 1: The first two sentences imply that a single > certificate is going to be present in a message. While this is true = in a > large number of cases, there are many times in which more than one > certificate may be present. These include having different signing an > encrypting keys or intermediate certificates for chain building. I = would > request that the first two sentences be modified to make certificate = be > plural. s/a certificate. This certificate assists/certificates. = These > certificates assist/ Done. > 2. Section 1, para 1: The last sentence is missing a step in the = description > of the process of validating that certificate is bound to a purported > sender. The current text just looks at the validation process and = does not > talk about what is necessary to check the binding itself. In most = cases, > but not all, this involves looking for the senders email address in = the > certificate itself. (In other cases some type of external database = would be > required or one could say that the sender and the signer may not be = the same > person even though the signature itself validates.) >=20 > One thing about this document that I don't remember having seen on the = list > is the question of doing the binding check between the senders address = and > the contents of a certificate. Is it going to be considered = sufficient if > one does the DNS look up for the certificates? Is it only a = sufficient > check for some types of SMIMEA records but not for others? I.e. EE > certificate vs CA or TA certificate. >=20 > The document needs to distinguish between the steps of validating and > trusting a certificate and doing the binding between an email address = and a > certificate. While it is possible to both in some cases, in others = these > need to be distinct steps. Nope, that's out of scope (and we have added a sentence to that effect). = This document should *not* change, nor even repeat, the identity-binding = rules for S/MIME. > 3. Section 2, para 1: First sentence - see the last item. It may be = not > an EE certificate that is being associated. It is *always* an EE cert that is being associated. It may not be an EE = cert that was gotten through SMIMEA. I have added wording to that = effect. > 4. Section 3, step 1: It would be nice to be explicit that you are = doing a > UTF8 Unicode string to octet string transformation before doing the = Base32 > conversion. The referenced document says that this is the case for = SMTP > submission in one mode, but it is not clear that the SMTP submission = format > is what we are doing here. Being explicit would be helpful. Yep. > There are two general problems that people are looking to solve with = this > document. >=20 > A) I have an email address and a certificate, I want to validate the > certificate and check the association between the certificate and the = email > address. >=20 > B) I have an email address, I need to find a certificate. >=20 > At present I believe that this document is addressing problem A and = not > problem B. It would be good to state that problem B is out of scope = in the > introduction if this is the case. As this is the debate that has happened later in the WG, we have not = added that to the new draft, but we expect to have to address this in a = later draft. It is a WG-wide issue, not related just to SMIMEA. I have = added a placeholder in the introduction for this topic. I'll post the new draft after PaulW posts his with the new hash-of-LHS = text. --Paul Hoffman= From nobody Fri Feb 14 12:00:10 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 217461A0361 for ; Fri, 14 Feb 2014 12:00:08 -0800 (PST) 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 jFGCf6flNUtc for ; Fri, 14 Feb 2014 12:00:05 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 45FC21A0323 for ; Fri, 14 Feb 2014 12:00:04 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id BB35D2AAD11; Fri, 14 Feb 2014 20:00:02 +0000 (UTC) Date: Fri, 14 Feb 2014 20:00:02 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140214200002.GK278@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/d1ICZx_epgppr72Udfxv47DT6vA Subject: [dane] Lukewarm discussion: DANE for opportunistic TLS protocols 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: Fri, 14 Feb 2014 20:00:08 -0000 Paul Hoffman (thanks) points out that there may be prior consensus with respect to the applicability of DANE TLSA to "discovery" of TLS enabled services. I was not party to the original discussion of this topic, my apologies if I am about to repeat previously discussed ideas. The SMTP draft defines an opportunistically secure protocol. For inter-domain email on Internet scale, no domain has prior knowledge of the set of peer domains (more specifically their MX hosts) that support TLS. Today's MTA employ TLS opportunistically, based on the offer of the "STARTTLS" SMTP extension in the SMTP server's EHLO response. This offers no protection against MITM attacks (or even transient errors, as many SMTP clients will retry in cleartext after TLS transmission fails). The DANE SMTP draft aims to provide a downgrade-resistant protocol by which SMTP clients can determine (discover if you will) that a given SMTP server support TLS and expects DANE SMTP clients to avoid using cleartext delivery with the server. The associated TLSA records are used to authenticate the server to mitigate MITM attacks that terminate TLS (rather simply suppress it). If determining whether TLS support is required is incompatible with DANE, I see no purpose for the SMTP draft. We already unauthenticated opportunistic TLS for SMTP (STARTTLS) which is vulnerable to various downgrade attacks. Without a secure signal to do TLS, the downgrade attacks remain, and opportunistic TLS does not benefit from DANE. So I hope the group can reach consensus that it is OK to use TLSA records to discover a requirement for TLS. This approach is not new with the SMTP draft, it dates back to the original SRV draft from Tony Finch, and is still stated in the revived version of that document. -- Viktor. From nobody Fri Feb 14 13:41:12 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 94ADE1A03C8 for ; Fri, 14 Feb 2014 13:41:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 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.548] 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 MxPHbhI6n5By for ; Fri, 14 Feb 2014 13:41:07 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id A85BE1A023F for ; Fri, 14 Feb 2014 13:41:07 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 30B78800AA for ; Fri, 14 Feb 2014 16:41:05 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1392414065; bh=rh0LraqistVkT2gjsDnDgWdjRiEaVgg0ulOR2VQd1eg=; h=Date:From:To:Subject; b=pnpkeEoTGgT9Y4hPG9o1AwyTAMrOwkvH1nSZQn/xdOx/S9DTmB/sBDCMob8oPL8id yZXvQBvjYpXCg2uUmxt0pwaQ7UUkB07sx1B5jnWV1D5Etxed8N/Je2rnonX3MQPBDa eJR9SxiAWK6ZTur9q0pf/OKYZUOCF1dgFz+5wxgs= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s1ELf4re010788 for ; Fri, 14 Feb 2014 16:41:05 -0500 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Fri, 14 Feb 2014 16:41:04 -0500 (EST) From: Paul Wouters To: dane WG list Message-ID: 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/I1KP8XzpZKAfR7tOm6Z6SL9rD0g Subject: [dane] Fwd: New Version Notification for draft-wouters-dane-openpgp-02.txt (fwd) 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, 14 Feb 2014 21:41:10 -0000 This is an updated openpgpkey draft. It sticks to just the DNS RRtype definition. The usage of the record has been moved into its own document. Changes from last version are some clarifications, using SHA2-224 instead of BASE32, indicating hashing is not a security feature, and explaining that DNAME use is the reason why the hash does not include the full domain name. Paul -------- Original Message -------- A new version of I-D, draft-wouters-dane-openpgp-02.txt has been successfully submitted by Paul Wouters and posted to the IETF repository. Name: draft-wouters-dane-openpgp Revision: 02 Title: Using DANE to Associate OpenPGP public keys with email addresses Document date: 2014-02-13 Group: Individual Submission Pages: 8 URL: http://www.ietf.org/internet-drafts/draft-wouters-dane-openpgp-02.txt Status: https://datatracker.ietf.org/doc/draft-wouters-dane-openpgp/ Htmlized: http://tools.ietf.org/html/draft-wouters-dane-openpgp-02 Diff: http://www.ietf.org/rfcdiff?url2=draft-wouters-dane-openpgp-02 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. 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. The IETF Secretariat From nobody Fri Feb 14 13:41: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 B73871A040C for ; Fri, 14 Feb 2014 13:41:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 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.548] 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 LBOyau624Gjr for ; Fri, 14 Feb 2014 13:41:40 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id ED0561A023F for ; Fri, 14 Feb 2014 13:41:39 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 4D32C800AA for ; Fri, 14 Feb 2014 16:41:38 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1392414098; bh=8ypGfmN2fAksriFn8hqKvIdjBaH3TxlzbUlcr4Kj4l0=; h=Date:From:To:Subject; b=oqTgvXoFi03zpyWJQyGNGc0mYQi5INwhCrKnMMT8gHP2fcSsAtk3+j/gl3fvMCTGN vc9nOOFUAkYuQxBkep0k2icMH/r/YzdAC3c3gAyvGWC7cx7wvlypQqNw30K8ldy443 m725qTenWVbZ+1s09ttRSJzmbjngC0ZT63sju8/k= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s1ELfcwj010933 for ; Fri, 14 Feb 2014 16:41:38 -0500 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Fri, 14 Feb 2014 16:41:38 -0500 (EST) From: Paul Wouters To: dane WG list Message-ID: 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/xL_7fhoxOaAdR-Dk3UiFQQ68xGg Subject: [dane] Fwd: New Version Notification for draft-wouters-dane-openpgpkey-usage-00.txt (fwd) 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, 14 Feb 2014 21:41:41 -0000 And this document is a start for discussing the usage of openpgpkey records by email clients, MUA's and MTA's. Paul -------- Original Message -------- A new version of I-D, draft-wouters-dane-openpgpkey-usage-00.txt has been successfully submitted by Paul Wouters and posted to the IETF repository. Name: draft-wouters-dane-openpgpkey-usage Revision: 00 Title: Best Common Practise for using OPENPGPKEY records Document date: 2014-02-14 Group: Individual Submission Pages: 8 URL: http://www.ietf.org/internet-drafts/draft-wouters-dane-openpgpkey-usage-00.txt Status: https://datatracker.ietf.org/doc/draft-wouters-dane-openpgpkey-usage/ Htmlized: http://tools.ietf.org/html/draft-wouters-dane-openpgpkey-usage-00 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. 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. The IETF Secretariat From nobody Fri Feb 14 13:48: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 3CCE51A02C0 for ; Fri, 14 Feb 2014 13:48:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 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.548] 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 FnmLXmzC92wm for ; Fri, 14 Feb 2014 13:48:27 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 63DD91A032B for ; Fri, 14 Feb 2014 13:48:27 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id B3BE5800AA for ; Fri, 14 Feb 2014 16:48:25 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1392414505; bh=Lq9xKyEY1QrcJo2/2JMAF8K+1aNBIcGzTrJ1znjSYPk=; h=Date:From:To:Subject; b=WFzWVVtqq4hjwG3dkSqNMTHvaRSyetcinibITtXspfHy1anNGoc5OXit2I1WPPkqy Cj0PSxtfVqgHKXcBq8xAd1rNsDxNHPC5qaC7KTQXSH3EPprTFaEuUtxhBqqLSpXsNT nOelx4ejJOJQub1rEvpGj0+vIVTxWCmD8K1fQJzQ= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s1ELmPhc012415 for ; Fri, 14 Feb 2014 16:48:25 -0500 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Fri, 14 Feb 2014 16:48:25 -0500 (EST) From: Paul Wouters To: dane WG list Message-ID: User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/dane/NIebG-VO-Fqm8ZqAeCKYS8NGkuw Subject: [dane] openpgpkey-milter-02 milter application 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, 14 Feb 2014 21:48:33 -0000 I forgot to mention that I wrote a sample milter implementation of draft-wouters-dane-openpgp-02. This milter will attempt to encrypt plaintext messages received as MUA or MTA. Feel free to test it with me using paul@nohats.ca, which is publishing an OPENPGPKEY record. ftp://ftp.nohats.ca/openpgpkey-milter/ https://github.com/letoams/openpgpkey-milter It has been packaged up for Fedora and EPEL (RHEL/CentOS) It has only been tested with postfix, but should work with sendmail too. There is some chance that python-gnupg does not like your key, especially if using exotic non-ascii characters. Or punycode. Paul From nobody Fri Feb 14 13:50:00 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 0A9BF1A0437 for ; Fri, 14 Feb 2014 13:49:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.493 X-Spam-Level: X-Spam-Status: No, score=0.493 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, TVD_PH_BODY_ACCOUNTS_PRE=2.393] 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 QMY9E-W84RhI for ; Fri, 14 Feb 2014 13:49:50 -0800 (PST) Received: from smtp68.ord1c.emailsrvr.com (smtp68.ord1c.emailsrvr.com [108.166.43.68]) by ietfa.amsl.com (Postfix) with ESMTP id CC2951A03E4 for ; Fri, 14 Feb 2014 13:49:46 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp1.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 4281B148405; Fri, 14 Feb 2014 16:49:45 -0500 (EST) X-Virus-Scanned: OK Received: by smtp1.relay.ord1c.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id 035D7148257; Fri, 14 Feb 2014 16:49:44 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Olafur Gudmundsson In-Reply-To: <52A23651.4000504@stpeter.im> Date: Fri, 14 Feb 2014 16:49:44 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <1D3B309F-B2FD-4316-9AA4-C73CC3CD4F10@ogud.com> References: <529E7488.80601@stpeter.im> <52A23651.4000504@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/PwCxvtsJvHQQxk_wis_VakLaX6w Cc: "dane@ietf.org list" Subject: Re: [dane] terminology question 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, 14 Feb 2014 21:49:53 -0000 On Dec 6, 2013, at 3:40 PM, Peter Saint-Andre = wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > Hi Olafur, thanks for the reply. Comments inline. >=20 > On 12/4/13 6:47 AM, Olafur Gudmundsson wrote: >>=20 >> On Dec 3, 2013, at 7:17 PM, Peter Saint-Andre =20 >> wrote: >>=20 >> In RFC 6125, Jeff Hodges and I tried hard to define some >> terminology related to certificate checking in TLS. That >> terminology might not be ideal, but I'd like to see if we can >> align draft-ogud-dane-vocabulary with the RFC 6125 terms. >>=20 >> In particular, RFC 6125 uses the term "source domain" to refer to=20 >> the fully qualified domain name that a TLS client expects to find >> in the certificate (or, in DANE, potentially the key) that is >> presented by the TLS server. RFC 6125 also uses the term "derived >> domain" to refer to a domain name (or host name) that the client >> has derived from the source domain in an automated fashion (e.g., >> via a DNS SRV record). >>=20 >> As far as I can determine, draft-ogud-dane-vocabulary uses the >> terms "Query [Name]" and "Final [Name]" for something like "source >> domain" and "derived domain". However, draft-ogud-dane-vocabulary >> also uses the terms "Service Specification Records" and "Service >> Address Records" in a way that might be similar, although I confess >> that I don't really grok draft-ogud-dane-vocabulary in fullness and >> the latter two terms are unclear to me. >>=20 >>> Peter, >>=20 >>> Thanks asking this question, >>=20 >>> You made me read RFC6125 and to my horror the vocabulary there >>> is attempting similar things as I'm doing in my draft, but in >>> section 1.8 I realized that you might have taken a shortcut that >>> leads to a incomplete specification i.e. you are not taking into >>> account the effects of CNAME and DNAME records on the resolution, >>> in particular DNAME requires careful rules as to the names used >>> to present to the servers. (my guess is this is where the "i >>> don't really grok" comment comes from) (I think NAPTR has >>> similar effects). >=20 > You are right, we did not address CNAME, DNAME, or NAPTR. The spec was > already convoluted enough. :-) But I think that was an oversight on > our part. I've bcc'd Jeff so he's aware of it. >=20 >>> "Source domain" definition is a good example of this. In=20 >>> -vocabulary- draft the application issues query for "query name" >=20 > Which, I take it, is roughly equivalent to "Name" in RFC 2782, right? Yes just more expressive :-)=20 >=20 >>> where it is expecting to find the "Service Specification >>> Records". >=20 > I'm not clear on exactly what those are. Perhaps a few (clearer?) > examples would help. The current examples confuse me: >=20 > Protocols have different ways to provide information about where > servers are located. Web servers are frequently specified by name > i.e. the "www" prefix. Email servers have a special RR type (MX), > Jabber uses SR records, ENUM uses NAPTR records etc. and there are > also protocols that use a combination like S-NAPTR a schema where > NAPTR records are used to specify where to look for SRV records. = For > all practical purposes NAPTR + SRV should combined be treated as the > Service Specification. >=20 > Does this mean that "www" is a Service Specification Record? ;-) No it says the "A" record at www=85 is the SSR=20 I will fix this text to be clearer, rewrote the section to large extent.=20= >=20 > It makes sense to me that, say, the result of an MX or SRV query is a > "Service Specification Record" -- a query for _Service._Proto.Name > gives you one or more addresses that together specify the service. For > example: >=20 In my terminology the MX is the Service Specification Record.=20 > $ dig +short -t SRV _xmpp-server._tcp.google.com > 5 0 5269 xmpp-server.l.google.com. > 20 0 5269 alt3.xmpp-server.l.google.com. > 20 0 5269 alt2.xmpp-server.l.google.com. > 20 0 5269 alt1.xmpp-server.l.google.com. > 20 0 5269 alt4.xmpp-server.l.google.com. >=20 > Is that what you have in mind? >=20 YES >>> but DNAME/NAPTER/CNAME rules may rewrite the name sent to=20 >>> application server to the "resulting name" from the query >=20 > Understood. >=20 >>> thus the term "Offered Name". >=20 > Offered by whom? >=20 The application when it sends a "name" in its request after connecting.=20= >>> For HTTP Service Specification Records =3D=3D Service Address >>> records i.e. address record is the service specification, >=20 > I assume that's because no MX, SRV, etc. is used for HTTP? >=20 Yes we are living with the mistake of HTTP of not using SRV records in = the beginning :-)=20 >>> but Jabber uses SRV records for the Service Specification >>> Records and the Service Address Records are associated with the >>> servers listed in the SRV RRset. >=20 > What does "associated with" mean here? >=20 The intent is say, "the address records returned when the address = records of the=20 servers are queried for" ?=20 =20 > I find the definition of "Service Address Records" confusing, too: >=20 > This is where the address records used by the servers reside, > specifications SHOULD NOT make a difference between what kind of > address records are used. >=20 > I am not sure what you mean when you talk about location here, i.e., > the place where the address records reside. What kind of location are > we talking about? >=20 I agree and will fix I was trying to cover both IPv4 and v6 plus the = possibility of geolocated address being returned.=20 How about: "These are the address records for the that offer the = service."=20 >>> To a large extent I think the differences we see are due to the=20 >>> different approaches, i.e. you are attempting to word rules for=20 >>> existing applications. >=20 > Yes. Plus I don't have a pair of DNS glasses that enables me to see > things the way you do. >=20 Nor do I have good App glasses :-)=20 >>> I'm defining rules that are general and ignore the names >>> existing applications have used an concentrate on concepts that >>> then can be used by application specifications. I wanted to >>> create definitions that allow minimal DNS related text inside a >>> DANE application specification (not sure I'm there yet). >=20 > Yes, I can see that's what you're doing. However, I find the level of > abstraction you've reached to be a bit rarified. At least, it's not > grounded in things that I can grasp easily (application space). But > that's perhaps my problem, not yours. :-) >=20 I think it is both our problems, I need to do better job of explaining, others need to tell me what needs explanation.=20 >> Naming is hard, and I hope we can get it right. >>=20 >>=20 >>> Naming of concepts is hard, definitions are hard, understanding >>> the nuances of interaction of multiple protocols is even harder >>> :-) >=20 > Indeed. :-) >=20 Sorry for taking this long to respond this fell of my todo list :-(=20 Olafur > Peter >=20 > - --=20 > Peter Saint-Andre > https://stpeter.im/ >=20 From nobody Fri Feb 14 14:44: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 5D2181A02E2; Fri, 14 Feb 2014 14:44:20 -0800 (PST) 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 aB1N_f06bM4N; Fri, 14 Feb 2014 14:44:18 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 642161A031E; Fri, 14 Feb 2014 14:44:17 -0800 (PST) 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.0.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140214224417.12588.43350.idtracker@ietfa.amsl.com> Date: Fri, 14 Feb 2014 14:44:17 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/wi4WaqNnfo2zoMqiKpO4K4KQOhg Cc: dane@ietf.org Subject: [dane] I-D Action: draft-ietf-dane-smime-05.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: Fri, 14 Feb 2014 22:44:20 -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 Secure DNS to Associate Certificates with Domain Names For S/MIME Authors : Paul Hoffman Jakob Schlyter Filename : draft-ietf-dane-smime-05.txt Pages : 7 Date : 2014-02-14 Abstract: This document describes how to use secure DNS to associate an S/MIME user's certificate with the intended domain name, similar to the way that DANE (RFC 6698) does for TLS. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dane-smime/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dane-smime-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-dane-smime-05 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 Fri Feb 14 14:57: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 AB8D81A01E0 for ; Fri, 14 Feb 2014 14:57:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_44=0.6, RP_MATCHES_RCVD=-0.548, 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 ZCDi0eaDiO0D for ; Fri, 14 Feb 2014 14:57:34 -0800 (PST) Received: from ore.jhcloos.com (ore.jhcloos.com [IPv6:2604:2880::b24d:a297]) by ietfa.amsl.com (Postfix) with ESMTP id 8C2411A02D0 for ; Fri, 14 Feb 2014 14:57:33 -0800 (PST) Received: by ore.jhcloos.com (Postfix, from userid 10) id E32A91DF86; Fri, 14 Feb 2014 22:57:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore13; t=1392418650; bh=G6hD1EKHP5bflPQtcG9rfw8WD8WRTHqLc4txKVr56Fw=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=heLwnASPXu6XckM3kFFAx2TACYsa/yCAp28ypyaKScBaCZdbYYJklnqzSSEkj6EI6 oyjGlNWQ2f8e1pvtp9btnlKxm2Qn9dEPjzinIFoUSNLbG+6CeSQuZQVDiEzezFQwDy puSbtDMi4G/Mix5NlRQ662LR6HtXwFn+qey4bPNQCRA== Received: by carbon.jhcloos.org (Postfix, from userid 500) id D29DE60021; Fri, 14 Feb 2014 22:50:44 +0000 (UTC) From: James Cloos To: dane@ietf.org In-Reply-To: <20140214200002.GK278@mournblade.imrryr.org> (Viktor Dukhovni's message of "Fri, 14 Feb 2014 20:00:02 +0000") References: <20140214200002.GK278@mournblade.imrryr.org> User-Agent: Gnus/5.13001 (Ma Gnus v0.10) Emacs/24.3.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2014 James Cloos OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Fri, 14 Feb 2014 17:50:38 -0500 Message-ID: Lines: 40 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" X-Hashcash: 1:30:140214:dane@ietf.org::Ja6HsAXSRpfTZONy:0007J1kL X-Hashcash: 1:30:140214:viktor1dane@dukhovni.org::XDfW1TRx4b5rbeR6:000000000000000000000000000000000000sILL+ Archived-At: http://mailarchive.ietf.org/arch/msg/dane/3sEB5M9UzXlmIn-Y1cha8LXrMl8 Subject: Re: [dane] Lukewarm discussion: DANE for opportunistic TLS protocols 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, 14 Feb 2014 22:57:38 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable It is important to note that many (though not all) of the original proponents only seemed to care about http, where opportunistic tls never caught on. Even with ipp, where existing software actually support it, the preference seems to be to use ipps:// (on the same port as ipp://) or https:// (on port 443) uris over using rfc2817 tls upgrade. But even so there were voices hoping for a mechanism to stipulate that tls SHOULD or even MUST be used for a given name+port. My impression at the time was that the consensus not to include language to that effect it rfc 6698 was not consensus that such a mechanism was undesireable, but just that it wasn=E2=80=99t generally enough wanted to wa= rrant making it a part of the base specification rather than part of some more specific followup specification. Clearly there needs to be a way to say =E2=80=98Use TLS when contacting this server, even though the protocol takes extra steps to do so.=E2=80=99 The existence of a relevant, secure TLSA is not an unreasonable way for specific tls communities to do so. Even though the broader tls community may not need (or want) such a mechanism for their servers. Not only do I encourage rfc publication of some mix of the dane-smtp- with-dane and dane-srv drafts, but I do not agree that either is contrary to the consensus for publishing what is now rfc 6698. Once the details are worked out -- progress looks good -- that also applies to the smime and openpgp drafts. The only real question is whether dane-srv and dane-smtp-with-dane should be published as two rfcs or combined into one? (I=E2=80=99m leaning towards two, numerically adjacent.) =2DJimC =2D- James Cloos OpenPGP: 1024D/ED7DAEA6 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJS/p3dAAoJECPGzfcnLZ1Dj0wP/2OheuGQiEs3MYYtCl9aUVyO S9fWOr7YLhCGkU9IKGLaM31Eo2gtSdgmOOTyTQwRxiKtlSJhqdESb6KklMPk0mar auGlTXd6io9vCIvw6l90TCgvqeD6g+eqBgs38z2udX2YblmI7OgGKUS5O89ZDPKn i60DxHOSD0N1YEPwj9cPT0uZ1VmzjeaFJS2FZ5qNLLEqLChn3qM26iEELdOFdPwZ l+5rB21y7uWgjoNNteJZ+to0hhfF19UtseDythnfD6oJ4oUOJKoDwCVULnRJyXD6 tsb+cG90x8yNRjGb84bJAbyjLBQR3lge8i4oJsqY8fYX1VG3ogpbQrGCHv8svwuT 4rQ8i6VzJ5wDYjLzZF9eGgSdXmTIECq6pKMDxLA/+d96+yJ8c9xKDh2yLP3q4nDi 0plIMUUxfOmaYM68oketCov+/TsW8cllnLr6Tmuh9sXC7D7fqpsr9nb8D2pne9cH eFxndbfaBewE5gn2cr44vLftnBGY+J33TnyiRDSa0HnmbBGtU1is59A3Izltxnwk frpsIK78/gd5IobFILaHXoINxVOUnmWaLqjfmOFYSzZJS5DSZEf2PT2jK4YcG5XJ OOz7nTBHzN9Oj9R0ezMl/d+ZE4n52oK9PEQWiIsE3RuOGNc10k9pNfmAZObyEI2/ 2PMDVFTm+AI987CHme8X =ZRFQ -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Feb 14 15:02:34 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 529AB1A029A for ; Fri, 14 Feb 2014 15:02:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, 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 mxs3w3bU0A0a for ; Fri, 14 Feb 2014 15:02:29 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id F1D3F1A00B5 for ; Fri, 14 Feb 2014 15:02:28 -0800 (PST) Received: from aither.local (unknown [24.8.129.242]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id BDA3D4010C; Fri, 14 Feb 2014 16:02:26 -0700 (MST) Message-ID: <52FEA082.5090908@stpeter.im> Date: Fri, 14 Feb 2014 16:02:26 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: James Cloos , dane@ietf.org References: <20140214200002.GK278@mournblade.imrryr.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/dane/62uZz2lyoNwFRv10dfkfqQAG0Eg Subject: Re: [dane] Lukewarm discussion: DANE for opportunistic TLS protocols 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, 14 Feb 2014 23:02:31 -0000 On 2/14/14, 3:50 PM, James Cloos wrote: > The only real question is whether dane-srv and dane-smtp-with-dane > should be published as two rfcs or combined into one? > (I’m leaning towards two, numerically adjacent.) IMHO we need two drafts, so that we properly cover non-SMTP technologies like IMAP and XMPP. Peter -- Peter Saint-Andre https://stpeter.im/ From nobody Fri Feb 14 15:19:35 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 6DD941A0414; Fri, 14 Feb 2014 15:19:33 -0800 (PST) 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 35LurFEKX9iL; Fri, 14 Feb 2014 15:19:31 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A43E1A045D; Fri, 14 Feb 2014 15:19:30 -0800 (PST) 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.0.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140214231930.14682.84643.idtracker@ietfa.amsl.com> Date: Fri, 14 Feb 2014 15:19:30 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/dLuy3_atehdePAREbRr75pX6V2o Cc: dane@ietf.org Subject: [dane] I-D Action: draft-ietf-dane-smime-06.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: Fri, 14 Feb 2014 23:19:33 -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 Secure DNS to Associate Certificates with Domain Names For S/MIME Authors : Paul Hoffman Jakob Schlyter Filename : draft-ietf-dane-smime-06.txt Pages : 7 Date : 2014-02-14 Abstract: This document describes how to use secure DNS to associate an S/MIME user's certificate with the intended domain name, similar to the way that DANE (RFC 6698) does for TLS. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dane-smime/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dane-smime-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-dane-smime-06 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 Fri Feb 14 15:53: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 CC77F1A00B0; Fri, 14 Feb 2014 15:53:36 -0800 (PST) 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 Kr2VHQ5ncoYJ; Fri, 14 Feb 2014 15:53:35 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DAA881A03F5; Fri, 14 Feb 2014 15:53:33 -0800 (PST) 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.0.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140214235333.32626.42578.idtracker@ietfa.amsl.com> Date: Fri, 14 Feb 2014 15:53:33 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/wO9GpdgLBB4QtNa7pb5EIyeXKRY Cc: dane@ietf.org Subject: [dane] I-D Action: draft-ietf-dane-ops-03.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: Fri, 14 Feb 2014 23:53:37 -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 : DANE TLSA implementation and operational guidance Authors : Viktor Dukhovni Wes Hardaker Filename : draft-ietf-dane-ops-03.txt Pages : 19 Date : 2014-02-14 Abstract: This memo provides guidance to server operators to help ensure that clients will be able to authenticate a server's certificate chain via published TLSA records. Guidance is also provided to clients for selecting reliable TLSA record parameters and using them for server authentication. Finally, guidance is given to protocol designers who wish to make use of TLSA records when securing protocols using a combination of the Transport Layer Security (TLS) protocol and TLSA records. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dane-ops/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dane-ops-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-dane-ops-03 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 Fri Feb 14 16:48: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 868971A00DE for ; Fri, 14 Feb 2014 16:48:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] 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 YEW_Q83K5VOQ for ; Fri, 14 Feb 2014 16:48:39 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 390A11A00A7 for ; Fri, 14 Feb 2014 16:48:39 -0800 (PST) Received: from [10.20.30.90] (50-1-98-67.dsl.dynamic.sonic.net [50.1.98.67]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s1F0mXVw075903 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 14 Feb 2014 17:48:34 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-67.dsl.dynamic.sonic.net [50.1.98.67] claimed to be [10.20.30.90] Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Paul Hoffman In-Reply-To: Date: Fri, 14 Feb 2014 16:48:32 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140214200002.GK278@mournblade.imrryr.org> To: "" X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/NAEbPFdvrKcnho0q-HtAF4kdfD4 Subject: Re: [dane] Lukewarm discussion: DANE for opportunistic TLS protocols 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, 15 Feb 2014 00:48:40 -0000 On Feb 14, 2014, at 2:50 PM, James Cloos wrote: > The only real question is whether dane-srv and dane-smtp-with-dane > should be published as two rfcs or combined into one? > (I=92m leaning towards two, numerically adjacent.) With all due respect, there are other real questions, much more = significant than that one. One of the biggest questions that needs to be asked is not whether DANE = can be used for opportunistic protocols, because of course it can, but = whether DANE can be used to determine whether a server at a domain name = "should" be speaking TLS at the time that a client tries to connect. = Viktor makes a strong case that it does for SMTP. During the early = discussions of TLSA, many people thought it should not. Viktor's view gives us good MITM protection if the DNS channel is not = broken and the client knows the DNSSEC status of its query. It also = causes messages to be lost if there is an operational problem or even an = unexpected mis-match on the crypto desires of the client and server. It = also assumes that the person running the DNS server for a name is in = active contact with the person operating the SMTP server. Personally, I don't care about MITM protection if it comes at the cost = of getting more organizations to turn on opportunistic crypto. I think = DANE still has an important role in that it gives the SMTP server = operator a logging capability to see if there is an MITM. Others prefer = more protection against MITMs even in the face of preventable = communication failures. And, to be blunt, if we think that Viktor is right about DANE for SMTP, = shouldn't DANE for HTTP have the same MITM protection and operational = downsides? --Paul Hoffman= From nobody Fri Feb 14 18:13: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 5E33B1A02EE for ; Fri, 14 Feb 2014 18:13:37 -0800 (PST) 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 i0t1rOxEG2H4 for ; Fri, 14 Feb 2014 18:13:35 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 229D61A02E0 for ; Fri, 14 Feb 2014 18:13:34 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 5472A2AB22D; Sat, 15 Feb 2014 02:13:32 +0000 (UTC) Date: Sat, 15 Feb 2014 02:13:32 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140215021332.GM278@mournblade.imrryr.org> References: <20140214200002.GK278@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.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/O0_EQDIGkN5M2ijxRW_3jrHNdB4 Subject: Re: [dane] Lukewarm discussion: DANE for opportunistic TLS protocols 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, 15 Feb 2014 02:13:37 -0000 On Fri, Feb 14, 2014 at 04:48:32PM -0800, Paul Hoffman wrote: > Personally, I don't care about MITM protection if it comes at > the cost of getting more organizations to turn on opportunistic > crypto. One quick comment, there is no conflict between opportunistic DANE TLS and "pre-DANE" opportunistic TLS. So I would take issue with "at the cost of". If anything the two are symbiotic. The first step for an SMTP server operator towards greater channel security is to enable STARTTLS if they have not already done that. At that point all TLS-enabled clients (be they DANE aware or not) will generally send email over unauthenticated TLS. Once the server operator determines that TLS is working satisfactorily for all clients (observed over weeks to months) he may decide to enable DNSSEC for his domain and if that works out OK, later publish a TLSA "3 1 1" RRset that matches his server certificate. The certificate will not capriciously expire causing an SMTP outage, it will only become invalid through explicit removal from the TLSA RRset (presumably after it is augmented by an RR matching a new certificate which then replaces the original). This simplified authentication protocol for SMTP is carefully designed to avoid most operational pitfalls, and the hope is that it will be reliable enough to be enabled by default on clients and stable when deployed with care on servers. All that aside, the main point is that there is NO conflict between "pre-DANE" opportunistic TLS and DANE opportunistic TLS. The latter is turned on only at the request of the server operator. As to why MTA to MTA SMTP is more special in this regard than HTTPS, the main reason is that MTAs don't generally roam into hotels, internet cafes, and other DNSSEC hostile environments. Being server infrastructure MTAs are much less likely to run into MITM false positives due to shifting network conditions. -- Viktor. From nobody Fri Feb 14 22:53: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 F3F341A0079 for ; Fri, 14 Feb 2014 22:53:53 -0800 (PST) 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 YqP6fBguLhK8 for ; Fri, 14 Feb 2014 22:53:50 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 47E031A0069 for ; Fri, 14 Feb 2014 22:53:49 -0800 (PST) Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id s1F6rkvo027977 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sat, 15 Feb 2014 07:53:46 +0100 (MET) In-Reply-To: <20140212232814.GM278@mournblade.imrryr.org> To: dane@ietf.org Date: Sat, 15 Feb 2014 07:53:46 +0100 (CET) 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: <20140215065346.794D91AC0D@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Archived-At: http://mailarchive.ietf.org/arch/msg/dane/QCVRh_I7OoVvGkxssnjrNMlRU_c Subject: Re: [dane] I-D Action: draft-ietf-dane-srv-04.txt 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, 15 Feb 2014 06:53:54 -0000 Viktor Dukhovni wrote: > Martin Rex wrote: >> Viktor Dukhovni wrote: >>> >>> You could mention that both name checks and key usage are >>> effectively handled by the TLSA record for DANE-EE(3). >> >> I'm sorry, but this simply isn't true today, I do not believe that >> this is (nor should be) the intention of DANE, and I'm strongly >> opposed to changing that part of the implementations. > > No name checks for CU-3 IIRC was discussed and agreed many months ago. I'm sorry for having been so unclear. I wasn't objecting to the "name checks" part here, only to the "both ... and key usage". > > There is no "true today" for DANE, as there are in effect no "real" > DANE implementations aside from the one in Postfix (I've looked at > some experimental implementations, but they are all incomplete and > often insecure). This is about TLS implementations. Keep in mind that the server does not even need to know about DANE at all -- anyhow the server WILL be acting on the KeyUsage in his very own certificate and drive the choice of cipher suites based on the KeyUsage requirements from the quoted part of the TLS spec: > >> DANE does NOT invalidate the key Usage checks and requirements that are >> normally part of TLS itself and described here: >> >> http://tools.ietf.org/html/rfc5246#page-56 > > Those other documents assume that the content of the certificate > is from a trusted authority. This is true for CU in {0, 1, 2}, > but false for CU=3. Nope. Defective implementations excepted, the TLS protocol engine will look at the KeyUsage attribute of the Server certificate and check the cipher suite selection for compatibility -- and the application call will NOT have a say in this. > > The requirement to not do name checks, EKU checks, date checks for > DANE is satisfied by the Postfix DANE implementation, and will be > satisfied by the OpenSSL implementation on which I'm collaborating > with one of the OpenSSL developers. You should not confuse EKU checks on the leaf certificate with KeyUsage checks on the leaf certificate. EKU checks on the leaf certificate are extremely application specific, and simply undefined for the majority of application protocols. TLS itself (rfc2246,rfc4346,rfc5246) is entirely ignorant of EKU, and so is HTTP-over-TLS (rfc2818). Browser vendors together with CAs have defined semantics for EKUs that browsers (but not necessarily generic TLS libs and programmatic HTTP clients) will typically check, such as the two id-kp-serverAuth and id-kp-clientAuth from PKIX(rfc5280) http://tools.ietf.org/html/rfc5280#page-45 Curiously, these EKUs are primarily a PKIX obsession, TLS just doesn't care. And PKIX has defined these two serverAuth and clientAuth purposes with an extremely narrow semantics: "TLS WWW server authentication" and "TLS WWW client authentication", which means that these would explicitly *NOT* apply to something like "TLS SMTP authentication" or "TLS SIP authentication", "TLS POP/IMAP authentication", "TLS XMPP authentication", etc. Whether a TLS server or TLS client will act on the expiration of an X.509 server certificate is also implementation dependent, and similarly, the application caller (that is using DANE for establishing trust), may not get a say in that. That is particularly true for the server-side which may not necessarily see/use any DANE code. I would really appreciate if you would refrain from suggesting to create and use bogus X.509 certificates with DANE, _including_ CU=3. DANE is an alternative means to establish trust, and for CU=3 it additionally shortcuts/omits the name checks. But not more. If you desperately want naked keys, join Paul Wouters in his effort to get that working with TLS. -Martin From nobody Sat Feb 15 08:44: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 854FF1A0185 for ; Sat, 15 Feb 2014 08:44:54 -0800 (PST) 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 MDTkrC9AfxPD for ; Sat, 15 Feb 2014 08:44:51 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id D6A4C1A0151 for ; Sat, 15 Feb 2014 08:44:50 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 133BC2AB253; Sat, 15 Feb 2014 16:44:47 +0000 (UTC) Date: Sat, 15 Feb 2014 16:44:47 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140215164446.GN278@mournblade.imrryr.org> References: <20140212232814.GM278@mournblade.imrryr.org> <20140215065346.794D91AC0D@ld9781.wdf.sap.corp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140215065346.794D91AC0D@ld9781.wdf.sap.corp> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/hMbLFXKnnZ4AsRqh43uDsJxhaco Subject: Re: [dane] I-D Action: draft-ietf-dane-srv-04.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, 15 Feb 2014 16:44:54 -0000 On Sat, Feb 15, 2014 at 07:53:46AM +0100, Martin Rex wrote: > > There is no "true today" for DANE, as there are in effect no "real" > > DANE implementations aside from the one in Postfix (I've looked at > > some experimental implementations, but they are all incomplete and > > often insecure). > > This is about TLS implementations. Keep in mind that the server does > not even need to know about DANE at all -- anyhow the server WILL > be acting on the KeyUsage in his very own certificate and drive > the choice of cipher suites based on the KeyUsage requirements > from the quoted part of the TLS spec: The CU=DANE-EE(3) requirements in the SMTP and SRV drafts apply ONLY to the verifier, i.e. the client. The server does not perform a lookup of its own TLSA RRs, ... and just sits there and does TLS. The only server-side TLS requirement with DANE is a requirement on the server operator to configure the server to include the root CA in the server certificate message when the server operator configures TLSA records with CU=DANE-TA(2) to specify trust in a root CA. In particular the server is quite free to enforce keyUsage or other policy, ... on itself. It is up to the server operator to make sure the server does not commit "TLS suicide" by deciding its own private keys and certificate chain are no longer suitable for TLS. > Defective implementations excepted, the TLS protocol engine will > look at the KeyUsage attribute of the Server certificate and check > the cipher suite selection for compatibility -- and the application > call will NOT have a say in this. You seem to be wedded to the idea that DANE support will be in application code and not in "TLS engine code". Having actually implemented a complete DANE verifier, I can assure you that there will be very few applications indeed that attempt to do this. DANE will only be adopted by applications when it is implemented in the TLS engine, and applications can just tell the TLS engine the server name/protocol/port or perhaps provide the relevant TLSA records and list of acceptable server names and ask the TLS engine to do all the work. > Whether a TLS server or TLS client will act on the expiration of an > X.509 server certificate is also implementation dependent, and similarly, > the application caller (that is using DANE for establishing trust), > may not get a say in that. That is particularly true for the server-side > which may not necessarily see/use any DANE code. Again a statement of the view that DANE in the TLS client is outside the TLS engine. DANE changes the semantics of the server certificate chain and needs to augment the chain processing in the TLS engine. > I would really appreciate if you would refrain from suggesting to > create and use bogus X.509 certificates with DANE, _including_ CU=3. > DANE is an alternative means to establish trust, and for > CU=3 it additionally shortcuts/omits the name checks. But not more. I am not suggesting that servers create "bogus" certificates. I am requiring *clients* with CU=DANE-EE(3) to ignore the certificate content except to the extent needed to match the certificate with the TLSA certificate association data field. The reason for this is that the most frequent (and essentially only) source of failure I observed in a decade of being a postmaster at large site that in fact applied PKIX secure-channel policy to some peer domains was certificate expiration. There was nothing appreciably more wrong with the peer domain's certificate, the day after it expired than the day before. Just an operational oversight. With DANE "IN TLSA 3 ? ?" we have an opportunity to move the expiration time outside the certificate, where it is difficult to change (requires someone to replace the server chain before a fixed future date). When the expiration time is in DNSSEC, it extends automatically every time the same zone file content is re-signed. No unplanned outages. The server operator is free to plan key/cert roll-over whenever it is convenient, independently of any artificial horizon in the server's certificate. Moving expiration out of the certificate will be the most important thing we can do to promote use of TLS! With many servers to manage, operations teams hate certificate expiration! Invariably some server is forgotten and is updated after an outage. With DANE "3 ? ?" the server operator can use the certificate expiration as in an input to a self-audit tool that reminds him to replace the certificate when convenient, but failure to do so is no longer a problem for either the client or the server. > If you desperately want naked keys, join Paul Wouters in his effort > to get that working with TLS. This would only work when all the TLSA RRs in the RRset are "DANE-EE(3) SPKI(1) ?". If any other TLSA RRs are present it is not safe to signal support for bare keys. And of course bare key support in TLS engines is some years away. I am not prepared to wait that long. Handling a mixture of certificates and bare keys makes APIs rather more complex, and breaks backwards compatibility. So I don't expect that DANE clients that support X.509 chains will bother to signal support for bare keys any time soon. -- Viktor. From nobody Sun Feb 16 13:42:04 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 017321A02D2 for ; Sun, 16 Feb 2014 13:42:02 -0800 (PST) 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 p_RpkKgzzl3k for ; Sun, 16 Feb 2014 13:41:59 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id AC1D31A02CD for ; Sun, 16 Feb 2014 13:41:58 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 2AA7F2AB254; Sun, 16 Feb 2014 21:41:54 +0000 (UTC) Date: Sun, 16 Feb 2014 21:41:54 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140216214154.GD278@mournblade.imrryr.org> References: <20140214171836.22671.11628.idtracker@ietfa.amsl.com> <0l7g8xvbx7.fsf@wjh.hardakers.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0l7g8xvbx7.fsf@wjh.hardakers.net> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/YSI8p-qSkUhhdz97nd4bS0TlYWI Subject: Re: [dane] I-D Action: draft-ietf-dane-smtp-with-dane-07.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: Sun, 16 Feb 2014 21:42:02 -0000 On Fri, Feb 14, 2014 at 09:31:16AM -0800, Wes Hardaker wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > This draft is a work item of the DNS-based Authentication of Named > > Entities Working Group of the IETF. > > The only changes in this version are fixes for idnits and cleaning up of > the required references. While the document is frozen for last-call and prior to the London meeting, I am staging changes based on feedback. Some of that feedback is off-list. In particular Wietse Venema sent review comments. I am posting the corresponding revisions to the list, if there are any objections, please speak up. The first set of staged changes is: * Fix title of section "2.", it is not about hardening (pre-DANE) opportunistc TLS, rather it specifies opportunistic DANE TLS. * Add a termilogy entry for MITM. * Fix hyphenation of qualifiers (e.g. high value -> high-value) and a typo or two. * Clarify claim that DANE authentication with input from server might be more reliable than authentication with no server provided parameters. diff --git a/draft-ietf-dane-smtp-with-dane-08.xml b/draft-ietf-dane-smtp-with-dane-08.xml index 3e36496..bdce22c 100644 --- a/draft-ietf-dane-smtp-with-dane-08.xml +++ b/draft-ietf-dane-smtp-with-dane-08.xml @@ -129,2 +129,6 @@ The following terms or concepts are used through the document: + + Active modification of network traffic by an adversary able to + thereby compromise the confidentiality or integrity of the data. + @@ -253,4 +257,3 @@ authentication, TLS provides only privacy protection against eavesdropping attacks. With authentication, TLS also provides data -integrity protection to guard against man-in-the-middle (MITM) -attacks. +integrity protection to guard against MITM attacks. @@ -310,6 +313,6 @@ the client also supports TLS, it may negotiate a TLS encrypted channel to use for email transmission. The server's indication of -TLS support can be easily suppressed by a man in the middle attacker. +TLS support can be easily suppressed by an MITM attacker. Thus pre-DANE SMTP TLS security can be subverted by simply downgrading a connection to cleartext. No TLS security feature, such as the -use of PKIX, can prevent this. The attacker can simply bypass TLS. +use of PKIX, can prevent this. The attacker can simply disable TLS. @@ -328,3 +331,3 @@ domain. -A PKIX TLS client is vulnerable to man in the middle (MITM) attacks +A PKIX TLS client is vulnerable to MITM attacks unless it verifies that the server's certificate binds its public @@ -365,3 +368,3 @@ more. Adding any other trusted actors to the mix can only reduce SMTP security. A sender may choose to harden DNSSEC for selected -high value receiving domains, by configuring explicit trust anchors +high-value receiving domains, by configuring explicit trust anchors for those domains instead of relying on the chain of trust from the @@ -431,3 +434,3 @@ inclusive enough. -
+
@@ -519,3 +522,2 @@ DNS resolver MUST be able to determine whether a given non-error DNS response is "secure", "insecure", "bogus" or "indeterminate". - It is expected that most security-aware stub resolvers will not @@ -730,3 +732,3 @@ than a DNS domain, DANE TLS does not apply. Delivery proceeds using any relevant security policy configured by the MTA administrator. -Similarly, when an MX RRset incorrectly lists an network address in lieu +Similarly, when an MX RRset incorrectly lists a network address in lieu of an MX hostname, if the MTA chooses to connect to the network address @@ -759,3 +761,3 @@ that has no TLSA records. In other words, prevention of delivery loops by obeying MX preferences MUST take precedence over channel -security considerations. Even with two equal preference MX records, an MTA +security considerations. Even with two equal-preference MX records, an MTA is not obligated to choose the MX hostname that offers more security. @@ -817,3 +819,3 @@ administrator to handle some or all mail. no MX records. In this case the domain's name is implicitly also -the hostname of its sole SMTP server. +its sole SMTP server name. @@ -1036,4 +1038,5 @@ implied by the presence of DANE TLSA records and the verification parameters necessary to authenticate the TLS peer are obtained -together, therefore authentication via this protocol is expected -to be less prone to connection failure caused by incompatible +together. In contrast to protocols where channel security policy +is set exclusively by the client, authentication via this protocol +is expected to be less prone to connection failure caused by incompatible configuration of the client and server. -- Viktor. From nobody Sun Feb 16 13:50:24 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 04CFB1A02B0 for ; Sun, 16 Feb 2014 13:50:23 -0800 (PST) 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 ffNraNACujiD for ; Sun, 16 Feb 2014 13:50:21 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id CC2631A021E for ; Sun, 16 Feb 2014 13:50:20 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 3A6EE2AB254; Sun, 16 Feb 2014 21:50:18 +0000 (UTC) Date: Sun, 16 Feb 2014 21:50:18 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140216215017.GE278@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/WzsSFwo_qmc8teoMKv6yOu_cVz4 Subject: [dane] Further off-list feedback on SMTP draft 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, 16 Feb 2014 21:50:23 -0000 Wietse also (correctly IMHO) suggest that the discussion of possible applicability to MUA DANE SMTP needlessly dominates the introduction. The corresponding change in the organization of the document is to move the short MUA discussion to its own small section in the document, and simply reference it briefly in the introduction. diff --git a/draft-ietf-dane-smtp-with-dane-08.xml b/draft-ietf-dane-smtp-with-dane-08.xml index bdce22c..066f3e7 100644 --- a/draft-ietf-dane-smtp-with-dane-08.xml +++ b/draft-ietf-dane-smtp-with-dane-08.xml @@ -91,22 +91,9 @@ generally opportunistic. -We note that the SMTP protocol is also used between Message User -Agents (MUAs) and Message Submission Agents (MSAs) . In a protocol is -specified that enables an MUA to dynamically locate the MSA based on -the user's email address. SMTP connection security requirements for -MUAs implementing are largely analogous to -connection security requirements for MTAs, and this specification -could be applied largely verbatim with DNS MX records replaced by -corresponding DNS Service (SRV) records . - - - -However, until MUAs begin to adopt the dynamic configuration -mechanisms of they are adequately served -by more traditional static TLS security policies. This document will not -discuss the MUA use case further, leaving specification -of DANE TLS for MUAs to future documents that focus specifically -on SMTP security between MUAs and MSAs. The rest of this memo will -focus on securing MTA to MTA SMTP connections. +Problems with existing use of TLS in MTA to MTA SMTP that motivate +this specification are described in . +The specification itself follows in . +Then, in , we discuss application of DANE +TLS to destinations for which channel integrity and confidentiality +are mandatory. In we briefly comment on +potential applicability of this specification to Message User Agents. @@ -1519,2 +1506,27 @@ or misconfigures SMTP server certificate chains, mail will be delayed. +
+ + +We note that the SMTP protocol is also used between Message User +Agents (MUAs) and Message Submission Agents (MSAs) . In a protocol is +specified that enables an MUA to dynamically locate the MSA based on +the user's email address. SMTP connection security considerations for +MUAs implementing are largely analogous to +connection security requirements for MTAs, and this specification +could be applied largely verbatim with DNS MX records replaced by +corresponding DNS Service (SRV) records . + + + +However, until MUAs begin to adopt the dynamic configuration +mechanisms of they are adequately served +by more traditional static TLS security policies. Specification +of DANE TLS for Message User Agent (MUA) to Message Submission Agent +(MSA) SMTP is left to future documents that focus specifically on +SMTP security between MUAs and MSAs. + + +
+
-- Viktor. From nobody Sun Feb 16 14:04: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 DDDCD1A040D; Sun, 16 Feb 2014 14:04:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 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.548] 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 OjelmYchAwUz; Sun, 16 Feb 2014 14:04:25 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id A08551A02C4; Sun, 16 Feb 2014 14:04:25 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 53AA5800AA; Sun, 16 Feb 2014 17:04:22 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1392588262; bh=umdGRtuVVd5oFrKBYABzCe/xWOaRyfy0NnPAy7iKX5Y=; h=Date:From:To:Subject; b=WI3mI65kPpCs1LVG9zgK+kTGvf3AtJdYWgCDRtYen1boE0EUfXiq/qgP4jCrlUYYh QBUBxWmDImBnfnHgWKKkcr6+hlcTmVbz6G1F3q9wcBzKjHUP8lNPuWPlL+xdd/4nDh ruK7h91lPoFZllukwjFnnDmXZgGEG+lDkiGJ58I0= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s1GM4LLb014255; Sun, 16 Feb 2014 17:04:22 -0500 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Sun, 16 Feb 2014 17:04:21 -0500 (EST) From: Paul Wouters To: "ipsec@ietf.org WG" , dane WG list Message-ID: User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/dane/_bfSpAi9tLza5prM6375F_TihYU Subject: [dane] Review of draft-osterweil-dane-ipsec 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: Sun, 16 Feb 2014 22:04:29 -0000 Review of draft-osterweil-dane-ipsec I'm heavilly involved with Oportunistic Encryption using IPsec with The Libreswan Project. We opted to first gain more experience with running code before attempting to write a draft. As such, we have found many corner cases that need to be handled that are completely left out of this document. I think it's a good idea if the authors of this document talk to people in the IPsec and DANE working groups. This draft introduces an overly complex and bad coupling of DNS, PKIX and IPsec with the very limited goal of encrypting _some_ DNS traffic. It seems to make a lot more sense to use (D)TLS to encrypt DNS traffic using the existing TLSA records at the _53.{tcp|udp} prefix. Further comments below, Paul Abstract It is not clear from the document what is being attempted. Is it encrypting all DNS traffic? The stub to the local resolver? Stub to a remote resolver? What's special about DNS compared to using IPsec to encrypt everything? Introduction Don't use the word meta-data. It's just data. We don't need to give TLA's more justification for the redefinition of the term meta-data. The introduction makes clear only (some?) DNS data is being targeted for encryption. Why would protecting DNS using OE-IPsec be treated differently from protecting ALL traffic using OE-IPsec? For example, the information leakage exposed by observing DNSSEC transactions, could enable an adversary to not only learn what Second Level Domains (SLDs) a user is querying (such as their bank, a funding agency, a security contractor, etc.), How does encrypting the DNS help? So now you don't see I was going to "nohats.ca", but you see port 443 packets to 193.110.157.102. DNS information that is encrypted yet acted upon, leaks per definition. This is like encrypting visits to Google Maps while broadcasting your GPS coordinates. The last-mile protection argument is very weak. DNSSEC validators are moving to what used to be stub resolvers only. There is no need for new technology for last-mile protection. The bootstreap is unclear. DANE uses DNS yet you plan to encrypt DNS? Section 1.1 This section introduces using PKIX certificates for binding DNS to IPsec. IPsec does not require X.509 and has support for bare public keys. Why drag in the whole TLS style Certificate, Usage and Selectors? Unlike TLS, there is no legacy base that needs to be accomodated. It makes no sense to deviate from bare public keys. It adds all the complexity without much, if any, benefit over the traditional IPSECKEY record. In fact, even the authors themselves see that: The advantages of using DANE for IPsec OE also include other simplifications that the DANE protocol inherently offers all of its protocols. Such as, the automatic deauthorization of certificates that happens when they are removed from a DNS zone , which may (under many circumstances) obviate the need for extensive use of revocation mechanisms (OCSP [RFC6960] or CRL [RFC5280]) Storing public keys in DNS removes the need for things like PKIX expiry times, CRL, OCSP... So why introduce PKIX at all??? Section 1.2 This section talks about IPSECKEY and dismisses its use because it is limited to IP-centric networks. This is not the case when one places IPSECKEYs in the forward DNS (as the current Libreswan IPsec Opportunistic Encryption uses). For example, one can build a OE-IPsec tunnel to the host bofh.nohats.ca using the IPSECKEY published for bofh.nohats.ca. No new IPSECA record is needed for that. Section 1.3 When an IPSECA record is discovered by a resolver, that resolver SHOULD follow its configurations and setup an SPD entry. If your approach uses a local resolver to setup IPsec security, then your approach could be much simplified using the same method we are curently experimenting with, which is IPSECKEY records in the forward DNS zone. If you are using a modified validating resolver on the host, it also undermines your statement in the Introduction about this solution being needed for last-mile authenticity of DNS - you already run a validating resolver on teh stub. When using IPSECA resource records to verify OE tunnels, clients MUST perform full DNSSEC validation of the DNSSEC chain of trust that leads to IPSECA RRs This looks like a big bootstrap issue. The old FreeS/WAN IPsec OE also had isues with bootstrapping and DNS. It was so bad that when starting freeswan, you would be dead in the water for about a minute while DNS lookups for OE hit the OE machinery causing more OE lookups and it took time to deal with all the failures before lines to DNS servers were either encrypted or marked as cleartext (as opposed to block until we know if we need to do crypto to it ) Trust anchors (which may be distributed during dynamic host configuration) may be useful for bootstrapping. Securing DHCP is a really hard problem. accepting trust anchors from DHCP seems a security nightmare. It goes on to note that it is okay when using RFC1918 space, but that is also dangerous. I might have VPN connections that use RFC1918 that I don't wish to yield to a wifi-based trust anchor. Section 2 This section specifies the IPSECA record. As I already said, I see no good reasons for introducing PKIX into this mix. Additionally, the use of a GATEWAY option means that these record MUST NOT be used in any forward DNS, but only in the reverse, otherwise I can put malicious entries into my forward DNS to steal other people's IP address ranges. It is not very clear IPSECA is meant only to appear in the reverse. Our experience with FreeS/WAN is that the reverse is just not good enough apart for a few big players in data centers. And with IPv6, it becomes even harder for people to put records in (resulting in amusing situations like that I cannot email Paul Vixie). Depending on the reverse tree means this will only be deployable by enterprises, and not by home users. IPsec is an IP to IP protocol. It can be used to hide port numbers. Deploying IPsec using _prefix constructions that expose port numbers defeats part of the security that IPsec offers over inline encryption such as TLS or STARTTLS. Section 3 The operational considerations are really weird. They basically state "there is no operational impact as long as our protocol is not deployed widely". It does not mention anything about additional latency for the end user. It does not talk about the IPsec NAT-T and clashing/overlapping internal IP addresses. It does not mention anycast issues, load balancers, crypto offloaders, etc. Section 5 I'm not sure what the "cooperative benefits with TLS" are? What advantage does this solution provide over using DNS (D)TLS with TLSA? Any combination of these types of protections offer both defense-in-depth (securing transactions at multiple levels) and offer security practitioners a larger mosaic of security tools from which to construct and maintain their security postures. This is a rather weak argument for adoption. From nobody Sun Feb 16 17:01:58 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 B04821A0204 for ; Sun, 16 Feb 2014 17:01:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.548, 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 f4z8JkUqVS6O for ; Sun, 16 Feb 2014 17:01:54 -0800 (PST) Received: from ore.jhcloos.com (ore.jhcloos.com [198.147.23.85]) by ietfa.amsl.com (Postfix) with ESMTP id D54D91A00E0 for ; Sun, 16 Feb 2014 17:01:54 -0800 (PST) Received: by ore.jhcloos.com (Postfix, from userid 10) id 2AF301DF79; Mon, 17 Feb 2014 01:01:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore13; t=1392598910; bh=3NOa4981IuP3PN13lLLsE6lomoYdmnhyA5pVOxk4Gd0=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=hA0qmI0Z8ECpNzPApY6A8K2BSYwgk6+cEOgey04h5DPLdApqNc+t+Aan4jrv/aKDX JOU8Vnw8Fyll38+U9/Tkl9JCaS/AZ7HH+ENrgpWEg8DpRFoxiBg97B9EdkmCXOx7tw eT2n/x1UnCBVHXkR6HxwXAEyOs6//ZrZF1eyUh4XHsw== Received: by carbon.jhcloos.org (Postfix, from userid 500) id 84FE860021; Mon, 17 Feb 2014 00:55:21 +0000 (UTC) From: James Cloos To: Paul Hoffman In-Reply-To: (Paul Hoffman's message of "Fri, 14 Feb 2014 16:48:32 -0800") References: <20140214200002.GK278@mournblade.imrryr.org> User-Agent: Gnus/5.13001 (Ma Gnus v0.10) Emacs/24.3.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2014 James Cloos OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Sun, 16 Feb 2014 19:55:21 -0500 Message-ID: Lines: 16 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Hashcash: 1:30:140217:paul.hoffman@vpnc.org::6hfGNHg5njFQM4Fh:000000000000000000000000000000000000000EDsiN X-Hashcash: 1:30:140217:dane\@ietf.org\::0IBr8gAg7yIMJvQ5:0RclU0 X-Hashcash: 1:30:140217:dane@ietf.org::/EXCovcrznGHhjJO:000SpdiF Archived-At: http://mailarchive.ietf.org/arch/msg/dane/PfKX2GjhT3F2SQZxLIyqZRC2f_Y Cc: "" Subject: Re: [dane] Lukewarm discussion: DANE for opportunistic TLS protocols 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: Mon, 17 Feb 2014 01:01:57 -0000 >>>>> "PH" == Paul Hoffman writes: JC>> The only real question is whether dane-srv and dane-smtp-with-dane JC>> should be published as two rfcs or combined into one? (I’m leaning JC>> towards two, numerically adjacent.) PH> With all due respect, there are other real questions, much more PH> significant than that one. Sorry. That paragraph does not express the tone for which I aimed. And I should have caught that fact before posting. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From nobody Sun Feb 16 18:36:13 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 303001A01D1 for ; Sun, 16 Feb 2014 18:36:11 -0800 (PST) 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 m8GN3MGuwpJf for ; Sun, 16 Feb 2014 18:36:08 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 1E9601A005F for ; Sun, 16 Feb 2014 18:36:07 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id D057D2AB254; Mon, 17 Feb 2014 02:36:04 +0000 (UTC) Date: Mon, 17 Feb 2014 02:36:04 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140217023604.GF278@mournblade.imrryr.org> References: <20140216215017.GE278@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140216215017.GE278@mournblade.imrryr.org> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/rVewBinUIlFeRPzoWYoJkMFxWTo Subject: Re: [dane] Further off-list feedback on SMTP draft 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: Mon, 17 Feb 2014 02:36:11 -0000 On Sun, Feb 16, 2014 at 09:50:18PM +0000, Viktor Dukhovni wrote: In addition Wietse's comments on Section 2.3.1, suggest a change in organization with a move of key rotation discussion to its own section. NOTE: The discussion of DANE-TA(2) was updated to recommend a selector of Cert(0). Earlier conversion of the document from bare numbers to the new acronyms introduced an error changing "2 1 1 or 2 0 1" to "2 1 1 or 2 1 0". While fixing that inadvertent error, I took the opportunity to note that with DANE-TA(2) associations it best to specify the whole certificate, not just the public key. --- a/draft-ietf-dane-smtp-with-dane-08.xml +++ b/draft-ietf-dane-smtp-with-dane-08.xml @@ -1088,2 +1088,12 @@ or public key, and likewise SHA2-512(2) means a SHA2-512 digest is used. +Since opportunistic DANE TLS will be used by non-interactive MTAs, +with no user to "press OK" when authentication fails, reliability +of peer authentication is paramount. Server operators are advised +to publish TLSA records that are least likely to fail authentication +due to interoperability or operational problems. Because DANE TLS +relies on coordinated changes to DNS and SMTP server settings, the +best choice of records to publish will depend on site-specific practices. + + + The certificate usage element of a TLSA record plays a critical @@ -1100,8 +1110,2 @@ with opportunistic DANE TLS. -Since opportunistic DANE TLS will be used by non-interactive MTAs, -with no user to "press OK" when authentication fails, reliability -of peer authentication is paramount. - - - Authentication via certificate usage DANE-EE(3) TLSA records involves @@ -1118,11 +1122,9 @@ when the TLSA record matches the server's default certificate). -Two TLSA records MUST be published before updating a server's -public key, one matching the currently deployed key and the other -matching the new key scheduled to replace it. Once sufficient time -has elapsed for all DNS caches to expire the previous TLSA RRset and -related signature RRsets, the server may be reconfigured to -use the new private key and associated public key certificate. Once -the server is using the new key, the TLSA RR that matches the retired -key can be removed from DNS, leaving only the RR that matches the -new key. +For domains where it is practical to make coordinated changes in +DNS TLSA records during SMTP server key rotation, it is often best +to publish end-entity DANE-EE(3) certificate associations. DANE-EE(3) +certificates don't suddenly stop working when leaf or intermediate +certificates expire, and don't fail when the server operator +neglects to configure all the required issuer certificates in the +server certificate chain. @@ -1131,6 +1133,5 @@ new key. TLSA records published for SMTP servers SHOULD, in most cases, be -"DANE-EE(3) SPKI(1) SHA2-256(1)" records. -Since all DANE implementations are required to support SHA2-256, -this record works for all clients and need not change across -certificate renewals with the same key. +"DANE-EE(3) SPKI(1) SHA2-256(1)" records. Since all DANE implementations +are required to support SHA2-256, this record type works for all clients +and need not change across certificate renewals with the same key. @@ -1168,7 +1169,17 @@ in the TLS server certificate message. -TLSA Publishers should publish either "DANE-TA(2) SPKI(1) Full(0)" or -"DANE-TA(2) Cert(0) SHA2-256(1)" TLSA parameters. -As with leaf certificate rollover discussed in , two such TLSA RRs need to be published to -facilitate TA certificate rollover. +TLSA Publishers employing DANE-TA(2) records SHOULD publish records +with a selector of Cert(0). Such TLSA records are associated with +the whole trust anchor certificate, not just with the trust anchor +public key. In particular, the SMTP client SHOULD then apply any +relevant constraints from the trust anchor certificate, such as, +for example, path length constraints. + + + +While a selector of SPKI(1) may also be employed, the resulting +TLSA record will not specify the full trust anchor certificate +content, and elements of the trust anchor certificate other than +the public key become mutable. This may, for example, allow a +subsidiary CA to issue a chain that violates the trust anchor's +path length or name constraints. @@ -1365,2 +1376,22 @@ care to authenticate the server. +
+ + +Two TLSA records MUST be published before employing a new EE or TA +public key or certificate, one matching the currently deployed key +and the other matching the new key scheduled to replace it. Once +sufficient time has elapsed for all DNS caches to expire the previous +TLSA RRset and related signature RRsets, servers may be configured +to use the new EE private key and associated public key certificate +or may employ certificates signed by the new trust anchor. + + + +Once the new public key or certificate is in use, the TLSA RR that +matches the retired key can be removed from DNS, leaving only RRs +that match keys or certificates in active use. + + +
+
-- Viktor. From nobody Mon Feb 17 05:31:07 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 AD2971A0006 for ; Mon, 17 Feb 2014 05:31:04 -0800 (PST) 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 qcOa4N41hnEt for ; Mon, 17 Feb 2014 05:31:01 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 7F7C81A01E0 for ; Mon, 17 Feb 2014 05:31:00 -0800 (PST) Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id s1HDUvh4019855 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 17 Feb 2014 14:30:57 +0100 (MET) In-Reply-To: <20140215164446.GN278@mournblade.imrryr.org> To: dane@ietf.org Date: Mon, 17 Feb 2014 14:30:57 +0100 (CET) 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: <20140217133057.2BDF41AC10@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Archived-At: http://mailarchive.ietf.org/arch/msg/dane/MCp2GfwshbuyMH2k9CeBHEEzVws Subject: Re: [dane] I-D Action: draft-ietf-dane-srv-04.txt 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: Mon, 17 Feb 2014 13:31:04 -0000 Viktor Dukhovni wrote: >> >> Defective implementations excepted, the TLS protocol engine will >> look at the KeyUsage attribute of the Server certificate and check >> the cipher suite selection for compatibility -- and the application >> call will NOT have a say in this. > > You seem to be wedded to the idea that DANE support will be in > application code and not in "TLS engine code". That isn't my idea, that is a fundamental part of the architecture of TLS, described in every existing TLS specification at the end of section 1, Introduction. http://tools.ietf.org/html/rfc2246#page-4 The TLS standard, however, does not specify how protocols add security with TLS; the decisions on how to initiate TLS handshaking and how to interpret the authentication certificates exchanged are left up to the judgment of the designers and implementors of protocols which run on top of TLS. > > Having actually implemented a complete DANE verifier, I can assure > you that there will be very few applications indeed that attempt > to do this. We know painfully well just how poor apps are in doing certificate verification: "The most dangerous Code in the World" http://www.cs.utexas.edu/~shmat/shmat_ccs12.pdf A number of TLS protocol implementations come with utility functions to make the task easier for applications to consume TLS. The model how server endpoint identites are checked in HTTP-over-TLS, as described in rfc2818, is a matter of the application from the TLS protocol perspective. Leaving the checking of certificates entirely to applications is what leads to the problem described in above paper. The situation with DANE is very much alike. DANE does not change anything about how TLS works, it only changes how applications make use (including certificate (parh) validation) of the certificates exchanged within the TLS protocol. It is likely that TLS implementation will add support for DANE to the the set of utility functions that are supposed to facilitate consumption of TLS for applications. DANE is *NOT* part of TLS, and it will be the task of application to actually have the checks performed. -Martin From nobody Mon Feb 17 10:15: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 97A451A0239 for ; Mon, 17 Feb 2014 10:15:41 -0800 (PST) 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 7XTJkpTtInqO for ; Mon, 17 Feb 2014 10:15:38 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 6C8E91A0207 for ; Mon, 17 Feb 2014 10:15:38 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id D10C02AB254; Mon, 17 Feb 2014 18:15:33 +0000 (UTC) Date: Mon, 17 Feb 2014 18:15:33 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140217181533.GG278@mournblade.imrryr.org> References: <20140215164446.GN278@mournblade.imrryr.org> <20140217133057.2BDF41AC10@ld9781.wdf.sap.corp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140217133057.2BDF41AC10@ld9781.wdf.sap.corp> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/bGDjgyh4TMpqI9NQ6RahpbBfsyY Subject: Re: [dane] I-D Action: draft-ietf-dane-srv-04.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: Mon, 17 Feb 2014 18:15:41 -0000 On Mon, Feb 17, 2014 at 02:30:57PM +0100, Martin Rex wrote: > > Having actually implemented a complete DANE verifier, I can assure > > you that there will be very few applications indeed that attempt > > to do this. > > A number of TLS protocol implementations come with utility functions > to make the task easier for applications to consume TLS. We should not descend into a scholastic debate of the fine details of where the boundary lies between "TLS engine code" and library code that performs related functions on behalf of the application. Both TLS protocol processing and certificate trust chain verification a la DANE, will need to be provided by a complete SSL/TLS toolkit to enable its applications to employ DANE. DANE will require various changes in those toolkits, some of those might be in the protocol engine some in the related functions. This said, my intention with DANE-EE(3) semantics is not necessarily to preempt various features of the EE certificate that are not covered by the TLSA record. Rather, my goal was to make sure that the TLSA record content is not trumped the content of the certificate (whose signer is not even trusted since we're not checking any PKIX trust chain). We've already agreed that name checks are more than adequately handled by the implied binding with the port, protocol and server name in the TLSA base domain. Beyond that, I'd like to make sure that also the validity interval is from DNSSEC (no sudden failure so long the DNS zone continues to publish a matching TLSA RR). Similarly, RFC 5280 extended Key Usage (sequence of KeyPurposeId) is superseded by the RRtype (TLSA) to imply an acceptable purpose of id-kp-serverAuth. So I can live with a weaker requirement, if that settles the issue. With DANE-EE(3): - No PKIX signature verification. Covered by TLSA association data field, and in any case we don't have a trusted issuer whose signature can be checked. [ Obvious. ] - No name checks based on certificate content. Covered by TLSA (service, protocol, base domain) triple. [ Already agreed. ] - No expiration checks based on certificate content. Covered by TLSA RRset's RRSIG expiration time. [ Still under discussion. ] - No purpose checks based on extended key usage. Covered by TLSA RRtype. [ Still under discussion. ] If there are other elements of the certificate potentially relevant to the TLS protocol engine, any related functions or the application, I can live with that. It was my purpose to make the requirement as simple as possible, and ignoring everything in the certificate is much simpler to state than ignoring a subset. In particular I have no objection to TLS protocol engines complying with the keyUsage bits from: http://tools.ietf.org/html/rfc5280#section-4.2.1.3 Of the two "Still under discussion" fields, the expiration is by far the most important for the operational success of DANE. By far the most common problem is expired certificates, and with DANE-EE(3), we have an opportunity to eliminate this problem. There is no more expiration, rather TLSA records are withdrawn from DNS by the server operator once the certificate is no longer appropriate (for whatever reason). The server operator should of course audit deployed certificates and may use the expiration date as a reminder to rotate keys, but with DANE-EE(3) I think it makes much more sense to leave the timing of key rotation to the server operator, not the client. -- Viktor. From nobody Mon Feb 17 11:54: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 781331A01F9 for ; Mon, 17 Feb 2014 11:54:36 -0800 (PST) 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 I95iafWyQJXU for ; Mon, 17 Feb 2014 11:54:33 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id D1E711A0257 for ; Mon, 17 Feb 2014 11:54:05 -0800 (PST) Received: by mail-we0-f172.google.com with SMTP id u56so1061815wes.31 for ; Mon, 17 Feb 2014 11:54:02 -0800 (PST) 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 :content-transfer-encoding; bh=TMY9XiZ+68RValVW2UUI7zEjDjv1ehHZqMTpy9NlLGc=; b=fime9T8VFm+0K7k7t283uFmv9ae5YzvbHztF/ynyE45hkr/p/0Y3aU9UhgllpCd76W WWeCC0iWMXgNbQM9V73rLKvSJASEMYRoCj96oOjHuNaQrRT7vzpq49RBhtXFqYqV9ONZ 5gsAbyfs4OBSFsJsw1Jx3sUYJdOybZpEt5A6/maDG8RzY+H9GHQ8hvC6YmHQO9a8f5eZ Q/FWyvf9CdZ2ahOK575lijjAMtL6Ei52nylJOH8MevrSjmRHS0WLmBkMYvxkLiAZtMpQ CZXLWWa2/NqivVNYU8b9M6xRceHmOKN9TiHqGVDSdSKEJOVaoHbVse01EZFUcyJPkOZy khdw== X-Gm-Message-State: ALoCoQm9D68jX4Jqe1CmFGvfKTWz21jR3FefeAlVF7c4bC2fnOvCxmxYjx91s8xO1Xn2d2lalzpQ MIME-Version: 1.0 X-Received: by 10.194.108.41 with SMTP id hh9mr12290wjb.89.1392666842524; Mon, 17 Feb 2014 11:54:02 -0800 (PST) Received: by 10.194.54.167 with HTTP; Mon, 17 Feb 2014 11:54:02 -0800 (PST) X-Originating-IP: [98.244.98.35] In-Reply-To: References: <20140214200002.GK278@mournblade.imrryr.org> Date: Mon, 17 Feb 2014 14:54:02 -0500 Message-ID: From: Warren Kumari To: Paul Hoffman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/dane/uVk7LUvqPtaajTCgBKvUGR3BUKk Cc: "" Subject: Re: [dane] Lukewarm discussion: DANE for opportunistic TLS protocols 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: Mon, 17 Feb 2014 19:54:36 -0000 On Fri, Feb 14, 2014 at 7:48 PM, Paul Hoffman wrote= : > On Feb 14, 2014, at 2:50 PM, James Cloos wrote: > >> The only real question is whether dane-srv and dane-smtp-with-dane >> should be published as two rfcs or combined into one? >> (I'm leaning towards two, numerically adjacent.) > > With all due respect, there are other real questions, much more significa= nt than that one. > > One of the biggest questions that needs to be asked is not whether DANE c= an be used for opportunistic protocols, because of course it can, but wheth= er DANE can be used to determine whether a server at a domain name "should"= be speaking TLS at the time that a client tries to connect. Viktor makes a= strong case that it does for SMTP. During the early discussions of TLSA, m= any people thought it should not. And some thought that it should -- IIRC, this, like many of the early DANE discussions was fairly heated, and the consensus was far from unanimous. We ended up with a number of compromises simply so that we could make progress... Again, IIRC there was a suggestion that the TLSA record should be able to signal if clients may continue without TLS / perform something analogous to HASTLS / HSTS. This could have been a single bit, or yet another byte. We decided not to do that, but I wonder if in light of recent revelations we should revisit this decision. I'm not quite sure how we'd cram this into the current record, if it should be defined in each of the "DANE with foo" docs or if it would require yet another RR type... > > Viktor's view gives us good MITM protection if the DNS channel is not bro= ken and the client knows the DNSSEC status of its query. It also causes mes= sages to be lost if there is an operational problem or even an unexpected m= is-match on the crypto desires of the client and server. It also assumes th= at the person running the DNS server for a name is in active contact with t= he person operating the SMTP server. > > Personally, I don't care about MITM protection if it comes at the cost of= getting more organizations to turn on opportunistic crypto. I think DANE s= till has an important role in that it gives the SMTP server operator a logg= ing capability to see if there is an MITM. Others prefer more protection ag= ainst MITMs even in the face of preventable communication failures. Or we could give the person publishing the RR the ability to specify. > > And, to be blunt, if we think that Viktor is right about DANE for SMTP, s= houldn't DANE for HTTP have the same MITM protection and operational downsi= des? Personally I think that it should, but I might be in the weeds here. W > > --Paul Hoffman > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From nobody Mon Feb 17 12:21: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 745581A026E for ; Mon, 17 Feb 2014 12:21:55 -0800 (PST) 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 Wb0_eHcLZc-U for ; Mon, 17 Feb 2014 12:21:53 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 0279B1A025C for ; Mon, 17 Feb 2014 12:21:52 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 190D22AABCE; Mon, 17 Feb 2014 20:21:50 +0000 (UTC) Date: Mon, 17 Feb 2014 20:21:50 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140217202149.GK278@mournblade.imrryr.org> References: <20140214200002.GK278@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.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/Mpw5CpWTLitzLzxz6HS1s3bD020 Subject: Re: [dane] Lukewarm discussion: DANE for opportunistic TLS protocols 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: Mon, 17 Feb 2014 20:21:55 -0000 On Fri, Feb 14, 2014 at 04:48:32PM -0800, Paul Hoffman wrote: > Viktor's view gives us good MITM protection if the DNS channel > is not broken and the client knows the DNSSEC status of its query. > It also causes messages to be lost if there is an operational > problem or even an unexpected mis-match on the crypto desires of > the client and server. It also assumes that the person running the > DNS server for a name is in active contact with the person operating > the SMTP server. Some comments on the above. - When authetication fails, the DANE SMTP draft specifies "delay" (aka defer, queue, ...) not bounce. Provided the receving system operator fixes the server configuration in a reasonably timely manner, no mail is lost. - Crypto parameter mismatch for SMTP TLS is quite rare. The only common problems are: * Microsoft Exchange 2003 only looks at the first 64 cipher suites in the TLS client's SSL HELLO. It has a broken 3DES implementation that mishandles CBC padding. SMTP clients that support TLS 1.2 typically have more 64 cipher suites stronger than RC4-SHA and TLS connections to Microsoft Exchange 2003 often fail after negotiating 3DES-CBC. While such server are still found here and there, operators of these would be foolish and unlikely to publish TLSA records. * Some Debian "squeeze" systems have an Exim SMTP client that was inadvisably patched by Debian to require 2048 bit or longer EDH primes. These fail to handshake with many servers that employ 1024 bit EDH primes. These SMTP clients do not implement DANE. The patch has been reverted in newer Debian releases. When Exim supports DANE, we can reasonably hope that Debian won't repeat their mistake. - As for "active contact", yes active contact is required after all to publish the TLSA record in the first place. However, at tiny sites (say dukhovni.org) whose SMTP server certificate is long expired, but still pinned and thus valid enough for my MUA, "active contact" is a non-issue. Simiarly, with DANE-EE(3) there is no need for "active contact" (though I admittedly am in "active contact" with myself). No "active contact is required" with DANE-TA(2). The DNS folks and the folks operating the domain's CA publish new TLSA RRs for the latest CA keys from time time. They issue new certs to the peons operating the SMTP server, these just work, because the TLSA RRs are CNAMEs pointing at the centrally managed TLSA RRset. Thus there are two reasonable models, that typically match smaller and larger organizations respectively, and don't impose undue operational burdens. These are described in the SMTP and ops drafts. -- Viktor. From nobody Mon Feb 17 12:35:29 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 7ED3C1A0239 for ; Mon, 17 Feb 2014 12:35:27 -0800 (PST) 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 wQNR_X8Mflue for ; Mon, 17 Feb 2014 12:35:25 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id A4AB01A026D for ; Mon, 17 Feb 2014 12:35:23 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 684E22AABCE; Mon, 17 Feb 2014 20:35:20 +0000 (UTC) Date: Mon, 17 Feb 2014 20:35:20 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140217203520.GL278@mournblade.imrryr.org> References: <20140214200002.GK278@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.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/vbcFNXilUl7-dgMCljd7h7JWQr0 Subject: Re: [dane] Lukewarm discussion: DANE for opportunistic TLS protocols 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: Mon, 17 Feb 2014 20:35:27 -0000 On Mon, Feb 17, 2014 at 02:54:02PM -0500, Warren Kumari wrote: > We decided not to do that, but I wonder if in light of recent > revelations we should revisit this decision. I'm not quite sure how > we'd cram this into the current record, if it should be defined in > each of the "DANE with foo" docs or if it would require yet another RR > type... For what it is worth, I think that the DANE TLSA RRset is already too much rope. There is no need for yet more complexity. > Or we could give the person publishing the RR the ability to specify. They do that by publishing the RR, in the context of an application protocol (e.g. SMTP) where DANE TLS is opportunistic. My vote is strongly to let the TLSA RRset stand as-is, and allow "DANE for foo" specifications to define appropriate semantics in the context of "foo". In particular "discovery" would be a "foo-specific" feature. > > And, to be blunt, if we think that Viktor is right about DANE > for SMTP, shouldn't DANE for HTTP have the same MITM protection > and operational downsides? > > Personally I think that it should, but I might be in the weeds here. One of the key points in the introduction to the SMTP draft (please read at least the introduction). Is that analogies between HTTP and SMTP are deeply flawed. HTTP has no STARTTLS. HTTP has a separate URI scheme for security, which runs on a different port. If one were to design an opportunistic downgrade-resistant upgrade from HTTP to HTTPS, then one might consider approaches similar in spirit to the SMTP draft, though there would difficulties. Lack of STARTTLS means that any secure HTTP would need a separate port, and thus a simple detection of TLSA RRs is not sufficient. There would likely need to be SRV records (or something similar) for HTTP that a client would consult to determine whether a domain supported HTTPS and on what hosts/ports before falling back to HTTP. Since we're not designing HTTP here, I don't think we should discuss this any further. It is not really relevant, other than an observation that direct application of the SMTP draft to HTTP is not possible. -- Viktor. From nobody Tue Feb 18 07:12:08 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 A87D21A068D for ; Tue, 18 Feb 2014 07:12:06 -0800 (PST) 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 9WeFpNGsnguf for ; Tue, 18 Feb 2014 07:12:02 -0800 (PST) Received: from mail-wg0-f49.google.com (mail-wg0-f49.google.com [74.125.82.49]) by ietfa.amsl.com (Postfix) with ESMTP id 143F01A068A for ; Tue, 18 Feb 2014 07:12:01 -0800 (PST) Received: by mail-wg0-f49.google.com with SMTP id y10so3461287wgg.16 for ; Tue, 18 Feb 2014 07:11:58 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=KmABXplcRG5CxrEjPB7rfSDKK9xTWob/3+Sg44vuhcM=; b=KYYXrCEFw31Xl9rCkqbyS/TU5gYcl8+uuSSBpJVhZf2hhQzeaJbNM13Y6FfZmyqt9p AfuJ+GBBOpKs1nKdNF+ZfH8NztIk9NIExCLyH3AYowneiMsv3V72+hmb5JIWPI/7WIml WIgyTLXYyddBr3R0Ftanbxbc1eCqGuIxXsT0C/RdDwS3ICsWcg+xW3RpGefm+JfJK2iQ zCiOsUqFiqBPc8VKhfMvXbhjq+JAYrZf876K59yjlo2SLKZ4UF71M7hujhzrXR5/bMkn GeGrMmNVIjXW4YlJGViZxcoFIhb47hjW47gBFFxiABDjD7IuB4Md4TnLbO5oSOLgiIR2 UsgA== X-Gm-Message-State: ALoCoQn0U9de+wuuBkvDWRDRGekJWIM8kp7wvz4Er48onjy6qcBdMziWpuayPXITasevQlkNAdUu MIME-Version: 1.0 X-Received: by 10.194.86.130 with SMTP id p2mr1793536wjz.88.1392736318492; Tue, 18 Feb 2014 07:11:58 -0800 (PST) Received: by 10.194.54.167 with HTTP; Tue, 18 Feb 2014 07:11:58 -0800 (PST) X-Originating-IP: [98.244.98.35] Date: Tue, 18 Feb 2014 10:11:58 -0500 Message-ID: From: Warren Kumari To: "" Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/FgAtorQRD4khyg8h61KiD2u8PJA Subject: [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: Tue, 18 Feb 2014 15:12:06 -0000 Dear DANE WG, 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. There has been some discussion on these (well, the doc that was split to make these), and Paul Wouters will be discussing them in London. Please read the drafts and provide feedback onlist, supporting (or objecting to) adoption. Please also indicate if you are willing to contribute text, review, etc. We will discuss any large open questions in London, and so the call for adoption will end shortly after the meeting. Please make sure that you have actually read the drafts - this should be questions / discussions, not "Please open your hymn books to the Introduction and we'll all read along together". Please also note that Paul Hoffman will be leading a discussion at the beginning of the meeting on the key acquisition vs service discovery vs key usage assurance topic. This call for adoption ends Wed 12-Mar-2014. Thanks, Warren Kumari (as DANE WG co-chair) From nobody Tue Feb 18 07:30:51 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 F017D1A0697 for ; Tue, 18 Feb 2014 07:30:50 -0800 (PST) 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 9TbijA-FCEfU for ; Tue, 18 Feb 2014 07:30:45 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1E64A1A0503 for ; Tue, 18 Feb 2014 07:30:43 -0800 (PST) Received: by mail-we0-f172.google.com with SMTP id u56so1872719wes.17 for ; Tue, 18 Feb 2014 07:30:40 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=Cm7BFVM1/Ktpv7wgjWlQD81MHQYLrzKN4kKrtaKzmWQ=; b=gyHbi/IX1uS4tJyhm2EwTSahYYxIrY3KShZc2Aj2opF6iCr/neYSgaahb0NSHIBxT6 ERlO5/kS4xdaUSurcHxdkiQ943JcpKDNjq/nc3fxNZCzj2QU/etVvOE8GCRY+yV91rbB EVkEnoxr/T6/y8TRSYwo85tn/x+fGC9bumRgevcDSUyf8p8ptwHhe6diI5fRLmawdBUV gno/qf+xH359HsYDBvA9KwSRIx/m6MOOEIXUdv6Q9JaHDCDsd+8AjBbiYxSxInibfIDi B00PiX3Fm90b52ULG/loKP+Klcr5hHzdz0+NsHmCd1ZZP+/W5guaz391HTe3eXn3HJ44 TJEQ== X-Gm-Message-State: ALoCoQlYTV25mpyejylvWIOrgdXbmS82yLpAgQXosbmI7Ho0D66nudrV38O1PW+JG4SdN1smNIp5 MIME-Version: 1.0 X-Received: by 10.180.73.173 with SMTP id m13mr18599487wiv.52.1392737440752; Tue, 18 Feb 2014 07:30:40 -0800 (PST) Received: by 10.194.54.167 with HTTP; Tue, 18 Feb 2014 07:30:40 -0800 (PST) X-Originating-IP: [98.244.98.35] Date: Tue, 18 Feb 2014 10:30:40 -0500 Message-ID: From: Warren Kumari To: "" Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/gdoCrylhsHNq1yxa2pB_orbajLk Subject: [dane] DANE Agenda 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, 18 Feb 2014 15:30:51 -0000 Hi all. Please find the updated agenda. We have 6 or 7 drafts on the agenda this time. Please read them ahead of time so you can be primed with (intelligent!) questions :-) W DANE ------------- Administrivia (Sit down, blue-sheets, agenda bashing) Warren / Ondrej - 5 minutes. DANE - key acquisition, service discovery or usage assurance? Paul Hoffman - 30 minutes Using DANE to Associate OpenPGP public keys with email addresses draft-wouters-dane-openpgp-01 Discuss draft updates / issues, quick demo Paul Wouters - 10 minutes IPSECKEY / Auth_none draft-smyslov-ipsecme-ikev2-null-auth-00 Paul Wouters - 20 minutes Using DNS-Based Authentication of Named Entities (DANE) TLSA records with SRV and MX records. draft-ietf-dane-srv-05 Peter Saint-Andre or Matt Miller - 20 min Harmonizing how applications specify DANE-like usage draft-ogud-dane-vocabulary-01 (Quick update) Olafur - 5 min SMTP security via opportunistic DANE TLS draft-ietf-dane-smtp-with-dane-06 (NOTE: This is in WGLC.) Wes Hardaker - 20 minutes. DANE TLSA implementation and operational guidance draft-ietf-dane-ops-02 Wes Hardaker - 15 minutes. Provisional: Opportunistic Encryption with DANE Semantics and IPsec: IPSECA draft-osterweil-dane-ipsec Eric Osterweil - 10 minutes. (Only if we have time remaining). From nobody Tue Feb 18 07:33:10 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 BD0931A06B7 for ; Tue, 18 Feb 2014 07:33:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 E0Nufzd-ZuS7 for ; Tue, 18 Feb 2014 07:33:06 -0800 (PST) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id C26FD1A06B0 for ; Tue, 18 Feb 2014 07:33:05 -0800 (PST) Received: from agave.lan (h217-27-188-82.cust.tyfon.se [217.27.188.82]) by smtp7.webway.se (Postfix) with ESMTPA id 2491893DE40; Tue, 18 Feb 2014 15:33:01 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: "Olle E. Johansson" In-Reply-To: Date: Tue, 18 Feb 2014 16:33:00 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3C87C686-E963-4224-8399-2298C734D3C0@edvina.net> References: To: Warren Kumari , "dane@ietf.org list" X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/BrakOKJ8ztxlfwNMa9_x5YzU7zw Subject: Re: [dane] DANE Agenda 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, 18 Feb 2014 15:33:09 -0000 Hi! I will be discussing my SIP/DANE draft in the SIPcore meeting. It is = still very much work in progress and I'm listening a lot to the SRV, = SMTP and other discussions here. If there are no scheduling collissions, I'll be in the DANE meeting too. /O On 18 Feb 2014, at 16:30, Warren Kumari wrote: > Hi all. >=20 > Please find the updated agenda. >=20 > We have 6 or 7 drafts on the agenda this time. Please read them ahead > of time so you can be primed with (intelligent!) questions :-) >=20 > W >=20 > DANE > ------------- > Administrivia > (Sit down, blue-sheets, agenda bashing) > Warren / Ondrej - 5 minutes. >=20 > DANE - key acquisition, service discovery or usage assurance? > Paul Hoffman - 30 minutes >=20 > Using DANE to Associate OpenPGP public keys with email addresses > draft-wouters-dane-openpgp-01 > Discuss draft updates / issues, quick demo > Paul Wouters - 10 minutes >=20 > IPSECKEY / Auth_none > draft-smyslov-ipsecme-ikev2-null-auth-00 > Paul Wouters - 20 minutes >=20 > Using DNS-Based Authentication of Named Entities (DANE) TLSA records > with SRV and MX records. > draft-ietf-dane-srv-05 > Peter Saint-Andre or Matt Miller - 20 min >=20 > Harmonizing how applications specify DANE-like usage > draft-ogud-dane-vocabulary-01 > (Quick update) > Olafur - 5 min >=20 > SMTP security via opportunistic DANE TLS > draft-ietf-dane-smtp-with-dane-06 > (NOTE: This is in WGLC.) > Wes Hardaker - 20 minutes. >=20 > DANE TLSA implementation and operational guidance > draft-ietf-dane-ops-02 > Wes Hardaker - 15 minutes. >=20 > Provisional: > Opportunistic Encryption with DANE Semantics and IPsec: IPSECA > draft-osterweil-dane-ipsec > Eric Osterweil - 10 minutes. > (Only if we have time remaining). >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From nobody Tue Feb 18 08:50:23 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 9CF471A0517; Tue, 18 Feb 2014 08:50:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 s9fdgKeKXNMO; Tue, 18 Feb 2014 08:50:16 -0800 (PST) Received: from exprod6og103.obsmtp.com (exprod6og103.obsmtp.com [64.18.1.185]) by ietfa.amsl.com (Postfix) with ESMTP id B90801A04CB; Tue, 18 Feb 2014 08:50:13 -0800 (PST) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob103.postini.com ([64.18.5.12]) with SMTP ID DSNKUwOPQsveY98c//xVWDDLDd9dqGlkt1Wn@postini.com; Tue, 18 Feb 2014 08:50:13 PST Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id s1IGo9Wm022279 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 18 Feb 2014 11:50:10 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Tue, 18 Feb 2014 11:50:08 -0500 From: "Osterweil, Eric" To: Paul Wouters Thread-Topic: [dane] Review of draft-osterweil-dane-ipsec Thread-Index: AQHPK2MUZRHb4t3pi0a5DkeHSl/INpq7kACA Date: Tue, 18 Feb 2014 16:50:07 +0000 Message-ID: <63AF3625-9DEB-4F99-BCE4-B461CF757F87@verisign.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/k88feHOd2WISl3BMn7MFkOzTHQ0 Cc: "ipsec@ietf.org WG" , dane WG list Subject: Re: [dane] Review of draft-osterweil-dane-ipsec 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, 18 Feb 2014 16:50:20 -0000 Thanks for your review, Paul! I made some detailed comments below, but ahe= ad of those, one of the core things that we were trying to facilitate with = this draft is the notion that services may want to enable privacy protectio= ns selectively. While IPsec is a network layer service, we feel that this = approach + DANE could be leveraged to let operators enable these protection= s separately per service. For example, a cloud provider could enable this = for some of the clients that are virtualized on an instance (an IP) w/o nec= essarily doing so for all. This, we felt, was a fundamental opportunity, a= nd helped motivate the new work (in our minds). More comments below: On Feb 16, 2014, at 5:04 PM, Paul Wouters wrote: >=20 > Review of draft-osterweil-dane-ipsec >=20 > I'm heavilly involved with Oportunistic Encryption using IPsec with The > Libreswan Project. We opted to first gain more experience with running > code before attempting to write a draft. As such, we have found many > corner cases that need to be handled that are completely left out of > this document. I think it's a good idea if the authors of this document > talk to people in the IPsec and DANE working groups. >=20 > This draft introduces an overly complex and bad coupling of DNS, PKIX > and IPsec with the very limited goal of encrypting _some_ DNS traffic. >=20 > It seems to make a lot more sense to use (D)TLS to encrypt DNS traffic > using the existing TLSA records at the _53.{tcp|udp} prefix. >From a defense-in-depth perspective, we felt it was prudent to offer operat= ors and security practitioners multiple options form which they can create = their own security posture. When we effectuate our security posture in our= network, we like to have multiple tools and configurable opportunities to = create the security policies that best fit our needs. Securing protocols a= t different layers offers different benefits and drawbacks, and may even pr= ovide additive protections. I think the [D]TLS discussion is orthogonal: t= hat is, I think it's totally a good idea, but not in conflict with securing= the IP layer. >=20 > Further comments below, >=20 > Paul >=20 > Abstract >=20 > It is not clear from the document what is being attempted. Is it > encrypting all DNS traffic? The stub to the local resolver? Stub to a > remote resolver? What's special about DNS compared to using IPsec to > encrypt everything? The goal was being able to specify IPsec encryption on a per-service basis = (this draft focused on DNS), and allowing the server operators to specify w= hether they offer IPsec. So, resolver operators _could_ offer it to stubs,= and name server operators _could_ offer it to resolvers, but it doesn't ma= ndate that anyone deploy anything anywhere. Rather, it's opportunistic abo= ut securing communications between networks. Does that run afoul of OE? > Introduction >=20 > Don't use the word meta-data. It's just data. We don't need to give > TLA's more justification for the redefinition of the term meta-data. Actually, the reason for this phraseology is that I had thought this was sp= ecifically protecting meta-data leakage (i.e. the presence and timing of tx= ns vs. their content), no? The idea that an adversary can see the presence= (and nature of) of a txn is what the meta-data discussions are about, and = those are not protected by https. By contrast, obfuscating the participant= s (i.e. the zone) of a transaction that is being attempted between transact= ing parties protects meta-data. That was the rationale, anyway. I'm not h= ung up on the wording, and if it is unpalatable, how would you suggest to d= raw the distinction? > The introduction makes clear only (some?) DNS data is being targeted for > encryption. Why would protecting DNS using OE-IPsec be treated > differently from protecting ALL traffic using OE-IPsec? In the event that you only wanted to pay the transaction overhead for some = services (DNS), or for some service addresses (only some name servers), or = just for some high priority transacting parties. This seemed to be useful = knob for those that run very large infrastructures and have operational ove= rhead concerns. Was the Section ``Operational Considerations,'' helpful, o= r did it not convey this clearly? We felt that being able to offer a nuanc= ed security policy was one of the real advantages we saw in this approach. = =20 > For example, the information leakage exposed by observing DNSSEC > transactions, could enable an adversary to not only learn what Second > Level Domains (SLDs) a user is querying (such as their bank, a > funding agency, a security contractor, etc.), >=20 > How does encrypting the DNS help? So now you don't see I was going to "no= hats.ca", > but you see port 443 packets to 193.110.157.102. DNS information that is = encrypted > yet acted upon, leaks per definition. This is like encrypting visits to G= oogle Maps > while broadcasting your GPS coordinates. Observing DNS transactions is a completely independent way to monitor someo= ne's behavior. In a defense-in-depth security mode, this approach plugs th= e information leakage that is completely unaddressed by 443. True, if you = have a root-kit on a system, you can see everything, but if you passively m= onitoring DNS, you would no longer learn info from transactions. Perhaps I= 'm missing the objection, but as you've outlined above, OE for DNS seems to= plug a very expressive hole, right? > The last-mile protection argument is very weak. DNSSEC validators are mov= ing to what > used to be stub resolvers only. There is no need for new technology for l= ast-mile > protection. I have heard this, and talked to many people about it. I've also heard man= y obstacles being encountered, and I have noted that some are not as eager = to do this as others. That said, the deployment base of those who _don't_ = run recursive resolvers on their stubs is much larger right? Why would we = not pursue a solution that would benefit the larger constituency? I think = there are lot of benefits to running recursive resolvers on stubs, but I do= n't think we should abandon those who aren't doing it (i.e. most everyone t= oday) and I don't think we can count this large change in the immediate fut= ure or mandate it. By contrast, this draft would allow OE between resolver= s and name servers or stubs and resolvers (which would secure the last mile= in either case). >=20 > The bootstreap is unclear. DANE uses DNS yet you plan to encrypt DNS? I think we were hoping that the Section that discussed the bootstrapping cl= arified this, but perhaps not? The first transaction with the resolver wou= ld be to learn its IPSECA RR from the reverse zone, and then create an SPD = entry. The 00 draft needs more details in Appendix B on this, but we had h= oped the section describing the high-level conveyed this. Was it unclear, = or was there an error that would need addressing? > Section 1.1 >=20 > This section introduces using PKIX certificates for binding DNS to IPsec. > IPsec does not require X.509 and has support for bare public keys. Why > drag in the whole TLS style Certificate, Usage and Selectors? Unlike TLS, > there is no legacy base that needs to be accomodated. It makes no sense > to deviate from bare public keys. It adds all the complexity without much= , > if any, benefit over the traditional IPSECKEY record. >=20 > In fact, even the authors themselves see that: >=20 > The advantages of using DANE for IPsec OE also include other > simplifications that the DANE protocol inherently offers all of its > protocols. Such as, the automatic deauthorization of certificates > that happens when they are removed from a DNS zone , which may (under > many circumstances) obviate the need for extensive use of revocation > mechanisms (OCSP [RFC6960] or CRL [RFC5280]) >=20 > Storing public keys in DNS removes the need for things like PKIX expiry t= imes, > CRL, OCSP... So why introduce PKIX at all??? Fair point. Do you think the text should simply accommodate PKIX certs, bu= t defer to bare keys? Any chance you would be willing to suggest some text= ? > Section 1.2 >=20 > This section talks about IPSECKEY and dismisses its use because it is lim= ited to > IP-centric networks. This is not the case when one places IPSECKEYs in th= e forward > DNS (as the current Libreswan IPsec Opportunistic Encryption uses). For e= xample, > one can build a OE-IPsec tunnel to the host bofh.nohats.ca using the IPSE= CKEY > published for bofh.nohats.ca. No new IPSECA record is needed for that. Yeah, I definitely understand that. The intent of this discussion was main= ly to outline that IP-centric lookups could be improved. The discussion wa= s motived by the prescription to place IPSECKEY RRs in the reverse zone for= lookups. That said, as a DANE protocol, it seemed to make sense to harmon= ize the RR w/ the architectural directions that seemed to be forming, no? = Also, this draft was aimed at trying to enable service-level policies. > Section 1.3 >=20 > When an IPSECA record is discovered by a resolver, that resolver SHOULD= follow > its configurations and setup an SPD entry. >=20 > If your approach uses a local resolver to setup IPsec security, then > your approach could be much simplified using the same method we are > curently experimenting with, which is IPSECKEY records in the forward DNS > zone. If you are using a modified validating resolver on the host, it > also undermines your statement in the Introduction about this solution > being needed for last-mile authenticity of DNS - you already run a > validating resolver on teh stub. I think there are a couple of points you're making in the above, but perhap= s I misunderstand: - This approach is designed to be incrementally deployable and service base= d. I mentioned this above, so I don't mean to be too terse, but I don't wa= nt to be repetitive: this was about differentiation protections for service= , and it was being illustrated for DNS. - Validating resolvers don't provide the same transactional security model = as IPsec, so I don't follow the comment about local validating resolvers. > When using IPSECA resource records to verify OE tunnels, clients MUST > perform full DNSSEC validation of the DNSSEC chain of trust that > leads to IPSECA RRs >=20 > This looks like a big bootstrap issue. The old FreeS/WAN IPsec OE also > had isues with bootstrapping and DNS. It was so bad that when starting > freeswan, you would be dead in the water for about a minute while DNS > lookups for OE hit the OE machinery causing more OE lookups and it took > time to deal with all the failures before lines to DNS servers were > either encrypted or marked as cleartext (as opposed to block until we > know if we need to do crypto to it ) Interesting. How did you solve this? The idea behind the ``MUST'' was to = avoid spoofing during the bootstrap (as w/ other conversations in the wg). = Is the suggestion to not use DNSSEC for bootstrapping? I would definitely= worry about that, but would definitely like to hear your thoughts. > Trust anchors (which may be distributed during dynamic host > configuration) may be useful for bootstrapping. >=20 > Securing DHCP is a really hard problem. accepting trust anchors from DHCP > seems a security nightmare. It goes on to note that it is okay when using > RFC1918 space, but that is also dangerous. I might have VPN connections > that use RFC1918 that I don't wish to yield to a wifi-based trust anchor. I think the wording must have been unclear. The local TA/1918 discussion i= s the same thing, and is just a for-instance. Nominally, we have the abili= ty to provide these details to clients in our corporate image, so we might = look at that option. In the draft, however, we were trying not to be overl= y prescriptive. We had imagined that different installations would have di= fferent approaches here. For example, if you were to have local validating= resolvers (as you championed above), you would have to solve this for the = root TA anyway. Do you see a substantive difference? > Section 2 >=20 > This section specifies the IPSECA record. As I already said, I see no goo= d > reasons for introducing PKIX into this mix. I'm totally amenable to changing that. Do you have some suggestions? > Additionally, the use of a GATEWAY option means that these record MUST > NOT be used in any forward DNS, but only in the reverse, otherwise I > can put malicious entries into my forward DNS to steal other people's > IP address ranges. It is not very clear IPSECA is meant only to appear > in the reverse. Can you help me understand this? I would be able to send my clients to som= eone else's IP address for tunnel setup, but that would allow _them_ to ste= al _my_ traffic, right? I don't think I can steal their traffic this way, = right? Resolvers would come to me to ask about my branch of DNS, I could l= ead them away, or answer them. So, if I point my zone to your name servers= , you are the winner, not me, right? > Our experience with FreeS/WAN is that the reverse is just not good enough > apart for a few big players in data centers. And with IPv6, it becomes > even harder for people to put records in (resulting in amusing situations > like that I cannot email Paul Vixie). Depending on the reverse tree > means this will only be deployable by enterprises, and not by home users. Yeah, I think we were only talking about the reverse tree for stub-to-resol= ver lookups (and we imagined many of those would be in 1918 space). It was= only our suggestion for last-mile DNS. Was that one of the design goals o= f FreeS/WAN? > IPsec is an IP to IP protocol. It can be used to hide port > numbers. Deploying IPsec using _prefix constructions that expose port > numbers defeats part of the security that IPsec offers over inline > encryption such as TLS or STARTTLS. Again, we felt that offering a defense-in-depth solution was useful because= these security protocols have different profiles/benefits/drawbacks/etc. = We have a mosaic of security policies in our operational network, and we fi= nd it useful to have multiple cooperating options to configure. From an Op= Sec perspective, I look at these security protocols as quite cooperative (e= specially as each entity's security posture can be motivated by their uniqu= e needs). Those that run operational networks ought to be able to use netw= ork layer security and transport layer security. > Section 3 >=20 > The operational considerations are really weird. They basically state > "there is no operational impact as long as our protocol is not deployed > widely". I don't think that's completely true. Maybe the wording was unclear? We m= ention that the overhead can be managed and scales with the deployment. Th= e scale drops to 0 under non-deployment, true. Maybe the wording was confu= sing? > It does not mention anything about additional latency for the end user. I= t > does not talk about the IPsec NAT-T and clashing/overlapping internal > IP addresses. It does not mention anycast issues, load balancers, crypto > offloaders, etc. True. What level of discussion of these do you think would make sense? Th= ere are almost certainly a myriad of situations in which it does not make s= ense to deploy this, or to only deploy it incrementally. Do you have any s= uggestions for how to structure these discussions in the draft? > Section 5 >=20 > I'm not sure what the "cooperative benefits with TLS" are? What advantage > does this solution provide over using DNS (D)TLS with TLSA? I'm sure you know that there are tradeoffs to when and where I might want t= o use these different protocols, so I feel like I must be missing your obje= ction. Are you intimating that IPsec has no advantages over [D]TLS, or jus= t that there's a nuanced distinction here? >=20 > Any combination of these types of > protections offer both defense-in-depth (securing transactions at > multiple levels) and offer security practitioners a larger mosaic of > security tools from which to construct and maintain their security > postures. >=20 > This is a rather weak argument for adoption. So, this doesn't make sense to me. We use defense-in-depth models in our o= perations, and we find it very important in our daily operations. Why do y= ou see this as weak? Eric From nobody Tue Feb 18 10:41: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 4E2661A010A for ; Tue, 18 Feb 2014 10:41:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_17=0.6] 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 RfhM2H-qzgfF for ; Tue, 18 Feb 2014 10:41:33 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 75B201A00F2 for ; Tue, 18 Feb 2014 10:41:33 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id F06642AB258; Tue, 18 Feb 2014 18:41:28 +0000 (UTC) Date: Tue, 18 Feb 2014 18:41:28 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140218184128.GV278@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/kL2wa0YiGsS2CkNNjrKE1TQpfRw Subject: [dane] DNAMEs and TLSA name checks. 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, 18 Feb 2014 18:41:35 -0000 A comment Paul Wouters' OpenPGP drafts leads to an interesting observation about the interaction of DNAME redirection and TLSA name checks. Suppose we have DNAME that designates "b.example" as an alternative name for "a.example". Suppose, in a hypothetical universe where browsers implement DANE, a user browses to . The DNSSEC query for the address records of "www.b.example" will determine that this host is an alias: b.example. IN DNAME a.example. www.b.example. IN CNAME www.a.example. ; + related RRSIGs proving the DNAME "secure" In our hypothetical universe, there are TLSA records of the form: _443._tcp.www.a.example. IN TLSA DANE-TA Cert SHA2-256 {blob} ; + related RRSIGs proving the TLSA RRset "secure" If the user's browser does not follow the advice of the DANE ops draft, it will look for TLSA records at the original dns name, that is not CNAME expanded: _443._tcp.www.b.example. IN TLSA ? Because of the DNAME it will see the same TLSA RRset: b.example. IN DNAME a.example. _443._tcp.www.b.example. IN CNAME _443._tcp.www.a.example. ; + related RRSIGs proving the DNAME "secure" _443._tcp.www.a.example. IN TLSA DANE-TA Cert SHA2-256 {blob} ; + related RRSIGs proving the TLSA RRset "secure" However, its "TLSA" base domain is "www.b.example", thus given a CU of DANE-TA(2) it will expect the server certificate to include "www.b.example". This means that servers would need to carry all DNAME variant DNS name forms in their certificates. If, however, CNAME expansion is performed per the OPs draft, the TLSA base domain will be "www.a.example", and server certificates need only match the primary domain. This issue should be rare with SRV and MX records, since the target of the SRV or MX record is required to not be an alias and the TLSA base domain is taken from the target of SRV or MX records. The point of this post is to highlight the interaction of DNAME records with certificate name checks and why (absent SRV or MX redirection) TLSA RRs should be sought after CNAME expansion of the target domain. The SMTP draft requires similar logic when MTAs allow CNAMEs in the MX hostname. I don't recall whether the SRV draft says anything about CNAME expansion for SRV targets (again not supposed to happen, but if supported, should probably be CNAME expanded). -- Viktor. From nobody Wed Feb 19 12:56:09 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 E78C11A0152 for ; Wed, 19 Feb 2014 12:56:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.249 X-Spam-Level: X-Spam-Status: No, score=-1.249 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.548] 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 rWMyFDFw8vMc for ; Wed, 19 Feb 2014 12:56:07 -0800 (PST) Received: from mail.hardakers.net (mail.hardakers.net [168.150.236.43]) by ietfa.amsl.com (Postfix) with ESMTP id 5A4501A01F9 for ; Wed, 19 Feb 2014 12:56:07 -0800 (PST) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id C0CE225A6D; Wed, 19 Feb 2014 12:56:03 -0800 (PST) From: Wes Hardaker To: Warren Kumari References: Date: Wed, 19 Feb 2014 12:56:03 -0800 In-Reply-To: (Warren Kumari's message of "Thu, 13 Feb 2014 16:58:15 -0500") Message-ID: <0lk3cqizz0.fsf@wjh.hardakers.net> User-Agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/dane/MIZ-isa8nRniAK9y_nnREdLJUsE Cc: dane@ietf.org Subject: Re: [dane] Reminder about IPR relating to draft-ietf-dane-smtp-with-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: Wed, 19 Feb 2014 20:56:09 -0000 Warren Kumari writes: > If you are a document author or listed contributor on this document, > please reply to this email regardless of whether or not you are > personally aware of any relevant IPR. We might not be able to advance > this document to the next stage until we have received a reply from > each author and listed contributor. I am not aware of any IPR related to the technology in the draft-ietf-dane-smtp-with-dane document. (I am also not a laywer) -- Wes Hardaker Parsons From nobody Thu Feb 20 07:49: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 D96541A01F2 for ; Thu, 20 Feb 2014 07:49:53 -0800 (PST) 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 7GKboI8_OB5f for ; Thu, 20 Feb 2014 07:49:51 -0800 (PST) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 917F61A01E4 for ; Thu, 20 Feb 2014 07:49:46 -0800 (PST) Received: by mail-wg0-f44.google.com with SMTP id k14so1578398wgh.11 for ; Thu, 20 Feb 2014 07:49:42 -0800 (PST) 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=gB8TXBuRvFeDvNJgOolX5vP4jh59EKnsAsjwQ1c8WSA=; b=OErVrCHZk457Hmvp7ie/IDk2pxMjETjy+YbkEEjzf47xyI20TSz1uzpyu94z+d9v9r 92BVxS7W6g/YKfWV4HfBKOSb7BwaD25dgRqWNlNMFqcrIn9H9GdiSF5I8qG8So08/sVL caMjfX3grmmcVqlGjUp3/tapricrim8TOwxk3qrbBLIy00tgOZCNa6oZJrZWIIFaZJ0l ei/DgjSvJYK5YGYD9wqYi3KHn1NvYcsVzM4D5/OpIbxE7/BaoFeXFhFUUabhEOEiK1qH 253DTewHUnBUrEXh/eYDDa2E6wJ/6UtoMSorowg1Tha0p9S3HJ4DxNXBM/yfzN/8LyeY VMTQ== X-Gm-Message-State: ALoCoQkvBNemicKuv9oxWkXtg//dB3Uo0Co8G2JHJuZcBNkvoFPPLT+vlH5jF2M7lL6mnC+8u8lq MIME-Version: 1.0 X-Received: by 10.195.13.103 with SMTP id ex7mr2690146wjd.3.1392911382267; Thu, 20 Feb 2014 07:49:42 -0800 (PST) Received: by 10.194.54.167 with HTTP; Thu, 20 Feb 2014 07:49:41 -0800 (PST) X-Originating-IP: [98.244.98.35] In-Reply-To: <20130523152607.GL25080@mournblade.imrryr.org> References: <519BDB2E.90805@stpeter.im> <2375B9D3-9A93-499F-A31C-8F6CB887FA05@vpnc.org> <20130521225232.GB582@mournblade.imrryr.org> <20130523152607.GL25080@mournblade.imrryr.org> Date: Thu, 20 Feb 2014 10:49:41 -0500 Message-ID: From: Warren Kumari To: "" Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/AHwqdTWwRI0LGACVRa_wfTxNpqo Subject: Re: [dane] making ietf.org eat the DANE dogfood 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: Thu, 20 Feb 2014 15:49:54 -0000 And reviving a really old thread... Just FYI, I posted this on perpass, realized I should have updated DANE too... AMS had lost one of their sysadmins a while back-- they have hired a replacement, and are still planning on doing STARTTLS and DANE. The new person started recently and it takes some time to get up to speed / figure out where the skeletons are buried. Their "current estimate is that we will be able to address it directly following London, rather than before." I'm sure we are all somewhat frustrated at the delays (it *should* be a simple change), but I can understand them not wanting to make changes before the meeting / before the new person is fully up to speed. I'll push them after the meeting ends... W On Thu, May 23, 2013 at 11:26 AM, Viktor Dukhovni wrote: > On Tue, May 21, 2013 at 10:52:32PM +0000, Viktor Dukhovni wrote: > >> posttls-finger: Connected to mail.ietf.org[2001:1890:123a::1:1e]:25 >> posttls-finger: < 220 ietfa.amsl.com ESMTP Postfix >> posttls-finger: > EHLO amnesiac.local >> posttls-finger: < 250-ietfa.amsl.com >> posttls-finger: < 250-PIPELINING >> posttls-finger: < 250-SIZE 67108864 >> posttls-finger: < 250-ETRN >> posttls-finger: < 250-AUTH LOGIN PLAIN >> posttls-finger: < 250-AUTH=LOGIN PLAIN >> posttls-finger: < 250-ENHANCEDSTATUSCODES >> posttls-finger: < 250-8BITMIME >> posttls-finger: < 250 DSN >> posttls-finger: > QUIT >> posttls-finger: < 221 2.0.0 Bye >> >> For some reason this MX host supports SASL (more suitable for an >> MSA, where one would also want TLS for PLAIN or LOGIN), but not >> TLS which is appropriate for an inbound MX. > > FWIW, AMS (aka amsl.com) are no strangers to SMTP + STARTTLS: > > $ posttls-finger amsl.com > posttls-finger: Connected to mail.amsl.com[64.170.98.20]:25 > posttls-finger: < 220 c8a.amsl.com ESMTP Postfix > posttls-finger: > EHLO amnesiac.localhost > posttls-finger: < 250-c8a.amsl.com > posttls-finger: < 250-PIPELINING > posttls-finger: < 250-SIZE 67108864 > posttls-finger: < 250-ETRN > posttls-finger: < 250-STARTTLS > posttls-finger: < 250-AUTH PLAIN LOGIN > posttls-finger: < 250-AUTH=PLAIN LOGIN > posttls-finger: < 250-ENHANCEDSTATUSCODES > posttls-finger: < 250-8BITMIME > posttls-finger: < 250 DSN > posttls-finger: > STARTTLS > posttls-finger: < 220 2.0.0 Ready to start TLS > posttls-finger: mail.amsl.com[64.170.98.20]:25 CommonName smtp.amsl.com > posttls-finger: certificate verification failed for mail.amsl.com[64.170.98.20]:25: self-signed certificate > posttls-finger: mail.amsl.com[64.170.98.20]:25: subject_CN=smtp.amsl.com, issuer_CN=smtp.amsl.com, fingerprint=A8:39:D3:5D:90:65:96:D4:BB:DB:0A:E5:F9:C8:0E:14:99:15:7D:6C, pkey_fingerprint=0F:E2:FB:2F:A6:AA:69:3B:B6:4A:A3:40:6B:FD:2D:09:95:03:74:38 > posttls-finger: Untrusted TLS connection established to mail.amsl.com[64.170.98.20]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits) > posttls-finger: > EHLO amnesiac.localhost > posttls-finger: < 250-c8a.amsl.com > posttls-finger: < 250-PIPELINING > posttls-finger: < 250-SIZE 67108864 > posttls-finger: < 250-ETRN > posttls-finger: < 250-AUTH PLAIN LOGIN > posttls-finger: < 250-AUTH=PLAIN LOGIN > posttls-finger: < 250-ENHANCEDSTATUSCODES > posttls-finger: < 250-8BITMIME > posttls-finger: < 250 DSN > posttls-finger: > QUIT > posttls-finger: < 221 2.0.0 Bye > > -- > Viktor. > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > From nobody Fri Feb 21 06:42:16 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 400921A018B for ; Fri, 21 Feb 2014 06:42:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hqx2m_war-Ux for ; Fri, 21 Feb 2014 06:42:12 -0800 (PST) Received: from mail-la0-x235.google.com (mail-la0-x235.google.com [IPv6:2a00:1450:4010:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 3F7291A0316 for ; Fri, 21 Feb 2014 06:42:11 -0800 (PST) Received: by mail-la0-f53.google.com with SMTP id e16so2369092lan.26 for ; Fri, 21 Feb 2014 06:42:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2/plgab7eAUqik2yRzz6RP0u2uv+7eCHn9WlqeBN4Bs=; b=vz/KbbLqdji0UnIuU3bAR9g+gJHu/9pclJy0icJxcrESVK+6Oa19Whl+5ww/rOsZEI UuUhR03i/uerpNx1qQl6jYG+b4Y7aelESd3AjOsTRrdqeU+/uRYQOzAbDoEOMeHkOU87 eGPcWR6vvnBYYhSm0qwZmWve7mXXncuyW89OCOfY2nJ/+6E6mRZNjz68wM8Oh3gyiLDd JCz+LY4BEQFwFtklD0bK7iQR5rhfz5V+eR1QhEwR50oAU8nd4gfgPLMSFYOU/snLFdHs wlrvG9zJuqLDTcWA+Y67vowLYPehzhWVlptkfkEnRaePRyxeoJWQnPxXkS6TZA1O2QJn ROaQ== MIME-Version: 1.0 X-Received: by 10.112.39.167 with SMTP id q7mr4254525lbk.82.1392993726533; Fri, 21 Feb 2014 06:42:06 -0800 (PST) Received: by 10.112.37.168 with HTTP; Fri, 21 Feb 2014 06:42:06 -0800 (PST) In-Reply-To: References: <20140214200002.GK278@mournblade.imrryr.org> Date: Fri, 21 Feb 2014 09:42:06 -0500 Message-ID: From: Phillip Hallam-Baker To: Paul Hoffman Content-Type: multipart/alternative; boundary=001a1134d7ae3e969404f2eba0f0 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/KNY7Ofd-eJF9h41s9BXEBaNstck Cc: "" Subject: Re: [dane] Lukewarm discussion: DANE for opportunistic TLS protocols 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, 21 Feb 2014 14:42:15 -0000 --001a1134d7ae3e969404f2eba0f0 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Feb 14, 2014 at 7:48 PM, Paul Hoffman wrote: > On Feb 14, 2014, at 2:50 PM, James Cloos wrote: > > > The only real question is whether dane-srv and dane-smtp-with-dane > > should be published as two rfcs or combined into one? > > (I'm leaning towards two, numerically adjacent.) > > With all due respect, there are other real questions, much more > significant than that one. > > One of the biggest questions that needs to be asked is not whether DANE > can be used for opportunistic protocols, because of course it can, but > whether DANE can be used to determine whether a server at a domain name > "should" be speaking TLS at the time that a client tries to connect. Viktor > makes a strong case that it does for SMTP. During the early discussions of > TLSA, many people thought it should not. > I argued for making DANE a security policy protocol at the start. Now you are wondering if what you produced works as a security policy protocol. It can but the critical mass for adoption is almost certainly too high. DNS resource records are cheap. DNS lookups are not cheap. DANE has a last mile problem because you can't know if the DNSSEC record has been stripped out by an attacker or by some local network firewall. The way to cut the Gordian knot here is to provide an efficient way to retrieve all the information necessary to set up a request in one lookup. That solves the last mile problem and the multiple lookup problem at the same time. -- Website: http://hallambaker.com/ --001a1134d7ae3e969404f2eba0f0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Fri, Feb 14, 2014 at 7:48 PM, Paul Hoffman <= ;paul.hoffman@vp= nc.org> wrote:
On Feb 14, 2014, at 2:50 PM, James Cloos &= lt;cloos@jhcloos.com> wrote:
> The only real question is whether dane-srv and dane-smtp-with-dane
> should be published as two rfcs or combined into one?
> (I’m leaning towards two, numerically adjacent.)

With all due respect, there are other real questions, much more signi= ficant than that one.

One of the biggest questions that needs to be asked is not whether DANE can= be used for opportunistic protocols, because of course it can, but whether= DANE can be used to determine whether a server at a domain name "shou= ld" be speaking TLS at the time that a client tries to connect. Viktor= makes a strong case that it does for SMTP. During the early discussions of= TLSA, many people thought it should not.

I argued for making DANE a security policy= protocol at the start. Now you are wondering if what you produced works as= a security policy protocol. It can but the critical mass for adoption is a= lmost certainly too high.

DNS resource records are cheap. DNS lookups are not che= ap.

DANE has a last mile problem because you can&#= 39;t know if the DNSSEC record has been stripped out by an attacker or by s= ome local network firewall.


The way to cut the Gordian knot here is = to provide an efficient way to retrieve all the information necessary to se= t up a request in one lookup. That solves the last mile problem and the mul= tiple lookup problem at the same time.

--
Website: ht= tp://hallambaker.com/
--001a1134d7ae3e969404f2eba0f0-- From nobody Fri Feb 21 06:47: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 83ED81A03EE for ; Fri, 21 Feb 2014 06:47:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.454 X-Spam-Level: X-Spam-Status: No, score=-0.454 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RP_MATCHES_RCVD=-0.548, 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 naD4M-2GpEpg for ; Fri, 21 Feb 2014 06:46:58 -0800 (PST) Received: from arn2-kamx.sidn.nl (kamx.sidn.nl [IPv6:2a00:d78:0:147:94:198:152:69]) by ietfa.amsl.com (Postfix) with ESMTP id AA7371A02D0 for ; Fri, 21 Feb 2014 06:46:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; d=sidn.nl; s=sidn_nl; c=relaxed/relaxed; h=message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding:x-originating-ip; bh=VfiJDqN+5iXQwQy7z2rbJpsYAGRm1ILC8k9oExMBpS0=; b=GUeTJTS7E4peuUEfksSbHbg5qEPRM2dRsmwMbJ3aEp1Cy7DSaNJD0rTdglfYvmP1o2JQc7sRWIGFJdOzVEPhhRX6gNnXZS3u1Y9n4uVNNgmGdqohrDwgZtZSfsfdyamUDDeEkVFCdm9Wnma4O4PdfFNRQQEHABqfxy/BFNHLVJY= Received: from kahubcasn01.SIDN.local ([192.168.2.73]) by arn2-kamx.sidn.nl with ESMTP id s1LEkoCa026481-s1LEkoCc026481 (version=TLSv1.0 cipher=AES128-SHA bits=128 verify=CAFAIL); Fri, 21 Feb 2014 15:46:50 +0100 Received: from [94.198.152.219] (94.198.152.219) by kahubcasn01.SIDN.local (192.168.2.77) with Microsoft SMTP Server (TLS) id 14.3.174.1; Fri, 21 Feb 2014 15:46:45 +0100 Message-ID: <530766D5.6070800@sidn.nl> Date: Fri, 21 Feb 2014 15:46:45 +0100 From: Jelte Jansen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131103 Icedove/17.0.10 MIME-Version: 1.0 To: Phillip Hallam-Baker References: <20140214200002.GK278@mournblade.imrryr.org> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [94.198.152.219] Archived-At: http://mailarchive.ietf.org/arch/msg/dane/MCUWgnOlCYg4iXEA-Df3WkkXhBk Cc: Paul Hoffman , "" Subject: Re: [dane] Lukewarm discussion: DANE for opportunistic TLS protocols 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, 21 Feb 2014 14:47:00 -0000 On 02/21/2014 03:42 PM, Phillip Hallam-Baker wrote: > > The way to cut the Gordian knot here is to provide an efficient way to > retrieve all the information necessary to set up a request in one > lookup. That solves the last mile problem and the multiple lookup > problem at the same time. > Something like http://tools.ietf.org/html/draft-wouters-edns-chain-query-00 might be of interest, in that case. Jelte From nobody Fri Feb 21 07:01:26 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 B3A3E1A0179 for ; Fri, 21 Feb 2014 07:01:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, 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 qvtLrJcpR1CZ for ; Fri, 21 Feb 2014 07:01:23 -0800 (PST) Received: from rock.ICSI.Berkeley.EDU (rock.ICSI.Berkeley.EDU [192.150.186.19]) by ietfa.amsl.com (Postfix) with ESMTP id DE5D41A0172 for ; Fri, 21 Feb 2014 07:01:22 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 3B4BE2C402A; Fri, 21 Feb 2014 07:01:19 -0800 (PST) X-Virus-Scanned: amavisd-new at ICSI.Berkeley.EDU Received: from rock.ICSI.Berkeley.EDU ([127.0.0.1]) by localhost (maihub.ICSI.Berkeley.EDU [127.0.0.1]) (amavisd-new, port 10024) with LMTP id L767yMibcsDL; Fri, 21 Feb 2014 07:01:16 -0800 (PST) Received: from gala.icir.org (gala.icir.org [192.150.187.130]) (Authenticated sender: nweaver) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 90A8E2C400A; Fri, 21 Feb 2014 07:01:16 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_BDCABE8E-3F0B-4FCF-ADBF-F8426A820BF9"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Nicholas Weaver In-Reply-To: Date: Fri, 21 Feb 2014 07:01:16 -0800 Message-Id: References: <20140214200002.GK278@mournblade.imrryr.org> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/wKZYwL4ArkVqvexKubn0fKMqBgM Cc: Paul Hoffman , "" Subject: Re: [dane] Lukewarm discussion: DANE for opportunistic TLS protocols 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, 21 Feb 2014 15:01:24 -0000 --Apple-Mail=_BDCABE8E-3F0B-4FCF-ADBF-F8426A820BF9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Feb 21, 2014, at 6:42 AM, Phillip Hallam-Baker = wrote: > DANE has a last mile problem because you can't know if the DNSSEC = record has been stripped out by an attacker or by some local network = firewall. The client can know. It starts by asking for DNSKEY for ., etc. = Because you have NSEC/NSEC3 provable denial of existence, you can know = if DNSSEC records are being stripped. In particular, the problem for this tends to be internet cafes and the = like. Home networks tend to be atrocious on the DNS proxies, but the = client can usually go around them and get things directly. Business = network firewalls may restrict client DNS, but they usually operate = properly and the recursive resolver itself supports DNSSEC. Its the net cafes, hotels, etc (basically, anything with a captive = portal) which combines both a crappy DNS proxy AND DNS access = restrictions that is the problem. > The way to cut the Gordian knot here is to provide an efficient way to = retrieve all the information necessary to set up a request in one = lookup. That solves the last mile problem and the multiple lookup = problem at the same time. Agreed, with a minor caveat. =20 The only disadvantage is that on the server side you need to get this = data fairly frequently, since the timeout may be fast (first expiring = RRSIG on the chain of validation from . to the DANE record), which means = the very rarely updating certificate store model common to web servers = isn't appropriate, but that's no real-big-deal. -- Nicholas Weaver it is a tale, told by an idiot, nweaver@icsi.berkeley.edu full of sound and fury, 510-666-2903 .signifying nothing PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc --Apple-Mail=_BDCABE8E-3F0B-4FCF-ADBF-F8426A820BF9 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCgAGBQJTB2o8AAoJEG2B1w+SDi/ugWUP/3PlATVsezx2mz5fLJ8oQyqE iyCLal+EE5iftPNwiel8WaiLeuX5JujFcK1jVfwfIWgf4GGw4G3DBZxT5uhDBHty 5dQTabOxx7T6zVmw+mWF8sArH5BhRb9G7XctvQpJxUMnl/UFGvQIqjiLqoBKT/Bo paHYH4fIaZ+M4SLn6R7TsAXSJkXkxODm9DtDSrxGfJbXkr8D8YAyNcsMx1c5nW1i pvzkx7g87wZ9DtlTyQnk1mg1f8jyN+gyggG+l8FwCbqaHpHS0eR8pPVlD0wizRhU AAg6HQo4uTKIi7GHoC1Oe/UaXRqZik5iRU44qDlBRJAXy6rP+oLpLb4bApy9pyu5 8mWjmKXtIFejvf6KQhhENVqIU9o38SF6J2Wq9vgjPwl8ccBMByCK97KAoVLQTEGJ x1ZpkRmIVCNpA/VHlNsRfDqu8/Pvy+UhOoAyL69rcGPrISDF2tEc2I5ZIZJ/AZnM oBp1QGfOpBRiC1WAaiUh3tvNT/YelfLSN4dsXzN+cfdADdPl0ATlJ+D/q05pcu8W CasGSvZShJZDViLNHrFLhl3A+7ZXUpInUh8/d0xNYw4Eb77EfBKdcaiKV2gL2qYt elnYUSDTKe4oSk0ekl/hABybuwNLCTyYJYoy9OfypLDeadwwDRyymyCQEUMwfl1t AohTGaP3pRuewbCVCVD+ =TDDU -----END PGP SIGNATURE----- --Apple-Mail=_BDCABE8E-3F0B-4FCF-ADBF-F8426A820BF9-- From nobody Fri Feb 21 08:00:07 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 1CD701A0279 for ; Fri, 21 Feb 2014 08:00:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 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.548] 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 A-bhQ_KEGaDy for ; Fri, 21 Feb 2014 08:00:04 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 02BDA1A01D3 for ; Fri, 21 Feb 2014 08:00:03 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 5730E800AF; Fri, 21 Feb 2014 10:59:59 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1392998399; bh=3dEkbShCUVIpVVyJ8cn8o4E9pbEyaj1yXF69dWckkS0=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=hFuWm7j19iti1M+td6jDfsfaRrLP28Q1YXiiyUCc3eI08aO8njaHcZNPTPAM5ImCD TJtsThtR1gdnHMSZLHWZj+LPVCKll8cXi/j0n5Regeose7uCGu5JosBDha6fDZFTk0 nQ0DX0QtPrxAERQuvitIg7cBKj+51Nm82eHxf2p8= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s1LFxwSs015473; Fri, 21 Feb 2014 10:59:59 -0500 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Fri, 21 Feb 2014 10:59:58 -0500 (EST) From: Paul Wouters To: Nicholas Weaver In-Reply-To: Message-ID: References: <20140214200002.GK278@mournblade.imrryr.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/L0R6yTqxuy4BXUVjPhw-sR1IYds Cc: "" Subject: Re: [dane] Lukewarm discussion: DANE for opportunistic TLS protocols 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, 21 Feb 2014 16:00:06 -0000 On Fri, 21 Feb 2014, Nicholas Weaver wrote: > The only disadvantage is that on the server side you need to get this data fairly frequently, since the timeout may be fast (first expiring RRSIG on the chain of validation from . to the DANE record), which means the very rarely updating certificate store model common to web servers isn't appropriate, but that's no real-big-deal. huh? If I put a 9999999 rrsig timeout on my TLSA signature, once you fetched it, it is pretty irrelevant that somewhere upstream an rrsig expired. Are you suggesting resolvers should throw away chains of dns from the cache once a single rrsig expires? Paul From nobody Fri Feb 21 08:25:09 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 D8BF31A01F1 for ; Fri, 21 Feb 2014 08:25:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, 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 dMpvDoQ9a1_H for ; Fri, 21 Feb 2014 08:25:05 -0800 (PST) Received: from rock.ICSI.Berkeley.EDU (rock.ICSI.Berkeley.EDU [192.150.186.19]) by ietfa.amsl.com (Postfix) with ESMTP id E77041A0170 for ; Fri, 21 Feb 2014 08:25:05 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 100342C4047; Fri, 21 Feb 2014 08:25:02 -0800 (PST) X-Virus-Scanned: amavisd-new at ICSI.Berkeley.EDU Received: from rock.ICSI.Berkeley.EDU ([127.0.0.1]) by localhost (maihub.ICSI.Berkeley.EDU [127.0.0.1]) (amavisd-new, port 10024) with LMTP id N9C5M1x2YVvy; Fri, 21 Feb 2014 08:24:59 -0800 (PST) Received: from gala.icir.org (gala.icir.org [192.150.187.130]) (Authenticated sender: nweaver) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 15B7C2C400A; Fri, 21 Feb 2014 08:24:59 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_C20B6DAC-7A29-42D4-AE82-32DD5EBFDE4F"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Nicholas Weaver In-Reply-To: Date: Fri, 21 Feb 2014 08:24:58 -0800 Message-Id: References: <20140214200002.GK278@mournblade.imrryr.org> To: Paul Wouters X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/WGJyuvqIx_XH11eNDk37PZEzlvY Cc: "" Subject: Re: [dane] Lukewarm discussion: DANE for opportunistic TLS protocols 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, 21 Feb 2014 16:25:08 -0000 --Apple-Mail=_C20B6DAC-7A29-42D4-AE82-32DD5EBFDE4F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Feb 21, 2014, at 7:59 AM, Paul Wouters wrote: > On Fri, 21 Feb 2014, Nicholas Weaver wrote: >=20 >> The only disadvantage is that on the server side you need to get this = data fairly frequently, since the timeout may be fast (first expiring = RRSIG on the chain of validation from . to the DANE record), which means = the very rarely updating certificate store model common to web servers = isn't appropriate, but that's no real-big-deal. >=20 > huh? If I put a 9999999 rrsig timeout on my TLSA signature, once you > fetched it, it is pretty irrelevant that somewhere upstream an rrsig > expired. >=20 > Are you suggesting resolvers should throw away chains of dns from the > cache once a single rrsig expires? F-yeah. An RRSIG's validity interval should not extend beyond the = validity interval of all RRSIGs needed to validate this RRSIG. DNSSEC = does not have a revocation mechanism, but in lieu of a revocation = mechanism you have the much more limited validity of RRSIGs, and if the = upstream authority says your DS record expires in an hour, why should = you be able to override that policy? But even if thats not the case, an non-DNS server which provides the = data on demand, namely a full validation chain, needs to treat things = this way, as it would not be able to provide a valid-at-the-time RRSIG: = yeah, your 9999999 RRSIG might still be valid, but the captured RRSIG = for the DS from the authority server also needs to be valid when it is = presented to the client. So lets take a real world case, www.isc.org: Record Expires DS org 2014-02-28-000000 DNSKEY org 2014-03-10-155510 DS isc.org 2014-03-10-155510 DNSKEY isc.org 2014-03-19-230128 A www.isc.org 2014-03-19-233241 A non-DNS server which is providing a DNSSEC validation chain for = www.isc.org needs to be aware of all these expiration times: there are = at least 3 (and possibly 4) separate expiration intervals, all with = different phase to boot. And I'd expect the expiration times for DNSSEC records to go down, = rather than up, as people realize that online signing offers some = significant advantages operationally (dynamic NSEC3 lies, quick reacting = DNS load balancing, etc) and the cost of online signing may have been = expensive 10 years ago but is nearly free today. -- Nicholas Weaver it is a tale, told by an idiot, nweaver@icsi.berkeley.edu full of sound and fury, 510-666-2903 .signifying nothing PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc --Apple-Mail=_C20B6DAC-7A29-42D4-AE82-32DD5EBFDE4F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCgAGBQJTB33aAAoJEG2B1w+SDi/umNwP/2G+2mVJ8cPpsndrTKeHPLK6 xn0zjuMnfPQEn7d0AnyQOEwUiHBzZVTf9ZbeK6xHdlwINfFNDH63z7hjZwCYC1cU UmqvEcwaps2OYI54bBcskoUofr78hGxjZRMEPQvQG9nxSTyuMIc9A5EahI8Fe5vP TxczCjZJ2HDLhi2XTUSnfQp48tbf0Y/X6x716YFs6wjIjWDOsFUXA3GnYFO9ldu9 zlL5C6Z0lBYnd2hRqrozGG32CnI6JHQ3iOvPv7pN+XA1sqnudlfiIV8vtHbrLjJo DtY1LU9BjHrrjJ/XrKi8MEeGuuQiuGPVJfS1ZUpVKcg35YiJD8F4sg7UhXFHy+z9 shyhi8OWKxbr4gjwqJ64npYfcyWlKEtT3CCU7GqGzVLZnlFvLjciryx3BxpIQ4BR ybt9wxDXnVDnJDPo/276D3FJyGwG179mDQkg6IinLmaK6JR/GwRSLfSbGUjmsdV8 yxG2tzx1NssYgQrJu+RZMA6qVSYhm2p+WB1B00yu+H++PGHD++CerPRBCRSCIzz5 fGH6Ehq7jK29BcciWed1mbX5a2lZdC8mLfWcMyGR2i6FbBucbaBxMUJJEmfIx3yd Dn/Ze52G0g7DGOVDfLeeg/RXY03sRDLxi/PWD4/gKfGeIjGOcfZUw3+at4nAKvB6 eTjsGtrHAFDCbLCgmyno =qQIE -----END PGP SIGNATURE----- --Apple-Mail=_C20B6DAC-7A29-42D4-AE82-32DD5EBFDE4F-- From nobody Fri Feb 21 08:38: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 452791A01EC for ; Fri, 21 Feb 2014 08:38:30 -0800 (PST) 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 tJkiJRQqP1av for ; Fri, 21 Feb 2014 08:38:27 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 941C41A01EB for ; Fri, 21 Feb 2014 08:38:27 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 1A44D2AAD11; Fri, 21 Feb 2014 16:38:22 +0000 (UTC) Date: Fri, 21 Feb 2014 16:38:22 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140221163822.GT278@mournblade.imrryr.org> References: <20140214200002.GK278@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.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/UStnTLc3HVEkz1x07d33yQGS3OA Subject: Re: [dane] Lukewarm discussion: DANE for opportunistic TLS protocols 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: Fri, 21 Feb 2014 16:38:30 -0000 On Fri, Feb 21, 2014 at 09:42:06AM -0500, Phillip Hallam-Baker wrote: > > One of the biggest questions that needs to be asked is not whether DANE > > can be used for opportunistic protocols, because of course it can, but > > whether DANE can be used to determine whether a server at a domain name > > "should" be speaking TLS at the time that a client tries to connect. Viktor > > makes a strong case that it does for SMTP. During the early discussions of > > TLSA, many people thought it should not. > > I argued for making DANE a security policy protocol at the start. Now you > are wondering if what you produced works as a security policy protocol. It > can but the critical mass for adoption is almost certainly too high. > > DNS resource records are cheap. DNS lookups are not cheap. For the record, my argument for DANE as a "TLS discovery" mechanism is strongly SMTP-specific. I make no claims about TLS discovery in other contexts. In MTA to MTA SMTP: - There is no signficant last-mile problem. The vast majority of MTAs don't globe-trot. - SMTP TLS security is opportunistic and sans DANE unauthenticated. We're using DANE to make possible an MITM downgrade-resistant opportunistic upgrade from cleartext to authenticated TLS. - SMTP is not a real-time protocol. - SMTP DNS lookups are not significantly latency impacting. Were gmail.com, for example, a DNSSEC signed zone, adding DANE would change the number of pre-connection DNS lookups for gmail.com in Postfix from 6 to 7. The local resolver caches the results ammortizing the cost over multiple deliveries. In fact gmail.com is not DNSSEC signed, and the SMTP draft explicitly suppresses TLSA lookups in zones where MX host A/AAAA records turn up "insecure" responses. Therefore, the cost of TLSA lookups for gmail.com with SMTP is currently ZERO. The main cost of DANE is incurred as soon as one enables a DNSSEC-aware recursive resolver on the MTA, whether for DANE or just to fend off Kaminsky cache poisoning. After that TLSA is basically free. Whatever concerns may exist for adding DANE to HTTP, do not apply to SMTP. It is somewhat unfortunate that the mindset around DANE TLSA is so HTTP-centric, since DANE is a much better fit for protocols other than HTTP. I plead that we not break DANE for SMTP just because it is perhaps a questionable fit for HTTP. If we stay focused on the problem at hand, the issue is quickly seen to be rather minor. -- Viktor. From nobody Fri Feb 21 11:48: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 41AC41A054A for ; Fri, 21 Feb 2014 11:48:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.955 X-Spam-Level: X-Spam-Status: No, score=0.955 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.793] 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 LtN5hq4-mmmq for ; Fri, 21 Feb 2014 11:48:35 -0800 (PST) Received: from mail.hardakers.net (unknown [IPv6:2001:470:1f00:187::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A7021A021B for ; Fri, 21 Feb 2014 11:48:35 -0800 (PST) Received: from localhost (50-1-19-226.dsl.dynamic.sonic.net [50.1.19.226]) by mail.hardakers.net (Postfix) with ESMTPSA id DF3D2304A0; Fri, 21 Feb 2014 11:48:25 -0800 (PST) From: Wes Hardaker To: Paul Hoffman References: <20140106212911.12960.24322.idtracker@ietfa.amsl.com> <5DEFF47F-6533-4F1B-8D23-216108989787@verisign.com> <03FF6C3C-0542-4D0F-97D5-1785F55D2CEF@vpnc.org> <6F632081-95C9-4E61-831D-EAEF2ECCE08C@vpnc.org> Date: Fri, 21 Feb 2014 11:48:24 -0800 In-Reply-To: <6F632081-95C9-4E61-831D-EAEF2ECCE08C@vpnc.org> (Paul Hoffman's message of "Wed, 5 Feb 2014 15:29:29 -0800") Message-ID: <0lk3coxn5j.fsf@wjh.hardakers.net> User-Agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/dane/ZGAjFOpkSHzO2A4qT9CwCBDb1lU Cc: "" Subject: Re: [dane] draft-ietf-dane-smime and certificate discovery 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, 21 Feb 2014 19:48:36 -0000 Paul Hoffman writes: > So, WG: is "DNS for delivery vs. DNS for delivery and discovery" a > topic people want to revisit? Sorry for the late response, but "yes" would be my answer. I've never been fully convinced that the discussion in the past was truly consensus one way or the other, and I do think we need some guidelines for doing security availability discovery. The world has proven time and time again that we can't do it without the DNS(SEC) helping to bootstrap it. -- Wes Hardaker Parsons From nobody Fri Feb 21 12:19:27 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 A74CB1A0271; Fri, 21 Feb 2014 12:19:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.048 X-Spam-Level: X-Spam-Status: No, score=-2.048 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548] 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 q5R7hpxboxUt; Fri, 21 Feb 2014 12:19:20 -0800 (PST) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id 985321A0242; Fri, 21 Feb 2014 12:19:20 -0800 (PST) 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, 21 Feb 2014 15:19:07 -0500 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, 21 Feb 2014 15:19:15 -0500 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 s1LKJA5L011923; Fri, 21 Feb 2014 15:19:11 -0500 Message-ID: <5307B4BE.9010706@nist.gov> Date: Fri, 21 Feb 2014 15:19:10 -0500 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: , , proj-had 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/ESa12LpIvq5Z8KdPzg14lxiFi-E Subject: [dane] DANE Testing 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, 21 Feb 2014 20:19:25 -0000 ** This is posted to both UTA and DANE mailgroups. Apologies if you get it twice. I don't know the overlap of the two groups. ** Some improvements to the DANE Testing site at NIST since I posted to the dane mailgroup last November. The site is at: https://www.had-pilot.com/dane/danelaw.html. It is now possible to test from both TLSlite based and GnuTLS based clients. The Form structure of the site offers the options of connecting users' own identified DANE-enabled sites, connecting to the set of sites listed on Dan York's ISOC DANE 360 page, and getting results therefrom, or connecting to the NIST 'DANE Reference site' that explores all 0xx, 1xx, 2xx and 3xx Certificate Usage permutations. Mine was one of the 'DANE-in-the-App' sites that Viktor Dukhovni reviewed, and he kindly gave an extensive critique. Many of his points have been addressed. A few things still to clear up: - I'm not checking for certificate revocation. That is on the list to fix. - For 0xx and 1xx uses, it is hard to identify a single canonical CA list. I have overlapping, but different Root Cert sets from Mozilla, Fedora and Linux Mint. So when searching for an authority to build a verification chain I cycle through all of these until succeeding or exhaustion of the possibilities. Some of the DANE 360 listed sets (including some from members of this group) fail to authenticate because the root certs are not in my authorities. A golden, canonical CA list would be nice to find. But I guess that its non-universal availability is one of the problems of the CA system that DANE is aiming squarely at. The differences between TLSlite and GnuTLS clients highlight the fact that there are unresolved interoperability issues among TLS implementations. It seems reasonable that TLS interoperability testing be instituted as pre-requisite to DANE testing. The development of a TLS Interoperability test suite is therefore on our 'to-do' list. I look forward to seeing the newly upgraded OpenSSL client with added DANE. It is quite possible that as an interim step before its appearance I will add this DANE-in-the-App implementation to pyOpenSSL and/or Twisted. If you find any glaring errors, I will be embarrassed but thankful. If you find any subtle errors I will be impressed and thankful. Cheers, Stephen Nightingale, NIST. - From nobody Fri Feb 21 13:38: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 83B311A0135 for ; Fri, 21 Feb 2014 13:38:28 -0800 (PST) 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 cepA8ziFoRNs for ; Fri, 21 Feb 2014 13:38:26 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 0585D1A028F for ; Fri, 21 Feb 2014 13:38:25 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id B5D5D2AB25A; Fri, 21 Feb 2014 21:38:19 +0000 (UTC) Date: Fri, 21 Feb 2014 21:38:19 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140221213819.GV278@mournblade.imrryr.org> References: <5307B4BE.9010706@nist.gov> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5307B4BE.9010706@nist.gov> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/NbVGAeYhRCPDy1mY_BSKzyWJMr8 Subject: Re: [dane] DANE Testing 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: Fri, 21 Feb 2014 21:38:28 -0000 On Fri, Feb 21, 2014 at 03:19:10PM -0500, Stephen Nightingale wrote: > It is now possible to test from both TLSlite based and GnuTLS based > clients. The GnuTLS DANE implementation does not implement DANE-TA(2) or correctly. It may also IIRC not do PKIX-TA(0) right either. The issue is that the TA is incorrectly constrained to be the immediate issuer of the leaf certificate. There may be other problems, I did not perform a comprehensive code review. So results from GnuTLS DANE verification can be misleading. > A golden, canonical CA list would be nice to find. But I guess that its > non-universal availability is one of the problems of the CA system > that DANE is aiming squarely at. There is no such beast. A form of Goedel's incompleteness theorem applies: any list of CAs is either incomplete or untrustworthy (or both). > The differences between TLSlite and GnuTLS clients highlight the > fact that there are unresolved interoperability issues among TLS > implementations. Default configurations of GnuTLS typically enforce unreasonable minimum sizes on EDH primes. Applications have to work around these with policy overrides. > I look forward to seeing the newly upgraded OpenSSL > client with added DANE. It is quite possible that as an interim step > before its appearance I will add this DANE-in-the-App implementation > to pyOpenSSL and/or Twisted. Such a project should not be undertaken lightly, it is too easy to get it wrong. > If you find any glaring errors, I will be embarrassed but thankful. > If you find any subtle errors I will be impressed and thankful. A code review is required to rule out subtle errors, glaring errors may show up in tests if the test bed is sufficiently comprehensive. -- Viktor. From nobody Fri Feb 21 13:54:20 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 0E3281A021A for ; Fri, 21 Feb 2014 13:54:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548] 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 6_wjc-2yIBTv for ; Fri, 21 Feb 2014 13:54:14 -0800 (PST) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id A40AF1A0152 for ; Fri, 21 Feb 2014 13:54:14 -0800 (PST) Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.3.174.1; Fri, 21 Feb 2014 16:53:58 -0500 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, 21 Feb 2014 16:54:07 -0500 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 s1LLs4iK029637 for ; Fri, 21 Feb 2014 16:54:04 -0500 Message-ID: <5307CAFC.1090205@nist.gov> Date: Fri, 21 Feb 2014 16:54:04 -0500 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: References: <5307B4BE.9010706@nist.gov> <20140221213819.GV278@mournblade.imrryr.org> In-Reply-To: <20140221213819.GV278@mournblade.imrryr.org> 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/PD9x72rsNjz0JX8uAS7khQOJ6CI Subject: Re: [dane] DANE Testing 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, 21 Feb 2014 21:54:17 -0000 On 2/21/2014 4:38 PM, Viktor Dukhovni wrote: > On Fri, Feb 21, 2014 at 03:19:10PM -0500, Stephen Nightingale wrote: > >> It is now possible to test from both TLSlite based and GnuTLS based >> clients. > The GnuTLS DANE implementation does not implement DANE-TA(2) or > correctly. It may also IIRC not do PKIX-TA(0) right either. The > issue is that the TA is incorrectly constrained to be the immediate > issuer of the leaf certificate. There may be other problems, I > did not perform a comprehensive code review. > > So results from GnuTLS DANE verification can be misleading. I should point out that I am not using GnuTLS idea of DANE verification. I'm getting the cert chain passed up and doing my own DANE verification. For this purpose I had to modify the python-gnutls-1.2.5 interface to GnuTLS, to pass in a certificate chain, since in the download it only passes in a single end cert. > >> A golden, canonical CA list would be nice to find. But I guess that its >> non-universal availability is one of the problems of the CA system >> that DANE is aiming squarely at. > There is no such beast. A form of Goedel's incompleteness theorem > applies: any list of CAs is either incomplete or untrustworthy (or > both). > >> The differences between TLSlite and GnuTLS clients highlight the >> fact that there are unresolved interoperability issues among TLS >> implementations. > Default configurations of GnuTLS typically enforce unreasonable > minimum sizes on EDH primes. Applications have to work around > these with policy overrides. > >> I look forward to seeing the newly upgraded OpenSSL >> client with added DANE. It is quite possible that as an interim step >> before its appearance I will add this DANE-in-the-App implementation >> to pyOpenSSL and/or Twisted. > Such a project should not be undertaken lightly, it is too easy to > get it wrong. > >> If you find any glaring errors, I will be embarrassed but thankful. >> If you find any subtle errors I will be impressed and thankful. > A code review is required to rule out subtle errors, glaring errors > may show up in tests if the test bed is sufficiently comprehensive. > From nobody Fri Feb 21 14:41: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 845831A0291 for ; Fri, 21 Feb 2014 14:41:37 -0800 (PST) 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 NdLcFckVL5UM for ; Fri, 21 Feb 2014 14:41:34 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 94BBA1A0152 for ; Fri, 21 Feb 2014 14:41:34 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id B505B2AB25A; Fri, 21 Feb 2014 22:41:28 +0000 (UTC) Date: Fri, 21 Feb 2014 22:41:28 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140221224128.GX278@mournblade.imrryr.org> References: <5307B4BE.9010706@nist.gov> <20140221213819.GV278@mournblade.imrryr.org> <5307CAFC.1090205@nist.gov> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5307CAFC.1090205@nist.gov> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/18t1qLwuw9b5SDr86-1RJOKSNLo Subject: Re: [dane] DANE Testing 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: Fri, 21 Feb 2014 22:41:37 -0000 On Fri, Feb 21, 2014 at 04:54:04PM -0500, Stephen Nightingale wrote: > >So results from GnuTLS DANE verification can be misleading. > > I should point out that I am not using GnuTLS idea of DANE > verification. I'm getting the cert chain passed up and doing my own > DANE verification. For this purpose I had to modify the > python-gnutls-1.2.5 interface to GnuTLS, to pass in a certificate > chain, since in the download it only passes in a single end cert. OK, but with DANE-TA(2) now you have the rather difficult task of performing PKIX validation of a complete trust chain. I forget what your approach was for this. Are you checking all the expiration dates, signatures, basic constraints, name constraints, pathlength constraints, performing name checks, ... That's a lot of difficult code. -- Viktor. From nobody Fri Feb 21 16:48:13 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 B98DC1A029B; Fri, 21 Feb 2014 13:31:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_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 dL-px-l_z0d4; Fri, 21 Feb 2014 13:30:58 -0800 (PST) Received: from defiant.e-webshops.eu (defiant.e-webshops.eu [82.146.122.140]) by ietfa.amsl.com (Postfix) with ESMTP id 56C751A028C; Fri, 21 Feb 2014 13:30:58 -0800 (PST) Received: from intrepid.roeckx.be (localhost [127.0.0.1]) by defiant.e-webshops.eu (Postfix) with ESMTP id E3E531C215E; Fri, 21 Feb 2014 22:30:52 +0100 (CET) Received: by intrepid.roeckx.be (Postfix, from userid 1000) id 96D331FE016D; Fri, 21 Feb 2014 22:30:52 +0100 (CET) Date: Fri, 21 Feb 2014 22:30:52 +0100 From: Kurt Roeckx To: Stephen Nightingale Message-ID: <20140221213052.GA4505@roeckx.be> References: <5307B4BE.9010706@nist.gov> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5307B4BE.9010706@nist.gov> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/dzXBKPvawwCdTRS0bcGEC613HKg X-Mailman-Approved-At: Fri, 21 Feb 2014 16:48:11 -0800 Cc: uta@ietf.org, proj-had , dane@ietf.org Subject: Re: [dane] [Uta] DANE Testing 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, 21 Feb 2014 21:31:01 -0000 On Fri, Feb 21, 2014 at 03:19:10PM -0500, Stephen Nightingale wrote: > > - For 0xx and 1xx uses, it is hard to identify a single canonical CA > list. I have overlapping, but different Root Cert sets from Mozilla, > Fedora and Linux Mint. So when searching for an authority to build a > verification chain I cycle through all of these until succeeding or > exhaustion of the possibilities. Some of the DANE 360 listed sets > (including some from members of this group) fail to authenticate > because the root certs are not in my authorities. I'm not really sure why you can't find the relevant CAs in your root store. It looks like you don't properly build the chain or something? Looking for instance at the fedoraproject.org results, you try all 3 of them, but each time fail, where for all 3 you actually seem to list the root CA as a relevant cert? Kurt From nobody Fri Feb 21 19:32: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 1DB841A0379 for ; Fri, 21 Feb 2014 19:32:41 -0800 (PST) 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 KWMFjsggqhB2 for ; Fri, 21 Feb 2014 19:32:38 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 755BC1A02BD for ; Fri, 21 Feb 2014 19:32:38 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id D76E62AB256; Sat, 22 Feb 2014 03:32:32 +0000 (UTC) Date: Sat, 22 Feb 2014 03:32:32 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140222033232.GY278@mournblade.imrryr.org> References: <5307B4BE.9010706@nist.gov> <20140221213052.GA4505@roeckx.be> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140221213052.GA4505@roeckx.be> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/C_OF7XVgGzjI2fGeIUB87FmIVXs Subject: Re: [dane] [Uta] DANE Testing 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, 22 Feb 2014 03:32:41 -0000 On Fri, Feb 21, 2014 at 10:30:52PM +0100, Kurt Roeckx wrote: > On Fri, Feb 21, 2014 at 03:19:10PM -0500, Stephen Nightingale wrote: > > > > - For 0xx and 1xx uses, it is hard to identify a single canonical CA > > list. I have overlapping, but different Root Cert sets from Mozilla, > > Fedora and Linux Mint. So when searching for an authority to build a > > verification chain I cycle through all of these until succeeding or > > exhaustion of the possibilities. Some of the DANE 360 listed sets > > (including some from members of this group) fail to authenticate > > because the root certs are not in my authorities. > > I'm not really sure why you can't find the relevant CAs in your > root store. It looks like you don't properly build the chain or > something? Looking for instance at the fedoraproject.org results, > you try all 3 of them, but each time fail, where for all 3 you > actually seem to list the root CA as a relevant cert? The handshake chain from fedoraproject.org is: subject=/serialNumber=GFaoFyCf99PHtAPDHLEBYfFi/1hePcED/C=US/ST=North Carolina/L=Raleigh/O=Red Hat Inc/OU=Fedora Infrastructure/CN=*.fedoraproject.org issuer=/C=US/O=GeoTrust, Inc./CN=GeoTrust SSL CA subject=/C=US/O=GeoTrust, Inc./CN=GeoTrust SSL CA issuer=/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA subject=/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA issuer=/C=US/O=Equifax/OU=Equifax Secure Certificate Authority Per http://tools.ietf.org/html/rfc5246#page-48 certificate_list This is a sequence (chain) of certificates. The sender's certificate MUST come first in the list. Each following certificate MUST directly certify the one preceding it. Because certificate validation requires that root keys be distributed independently, the self-signed certificate that specifies the root certificate authority MAY be omitted from the chain, under the assumption that the remote end must already possess it in order to validate it in any case. and of course fedoraproject.org does not include the root cert in the TLS handshake chain. The chain needs to be augmented with the relevant issuing root by the verifier. In this case the Equifax root CA. Which is in many of the popular CA bundles. The certificate that matches the TLSA record (CA constraint) is the immediate issuer, but is not the root issuer and does not appear in various CA bundles. Perhaps the code incorrectly assumes that the CA matched by a "0 0 1" TLSA record, needs to be the root CA. -- Viktor. From nobody Mon Feb 24 02:26:05 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 DEB411A0440 for ; Mon, 24 Feb 2014 02:26:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.802 X-Spam-Level: * X-Spam-Status: No, score=1.802 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.547] 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 IFAw9nDN93eX for ; Mon, 24 Feb 2014 02:26:00 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 00EAF1A043A for ; Mon, 24 Feb 2014 02:25:59 -0800 (PST) Received: from labs.ondrej.sury.nb.eth.3.office.nic.cz (fw.nic.cz [217.31.207.1]) by mail.nic.cz (Postfix) with ESMTPSA id 4005213F9E7 for ; Mon, 24 Feb 2014 11:25:58 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1393237558; bh=o5Jbqa+HiUPBPHfm9NjKk3hzi/xGCoBeY/ggtaKDqnM=; h=From:Content-Type:Subject:Message-Id:Date:To:Mime-Version; b=unpTgqKJ6QlIKboKgMDxwG9ssngyHD7T7OHuMV74vW6NWrFsIaxjZrpQGhNiRwOlN hlwWN41BOCZqFU2WjLitNIgwAnUu6nTIr/r0L7YExxr3kVkuA/aTeADHjKzzBYo0T0 EtOVtZvHdZfavkzvjrYo/E4jC15jcDsmQuqn7QmY= From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= Content-Type: multipart/signed; boundary="Apple-Mail=_9EF22366-6500-49E3-9629-0A8301DF3C66"; protocol="application/pgp-signature"; micalg=pgp-sha1 Message-Id: <7B475651-39DD-42E2-B17E-10076CEF368E@nic.cz> Date: Mon, 24 Feb 2014 11:25:57 +0100 To: "dane@ietf.org list" Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) X-Mailer: Apple Mail (2.1827) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/dane/GXA8rOnXf8rFvw_nHltsw548JHc Subject: [dane] Stepping down as the DANE co-chair... 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: Mon, 24 Feb 2014 10:26:02 -0000 --Apple-Mail=_9EF22366-6500-49E3-9629-0A8301DF3C66 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear WG members, Due to various personal (a baby girl[1]) and work reasons I have decided = to step down as a co-chair of DANE WG. However I will stay in the WG = monitoring it's progress and contributing with draft reviews as the time = will allow. =C3=93lafur Gu=C3=B0mundsson was so kind to accept to position of = co-chair this DANE beast with Warren Kumari. Thanks to you all for your WG work, Ond=C5=99ej 1. Warren, has asked me to add a picture as a proof, so here it is: = https://dl.dropboxusercontent.com/u/3875106/Ester/IMGP1083.jpg (The box is not a box, but crypto envelope :-D.) -- Ond=C5=99ej Sur=C3=BD -- Chief Science Officer ------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- --Apple-Mail=_9EF22366-6500-49E3-9629-0A8301DF3C66 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAlMLHjUACgkQYYkZMXof23wJOQCgg7A3rcTQ+BnCArW5f0Mry6zj nTgAnRKZrmRF467e85AfBv++DTSqOoxB =aP+J -----END PGP SIGNATURE----- --Apple-Mail=_9EF22366-6500-49E3-9629-0A8301DF3C66-- From nobody Mon Feb 24 02:41:33 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 BAC411A0440 for ; Mon, 24 Feb 2014 02:41:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.553 X-Spam-Level: X-Spam-Status: No, score=0.553 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.547] 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 LTJnrdBepwka for ; Mon, 24 Feb 2014 02:41:29 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id C6FE71A06BD for ; Mon, 24 Feb 2014 02:41:25 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id D484ABEFE; Mon, 24 Feb 2014 10:41:23 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ij5Yz3+bhG2h; Mon, 24 Feb 2014 10:41:23 +0000 (GMT) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id A295ABEF7; Mon, 24 Feb 2014 10:41:23 +0000 (GMT) Message-ID: <530B21D4.1050407@cs.tcd.ie> Date: Mon, 24 Feb 2014 10:41:24 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= , "dane@ietf.org list" References: <7B475651-39DD-42E2-B17E-10076CEF368E@nic.cz> In-Reply-To: <7B475651-39DD-42E2-B17E-10076CEF368E@nic.cz> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/dane/2Sx79FimIokQCgp4aNrVjx2dCvU Subject: Re: [dane] Stepping down as the DANE co-chair... 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: Mon, 24 Feb 2014 10:41:32 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'd like to express my appreciation to Ondřej for the great job he and Warren have done with DANE over the last few years, and also to Warren and Olafur for being willing to see it through to the end. Thanks folks! S. PS: Nice pic! On 02/24/2014 10:25 AM, Ondřej Surý wrote: > Dear WG members, > > Due to various personal (a baby girl[1]) and work reasons I have > decided to step down as a co-chair of DANE WG. However I will > stay in the WG monitoring it's progress and contributing with > draft reviews as the time will allow. > > Ólafur Guðmundsson was so kind to accept to position of co-chair > this DANE beast with Warren Kumari. > > Thanks to you all for your WG work, Ondřej > > 1. Warren, has asked me to add a picture as a proof, so here it > is: https://dl.dropboxusercontent.com/u/3875106/Ester/IMGP1083.jpg > (The box is not a box, but crypto envelope :-D.) -- Ondřej Surý -- > Chief Science Officer ------------------------------------------- > CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC Americka 23, 120 00 > Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ > tel:+420.222745110 fax:+420.222745112 > ------------------------------------------- > > > > _______________________________________________ dane mailing list > dane@ietf.org https://www.ietf.org/mailman/listinfo/dane > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) iQEcBAEBAgAGBQJTCyHQAAoJEC88hzaAX42iNhoIAKjtRiC2sQLqGSBzjqZj/DFx L4nabku8GEI60HWnkQzJ6p//muwihHdRzc/A4C71VYa9lwpR5JiMO4uaH2s2UEyd pxIR0aKLHhn46bbAljJR9xlzAGg1/T9wibmb/tXuPe17G+9CW9JPjL3k2UR+Pi/8 odpADOXkbiXvFuaCZJGYWmndWTGHZkj1yf3gp6WHA2XlKKiYHXTrGm1OnnLMUlpc PaTP1CrvT2YDMqqbL62Ts3YJRqfVHbu0TbZRi4gsHQDWXTWcC+ZqFl2TZVOSNsPh Evzg8TZLUWCQh338TbwLbjVuYwzcbrhngFrzyVQW07qjxdqVF6vedMf4DVNcd1Q= =nl/8 -----END PGP SIGNATURE----- From nobody Mon Feb 24 09:02: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 9CFB01A0105 for ; Mon, 24 Feb 2014 09:02:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.022 X-Spam-Level: * X-Spam-Status: No, score=1.022 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, 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 INQ_WCidyNEv for ; Mon, 24 Feb 2014 09:02:46 -0800 (PST) Received: from mail-we0-f173.google.com (mail-we0-f173.google.com [74.125.82.173]) by ietfa.amsl.com (Postfix) with ESMTP id E260A1A00AF for ; Mon, 24 Feb 2014 09:02:45 -0800 (PST) Received: by mail-we0-f173.google.com with SMTP id x48so4945685wes.32 for ; Mon, 24 Feb 2014 09:02:44 -0800 (PST) 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 :content-transfer-encoding; bh=rbLoJiO1uOesY/GrRL3oXT4ebtgi4bHTErXCBUIAlYc=; b=SXNY0+LWxMRYCrP5wGiMtPg6O2AVwK2eeBsFW5dE+BwmqSpLXq9ycmIMqCaFbzzseq DZ+t4FsTBCZzdJjjTzfWF+HU4JdOz3BUEgxjRU+VEo03nESkXmuzaXyJDW9G1tRi3l3F opkxHWmomBQwmZXOHkPs9I5cHdxzf/fywObaJofiK4sSSMxeKeyWexUEBV3yMfeGF5iG 1oGYo8oOlxg2rxia4PW5Vs4yQ7z8ed4nZbkA2q7C0ytIywXaEIMpg2jmA6LYcdw2L5dA gc1p99TkHZbkxgzvYrOf5c5H4NXYBCr8S7F95UNPYQqJQANwkJ7WTZOU7iUVwqfuTZ7W AIcQ== X-Gm-Message-State: ALoCoQkC9bsjOEUbaATr6CX3jvIK17n7IDRR4VIsKCASL6N5Ofw+qUDLpGwD4wQdRm4n2vjQJQsk MIME-Version: 1.0 X-Received: by 10.195.13.103 with SMTP id ex7mr19746927wjd.3.1393261364797; Mon, 24 Feb 2014 09:02:44 -0800 (PST) Received: by 10.194.54.167 with HTTP; Mon, 24 Feb 2014 09:02:44 -0800 (PST) X-Originating-IP: [98.244.98.35] In-Reply-To: <7B475651-39DD-42E2-B17E-10076CEF368E@nic.cz> References: <7B475651-39DD-42E2-B17E-10076CEF368E@nic.cz> Date: Mon, 24 Feb 2014 12:02:44 -0500 Message-ID: From: Warren Kumari To: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/dane/2ShAClaudXlNPSzXE-JpRTqN5RE Cc: "dane@ietf.org list" Subject: Re: [dane] Stepping down as the DANE co-chair... 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: Mon, 24 Feb 2014 17:02:47 -0000 On Mon, Feb 24, 2014 at 5:25 AM, Ond=C5=99ej Sur=C3=BD = wrote: > Dear WG members, > > Due to various personal (a baby girl[1]) and work reasons I have decided = to step down as a co-chair of DANE WG. > However I will stay in the WG monitoring it's progress and contributing w= ith draft reviews as the time will allow. I wanted to thank Ondrej for all of his work chairing the DANE Working Grou= p. Obviously family comes first, luckily his experience chairing DANE should be very valuable in fatherhood. > > =C3=93lafur Gu=C3=B0mundsson was so kind to accept to position of co-chai= r this DANE beast with Warren Kumari. Sucker! > > Thanks to you all for your WG work, > Ond=C5=99ej > > 1. Warren, has asked me to add a picture as a proof, so here it is: https= ://dl.dropboxusercontent.com/u/3875106/Ester/IMGP1083.jpg > (The box is not a box, but crypto envelope :-D.) Cute picture. > -- > Ond=C5=99ej Sur=C3=BD -- Chief Science Officer > ------------------------------------------- > CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC > Americka 23, 120 00 Praha 2, Czech Republic > mailto:ondrej.sury@nic.cz http://nic.cz/ > tel:+420.222745110 fax:+420.222745112 > ------------------------------------------- > > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > From nobody Mon Feb 24 09:32:47 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 B78331A01E4; Mon, 24 Feb 2014 09:32:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ff5j_I62h7Ea; Mon, 24 Feb 2014 09:32:34 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 797131A023F; Mon, 24 Feb 2014 09:32:25 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.0.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140224173225.14286.18792.idtracker@ietfa.amsl.com> Date: Mon, 24 Feb 2014 09:32:25 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/3ovKL7AgmuAkVafwqg1-mOtrDFg Cc: dane mailing list , dane chair , RFC Editor Subject: [dane] Protocol Action: 'Adding acronyms to simplify DANE conversations' to Proposed Standard (draft-ietf-dane-registry-acronyms-04.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: Mon, 24 Feb 2014 17:32:38 -0000 The IESG has approved the following document: - 'Adding acronyms to simplify DANE conversations' (draft-ietf-dane-registry-acronyms-04.txt) as Proposed Standard This document is the product of the DNS-based Authentication of Named Entities Working Group. The IESG contact persons are Stephen Farrell and Sean Turner. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-dane-registry-acronyms/ Technical Summary Experience has show that people get confused using the three numeric fields the TLSA record. This document specifies descriptive acronyms for the three numeric fields in the TLSA records. This document updates the format of the IANA registry created by RFC6698. Working Group Summary This document is a small update to RFC 6698, the specification for the DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol, also known by its DNS RRset name, TLSA. The revision has one narrow purpose: to give the three numeric fields in the RRtype definition mnemonic names. This is meant to allow easier discussion of TLSA, particular for the "certificate usage" field that specifies what type of public key is in the TLSA record. Because this draft updates a standards track RFC, the draft is meant to be a proposed standard as well. The short document was thoroughly reviewed in the WG. That very active discussion among many people led to some very deep (but pointless:-) divisions in the WG about what the "certificate usage" fields should be called. The WG chairs called rough consensus, but a significant number of people in the WG disagreed that there was consensus at all. It should be noted that the WG has consensus that some terminology is better than just having the numbers in RFC 6698; however, there are strong opinions for three or four different sets of terminology. The shepherd does not believe that the wording in the current draft represents "rough consensus" but, at the same time, he doesn't see any of the other options as having noticeably more consensus. The responsible AD is ok with that, as are the chairs. There is consensus that impercted words are better than numbers. Document Quality There are DANE tools, not sure if this has been coded up in those. AD thinks he recalls one developer who said he'd add this but only after we stop futzing with different names. Personnel Paul Hoffman is the document shepherd; Stephen Farrell is the responsible AD. RFC Editor Note Please delete the text "Other options suggested for 0: PKIX-TA" from section 2.1 - its a bit of hanging text in the xml file that should be gone or commented out. The authors may do for you before auth-48. From nobody Mon Feb 24 18:33:33 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 BAEFF1A039B for ; Mon, 24 Feb 2014 18:33:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, 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 fgCTAiCpKdDO for ; Mon, 24 Feb 2014 18:33:31 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id A39841A0389 for ; Mon, 24 Feb 2014 18:33:31 -0800 (PST) Received: from aither.local (unknown [24.8.184.175]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id AAC9F40347; Mon, 24 Feb 2014 19:33:30 -0700 (MST) Message-ID: <530C00FB.7040406@stpeter.im> Date: Mon, 24 Feb 2014 19:33:31 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: dane@ietf.org References: <7B475651-39DD-42E2-B17E-10076CEF368E@nic.cz> In-Reply-To: <7B475651-39DD-42E2-B17E-10076CEF368E@nic.cz> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/dane/N52Y3WYo6qJ_hg5jKcH24Nntktw Subject: Re: [dane] Stepping down as the DANE co-chair... 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, 25 Feb 2014 02:33:33 -0000 On 2/24/14, 3:25 AM, Ondřej Surý wrote: > I have decided to step down as a co-chair of DANE WG. Děkuji vám! Peter From nobody Wed Feb 26 06:12: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 A10211A0321 for ; Wed, 26 Feb 2014 06:12:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.147 X-Spam-Level: X-Spam-Status: No, score=-1.147 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547] 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 zT7KMYfoM7iH for ; Wed, 26 Feb 2014 06:12:24 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 599AC1A033F for ; Wed, 26 Feb 2014 06:12:23 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 10F5380D6D for ; Wed, 26 Feb 2014 09:12:21 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1393423941; bh=cLV0xaIVnVjB3prMf9VxmHMGM51Iufx/JWtDdWylITw=; h=Date:From:To:Subject; b=pZdsyICfkJX2DNTnPvPYaEitfTPPT6SJAgzYv6YqN4ddL800lwuX4lxfYjfePjwze TDHRd192V3GT5MZG1boZWdLiDqVQnZIpt+nuF4VYmOoIRraigprgZVUl1WJw48dwyX fFl+p5funEkRU2oJZEVohuAvgV8DoLiT1WFVJD8Y= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s1QECKTX025055 for ; Wed, 26 Feb 2014 09:12:20 -0500 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Wed, 26 Feb 2014 09:12:20 -0500 (EST) From: Paul Wouters To: dane WG list Message-ID: User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/dane/sOBR_H2su4lTdvCysFj8OQymimQ Subject: [dane] An AD bit discussion 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, 26 Feb 2014 14:12:27 -0000 Hi, I've been part of a very long and heated discussion about the trust of the AD bit. I would like to hear from people here what they think. I'm currently aware of two (non-dns utilities) applications that make security decisions based on "blindly" trusting the AD bit: ssh with VerifyHostKeyDNS=yes|ask and Postfix. libreswan and strongswan are examples of applications that use libunbound for in-application DNSSEC validation to avoid needing to trust /etc/resolv.conf DNS servers for the AD bit. First, let me list 4 items everyone seems to agree on: 1 Applications can either do dnssec validation themselves, or trust the AD bit. 2 It is undesirable that each application has its own DNSSEC validation code, trust anchors and DNS cache. 3 It is undesirable that applications blindly trust the AD bit when resolv.conf points to another host as the AD bit could have been modified on the network. 4 In the ideal world tomorrow, each host has its own automatically configured, perfectly working validing DNS server and resolv.conf can be ignored or is always hardcoded with nameserver 127.0.0.1 Now for my question. Until we reach 4), what should we do with the AD bit in getaddrinfo() ? A) strip the AD bit in struct addrinfo for "untrusted nameservers". A new configuration mechanism will allow white-listing nameservers and 127.0.0.1 will always be on the whitelist. B) do nothing C) Something else, please specify Paul From nobody Wed Feb 26 06:41: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 8F3D21A03AA for ; Wed, 26 Feb 2014 06:41:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 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.547, 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 8y98vIe-qZ_C for ; Wed, 26 Feb 2014 06:41:47 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 3CDAA1A0390 for ; Wed, 26 Feb 2014 06:41:47 -0800 (PST) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 7F93CC94D1; Wed, 26 Feb 2014 14:41:33 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1393425706; bh=bjhKlkl8KzV1zhhipMrCEeWXHahiL4E8q80i+Ud3NmA=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=oFfZHKzArst1wluXSS3NpLfrww2l/HF15Reiv1P4URnW2r1O8a8APv1uSwKk1XMQc AY+0KYJKJGbYaS4OLx1LdIWBPKAORtCgekqGHRjgNWY/cncgJ9xW5jPVs+b7yyDIqt 4VhsRDSQFo6kexN+fiTJp5P7vdpVr0YHsKOpJhqU= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Wed, 26 Feb 2014 14:41:33 +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 DF18F16005C; Wed, 26 Feb 2014 14:42:25 +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 B21E416004A; Wed, 26 Feb 2014 14:42:15 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 72FEA106BCFB; Thu, 27 Feb 2014 01:41:21 +1100 (EST) To: Paul Wouters From: Mark Andrews References: In-reply-to: Your message of "Wed, 26 Feb 2014 09:12:20 -0500." Date: Thu, 27 Feb 2014 01:41:21 +1100 Message-Id: <20140226144121.72FEA106BCFB@rock.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Archived-At: http://mailarchive.ietf.org/arch/msg/dane/OMwmC4SRpAaVJ0IOL6tTAbqHjzI Cc: dane WG list Subject: Re: [dane] An AD bit discussion 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, 26 Feb 2014 14:41:49 -0000 In message , Paul Wouters writes: > > Hi, > > I've been part of a very long and heated discussion about the trust of > the AD bit. I would like to hear from people here what they think. > > I'm currently aware of two (non-dns utilities) applications that make > security decisions based on "blindly" trusting the AD bit: ssh with > VerifyHostKeyDNS=yes|ask and Postfix. > > libreswan and strongswan are examples of applications that use libunbound > for in-application DNSSEC validation to avoid needing to trust > /etc/resolv.conf DNS servers for the AD bit. > > First, let me list 4 items everyone seems to agree on: Actually 2 is very much not agreeded apon by everyone. > 1 Applications can either do dnssec validation themselves, or trust the > AD bit. > > 2 It is undesirable that each application has its own DNSSEC validation > code, trust anchors and DNS cache. > > 3 It is undesirable that applications blindly trust the AD bit when > resolv.conf points to another host as the AD bit could have been modified > on the network. > > 4 In the ideal world tomorrow, each host has its own automatically > configured, perfectly working validing DNS server and resolv.conf can > be ignored or is always hardcoded with nameserver 127.0.0.1 > > Now for my question. Until we reach 4), what should we do with the AD > bit in getaddrinfo() ? > > A) strip the AD bit in struct addrinfo for "untrusted nameservers". A new > configuration mechanism will allow white-listing nameservers and 127.0.0.1 > will always be on the whitelist. > > B) do nothing > > C) Something else, please specify > > 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 Wed Feb 26 07:39: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 29F511A0693 for ; Wed, 26 Feb 2014 07:39:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.001 X-Spam-Level: * X-Spam-Status: No, score=1.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.547] 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 z6AwziP_H3sq for ; Wed, 26 Feb 2014 07:39:39 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 853991A00C0 for ; Wed, 26 Feb 2014 07:39:37 -0800 (PST) Received: from labs.ondrej.sury.nb.wifi.4.office.nic.cz (fw.nic.cz [217.31.207.1]) by mail.nic.cz (Postfix) with ESMTPSA id D740913F9D7; Wed, 26 Feb 2014 16:39:35 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1393429175; bh=vVZV/rQyEZsgq+PhO9Ogw9diAHqlI5RldgE4UN+G24k=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=IZohn5AowG/4zDfz7QHRHc5sS/Dk3WsTkYjlYDWW7oi0aZPsU+QqNdoaBhfWPst7c GnaHQyHs4KA43vk5flwFuTj5eh90orgfPNzKHZTY3kQU3sBA7kEEhMLCjalDTtrHyB fZFxVIjNpIumsSeKvQX8nO/5WMImF/0kuF97gEjY= Content-Type: multipart/signed; boundary="Apple-Mail=_A4F6ABBA-B980-4FB8-A65F-12FAA112B3E6"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: Date: Wed, 26 Feb 2014 16:39:35 +0100 Message-Id: References: To: Paul Wouters X-Mailer: Apple Mail (2.1874) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/dane/ki5zDgWDePEXhafAdIseyVvN_8U Cc: dane WG list Subject: Re: [dane] An AD bit discussion 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, 26 Feb 2014 15:39:41 -0000 --Apple-Mail=_A4F6ABBA-B980-4FB8-A65F-12FAA112B3E6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Paul, On 26. 2. 2014, at 15:12, Paul Wouters wrote: > Hi, >=20 > I've been part of a very long and heated discussion about the trust of > the AD bit. I would like to hear from people here what they think. >=20 > I'm currently aware of two (non-dns utilities) applications that make > security decisions based on "blindly" trusting the AD bit: ssh with > VerifyHostKeyDNS=3Dyes|ask and Postfix. >=20 > libreswan and strongswan are examples of applications that use = libunbound > for in-application DNSSEC validation to avoid needing to trust > /etc/resolv.conf DNS servers for the AD bit. >=20 > First, let me list 4 items everyone seems to agree on: >=20 > 1 Applications can either do dnssec validation themselves, or trust = the > AD bit. >=20 > 2 It is undesirable that each application has its own DNSSEC = validation > code, trust anchors and DNS cache. >=20 > 3 It is undesirable that applications blindly trust the AD bit when > resolv.conf points to another host as the AD bit could have been = modified > on the network. >=20 > 4 In the ideal world tomorrow, each host has its own automatically > configured, perfectly working validing DNS server and resolv.conf can > be ignored or is always hardcoded with nameserver 127.0.0.1 My personal opinion on that matter is that the application should not = have to care about that and they should just use (some) API to get the = validated response from system library (not necessarily glibc). > Now for my question. Until we reach 4), what should we do with the AD > bit in getaddrinfo() ? >=20 > A) strip the AD bit in struct addrinfo for "untrusted nameservers". A = new > configuration mechanism will allow white-listing nameservers and = 127.0.0.1 > will always be on the whitelist. This seems to be reasonable to me for the time being. > B) do nothing >=20 > C) Something else, please specify O. -- Ond=C5=99ej Sur=C3=BD -- Chief Science Officer ------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- --Apple-Mail=_A4F6ABBA-B980-4FB8-A65F-12FAA112B3E6 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAlMOCrcACgkQYYkZMXof23zIKACfZAE8eAXIGeGQx+kgz857AbSJ wtYAnjL7eEwv7HYAcT4Jtc0klniBmg/4 =Zn1p -----END PGP SIGNATURE----- --Apple-Mail=_A4F6ABBA-B980-4FB8-A65F-12FAA112B3E6-- From nobody Wed Feb 26 07:58: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 7BAA71A0676 for ; Wed, 26 Feb 2014 07:57:58 -0800 (PST) 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_40=-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 FgBODqZdciZX for ; Wed, 26 Feb 2014 07:57:55 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 2FE081A066E for ; Wed, 26 Feb 2014 07:57:54 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 276072AAD0C; Wed, 26 Feb 2014 15:57:52 +0000 (UTC) Date: Wed, 26 Feb 2014 15:57:52 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140226155752.GT21390@mournblade.imrryr.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/S-Ja1t4Fb_R_wr_RrCvAeYS5PcM Subject: Re: [dane] An AD bit discussion 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: Wed, 26 Feb 2014 15:57:59 -0000 On Wed, Feb 26, 2014 at 09:12:20AM -0500, Paul Wouters wrote: > 4 In the ideal world tomorrow, each host has its own automatically > configured, perfectly working validing DNS server and resolv.conf can > be ignored or is always hardcoded with nameserver 127.0.0.1 This is also my ideal world of tomorrow. > Now for my question. Until we reach 4), what should we do with the AD > bit in getaddrinfo() ? I was not aware of any mechanism in getaddrinfo() to communicate the AD bit? Is this a new getaddrinfo() implementation with features I've not looked at yet? Also getaddrinfo() typically uses RES_DEFNAMES and RES_SEARCH, which make the meaning of any security bit rather ambiguous. When the input is not a fully-qualified DNS name, what is it the user has learned to be secure? What happens when one of the domains on the search list returns NXDOMAIN (without proof non-existence), but a subsequent suffix yields a "secure" result? I am fairly confident that security is rather elusive when the input name is only partially specified. Lots of ways to get this wrong. -- Viktor. From nobody Wed Feb 26 08:16:58 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 214571A0675 for ; Wed, 26 Feb 2014 08:16:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.547 X-Spam-Level: X-Spam-Status: No, score=-2.547 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.547] 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 devfNt_Yk8pP for ; Wed, 26 Feb 2014 08:16:49 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 6B6BD1A06A4 for ; Wed, 26 Feb 2014 08:16:38 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 7A8CD80D6D for ; Wed, 26 Feb 2014 11:16:36 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1393431396; bh=uaYe/7EP2GGFqlJStTdOSIZJ7truwDXFLoqZy5jZR+Y=; h=Date:From:To:Subject:In-Reply-To:References; b=DMurruifNOWImu+xbdb0IQOWT0tbGgDn/3l44dXCCPvhgwYSklpCtfRYt+9nNhmuK 7mpUJHibDVKjNJleyNHqLI0YytgvAIcnWTjJXgNJiX8tJjyTP9ysu5Kf/JkQUKOuKW m6vDy/CO17+4yHsFLH5OqgIHoRXxWK72Jcb4lS9Q= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s1QGGa24023339 for ; Wed, 26 Feb 2014 11:16:36 -0500 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Wed, 26 Feb 2014 11:16:36 -0500 (EST) From: Paul Wouters To: dane@ietf.org In-Reply-To: <20140226155752.GT21390@mournblade.imrryr.org> Message-ID: References: <20140226155752.GT21390@mournblade.imrryr.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/C3w0QJlpS29PGC1IWVR-_BjvLvM Subject: Re: [dane] An AD bit discussion 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, 26 Feb 2014 16:16:53 -0000 On Wed, 26 Feb 2014, Viktor Dukhovni wrote: >> Now for my question. Until we reach 4), what should we do with the AD >> bit in getaddrinfo() ? > > I was not aware of any mechanism in getaddrinfo() to communicate > the AD bit? Is this a new getaddrinfo() implementation with features > I've not looked at yet? Sorry, I mistook the flags in the struct to be the DNS flags. Let me rephrase it as "a DNS API call that returns the presence or lack of AD bit" Paul From nobody Wed Feb 26 08:22: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 25AB81A06A9 for ; Wed, 26 Feb 2014 08:22:25 -0800 (PST) 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 OZ9rq1PSkT_b for ; Wed, 26 Feb 2014 08:22:23 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 1DCB81A068F for ; Wed, 26 Feb 2014 08:22:23 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 5AF802AAD0C; Wed, 26 Feb 2014 16:22:21 +0000 (UTC) Date: Wed, 26 Feb 2014 16:22:21 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140226162221.GV21390@mournblade.imrryr.org> References: <20140226155752.GT21390@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.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/W2AL-xQlhsvxFA5DC72uTjKrXeQ Subject: Re: [dane] An AD bit discussion 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: Wed, 26 Feb 2014 16:22:25 -0000 On Wed, Feb 26, 2014 at 11:16:36AM -0500, Paul Wouters wrote: > >>Now for my question. Until we reach 4), what should we do with the AD > >>bit in getaddrinfo() ? > > > >I was not aware of any mechanism in getaddrinfo() to communicate > >the AD bit? Is this a new getaddrinfo() implementation with features > >I've not looked at yet? > > Sorry, I mistook the flags in the struct to be the DNS flags. Let me > rephrase it as "a DNS API call that returns the presence or lack of AD bit" I, for one, no longer know what you're asking. Not enough context. If your question is not about getaddrinfo(), can you ask it again with a bit of context? Are you asking what applications should (in general?) do with the AD bit from stub resolvers? Or how libraries should report the AD bit from DNS to applications when the library has a mechanism to do so unambiguously? Or ...? -- Viktor. From nobody Wed Feb 26 08:28: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 58DF31A06D5 for ; Wed, 26 Feb 2014 08:28:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.449 X-Spam-Level: X-Spam-Status: No, score=-7.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, 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 jtxBJmCpOBqh for ; Wed, 26 Feb 2014 08:27:54 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 10CB51A0139 for ; Wed, 26 Feb 2014 08:27:48 -0800 (PST) Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s1QGRkgJ022346 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 26 Feb 2014 11:27:46 -0500 Received: from pspacek.brq.redhat.com (vpn1-4-54.ams2.redhat.com [10.36.4.54]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s1QGRioM027720 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Wed, 26 Feb 2014 11:27:45 -0500 Message-ID: <530E15FF.2020107@redhat.com> Date: Wed, 26 Feb 2014 17:27:43 +0100 From: Petr Spacek Organization: Red Hat User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: dane@ietf.org References: <20140226155752.GT21390@mournblade.imrryr.org> <20140226162221.GV21390@mournblade.imrryr.org> In-Reply-To: <20140226162221.GV21390@mournblade.imrryr.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/qgtW583Neg1gjUXNWsjeanKML4g Subject: Re: [dane] An AD bit discussion 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, 26 Feb 2014 16:28:00 -0000 Greetings, On 26.2.2014 17:22, Viktor Dukhovni wrote: > On Wed, Feb 26, 2014 at 11:16:36AM -0500, Paul Wouters wrote: > >>>> Now for my question. Until we reach 4), what should we do with the AD >>>> bit in getaddrinfo() ? >>> >>> I was not aware of any mechanism in getaddrinfo() to communicate >>> the AD bit? Is this a new getaddrinfo() implementation with features >>> I've not looked at yet? >> >> Sorry, I mistook the flags in the struct to be the DNS flags. Let me >> rephrase it as "a DNS API call that returns the presence or lack of AD bit" > > I, for one, no longer know what you're asking. Not enough context. > If your question is not about getaddrinfo(), can you ask it again > with a bit of context? Are you asking what applications should > (in general?) do with the AD bit from stub resolvers? Or how > libraries should report the AD bit from DNS to applications when > the library has a mechanism to do so unambiguously? Or ...? Paul and me have accidentally open threads about the same topic on this list and also on dnsop-list. I guess that this discussion fits better here so I will post our reasoning. Please note that we would like to discuss the right implementation approach with you and not to push described proposal. I work in Red Hat's Identity Management group and my opinions can differ from Paul's, don't be surprised. (I.e. "we" in following text doesn't necessarily include Paul We can see two very basic approaches: A) Do DNSSEC response validation in each application. B) Let recursive resolver do the validation and use AD bit in the application. We consider the first approach (i.e. each application doing response validation) too heavy-weight and hard to administer for various reasons: - Response validation is sensitive operation and application programmers should not do it themselves. - A variant where every application calls validation library is still not optimal. Experience with crypto libraries shows that there are many opportunities to use a library incorrectly (in a way which works but is not secure). - This approach has potential to create administrative nightmare if each application decides to maintain own set of trust anchors etc. We can see results of such approach in PKI world ... We believe that better approach is to centralize validation in local system-wide recursive resolver and use AD bit for signaling that data are trustworthy to applications. A n application should use stub-resolver to talk to local recursive resolver and use received AD bit to decide e.g. if it is possible to trust TLSA records or not. Unfortunately, there are use cases where neither a locally running validating resolver nor a trusted path to a remote resolver are available and deployment of such is unacceptable. It seems that existing stub-resolvers unconditionally trust recursive resolvers and just forward the AD bit back and forth. This behavior is okay only if no application relays on the AD bit. In other words, supporting DANE with current stub-resolvers practically requires to add a configuration option 'recursive resolver is un/trusted' to each and every DANE-enabled application and library. (This is exactly what OpenSSH client does. An additional problem is that this value has to be maintained as network configuration changes over time.) We would like to make DNSSEC implementation in applications as simple and secure as possible. That is a reason why we are looking for a solution for a case where AD bit can't be trusted because validating resolver is not available for whatever reason. It would allow applications to use AD bit without explicit configuration per-application if we solve this case somehow. Is there any 'standard' way to handle described situation? We have the following proposal (some people say it is controversial): - Extend stub-resolvers with a new call for resolver initialization: In case of ldns it would be something like: ldns_resolver_new_frm_file_trusted(). - The new call will initialize library as usual + read some system-wide configuration (it can be whatever, imagine for example a new file /etc/resolv.trusted). - Client applications will use the same API (except the initialization) to do DNS queries. - When a DNS answer is received from network the stub-resolver will consult configuration read from /etc/resolv.trusted: -- If the particular recursive resolver is listed as trusted - pass AD bit to the application. -- *Otherwise: Clear AD bit and pass the answer with AD=0 to the application.* This allows an administrator to configure system-wide policy. In case with locally running validating resolver or e.g. IPSec tunnel to trusted resolver admin can declare it as trusted and nothing changes. However, this mechanism allows the system to be safe even in configurations *without* validating resolver. No explicit configuration in application is need, just one system-wide setting. It could seem like a minor improvement or a hack, but it allows applications to trust the AD bit unconditionally and as a result it significantly simplifies DNSSEC implementation and configuration on client machines. We hope that this simple approach will allow us to implement and deploy DANE and similar technologies widely. This proposal can be seen as temporary solution before secure transport mechanisms like IPSec or CGA-TSIG are widelly available and used. The main advantage is that it is easy to implement and it doesn't require any new technology so we can use it in applications today. We would like to hear your opinions and recommendations for this area. Thank you for your time. -- Petr Spacek @ Red Hat From nobody Wed Feb 26 09:05: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 DC26E1A0077 for ; Wed, 26 Feb 2014 09:05:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.449 X-Spam-Level: X-Spam-Status: No, score=-7.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, 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 lKttc2xwYf2E for ; Wed, 26 Feb 2014 09:05:29 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id F37F01A06D0 for ; Wed, 26 Feb 2014 09:05:28 -0800 (PST) Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s1QH4Xi3024589 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 26 Feb 2014 12:05:26 -0500 Received: from pspacek.brq.redhat.com (vpn1-4-54.ams2.redhat.com [10.36.4.54]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s1QFxu2s009410 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Wed, 26 Feb 2014 10:59:57 -0500 Message-ID: <530E0F7B.2080306@redhat.com> Date: Wed, 26 Feb 2014 16:59:55 +0100 From: Petr Spacek Organization: Red Hat User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: dane@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/OEE-nhi7qzyLn7qwxNJU-YUGiEo Subject: Re: [dane] An AD bit discussion 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, 26 Feb 2014 17:05:36 -0000 Greetings, On 26.2.2014 15:12, Paul Wouters wrote: > I've been part of a very long and heated discussion about the trust of > the AD bit. I would like to hear from people here what they think. > > I'm currently aware of two (non-dns utilities) applications that make > security decisions based on "blindly" trusting the AD bit: ssh with > VerifyHostKeyDNS=yes|ask and Postfix. > > libreswan and strongswan are examples of applications that use libunbound > for in-application DNSSEC validation to avoid needing to trust > /etc/resolv.conf DNS servers for the AD bit. > > First, let me list 4 items everyone seems to agree on: > > 1 Applications can either do dnssec validation themselves, or trust the > AD bit. > > 2 It is undesirable that each application has its own DNSSEC validation > code, trust anchors and DNS cache. > > 3 It is undesirable that applications blindly trust the AD bit when > resolv.conf points to another host as the AD bit could have been modified > on the network. > > 4 In the ideal world tomorrow, each host has its own automatically > configured, perfectly working validing DNS server and resolv.conf can > be ignored or is always hardcoded with nameserver 127.0.0.1 > > Now for my question. Until we reach 4), what should we do with the AD > bit in getaddrinfo() ? > > A) strip the AD bit in struct addrinfo for "untrusted nameservers". A new > configuration mechanism will allow white-listing nameservers and 127.0.0.1 > will always be on the whitelist. > > B) do nothing > > C) Something else, please specify Paul and me have accidentally open threads about the same topic on this list and also on dnsop-list. I guess that this discussion fits better here so I will post our reasoning. Please note that we would like to discuss the right implementation approach with you and not to push described proposal. I work in Red Hat's Identity Management group and my opinions can differ from Paul's, don't be surprised. (I.e. "we" in following text doesn't necessarily include Paul :-) We can see two very basic approaches: A) Do DNSSEC response validation in each application. B) Let recursive resolver do the validation and use AD bit in the application. We consider the first approach (i.e. each application doing response validation) too heavy-weight and hard to administer for various reasons: - Response validation is sensitive operation and application programmers should not do it themselves. - A variant where every application calls validation library is still not optimal. Experience with crypto libraries shows that there are many opportunities to use a library incorrectly (in a way which works but is not secure). - This approach has potential to create administrative nightmare if each application decides to maintain own set of trust anchors etc. We can see results of such approach in PKI world ... We believe that better approach is to centralize validation in local system-wide recursive resolver and use AD bit for signaling that data are trustworthy to applications. A n application should use stub-resolver to talk to local recursive resolver and use received AD bit to decide e.g. if it is possible to trust TLSA records or not. Unfortunately, there are use cases where neither a locally running validating resolver nor a trusted path to a remote resolver are available and deployment of such is unacceptable. It seems that existing stub-resolvers unconditionally trust recursive resolvers and just forward the AD bit back and forth. This behavior is okay only if no application relays on the AD bit. In other words, supporting DANE with current stub-resolvers practically requires to add a configuration option 'recursive resolver is un/trusted' to each and every DANE-enabled application and library. (This is exactly what OpenSSH client does. An additional problem is that this value has to be maintained as network configuration changes over time.) We would like to make DNSSEC implementation in applications as simple and secure as possible. That is a reason why we are looking for a solution for a case where AD bit can't be trusted because validating resolver is not available for whatever reason. It would allow applications to use AD bit without explicit configuration per-application if we solve this case somehow. Is there any 'standard' way to handle described situation? We have the following proposal (some people say it is controversial): - Extend stub-resolvers with a new call for resolver initialization: In case of ldns it would be something like: ldns_resolver_new_frm_file_trusted(). - The new call will initialize library as usual + read some system-wide configuration (it can be whatever, imagine for example a new file /etc/resolv.trusted). - Client applications will use the same API (except the initialization) to do DNS queries. - When a DNS answer is received from network the stub-resolver will consult configuration read from /etc/resolv.trusted: -- If the particular recursive resolver is listed as trusted - pass AD bit to the application. -- *Otherwise: Clear AD bit and pass the answer with AD=0 to the application.* This allows an administrator to configure system-wide policy. In case with locally running validating resolver or e.g. IPSec tunnel to trusted resolver admin can declare it as trusted and nothing changes. However, this mechanism allows the system to be safe even in configurations *without* validating resolver. No explicit configuration in application is need, just one system-wide setting. It could seem like a minor improvement or a hack, but it allows applications to trust the AD bit unconditionally and as a result it significantly simplifies DNSSEC implementation and configuration on client machines. We hope that this simple approach will allow us to implement and deploy DANE and similar technologies widely. This proposal can be seen as temporary solution before secure transport mechanisms like IPSec or CGA-TSIG are widelly available and used. The main advantage is that it is easy to implement and it doesn't require any new technology so we can use it in applications today. We would like to hear your opinions and recommendations for this area. Thank you for your time. -- Petr Spacek @ Red Hat From nobody Wed Feb 26 09:10: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 837E81A06E3 for ; Wed, 26 Feb 2014 09:10:26 -0800 (PST) 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 XO9L3yjVJaDr for ; Wed, 26 Feb 2014 09:10:16 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id E6ADF1A06B3 for ; Wed, 26 Feb 2014 09:10:12 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 5EEF92AAC73; Wed, 26 Feb 2014 17:10:11 +0000 (UTC) Date: Wed, 26 Feb 2014 17:10:11 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140226171011.GX21390@mournblade.imrryr.org> References: <20140226155752.GT21390@mournblade.imrryr.org> <20140226162221.GV21390@mournblade.imrryr.org> <530E15FF.2020107@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <530E15FF.2020107@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/uLCU2h7G4DHq2D9fRzJ_DMRzIEI Subject: Re: [dane] An AD bit discussion 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: Wed, 26 Feb 2014 17:10:26 -0000 On Wed, Feb 26, 2014 at 05:27:43PM +0100, Petr Spacek wrote: > We believe that better approach is to centralize validation in local > system-wide recursive resolver and use AD bit for signaling that data are > trustworthy to applications. An application should use stub-resolver to > talk to local recursive resolver and use received AD bit to decide e.g. > if it is possible to trust TLSA records or not. > > Unfortunately, there are use cases where neither a locally running > validating resolver nor a trusted path to a remote resolver are available > and deployment of such is unacceptable. Please adopt the more modern BSD-style res_ninit(), ... libresolv interface which improves thread-safety of the stub resolver, and allows clients to set or query the server list via res_setservers() and res_getservers(). Extend that API to include a res_ninit_ex() (or similar) that can specify an alternative resolv.conf file (in coordination with other implementations if possible). Some applications will want to explicitly ensure that the trusted recursive resolver is local. Others, for better or worse, may prefer to trust the administrator's judgement about which recursive resolvers are secure. See this and related posts in thread by the same author: http://archives.neohapsis.com/archives/postfix/2014-02/0499.html Applications, that place trust in the AD bit (choose to not implement their own validation) should be able to decide whether they also trust everything in /etc/resolv.conf, or whether they'd rather be sure. Paul Hoffman's new DNS API may also be something to consider. I am hoping Paul or someone else intimately familiar with it can chime in about that. > We would like to make DNSSEC implementation in applications as simple and > secure as possible. That is a reason why we are looking for a solution > for a case where AD bit can't be trusted because validating resolver is > not available for whatever reason. It would allow applications to use AD > bit without explicit configuration per-application if we solve this case > somehow. > > Is there any 'standard' way to handle described situation? No. But you could extend /etc/resolv.conf to support a verb that marks the AD bit authoritative. If the file is maintained by the administrator and uses the new verb, the AD bit is passed on, otherwise (as e.g. with /etc/resolv.conf populated by DHCP) it is ignored. This could be useful for applications that don't want to employ res_[sg]etserver(). > We have the following proposal (some people say it is controversial): > > - Extend stub-resolvers with a new call for resolver initialization: In > case of ldns it would be something like: > > ldns_resolver_new_frm_file_trusted(). > > - The new call will initialize library as usual + read some system-wide > configuration (it can be whatever, imagine for example a new file > /etc/resolv.trusted). > > - Client applications will use the same API (except the initialization) > to do DNS queries. > > - When a DNS answer is received from network the stub-resolver will consult > configuration read from /etc/resolv.trusted: > > -- If the particular recursive resolver is listed as trusted - pass > AD bit to the application. > -- *Otherwise: Clear AD bit and pass the answer with AD=0 to the > application.* I think this is unwise, forcing all applications that want validated results to make new platform-specific calls is unwise. Instead extend the /etc/resolv.conf syntax: nameserver 127.0.0.1 ad_trusted yes the default can be "ad_trusted no". Applications that want to control the server list and specify a corresponding value of "ad_trusted" can employ a custom resolv.conf file or call res_setservers(), which would turn on the AD bit (the application knows which servers it asked for, and can decide whether to believe the AD bit). > This proposal can be seen as temporary solution before secure transport > mechanisms like IPSec or CGA-TSIG are widely available and used. The main > advantage is that it is easy to implement and it doesn't require any new > technology so we can use it in applications today. I don't expect wide adoption of IPSec or TSIG any time soon if ever. > We would like to hear your opinions and recommendations for this area. Whatever you do, don't force applications to make new calls to avoid having the AD bit clobbered by the stub resolver. It must be possible to configure the system so that the AD is usable with no changes to applications using the resolver API. Thus the suggestion to move the signal out of the application and into /etc/resolv.conf. -- Viktor. From nobody Wed Feb 26 09:24:51 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 0F0481A0730 for ; Wed, 26 Feb 2014 09:24:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.253 X-Spam-Level: X-Spam-Status: No, score=0.253 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.547] 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 4n8F-TFReL7N for ; Wed, 26 Feb 2014 09:24:41 -0800 (PST) Received: from ppsw-32.csi.cam.ac.uk (ppsw-32.csi.cam.ac.uk [IPv6:2001:630:212:8::e:f32]) by ietfa.amsl.com (Postfix) with ESMTP id 1F98B1A0725 for ; Wed, 26 Feb 2014 09:24:40 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:56138) by ppsw-32.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:fanf2) id 1WIiDl-00087X-2u (Exim 4.82_3-c0e5623) (return-path ); Wed, 26 Feb 2014 17:24:37 +0000 Received: from fanf2 by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1WIiDl-00072a-R4 (Exim 4.72) (return-path ); Wed, 26 Feb 2014 17:24:37 +0000 Date: Wed, 26 Feb 2014 17:24:37 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Paul Wouters In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Archived-At: http://mailarchive.ietf.org/arch/msg/dane/NGEFT4-AFnbosGsXOfesXRsvsXc Cc: dane WG list Subject: Re: [dane] An AD bit discussion 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, 26 Feb 2014 17:24:44 -0000 Paul Wouters wrote: > I'm currently aware of two (non-dns utilities) applications that make > security decisions based on "blindly" trusting the AD bit: ssh with > VerifyHostKeyDNS=yes|ask and Postfix. Note that OpenSSH can be linked with ldns to do its own validation. > 1 Applications can either do dnssec validation themselves, or trust the > AD bit. At the moment I consider in-process validation to be the safer way to do it, because apps do not have any sane way to verify that it is safe to trust the AD bit (more about that below). That is, by doing its own validation the app is better able to guarantee safety, without assuming that there is an expert and diligent sysadmin who is able to do arcane things like override the DHCP server's suggested nameserver addresses. > 2 It is undesirable that each application has its own DNSSEC validation > code, trust anchors and DNS cache. Agreed, but there are some subtleties. It's probably not too bad if the validation code is in a shared library that is centrally configured - like the traditional resolver or ldns's resolver. However if ldns's resolver were to be more widely used it will need MUCH better trust anchor management. Even so a system-wide cache should perform better. Perhaps multi-user systems should have per-user validating caches so that users don't have to trust each other too much :-) > 3 It is undesirable that applications blindly trust the AD bit when > resolv.conf points to another host as the AD bit could have been modified > on the network. Right. What makes this particularly pernicious is that the resolver API does not give an app any reasonable way to find out if it would be safe to trust the AD bit. To do so the app would have to extract the name server addresses from the __res_state and compare that with the system's list of network interface addresses. The layout of __res_state is private and the way IPv6 support has been added varies wildly between different flavours of unix. Utterly horrible. > 4 In the ideal world tomorrow, each host has its own automatically > configured, perfectly working validing DNS server and resolv.conf can > be ignored or is always hardcoded with nameserver 127.0.0.1 That would be nice :-) > Now for my question. Until we reach 4), what should we do with the AD > bit in getaddrinfo() ? > > A) strip the AD bit in struct addrinfo for "untrusted nameservers". A new > configuration mechanism will allow white-listing nameservers and 127.0.0.1 > will always be on the whitelist. That sounds like a fair plan. Note that what ssh does is use the low-level res_query() API which returns a raw DNS packet, and examines the AD bit in the packet header. http://svnweb.freebsd.org/base/vendor-crypto/openssh/6.5p1/openbsd-compat/getrrsetbyname.c?revision=261288&view=markup#l274 Exim's preliminary DNSSEC support does the same. http://git.exim.org/exim.git/blob/HEAD:/src/src/dns.c#l430 So you should change the low-level parts of the traditional resolver to clear the AD bit in the packet header before returning to any higher level code, unless the connection to the nameserver is known to be safe. Question: along with this change are you planning to change the resolver to set the AD flag in queries when the nameserver is known to be safe? Usually the AD flag only appears in responses if the query had the AD or DO flags set. DO is a bit wasteful for clients that only care about the AD bit. However the only DNSSEC switch that libc resolvers currently have is options edns0 (which implies DO). Tony. -- f.anthony.n.finch http://dotat.at/ Malin: West or southwest 5 to 7, backing south 6 to gale 8 for a time. Rough or very rough. Showers, rain for a time. Good, occasionally poor. From nobody Wed Feb 26 09:36: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 041871A070B for ; Wed, 26 Feb 2014 09:36:36 -0800 (PST) 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 QEVMWtKCg-T0 for ; Wed, 26 Feb 2014 09:36:33 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id E9A301A00AE for ; Wed, 26 Feb 2014 09:36:32 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 588552AAC73; Wed, 26 Feb 2014 17:36:30 +0000 (UTC) Date: Wed, 26 Feb 2014 17:36:30 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140226173630.GZ21390@mournblade.imrryr.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/vEd65aLbkJKar5yzKqrnm3fsOOw Subject: Re: [dane] An AD bit discussion 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: Wed, 26 Feb 2014 17:36:36 -0000 On Wed, Feb 26, 2014 at 05:24:37PM +0000, Tony Finch wrote: > > A) strip the AD bit in struct addrinfo for "untrusted nameservers". A new > > configuration mechanism will allow white-listing nameservers and 127.0.0.1 > > will always be on the whitelist. > > That sounds like a fair plan. It is in fact problematic if both 127.0.0.1 and another nameserver are listed. The correct semantics of that are hard to define. It makes more sense to define a boolean primitive that marks all the nameservers collectively as either trusted or not. > Question: along with this change are you planning to change the resolver > to set the AD flag in queries when the nameserver is known to be safe? > > Usually the AD flag only appears in responses if the query had the AD or > DO flags set. DO is a bit wasteful for clients that only care about the AD > bit. However the only DNSSEC switch that libc resolvers currently have is > options edns0 (which implies DO). The RES_USE_DNSSEC flag turns on the "DO" bit. I would be surprised if RES_USE_EDNS0 enabled "DO". As for setting the "AD" bit in the request automatically, it probably should still require an explicit indication of interest from the application or be set via a default option value /etc/resolv.conf. -- Viktor. From nobody Wed Feb 26 09:41:50 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 F3B8B1A00F6 for ; Wed, 26 Feb 2014 09:41:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.449 X-Spam-Level: X-Spam-Status: No, score=-7.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, 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 J0m_pRtPx_CN for ; Wed, 26 Feb 2014 09:41:41 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 625B91A0074 for ; Wed, 26 Feb 2014 09:41:41 -0800 (PST) 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 s1QHfbEU009674 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 26 Feb 2014 12:41:37 -0500 Received: from pspacek.brq.redhat.com (vpn1-4-54.ams2.redhat.com [10.36.4.54]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s1QHfXvb030921 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 26 Feb 2014 12:41:36 -0500 Message-ID: <530E274D.6030500@redhat.com> Date: Wed, 26 Feb 2014 18:41:33 +0100 From: Petr Spacek Organization: Red Hat User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Tony Finch , Paul Wouters References: In-Reply-To: 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/8Gg_oQeqix6zmHJEnhopFBH1PMo Cc: dane WG list Subject: Re: [dane] An AD bit discussion 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, 26 Feb 2014 17:41:45 -0000 On 26.2.2014 18:24, Tony Finch wrote: > Paul Wouters wrote: >> 1 Applications can either do dnssec validation themselves, or trust the >> AD bit. > > At the moment I consider in-process validation to be the safer way to do > it, because apps do not have any sane way to verify that it is safe to > trust the AD bit (more about that below). That is, by doing its own > validation the app is better able to guarantee safety, without assuming > that there is an expert and diligent sysadmin who is able to do arcane > things like override the DHCP server's suggested nameserver addresses. A proposal sent to the other thread (http://www.ietf.org/mail-archive/web/dane/current/msg06475.html) attempts to address this problem with explicit name server white-listing. >> 2 It is undesirable that each application has its own DNSSEC validation >> code, trust anchors and DNS cache. > > Agreed, but there are some subtleties. It's probably not too bad if the > validation code is in a shared library that is centrally configured - like > the traditional resolver or ldns's resolver. However if ldns's resolver > were to be more widely used it will need MUCH better trust anchor > management. Even so a system-wide cache should perform better. Perhaps > multi-user systems should have per-user validating caches so that users > don't have to trust each other too much :-) The mentioned proposal calls for per-system centralized trust anchor management. >> 3 It is undesirable that applications blindly trust the AD bit when >> resolv.conf points to another host as the AD bit could have been modified >> on the network. > > Right. What makes this particularly pernicious is that the resolver API > does not give an app any reasonable way to find out if it would be safe to > trust the AD bit. This is exactly the reason why we propose to strip the AD bit in library so application don't need to think about it's trustworthiness. >> 4 In the ideal world tomorrow, each host has its own automatically >> configured, perfectly working validing DNS server and resolv.conf can >> be ignored or is always hardcoded with nameserver 127.0.0.1 > > That would be nice :-) > >> Now for my question. Until we reach 4), what should we do with the AD >> bit in getaddrinfo() ? >> >> A) strip the AD bit in struct addrinfo for "untrusted nameservers". A new >> configuration mechanism will allow white-listing nameservers and 127.0.0.1 >> will always be on the whitelist. > > That sounds like a fair plan. > > Note that what ssh does is use the low-level res_query() API which returns > a raw DNS packet, and examines the AD bit in the packet header. > http://svnweb.freebsd.org/base/vendor-crypto/openssh/6.5p1/openbsd-compat/getrrsetbyname.c?revision=261288&view=markup#l274 > Exim's preliminary DNSSEC support does the same. > http://git.exim.org/exim.git/blob/HEAD:/src/src/dns.c#l430 > > So you should change the low-level parts of the traditional resolver to > clear the AD bit in the packet header before returning to any higher level > code, unless the connection to the nameserver is known to be safe. Note we are not trying to 'target' one particular library. It would be great if we can reach consensus on some universal approach and then actively work with DNS library maintainers to add the new behavior to DNS libraries. > Question: along with this change are you planning to change the resolver > to set the AD flag in queries when the nameserver is known to be safe? > > Usually the AD flag only appears in responses if the query had the AD or > DO flags set. DO is a bit wasteful for clients that only care about the AD > bit. However the only DNSSEC switch that libc resolvers currently have is > options edns0 (which implies DO). Could you elaborate on reasons for setting AD=1, please? -- Petr Spacek @ Red Hat @ Brno office From nobody Wed Feb 26 09:50:22 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 7B2731A0758 for ; Wed, 26 Feb 2014 09:50:16 -0800 (PST) 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 Dj-pPkBXkX6n for ; Wed, 26 Feb 2014 09:50:13 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id B96A41A0739 for ; Wed, 26 Feb 2014 09:50:13 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 2F1A52AAC73; Wed, 26 Feb 2014 17:50:12 +0000 (UTC) Date: Wed, 26 Feb 2014 17:50:12 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140226175012.GA21390@mournblade.imrryr.org> References: <530E274D.6030500@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <530E274D.6030500@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/S2O7HUtQqP0LYd9T2zxlcyuAn4M Subject: Re: [dane] An AD bit discussion 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: Wed, 26 Feb 2014 17:50:16 -0000 On Wed, Feb 26, 2014 at 06:41:33PM +0100, Petr Spacek wrote: > Could you elaborate on reasons for setting AD=1, please? With "DO=1", applications that only care about the AD bit in the reply also receive unwanted "RRSIG" records. Setting "AD=1" may however require a new request option bit, since RES_USE_DNSSEC sets "DO=1". I am not sure whether it would be right to always send "AD=1" when all the nameservers are trusted and believed to support validation. Perhaps that's OK, but it may be prudent to only do this when specifically requested. -- Viktor. From nobody Wed Feb 26 10:04:45 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 41C911A04BA for ; Wed, 26 Feb 2014 10:04:39 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001] 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 dTVqmRAZdTI3 for ; Wed, 26 Feb 2014 10:04:35 -0800 (PST) Received: from smtp108.ord1c.emailsrvr.com (smtp108.ord1c.emailsrvr.com [108.166.43.108]) by ietfa.amsl.com (Postfix) with ESMTP id 6675D1A01E2 for ; Wed, 26 Feb 2014 10:04:35 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp6.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 49D7898A27 for ; Wed, 26 Feb 2014 13:04:33 -0500 (EST) X-Virus-Scanned: OK Received: by smtp6.relay.ord1c.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id 1AC4D98ADF for ; Wed, 26 Feb 2014 13:04:33 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Olafur Gudmundsson In-Reply-To: <420AB1E7-1E9B-457D-81B7-35C53426841D@ogud.com> Date: Wed, 26 Feb 2014 13:04:33 -0500 Content-Transfer-Encoding: 7bit Message-Id: References: <420AB1E7-1E9B-457D-81B7-35C53426841D@ogud.com> To: "dane@ietf.org list" X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/bQQyUw3NxsvMWUmUlQQMhsfZc6M Subject: Re: [dane] DANE Agenda 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, 26 Feb 2014 18:04:39 -0000 Forgot to add the link http://www.ietf.org/proceedings/89/agenda/agenda-89-dane Olafur On Feb 26, 2014, at 12:48 PM, Olafur Gudmundsson wrote: > I uploaded a new agenda to the meeting tool > no new drafts reordered topics, added some time for DANE future discussion > > The new and updated agenda's are available via: > > On Feb 18, 2014, at 10:30 AM, Warren Kumari wrote: > >> Hi all. >> >> Please find the updated agenda. >> >> We have 6 or 7 drafts on the agenda this time. Please read them ahead >> of time so you can be primed with (intelligent!) questions :-) >> >> W >> >> DANE >> ------------- >> Administrivia >> (Sit down, blue-sheets, agenda bashing) >> Warren / Ondrej - 5 minutes. >> >> DANE - key acquisition, service discovery or usage assurance? >> Paul Hoffman - 30 minutes >> >> Using DANE to Associate OpenPGP public keys with email addresses >> draft-wouters-dane-openpgp-01 >> Discuss draft updates / issues, quick demo >> Paul Wouters - 10 minutes >> >> IPSECKEY / Auth_none >> draft-smyslov-ipsecme-ikev2-null-auth-00 >> Paul Wouters - 20 minutes >> >> Using DNS-Based Authentication of Named Entities (DANE) TLSA records >> with SRV and MX records. >> draft-ietf-dane-srv-05 >> Peter Saint-Andre or Matt Miller - 20 min >> >> Harmonizing how applications specify DANE-like usage >> draft-ogud-dane-vocabulary-01 >> (Quick update) >> Olafur - 5 min >> >> SMTP security via opportunistic DANE TLS >> draft-ietf-dane-smtp-with-dane-06 >> (NOTE: This is in WGLC.) >> Wes Hardaker - 20 minutes. >> >> DANE TLSA implementation and operational guidance >> draft-ietf-dane-ops-02 >> Wes Hardaker - 15 minutes. >> >> Provisional: >> Opportunistic Encryption with DANE Semantics and IPsec: IPSECA >> draft-osterweil-dane-ipsec >> Eric Osterweil - 10 minutes. >> (Only if we have time remaining). >> >> _______________________________________________ >> dane mailing list >> dane@ietf.org >> https://www.ietf.org/mailman/listinfo/dane > From nobody Wed Feb 26 10:09: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 02A5A1A00E8 for ; Wed, 26 Feb 2014 10:09:39 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001] 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-IOHZxxx8Fp for ; Wed, 26 Feb 2014 10:09:32 -0800 (PST) Received: from smtp100.ord1c.emailsrvr.com (smtp100.ord1c.emailsrvr.com [108.166.43.100]) by ietfa.amsl.com (Postfix) with ESMTP id 03D9B1A005B for ; Wed, 26 Feb 2014 10:09:31 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp5.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id BC71A1B16AA; Wed, 26 Feb 2014 13:09:30 -0500 (EST) X-Virus-Scanned: OK Received: by smtp5.relay.ord1c.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id 7042B1B0A05; Wed, 26 Feb 2014 13:09:28 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Olafur Gudmundsson In-Reply-To: Date: Wed, 26 Feb 2014 13:09:28 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <1ECDE2FC-CA24-43BF-8DAF-DAA8D98721B1@ogud.com> References: To: Paul Wouters X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/SRzoLHfjBULC0BLcb8f6dJFvJIQ Cc: dane WG list Subject: Re: [dane] An AD bit discussion 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, 26 Feb 2014 18:09:39 -0000 On Feb 26, 2014, at 9:12 AM, Paul Wouters wrote: >=20 > Hi, >=20 > I've been part of a very long and heated discussion about the trust of > the AD bit. I would like to hear from people here what they think. >=20 > I'm currently aware of two (non-dns utilities) applications that make > security decisions based on "blindly" trusting the AD bit: ssh with > VerifyHostKeyDNS=3Dyes|ask and Postfix. >=20 > libreswan and strongswan are examples of applications that use = libunbound > for in-application DNSSEC validation to avoid needing to trust > /etc/resolv.conf DNS servers for the AD bit. >=20 > First, let me list 4 items everyone seems to agree on: >=20 > 1 Applications can either do dnssec validation themselves, or trust = the > AD bit. >=20 > 2 It is undesirable that each application has its own DNSSEC = validation > code, trust anchors and DNS cache. >=20 > 3 It is undesirable that applications blindly trust the AD bit when > resolv.conf points to another host as the AD bit could have been = modified > on the network. >=20 > 4 In the ideal world tomorrow, each host has its own automatically > configured, perfectly working validing DNS server and resolv.conf can > be ignored or is always hardcoded with nameserver 127.0.0.1 >=20 > Now for my question. Until we reach 4), what should we do with the AD > bit in getaddrinfo() ? >=20 > A) strip the AD bit in struct addrinfo for "untrusted nameservers". A = new > configuration mechanism will allow white-listing nameservers and = 127.0.0.1 > will always be on the whitelist. >=20 > B) do nothing >=20 > C) Something else, please specify >=20 I agree with most of what you said.=20 Strictly the AD bit "problem" is twofold,=20 a) Application does not know where the AD bit came from nor if = the bit/data has been changed in flight.=20 b) Application does not know the security policy of the "entity" = that set the AD bit or who operates it.=20 a) is caused by the fact that most systems do not do 4) but blindly = accept DNS resolvers supplied by=20 network configuration protocols like DHCP and RA. For all practical = purposes this while a nice "convenience" it=20 is a security hole that someone will drive a truck though one day = (actually they have it is called a coffee shop network)=20 To further make things worse there is frequently no integrity protection = on the last "hop/mile" between the recursive resolver and=20 host stub-resolver.=20 =20 There is a large hotel chain that advertises that the resolvers used in = their hotels are 8.8.8.8 (Google) and two others ISP's=20 the answers when sent to directly 8.8.8.8 only about 1/3 of the time = look like they come from 8.8.8.8. When asking OpenDNS directly=20 the answers are supplied by the resolvers in the DHCP list. This can = only be defeated by sending queries to a port !=3D 53 and in some cases requires TCP connections. b) This is a big issue, and without some research you can not find this = out what the resolver is doing, and then you can=20 not be sure if the resolver has special cases where it will not give you = the real answers but the ones it is told by higher authority to give out.=20 As what a DNS library should do, IMHO work on setting up a trusted path = to a trusted Recursive resolver, and then add info in the returned structure that gives credibility of = the AD bit.=20 DNS cookies are one option, TSIG and DNScurve are better, SIG(0) will = scale to random servers,=20 TLS over long lived TCP/SCCP are also possible, IPsec to resolver will = work as well.=20 If someone can figure out how to do Encrypted DNS over UDP that would be = great.=20 If you trust 127.0.0.1 fine but make sure all the answers come from it.=20= The biggest difficulty you will face is encryption and Anycast DNS are = unfriendly to integrity,=20 In summary we need to=20 - deploy security for the last mile - extend API's to return info that the application can USE (not what = we think it wants)=20 Olafur > Paul >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From nobody Wed Feb 26 10:14: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 26B0B1A00A9 for ; Wed, 26 Feb 2014 10:14:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.548 X-Spam-Level: X-Spam-Status: No, score=-0.548 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RP_MATCHES_RCVD=-0.547] 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 icMxJv5bJ4K9 for ; Wed, 26 Feb 2014 10:14:37 -0800 (PST) Received: from ppsw-52.csi.cam.ac.uk (ppsw-52.csi.cam.ac.uk [IPv6:2001:630:212:8::e:f52]) by ietfa.amsl.com (Postfix) with ESMTP id BEA191A075C for ; Wed, 26 Feb 2014 10:14:11 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:34248) by ppsw-52.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:fanf2) id 1WIizh-0004Lz-FD (Exim 4.82_3-c0e5623) for dane@ietf.org (return-path ); Wed, 26 Feb 2014 18:14:09 +0000 Received: from fanf2 by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1WIizh-0003da-Dh (Exim 4.72) for dane@ietf.org (return-path ); Wed, 26 Feb 2014 18:14:09 +0000 Date: Wed, 26 Feb 2014 18:14:09 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: dane@ietf.org In-Reply-To: <20140226173630.GZ21390@mournblade.imrryr.org> Message-ID: References: <20140226173630.GZ21390@mournblade.imrryr.org> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Archived-At: http://mailarchive.ietf.org/arch/msg/dane/gnhjnGVisksHL8Vxc9hSpXx_FyU Subject: Re: [dane] An AD bit discussion 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, 26 Feb 2014 18:14:41 -0000 Viktor Dukhovni wrote: > > It is in fact problematic if both 127.0.0.1 and another nameserver > are listed. The correct semantics of that are hard to define. It > makes more sense to define a boolean primitive that marks all the > nameservers collectively as either trusted or not. Yes. > The RES_USE_DNSSEC flag turns on the "DO" bit. I would be surprised > if RES_USE_EDNS0 enabled "DO". Er yes, you are right. I was confused by the way ssh uses the resolver: it sets RES_USE_DNSSEC only if RES_USE_EDNS0 is set, so putting "options edns0" in /etc/resolv.conf turns on ssh's trust-AD behaviour. There is not a separate resolv.conf option for DNSSEC. Grotty. (Note that when I make statements about resolver behaviour I am checking boh FreeBSD and glibc - they are pretty consistent in all this.) > As for setting the "AD" bit in the request automatically, it probably > should still require an explicit indication of interest from the > application or be set via a default option value /etc/resolv.conf. Perhaps, though I think the AD flag is pretty benign. Tony. -- f.anthony.n.finch http://dotat.at/ Forties, Cromarty, Forth, Tyne, Dogger: Southwest 5 to 7, backing south or southeast 6 to gale 8 for a time. Moderate or rough. Showers then rain. Good, becoming moderate or poor. From nobody Wed Feb 26 10:16: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 B4B601A075C for ; Wed, 26 Feb 2014 10:16:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] 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 wSovrw_y1GUx for ; Wed, 26 Feb 2014 10:16:27 -0800 (PST) Received: from ppsw-32.csi.cam.ac.uk (ppsw-32.csi.cam.ac.uk [IPv6:2001:630:212:8::e:f32]) by ietfa.amsl.com (Postfix) with ESMTP id 52D311A00A9 for ; Wed, 26 Feb 2014 10:16:27 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:58186) by ppsw-32.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:fanf2) id 1WIj1t-0006wn-2j (Exim 4.82_3-c0e5623) for dane@ietf.org (return-path ); Wed, 26 Feb 2014 18:16:25 +0000 Received: from fanf2 by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1WIj1t-0003vT-QF (Exim 4.72) for dane@ietf.org (return-path ); Wed, 26 Feb 2014 18:16:25 +0000 Date: Wed, 26 Feb 2014 18:16:25 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: dane@ietf.org In-Reply-To: <20140226175012.GA21390@mournblade.imrryr.org> Message-ID: References: <530E274D.6030500@redhat.com> <20140226175012.GA21390@mournblade.imrryr.org> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Archived-At: http://mailarchive.ietf.org/arch/msg/dane/u1u90NtkUfh-WtJXTmjuXIPyCMQ Subject: Re: [dane] An AD bit discussion 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, 26 Feb 2014 18:16:30 -0000 Viktor Dukhovni wrote: > On Wed, Feb 26, 2014 at 06:41:33PM +0100, Petr Spacek wrote: > > > Could you elaborate on reasons for setting AD=1, please? > > With "DO=1", applications that only care about the AD bit in the > reply also receive unwanted "RRSIG" records. Exactly. > Setting "AD=1" may however require a new request option bit, Definitely. Tony. -- f.anthony.n.finch http://dotat.at/ Forties, Cromarty, Forth, Tyne, Dogger: Southwest 5 to 7, backing south or southeast 6 to gale 8 for a time. Moderate or rough. Showers then rain. Good, becoming moderate or poor. From nobody Wed Feb 26 10:24:45 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 33CC51A021B for ; Wed, 26 Feb 2014 10:24:37 -0800 (PST) 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 MKR4Y5drKSfM for ; Wed, 26 Feb 2014 10:24:34 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 391291A0106 for ; Wed, 26 Feb 2014 10:24:34 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 956DC2AAD0C; Wed, 26 Feb 2014 18:24:32 +0000 (UTC) Date: Wed, 26 Feb 2014 18:24:32 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140226182432.GB21390@mournblade.imrryr.org> References: <20140226173630.GZ21390@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.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/RPIYddLzJ2UG9UEtSjFKQgOpwpY Subject: Re: [dane] An AD bit discussion 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: Wed, 26 Feb 2014 18:24:37 -0000 On Wed, Feb 26, 2014 at 06:14:09PM +0000, Tony Finch wrote: > > As for setting the "AD" bit in the request automatically, it probably > > should still require an explicit indication of interest from the > > application or be set via a default option value /etc/resolv.conf. > > Perhaps, though I think the AD flag is pretty benign. I think it requires EDNS0, but if that is already set, perhaps turning on AD by default is harmless. This specific detail is perhaps more of a "dnsop" than "dane" question. By the way I just noticed that http://www.vpnc.org/getdns-api/ does not define the interaction of DNSSEC with: getdns_return_t getdns_context_set_append_name( getdns_context *context, getdns_append_name_t value ); Specifies whether to append a suffix to the query string before the API starts resolving a name. The value is GETDNS_APPEND_NAME_ALWAYS, GETDNS_APPEND_NAME_ONLY_TO_SINGLE_LABEL_AFTER_FAILURE, GETDNS_APPEND_NAME_ONLY_TO_MULTIPLE_LABEL_NAME_AFTER_FAILURE, or GETDNS_APPEND_NAME_NEVER. This controls whether or not to append the suffix given by getdns_context_set_suffix Name appending breaks DNSSEC when any of the resulting zones are insecure and are tried before ultimately secure zones. The validity of a request for a secure response for an under-specified query is IMHO questionable. -- Viktor. From nobody Wed Feb 26 11:03:00 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 6E4881A07F6 for ; Wed, 26 Feb 2014 11:02:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] 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 osKBPcBZV_kV for ; Wed, 26 Feb 2014 11:02:48 -0800 (PST) Received: from ppsw-42.csi.cam.ac.uk (ppsw-42.csi.cam.ac.uk [IPv6:2001:630:212:8::e:f42]) by ietfa.amsl.com (Postfix) with ESMTP id C1F361A0205 for ; Wed, 26 Feb 2014 11:02:47 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:33136) by ppsw-42.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1WIjkj-0000Co-9B (Exim 4.82_3-c0e5623) for dane@ietf.org (return-path ); Wed, 26 Feb 2014 19:02:45 +0000 Received: from fanf2 by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1WIjkj-0008Cq-QL (Exim 4.72) for dane@ietf.org (return-path ); Wed, 26 Feb 2014 19:02:45 +0000 Date: Wed, 26 Feb 2014 19:02:45 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: dane@ietf.org In-Reply-To: <20140226182432.GB21390@mournblade.imrryr.org> Message-ID: References: <20140226173630.GZ21390@mournblade.imrryr.org> <20140226182432.GB21390@mournblade.imrryr.org> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Archived-At: http://mailarchive.ietf.org/arch/msg/dane/_7j-GqRp2kfRnq7t_KgZEE3M87c Subject: Re: [dane] An AD bit discussion 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, 26 Feb 2014 19:02:53 -0000 Viktor Dukhovni wrote: > > I think it requires EDNS0, The AD bit is in the message header not the OPT pseudo-RR, so syntactically it doesn't require EDNS0. BIND works OK (try dig +qr +noedns). However the spec is silent on this matter. http://tools.ietf.org/html/rfc6840#page-10 Also I think it is arguable that RFC 4035 says servers should set the AD flag in the response regardless of whether the client indicates it is security-aware. But implementations do not do that. Tony. -- f.anthony.n.finch http://dotat.at/ Lundy, Fastnet, Irish Sea: South veering west 6 to gale 8, occasionally severe gale 9 at first. Rough or very rough, occasionally high in Fastnet. Showers, rain for a time. Good, occasionally poor. From nobody Wed Feb 26 11:10:24 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 912441A0813 for ; Wed, 26 Feb 2014 11:10:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 fyWMNoZzzeaH for ; Wed, 26 Feb 2014 11:10:12 -0800 (PST) Received: from exprod6og111.obsmtp.com (exprod6og111.obsmtp.com [64.18.1.27]) by ietfa.amsl.com (Postfix) with ESMTP id 517921A0726 for ; Wed, 26 Feb 2014 11:10:00 -0800 (PST) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob111.postini.com ([64.18.5.12]) with SMTP ID DSNKUw48B+7kn1CNfdXgyTu9+/DOT4Bp6E+G@postini.com; Wed, 26 Feb 2014 11:09:59 PST Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02.vcorp.ad.vrsn.com [10.173.152.206]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id s1QJ9wNw018442 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 26 Feb 2014 14:09:58 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0123.003; Wed, 26 Feb 2014 14:09:58 -0500 From: "Wiley, Glen" To: "dane@ietf.org" Thread-Topic: [dane] An AD bit discussion Thread-Index: AQHPMxefb3KO91hA20Sgmp6++Nrbq5rIIDMAgAAKhYCAAALmAP//uN4A Date: Wed, 26 Feb 2014 19:09:57 +0000 Message-ID: References: <20140226173630.GZ21390@mournblade.imrryr.org> <20140226182432.GB21390@mournblade.imrryr.org> In-Reply-To: <20140226182432.GB21390@mournblade.imrryr.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/uUhckQFh9FhQvzYN_lsLLGERqW0 Subject: Re: [dane] An AD bit discussion 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, 26 Feb 2014 19:10:17 -0000 Viktor, Your mention of the getdns api is apropos since we just announced the beat release of our implementation :) An application using the getdns api can decide how it will take advantage of the system files - for example whether it wants to use a search option which is an improvement over the current approach in which applications are not aware of whether a suffix was appended to a query. I would add however that the same root operator that might add a suffix to resolv.conf could do other nefarious things to resolvers on that host since the root operator has significant opportunities for MITM attacks on applications running on that host. I think the specification takes the most reasonable approach by deferring to the application to decide the extent to which it will respect system-wide settings (even including trust anchors). --=20 Glen Wiley KK4SFV Sr. Engineer The Hive, Verisign, Inc. On 2/26/14 1:24 PM, "Viktor Dukhovni" wrote: >On Wed, Feb 26, 2014 at 06:14:09PM +0000, Tony Finch wrote: > >> > As for setting the "AD" bit in the request automatically, it probably >> > should still require an explicit indication of interest from the >> > application or be set via a default option value /etc/resolv.conf. >>=20 >> Perhaps, though I think the AD flag is pretty benign. > >I think it requires EDNS0, but if that is already set, perhaps >turning on AD by default is harmless. This specific detail is >perhaps more of a "dnsop" than "dane" question. > >By the way I just noticed that http://www.vpnc.org/getdns-api/ >does not define the interaction of DNSSEC with: > > getdns_return_t getdns_context_set_append_name( > getdns_context *context, > getdns_append_name_t value ); > > Specifies whether to append a suffix to the query string before > the API starts resolving a name. The value is > > GETDNS_APPEND_NAME_ALWAYS, > GETDNS_APPEND_NAME_ONLY_TO_SINGLE_LABEL_AFTER_FAILURE, > GETDNS_APPEND_NAME_ONLY_TO_MULTIPLE_LABEL_NAME_AFTER_FAILURE, or > GETDNS_APPEND_NAME_NEVER. > > This controls whether or not to append the suffix given by > getdns_context_set_suffix > >Name appending breaks DNSSEC when any of the resulting zones are >insecure and are tried before ultimately secure zones. The validity >of a request for a secure response for an under-specified query is >IMHO questionable. > >--=20 > Viktor. > >_______________________________________________ >dane mailing list >dane@ietf.org >https://www.ietf.org/mailman/listinfo/dane From nobody Wed Feb 26 11:11:34 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 36D4A1A0841 for ; Wed, 26 Feb 2014 11:11:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 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.547, 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 C7OgKCTy4VY9 for ; Wed, 26 Feb 2014 11:11:17 -0800 (PST) Received: from ore.jhcloos.com (ore.jhcloos.com [198.147.23.85]) by ietfa.amsl.com (Postfix) with ESMTP id 126651A0860 for ; Wed, 26 Feb 2014 11:10:32 -0800 (PST) Received: by ore.jhcloos.com (Postfix, from userid 10) id 9705C1DDEC; Wed, 26 Feb 2014 19:10:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore13; t=1393441829; bh=8mkUD8CuyYkqslWrT1v/233fcukjeP0KEykag73uRnE=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=b7bagig4yVNOVRsI73q1b1DJIKEfhvCZvKYyiQkH5deQJyeJRZ6gmlCofwFub8TTg 98SsEI41H+8DYnzzYhqs6zA4ORyzT64S5MFWBC174G1wx8/BzKvjQW4aKpTP7iuFpW BFu/I1sWqB96U1cWK3Jk0OLncRwu51M7IDjLq5KqBug== Received: by carbon.jhcloos.org (Postfix, from userid 500) id 4BA5D60030; Wed, 26 Feb 2014 19:03:40 +0000 (UTC) From: James Cloos To: In-Reply-To: (Paul Wouters's message of "Wed, 26 Feb 2014 09:12:20 -0500 (EST)") References: User-Agent: Gnus/5.13001 (Ma Gnus v0.10) Emacs/24.3.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2014 James Cloos OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Wed, 26 Feb 2014 14:03:40 -0500 Message-ID: Lines: 18 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:140226:dane@ietf.org::mbPIfvYGiOyd1nla:000m6hGc X-Hashcash: 1:30:140226:paul@nohats.ca::wbNSo4DzjlpFrWvW:00RDgAl Archived-At: http://mailarchive.ietf.org/arch/msg/dane/ki1rZsZGr8Q3sf4vW2mUi7rIHjk Cc: Paul Wouters Subject: Re: [dane] An AD bit discussion 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, 26 Feb 2014 19:11:27 -0000 >>>>> "PW" == Paul Wouters writes: PW> Now for my question. Until we reach 4), what should we do with the AD PW> bit in getaddrinfo() ? PW> A) strip the AD bit in struct addrinfo for "untrusted nameservers". A new PW> configuration mechanism will allow white-listing nameservers and 127.0.0.1 PW> will always be on the whitelist. PW> B) do nothing I've always preferred a local resolver, and with dnssec a local verifier, on every system. If there are systems unable or unwilling to do that, then A is a reasonable compromize until they can and will. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From nobody Wed Feb 26 11:12: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 BAF7D1A0118 for ; Wed, 26 Feb 2014 11:12:11 -0800 (PST) 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 88xIO5oFa_eG for ; Wed, 26 Feb 2014 11:12:08 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 334DD1A01DD for ; Wed, 26 Feb 2014 11:11:46 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id B1B4A2AAD0C; Wed, 26 Feb 2014 19:11:44 +0000 (UTC) Date: Wed, 26 Feb 2014 19:11:44 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140226191144.GC21390@mournblade.imrryr.org> References: <20140226173630.GZ21390@mournblade.imrryr.org> <20140226182432.GB21390@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.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/VF1rum9jkSqXv73cZbCjl0RaDiw Subject: Re: [dane] An AD bit discussion 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: Wed, 26 Feb 2014 19:12:12 -0000 On Wed, Feb 26, 2014 at 07:02:45PM +0000, Tony Finch wrote: > Viktor Dukhovni wrote: > > > I think it requires EDNS0, > > The AD bit is in the message header not the OPT pseudo-RR, so > syntactically it doesn't require EDNS0. BIND works OK (try > dig +qr +noedns). However the spec is silent on this matter. > http://tools.ietf.org/html/rfc6840#page-10 > Also I think it is arguable that RFC 4035 says servers should set the > AD flag in the response regardless of whether the client indicates > it is security-aware. But implementations do not do that. You're right about the AD bit of course, I was thinking of "DO". Below setting either "AD=1" or "DO=1" elicits a validated response from unbound, but with "DO=1" additional RRSIG records are returned. The libresolv API does not currently expose a portable mechanism for setting AD=1 in requests. $ dig +noall +comment +answer +noedns +adflag -t mx debian.org ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28554 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 6 ;; ANSWER SECTION: debian.org. 3567 IN MX 0 mailly.debian.org. debian.org. 3567 IN MX 0 muffat.debian.org. $ dig +noall +comment +answer +dnssec -t mx debian.org ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15599 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 4, AUTHORITY: 6, ADDITIONAL: 19 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; ANSWER SECTION: debian.org. 3552 IN MX 0 mailly.debian.org. debian.org. 3552 IN MX 0 muffat.debian.org. debian.org. 3552 IN RRSIG MX 7 2 ... debian.org. 3552 IN RRSIG MX 8 2 ... -- Viktor. From nobody Wed Feb 26 11:30: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 2D92B1A017D for ; Wed, 26 Feb 2014 11:30:37 -0800 (PST) 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_40=-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 KhW-ztqNOap5 for ; Wed, 26 Feb 2014 11:30:33 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id C6E751A01E4 for ; Wed, 26 Feb 2014 11:30:33 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 386612AAD0C; Wed, 26 Feb 2014 19:30:32 +0000 (UTC) Date: Wed, 26 Feb 2014 19:30:32 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140226193031.GD21390@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/pcEw2D4jB0-xOVOrYzwyzFyCY14 Subject: [dane] getdns API and suffix search list 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: Wed, 26 Feb 2014 19:30:37 -0000 On Wed, Feb 26, 2014 at 07:09:57PM +0000, Wiley, Glen wrote: > An application using the getdns api can decide how it will take advantage > of the system files - for example whether it wants to use a search option > which is an improvement over the current approach in which applications > are not aware of whether a suffix was appended to a query. The write-up on Paul's site does not specify how suffix appending interacts with DNSSEC. Is that writted down somewhere? I think that applications should studiously avoid mixing the two, but they may need to be warned, or at least the interaction of the two needs to be documented. In particular, after an insecure denial of existence (or after any lookup failure, such as a timeout, SERVFAIL, ...) of a suffixed name, all subsequent lookups with other suffixes, or with no suffix, must be deemed insecure. How do suffixed looks handle lookup errors for a suffixed name? Does the query fail at that point, or does it continue with any remaining suffixes or bare name? -- Viktor. From nobody Wed Feb 26 11:42: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 D6AB51A0117 for ; Wed, 26 Feb 2014 11:42:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.547, 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 BAK0z0tO9-vO for ; Wed, 26 Feb 2014 11:42:22 -0800 (PST) Received: from mout.andreasschulze.de (mout.andreasschulze.de [IPv6:2001:1608:12:1:8ead:7d6c:3132:6a07]) by ietfa.amsl.com (Postfix) with ESMTP id 0B8931A0164 for ; Wed, 26 Feb 2014 11:42:19 -0800 (PST) X-Received: line deleted by mout X-Received: line deleted by mout DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=andreasschulze.de; s=J4bWGJQcBmxMQ; t=1393443733; bh=o+rgFUtLTcN+6bHz+dbgbwA1ukxOo9viUGL/PWINYmk=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=IOSUPj7QaML3xhfCgKwrAnuNXZsKu3YfPWeUd2D1FCcdFf0i0/pbW4HvuA/EPHRH7 TBgHz2EG4J17HmjaMlb6bEwvot2xXSTmUonZ7MM+/VT0QJCEfeEHXlNdtSvGC2qqcr S0Z/EYUkg90DLVucfP0p3Li7OIC0c2V2kkrj5Ta8haq3kAfkli5TE0EtDjwPf72Un5 TYLe8q+bm/d6RpNQTR+/tMZmiY27+hOw2uOZaHcLX4+zAcVLxKTDKPp3mRIdu24omo z7hAPHl/D+9KIv9a0m3DIYdIr2bgWYaUktuK9oRnWb7MSSugcBnSoBAKPYhaQpcwKD 4mjzmDcFwE+3sPBTaPEyk1aXr1N7xhtklxNAuFZHMlvg4uQXABja7duoRH8xqto8z9 x3QECDRw4H2X2LDgc+z+uatFdgSAOqOutDGaXGd5XpOBkda2/ZZP0vWoVOqn3BRkXH Zd1IBskqQG+uC+VDeK2iHw7stVNd81BCzI4aD+K+9JVqjc/qcMKQLrrTs3O/deMcCo PGJlV2J7rgASguR1QRmXGiyM4Wo14lSQ8z9V6F5HpFRkGQ/0dVddLVqKaMuR0dA9JR 88H+jA8sh7oiEsKIPpWavsy+7OgQo+QZhTZwF7s/KspKXL9Pml8T8oesjJ4WrOwZKY MFd8G91yg2X7CN5T7ScXTMhg= X-Received: line deleted by mout Date: Wed, 26 Feb 2014 20:42:09 +0100 From: Andreas Schulze To: Paul Wouters Message-ID: <20140226194208.GA19694@solar.andreasschulze.de> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-GPG-Key-ID: 0xA7DBA67F X-GPG-Fingerprint: 14C1 39A8 CE6D 6BE0 28C6 5652 03B5 6793 A7DB A67F X-GPG-Public-Key: http://9645f8.dyndns.org/a7dba67f.asc X-Location: Germany, Earth User-Agent: mutt Archived-At: http://mailarchive.ietf.org/arch/msg/dane/3zDwbObgjMWao4q03Qhnuv02H-g Cc: dane WG list Subject: Re: [dane] An AD bit discussion 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, 26 Feb 2014 19:42:25 -0000 Paul Wouters: > I'm currently aware of two (non-dns utilities) applications that make > security decisions based on "blindly" trusting the AD bit: ssh with > VerifyHostKeyDNS=yes|ask and Postfix. opendkim could be linked with libunbound too to mark a dkim key fetched for validation as "secured" or "nonsecured" > libreswan and strongswan are examples of applications that use libunbound > for in-application DNSSEC validation to avoid needing to trust > /etc/resolv.conf DNS servers for the AD bit. opendkim too... Upon validation DKIM public keys are fetched freom DNS and the validation result is part of the Authentication-Results header. But there is no further policy decision made. > 4 In the ideal world tomorrow, each host has its own automatically > configured, perfectly working validing DNS server and resolv.conf can > be ignored or is always hardcoded with nameserver 127.0.0.1 Oh, I'm near your ideal world since years :-) $ cat /etc/resolv.conf nameserver ::1 Andreas From nobody Wed Feb 26 13:26:10 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 911A61A06BC for ; Wed, 26 Feb 2014 13:26:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.448 X-Spam-Level: X-Spam-Status: No, score=-7.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, 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 0ElD4Cju1Vac for ; Wed, 26 Feb 2014 13:26:03 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) by ietfa.amsl.com (Postfix) with ESMTP id A9B0F1A0713 for ; Wed, 26 Feb 2014 13:25:57 -0800 (PST) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.ams1.isc.org (Postfix) with ESMTP id 7CDBA238400; Wed, 26 Feb 2014 21:25:44 +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 81B2216005C; Wed, 26 Feb 2014 21:26:36 +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 5315916004A; Wed, 26 Feb 2014 21:26:36 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 26889106C669; Thu, 27 Feb 2014 08:25:40 +1100 (EST) To: Andreas Schulze From: Mark Andrews References: <20140226194208.GA19694@solar.andreasschulze.de> In-reply-to: Your message of "Wed, 26 Feb 2014 20:42:09 +0100." <20140226194208.GA19694@solar.andreasschulze.de> Date: Thu, 27 Feb 2014 08:25:40 +1100 Message-Id: <20140226212540.26889106C669@rock.dv.isc.org> Archived-At: http://mailarchive.ietf.org/arch/msg/dane/__0yqI9QfOHuBjg4Q-g3jYi50Ng Cc: Paul Wouters , dane WG list Subject: Re: [dane] An AD bit discussion 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, 26 Feb 2014 21:26:08 -0000 The history of the AD bit in responses and it meaning. RFC 1035 -> AD=0 RFC 2535 -> AD=0/1 (records gone through validation) RCC 3225 (DO introduced) RFC 3655 -> AD=0/1 (DO=1 required, answer and authority sections all secure) RFC 3755 (type code roll) RFC 4035 -> AD=0/1 (DO=1 required, answer and authority sections all secure) RFC 6840 -> AD=0/1 (DO=1 or AD=1 required, answer and authority sections all secure) -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Wed Feb 26 13:42: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 6579A1A036D for ; Wed, 26 Feb 2014 13:42:25 -0800 (PST) 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 C9Vue4aU_kJj for ; Wed, 26 Feb 2014 13:42:22 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 30DF91A02C3 for ; Wed, 26 Feb 2014 13:42:22 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 5C8A82AAD0C; Wed, 26 Feb 2014 21:42:20 +0000 (UTC) Date: Wed, 26 Feb 2014 21:42:20 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140226214220.GH21390@mournblade.imrryr.org> References: <20140226194208.GA19694@solar.andreasschulze.de> <20140226212540.26889106C669@rock.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140226212540.26889106C669@rock.dv.isc.org> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/Cs3TFDojG09SmWUuwcnEzJLyffc Subject: Re: [dane] An AD bit discussion 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: Wed, 26 Feb 2014 21:42:25 -0000 On Thu, Feb 27, 2014 at 08:25:40AM +1100, Mark Andrews wrote: > The history of the AD bit in responses and it meaning. > > RFC 1035 -> AD=0 > RFC 2535 -> AD=0/1 (records gone through validation) > RCC 3225 (DO introduced) > RFC 3655 -> AD=0/1 (DO=1 required, answer and authority sections all secure) > RFC 3755 (type code roll) > RFC 4035 -> AD=0/1 (DO=1 required, answer and authority sections all secure) > RFC 6840 -> AD=0/1 (DO=1 or AD=1 required, answer and authority sections all > secure) Thanks, this is very useful. It remains only to determine whether for platforms on which the proposed designs are being contemplated, one can reasonably expect the target (reachable securely, typically local) resolvers to support AD=1 in the query. This information seems to me to be more likely available to the administrator configuring *static* resolv.conf settings, than to an application author or user. Therefore, my gut reaction is that applications that want the AD bit need to be able to ask for it, and the stub resolver library determines how to get the job done with help from resolv.conf. The stub resolver library may be able to get away with sending AD=1 instead of DO=1 and getting a more compact reply. And may suppress RRSIG elements in the answer, authority and additional sections when the DO=1 was used because AD=1 was not known to be supported. This still leaves us with the question of how libresolv clients should signal their interest in the AD bit? At the very least the application needs to know that DNSSEC support is not simply unavailable. With RES_USE_DNSSEC #defined, the application knows that the run-time promises to send DO=1. There needs to be a similar option bit one can test for at compile-time, and use to signal that the stub-resolver library should return AD bits without RRSIGs (or with RRSIGs not specifically required if it is easier to pass them along if returned). -- Viktor. From nobody Wed Feb 26 14:51:24 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 5E1781A0762 for ; Wed, 26 Feb 2014 14:51:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 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.547, 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 CikK01DR88_b for ; Wed, 26 Feb 2014 14:51:17 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 0B3AB1A0723 for ; Wed, 26 Feb 2014 14:51:17 -0800 (PST) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 2D713C94D0 for ; Wed, 26 Feb 2014 22:51:03 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1393455075; bh=Wy9E/CCNuI6lZsHHoEOQLNucPShY/cSeS7P1575OBcQ=; h=To:From:References:Subject:In-reply-to:Date; b=iK9jLy5BtIn9zKVZbJyelmDGWCciS0Pq8VT3YytuIFrlzztUMUU0Nvxlf95EstA8O H6UyyL+DSnjd3qNvOcK6HDTIOB8ZRAVah/Zf6gxRAF1kDeohr5gvbGLnvioVGMTR+L BcWK3RR9tWuVKnfB+UO1a4N8wbadNFIjvkaTv9jk= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP for ; Wed, 26 Feb 2014 22:51:03 +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 C1B1F16005C for ; Wed, 26 Feb 2014 22:51:55 +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 9473416004A for ; Wed, 26 Feb 2014 22:51:55 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 9A0FC106CFB5 for ; Thu, 27 Feb 2014 09:50:59 +1100 (EST) To: dane@ietf.org From: Mark Andrews References: <20140226194208.GA19694@solar.andreasschulze.de> <20140226212540.26889106C669@rock.dv.isc.org> <20140226214220.GH21390@mournblade.imrryr.org> In-reply-to: Your message of "Wed, 26 Feb 2014 21:42:20 -0000." <20140226214220.GH21390@mournblade.imrryr.org> Date: Thu, 27 Feb 2014 09:50:59 +1100 Message-Id: <20140226225059.9A0FC106CFB5@rock.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Archived-At: http://mailarchive.ietf.org/arch/msg/dane/JyiaCau4WbjHWF9TA-8tJ7HTIfc Subject: Re: [dane] An AD bit discussion 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, 26 Feb 2014 22:51:20 -0000 In message <20140226214220.GH21390@mournblade.imrryr.org>, Viktor Dukhovni writ es: > On Thu, Feb 27, 2014 at 08:25:40AM +1100, Mark Andrews wrote: > > > The history of the AD bit in responses and it meaning. > > > > RFC 1035 -> AD=0 > > RFC 2535 -> AD=0/1 (records gone through validation) > > RCC 3225 (DO introduced) > > RFC 3655 -> AD=0/1 (DO=1 required, answer and authority sections all secure > ) > > RFC 3755 (type code roll) > > RFC 4035 -> AD=0/1 (DO=1 required, answer and authority sections all secure > ) > > RFC 6840 -> AD=0/1 (DO=1 or AD=1 required, answer and authority sections al > l > > secure) > > Thanks, this is very useful. It remains only to determine whether > for platforms on which the proposed designs are being contemplated, > one can reasonably expect the target (reachable securely, typically > local) resolvers to support AD=1 in the query. > > This information seems to me to be more likely available to the > administrator configuring *static* resolv.conf settings, than to > an application author or user. > > Therefore, my gut reaction is that applications that want the AD > bit need to be able to ask for it, and the stub resolver library > determines how to get the job done with help from resolv.conf. > > The stub resolver library may be able to get away with sending AD=1 > instead of DO=1 and getting a more compact reply. And may suppress > RRSIG elements in the answer, authority and additional sections when > the DO=1 was used because AD=1 was not known to be supported. > > This still leaves us with the question of how libresolv clients > should signal their interest in the AD bit? At the very least the > application needs to know that DNSSEC support is not simply > unavailable. > > With RES_USE_DNSSEC #defined, the application knows that the run-time > promises to send DO=1. There needs to be a similar option bit one > can test for at compile-time, and use to signal that the stub-resolver > library should return AD bits without RRSIGs (or with RRSIGs not > specifically required if it is easier to pass them along if returned). Setting AD isn't that hard. For DANE you aren't going to want to use res_search() to retrieve the TLSA record so this just unwraps res_query(). res_mkquery(...,query,...); query[3] |= 0x08; // set ad in request res_send(query,...); Mark > -- > 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 Wed Feb 26 15:17:00 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 999831A030C for ; Wed, 26 Feb 2014 15:16:53 -0800 (PST) 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 d6ejt5WWPDFa for ; Wed, 26 Feb 2014 15:16:51 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 1B0BD1A02F1 for ; Wed, 26 Feb 2014 15:16:51 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 737232AAC73; Wed, 26 Feb 2014 23:16:49 +0000 (UTC) Date: Wed, 26 Feb 2014 23:16:49 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140226231649.GJ21390@mournblade.imrryr.org> References: <20140226194208.GA19694@solar.andreasschulze.de> <20140226212540.26889106C669@rock.dv.isc.org> <20140226214220.GH21390@mournblade.imrryr.org> <20140226225059.9A0FC106CFB5@rock.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140226225059.9A0FC106CFB5@rock.dv.isc.org> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/AkqaXXPN40_Nb0Vl8r0_RYzzO18 Subject: Re: [dane] An AD bit discussion 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: Wed, 26 Feb 2014 23:16:53 -0000 On Thu, Feb 27, 2014 at 09:50:59AM +1100, Mark Andrews wrote: > > With RES_USE_DNSSEC #defined, the application knows that the run-time > > promises to send DO=1. There needs to be a similar option bit one > > can test for at compile-time, and use to signal that the stub-resolver > > library should return AD bits without RRSIGs (or with RRSIGs not > > specifically required if it is easier to pass them along if returned). > > Setting AD isn't that hard. For DANE you aren't going to want to use > res_search() to retrieve the TLSA record so this just unwraps res_query(). > > res_mkquery(...,query,...); > query[3] |= 0x08; // set ad in request > res_send(query,...); Thanks for the proof of concept! From an application developer perspective, I'd like to suggest that this is not terribly practical as an application interface. The decision is made in the wrong place if this is application code, rather than stub resolver internal code. For example, Postfix uses res_search for everything, including TLSA lookups, but being single-threaded, it can safely make temporary changes in _res.options before each lookup (the original value is restored when the lookup completes). #define USER_FLAGS (RES_DEBUG | RES_DNSRCH | RES_DEFNAMES | RES_USE_DNSSEC) #define XTRA_FLAGS (RES_USE_EDNS0) #define SAVE_FLAGS (USER_FLAGS | XTRA_FLAGS) saved_options = (_res.options & SAVE_FLAGS); _res.options &= ~saved_options; _res.options |= flags; len = res_search(name, C_IN, type, reply->buf, reply->buf_len); _res.options &= ~flags; _res.options |= saved_options; Here "flags" is always a subset of "saved_options" that is set for the current query, the remainder (including RES_DEFNAMES and RES_DNSRCH) are cleared, unless explicitly requested in "flags". This is about the lowest level of the libresolv API that Postfix will use. Also control over whether the right bit to send is "AD=1" in the header or "DO=1" in the OPT pseudo-header really belongs in stub resolver configuration, not in Postfix. What would make more sense, is the ability to request pre-validated responses (AD without RRSIG if possible), and have the stub-resolver, based on /etc/resolv.conf settings, figure out the best way to satisfy the request. A new RES_IGNORE_RRSIG or similar option could be used in combination with RES_USE_DNSSEC signal that an application wants "AD" in responses, but is not interested in RRSIGs (though might still get them). The library would send whichever of "AD=1" or "DO=1" is specified in resolv.conf as being supported by the designated nameservers. -- Viktor. From nobody Wed Feb 26 16:41:12 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 381141A0816 for ; Wed, 26 Feb 2014 16:41:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.547 X-Spam-Level: X-Spam-Status: No, score=-2.547 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.547] 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 iLDPr5jahZhF for ; Wed, 26 Feb 2014 16:41:03 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 799E31A074A for ; Wed, 26 Feb 2014 16:41:03 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id AFA8C80D6D; Wed, 26 Feb 2014 19:41:00 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1393461660; bh=+1XcVUmkxafxLrMHuHdPoWVWTxAXfytkzH0QQ+JDGrM=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=cyjveZkD/TFDhc0zR52UdEoPidthDcKt79G0NepUumY6Ho1IGDVIRhJYOdoVxHEYG 7zwE94NwQhw/bqzdliqd3RzYpAjo3kSAmYIa2FHTogj3M7lruhhlpzameF6YmFYLBq ZsApAcS43UamiqFVcnJ6q1Xthb3ICX2Ti8u0mB1I= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s1R0f0mI006781; Wed, 26 Feb 2014 19:41:00 -0500 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Wed, 26 Feb 2014 19:41:00 -0500 (EST) From: Paul Wouters To: James Cloos In-Reply-To: Message-ID: References: User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/dane/RahzGfzzoKvg4ZLCYps1bj-UTLc Cc: dane@ietf.org Subject: Re: [dane] An AD bit discussion 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: Thu, 27 Feb 2014 00:41:08 -0000 On Wed, 26 Feb 2014, James Cloos wrote: [ picking this answer because it brings back this thread to my question ] >>>>>> "PW" == Paul Wouters writes: > > PW> Now for my question. Until we reach 4), what should we do with the AD > PW> bit in getaddrinfo() ? > > PW> A) strip the AD bit in struct addrinfo for "untrusted nameservers". A new > PW> configuration mechanism will allow white-listing nameservers and 127.0.0.1 > PW> will always be on the whitelist. > > PW> B) do nothing > > I've always preferred a local resolver, and with dnssec a local > verifier, on every system. If there are systems unable or unwilling > to do that, then A is a reasonable compromize until they can and will. So my fear of that doing A) are negative consequences. Admins installing a rack of servers or VMs, and pointing resolv.conf to something trusted nearby, but not on localhost itself, will get the AD bit stripped without additional configuration. If those people upgrade their systems to the new A) solution, their applications will no longer see the AD bit. But so far, it seems I'm the only one worried about that case. That and I prefer solutions working on obsoleting resolv.conf over extending it and I think most cases can already be covered by running a DNS server on localhost - with the exception of laptops (dnssec-trigger+unbound does not cut it yet for non-techies) If there are more people who would like to reply to this issue specifically (as opposed to other APIs or _sending_ AD bits), that would be useful. So far it seems people are leaning towards A) over B) while everyone seems to agree doing DNSSEC on the host itself (server or in-app) is still the preferred method. Paul From nobody Wed Feb 26 17:32:07 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 89E0A1A07A0 for ; Wed, 26 Feb 2014 17:32:01 -0800 (PST) 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_40=-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 aNw7TXtuJNf9 for ; Wed, 26 Feb 2014 17:31:59 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 9814F1A07CD for ; Wed, 26 Feb 2014 17:31:59 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id F1D352AAC73; Thu, 27 Feb 2014 01:31:56 +0000 (UTC) Date: Thu, 27 Feb 2014 01:31:56 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140227013156.GL21390@mournblade.imrryr.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/2YO2QicQtq3V4dHbW49Fe9YPO5Q Subject: Re: [dane] An AD bit discussion 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, 27 Feb 2014 01:32:01 -0000 On Wed, Feb 26, 2014 at 07:41:00PM -0500, Paul Wouters wrote: > That and I prefer solutions working on obsoleting resolv.conf > over extending it and I think most cases can already be covered by > running a DNS server on localhost - with the exception of laptops > (dnssec-trigger+unbound does not cut it yet for non-techies) I think obsoleting resolv.conf would be a grave mistake. More precisely, control over the security properties of the default list of recursive resolvers needs to be by default in the hands of the party that sets up the set of resolvers. Some applications may want to tweak this, but out of the box the system administrator sets the resolver list, and designates them trusted or not. Applications that delegate validation are rarely well positioned to know all the gory details, certainly not by default. So while system configuration may default to fail safe (not lie), it should be up to the administrator, not the application user or developer to vouch for the safety of a given configuration. > So far it seems people are leaning towards A) over B) while everyone > seems to agree doing DNSSEC on the host itself (server or in-app) is > still the preferred method. Modulo some adamant administrators who insist that multiple resolvers on a physically secured firewalled LAN obviate the need for a local resolver on each machine, and desperately want to configure trust in nearby, but not on-host local resolvers. (See earlier link to postfix-users list). For them, I am proposing a damn-the-torpedoes flag in resolv.conf, global boolean, rather than a one nameserver at a time white-list. -- Viktor. From nobody Wed Feb 26 18:02: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 6D5AF1A027B for ; Wed, 26 Feb 2014 18:02:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.948 X-Spam-Level: X-Spam-Status: No, score=-1.948 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_46=0.6, RP_MATCHES_RCVD=-0.547, 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 j4O2a2Kw7kMC for ; Wed, 26 Feb 2014 18:02:46 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 5837C1A0158 for ; Wed, 26 Feb 2014 18:02:46 -0800 (PST) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id F17EFC94E0 for ; Thu, 27 Feb 2014 02:02:29 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1393466565; bh=ofeBBQHIOKqT8LQR9JY6C82GgwR9JkyLY0q8omhllYQ=; h=To:From:References:Subject:In-reply-to:Date; b=hu2rYgv7BMOJ7UNh6dhxRZ0pFLJgsElfGdWUZOO6ORfWK9Ks0nLK78AiMY4tQLmvy YhTCjebhpv2fPuMNkrnba554/UH5czzbZBs69gBEsVmcLBjXiIa17wdIzX2Qk9D97y M931yChkmY4JdqiZ+ItZR29ZPU5MOal5yrP+8R7E= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP for ; Thu, 27 Feb 2014 02:02: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 A555B16004A for ; Thu, 27 Feb 2014 02:03:22 +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 7EE7516005C for ; Thu, 27 Feb 2014 02:03:21 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 7828C1070181 for ; Thu, 27 Feb 2014 13:02:27 +1100 (EST) To: dane@ietf.org From: Mark Andrews References: <20140226194208.GA19694@solar.andreasschulze.de> <20140226212540.26889106C669@rock.dv.isc.org> <20140226214220.GH21390@mournblade.imrryr.org> <20140226225059.9A0FC106CFB5@rock.dv.isc.org> <20140226231649.GJ21390@mournblade.imrryr.org> In-reply-to: Your message of "Wed, 26 Feb 2014 23:16:49 -0000." <20140226231649.GJ21390@mournblade.imrryr.org> Date: Thu, 27 Feb 2014 13:02:27 +1100 Message-Id: <20140227020227.7828C1070181@rock.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Archived-At: http://mailarchive.ietf.org/arch/msg/dane/-_aDMU8y3hTFgo1AiSOKDVXoMtQ Subject: Re: [dane] An AD bit discussion 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: Thu, 27 Feb 2014 02:02:50 -0000 In message <20140226231649.GJ21390@mournblade.imrryr.org>, Viktor Dukhovni writ es: > On Thu, Feb 27, 2014 at 09:50:59AM +1100, Mark Andrews wrote: > > > > With RES_USE_DNSSEC #defined, the application knows that the run-time > > > promises to send DO=1. There needs to be a similar option bit one > > > can test for at compile-time, and use to signal that the stub-resolver > > > library should return AD bits without RRSIGs (or with RRSIGs not > > > specifically required if it is easier to pass them along if returned). > > > > Setting AD isn't that hard. For DANE you aren't going to want to use > > res_search() to retrieve the TLSA record so this just unwraps res_query(). > > > > res_mkquery(...,query,...); > > query[3] |= 0x08; // set ad in request > > res_send(query,...); > > Thanks for the proof of concept! From an application developer > perspective, I'd like to suggest that this is not terribly practical > as an application interface. The decision is made in the wrong place > if this is application code, rather than stub resolver internal code. It wasn't to say that it was practical or best practice. Extending options to set AD would be useful but there is no reason to wait for that to happen. > For example, Postfix uses res_search for everything, including TLSA > lookups, but being single-threaded, it can safely make temporary > changes in _res.options before each lookup (the original value is > restored when the lookup completes). Or one could use res_nsearch/res_nquery and have it work in a threaded envionment. Personally I would be using res_{n}query in a MTA to avoid any possibility of searching. > #define USER_FLAGS (RES_DEBUG | RES_DNSRCH | RES_DEFNAMES | RES_USE_DNSSEC) > #define XTRA_FLAGS (RES_USE_EDNS0) > #define SAVE_FLAGS (USER_FLAGS | XTRA_FLAGS) > saved_options = (_res.options & SAVE_FLAGS); > _res.options &= ~saved_options; > _res.options |= flags; > len = res_search(name, C_IN, type, reply->buf, reply->buf_len); > _res.options &= ~flags; > _res.options |= saved_options; > Here "flags" is always a subset of "saved_options" that is set for > the current query, the remainder (including RES_DEFNAMES and > RES_DNSRCH) are cleared, unless explicitly requested in "flags". > > This is about the lowest level of the libresolv API that Postfix > will use. Also control over whether the right bit to send is "AD=1" > in the header or "DO=1" in the OPT pseudo-header really belongs > in stub resolver configuration, not in Postfix. res_search and res_query are on the same level. len = res_search(name, C_IN, type, reply->buf, reply->buf_len); len = res_query(name, C_IN, type, reply->buf, reply->buf_len); Additionally res_search should only proceed to the next name on NXDOMAIN. Currently it is type sensitive which is a hold over from the when always appended the first search element regardless of the number of labels in it and handling wildcard MX records. If you had a MX record like *.element.in.search.list MX 0 some.server you didn't want to stop a search for A records for foo.example.net. > What would make more sense, is the ability to request pre-validated > responses (AD without RRSIG if possible), and have the stub-resolver, > based on /etc/resolv.conf settings, figure out the best way to > satisfy the request. > > A new RES_IGNORE_RRSIG or similar option could be used in combination > with RES_USE_DNSSEC signal that an application wants "AD" in > responses, but is not interested in RRSIGs (though might still > get them). The library would send whichever of "AD=1" or "DO=1" > is specified in resolv.conf as being supported by the designated > nameservers. > > -- > 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 Wed Feb 26 18:18:44 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 1E80F1A07C1 for ; Wed, 26 Feb 2014 18:18:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_46=0.6] 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 DqhoPj52HnIe for ; Wed, 26 Feb 2014 18:18:39 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id A548C1A0686 for ; Wed, 26 Feb 2014 18:18:39 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 3A28F2AAD0C; Thu, 27 Feb 2014 02:18:38 +0000 (UTC) Date: Thu, 27 Feb 2014 02:18:38 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140227021838.GM21390@mournblade.imrryr.org> References: <20140226194208.GA19694@solar.andreasschulze.de> <20140226212540.26889106C669@rock.dv.isc.org> <20140226214220.GH21390@mournblade.imrryr.org> <20140226225059.9A0FC106CFB5@rock.dv.isc.org> <20140226231649.GJ21390@mournblade.imrryr.org> <20140227020227.7828C1070181@rock.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140227020227.7828C1070181@rock.dv.isc.org> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/5EuxGlz7gG2EecwciT_Q2QzrHyM Subject: Re: [dane] An AD bit discussion 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, 27 Feb 2014 02:18:41 -0000 On Thu, Feb 27, 2014 at 01:02:27PM +1100, Mark Andrews wrote: > Additionally res_search should only proceed to the next name on > NXDOMAIN. Currently it is type sensitive which is a hold over from > the when always appended the first search element regardless of the > number of labels in it and handling wildcard MX records. If you had > a MX record like > > *.element.in.search.list MX 0 some.server > > you didn't want to stop a search for A records for foo.example.net. Looking at somewhat recent NetBSD source: switch (statp->res_h_errno) { case NO_DATA: got_nodata++; /* FALLTHROUGH */ case HOST_NOT_FOUND: /* keep trying */ break; case TRY_AGAIN: if (hp->rcode == SERVFAIL) { /* try next search element, if any */ got_servfail++; break; } /* FALLTHROUGH */ default: /* anything else implies that we're done */ done++; } we see that searching continues with NXDOMAIN, NODATA, and also SERVFAIL! As no tracking of the security status of NXDOMAIN or NODATA takes place, unaware applications can get false "secure" results when RES_DNSRCH is enabled. I don't know how the new "getdns" handles mixing of DNSSEC and appending suffixes. -- Viktor. From nobody Wed Feb 26 18:23:59 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 8FCD91A0806 for ; Wed, 26 Feb 2014 18:23:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.141 X-Spam-Level: X-Spam-Status: No, score=-0.141 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] 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 GtF16_k288O9 for ; Wed, 26 Feb 2014 18:23:51 -0800 (PST) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 8442F1A07C1 for ; Wed, 26 Feb 2014 18:23:51 -0800 (PST) Received: from mx1.yitter.info (c-75-69-155-67.hsd1.nh.comcast.net [75.69.155.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id E07C18A031 for ; Thu, 27 Feb 2014 02:23:49 +0000 (UTC) Date: Wed, 26 Feb 2014 21:23:48 -0500 From: Andrew Sullivan To: dane@ietf.org Message-ID: <20140227022347.GC73737@mx1.yitter.info> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/2CE0BLOOze61x5xkgPQ8fyphzCk Subject: Re: [dane] An AD bit discussion 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: Thu, 27 Feb 2014 02:23:54 -0000 On Wed, Feb 26, 2014 at 07:41:00PM -0500, Paul Wouters wrote: > seems to agree doing DNSSEC on the host itself (server or in-app) is > still the preferred method. Is Micorosoft's method still to prefer the AD bit from the server, but use IPSec between the clients and the servers? That would seem to be similar to your concern. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Wed Feb 26 19:16:51 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 5E42C1A01A9 for ; Wed, 26 Feb 2014 19:16:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.448 X-Spam-Level: X-Spam-Status: No, score=-7.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, 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 pJe02YRZUteT for ; Wed, 26 Feb 2014 19:16:45 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) by ietfa.amsl.com (Postfix) with ESMTP id 5D37C1A015C for ; Wed, 26 Feb 2014 19:16:45 -0800 (PST) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.ams1.isc.org (Postfix) with ESMTP id 910652383A7; Thu, 27 Feb 2014 03:16:31 +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 B68E516004C; Thu, 27 Feb 2014 03:17:23 +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 8662416004A; Thu, 27 Feb 2014 03:17:23 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id B4A1610765F9; Thu, 27 Feb 2014 14:16:28 +1100 (EST) To: Andrew Sullivan From: Mark Andrews References: <20140227022347.GC73737@mx1.yitter.info> In-reply-to: Your message of "Wed, 26 Feb 2014 21:23:48 -0500." <20140227022347.GC73737@mx1.yitter.info> Date: Thu, 27 Feb 2014 14:16:28 +1100 Message-Id: <20140227031628.B4A1610765F9@rock.dv.isc.org> Archived-At: http://mailarchive.ietf.org/arch/msg/dane/th7ILJ2ZbDNuvPuc9NzG7GsUpGw Cc: dane@ietf.org Subject: Re: [dane] An AD bit discussion 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: Thu, 27 Feb 2014 03:16:47 -0000 In message <20140227022347.GC73737@mx1.yitter.info>, Andrew Sullivan writes: > On Wed, Feb 26, 2014 at 07:41:00PM -0500, Paul Wouters wrote: > > seems to agree doing DNSSEC on the host itself (server or in-app) is > > still the preferred method. > > Is Micorosoft's method still to prefer the AD bit from the server, but > use IPSec between the clients and the servers? That would seem to be > similar to your concern. Blindly trusting AD from anything other than 127.0.0.1 / ::1 is asking for trouble even if IPsec is being used. The problem is that you still need to trust the server and anything over the net should be untrusted by default. Adding a trusted key clause to resolv.conf would work e.g. trusted-key start-date end-date . 257 3 8 "AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjFFVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoXbfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaDX6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpzW5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relSQageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulqQxA+Uk1ihz0=" Better still would be a RFC 5011 replacement that published START and END dates along with a poll frequency for keys that should be used as trust anchors along with the key material. The START and END dates would be updated periodically. RFC 5011 is a grose hack. We can do significantly better. It the trusted-key clauses haven't been updated before the end date the validator ignores the trusted key if there are no trusted-key clauses clauses left you treat everything as insecure. > Best, > > A > > -- > Andrew Sullivan > ajs@anvilwalrusden.com > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Wed Feb 26 19:47:33 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 952D11A069A for ; Wed, 26 Feb 2014 19:47:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.559 X-Spam-Level: ** X-Spam-Status: No, score=2.559 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] 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 2PcmWyr0ZYCZ for ; Wed, 26 Feb 2014 19:47:30 -0800 (PST) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 5CE231A037C for ; Wed, 26 Feb 2014 19:47:30 -0800 (PST) Received: from mx1.yitter.info (c-75-69-155-67.hsd1.nh.comcast.net [75.69.155.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 975188A031 for ; Thu, 27 Feb 2014 03:47:28 +0000 (UTC) Date: Wed, 26 Feb 2014 22:47:23 -0500 From: Andrew Sullivan To: dane@ietf.org Message-ID: <20140227034723.GA73861@mx1.yitter.info> References: <20140227022347.GC73737@mx1.yitter.info> <20140227031628.B4A1610765F9@rock.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140227031628.B4A1610765F9@rock.dv.isc.org> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/D3MpVmMcpEFKlOeiXyJbrmJ9d9U Subject: Re: [dane] An AD bit discussion 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: Thu, 27 Feb 2014 03:47:31 -0000 Hi, On Thu, Feb 27, 2014 at 02:16:28PM +1100, Mark Andrews wrote: > Blindly trusting AD from anything other than 127.0.0.1 / ::1 is > asking for trouble even if IPsec is being used. The problem is > that you still need to trust the server and anything over the net > should be untrusted by default. While I'm pleased as ever to know your personal preferences in this matter, what I was asking was for information about what Microsoft is actually shipping, and you seem not to have replied to that question at all. But I am not sure about your assertion about "should" above, in at least some scenarios: I think that's exactly what we're discussing, so you can't just say that one of the possibilities is the right answer (that would be circular). As I understood the deployment model implicit in what Microsoft shipped (at least in the past), you were not "blindly" trusting the server, but trusting the server that gave you your IP address, your definition within the local SMB domain, and so on. In other words, _not_ trusting the server in question is functionally equivalent to "doesn't work", so the threat model you have in the above is completely misaligned with the deployment scenario that I think was implicit in the product Microsoft shipped. This is the reason for the reliance on IPSec. I believe that that product was entirely consistent with the DNSSEC specifications (though it might be subject to certain kinds of attacks if the attacker can take over the relevant server). I think that it is quite similar to the issue that Paul was raising with his "virtual servers" scenario. In some virtualized environment, if you can't trust other systems that share the same physical hardware as you, you're hosed anyway. Additional protection is going to get you nothing, and in that case as Paul was arguing it's better to have the default provide more rather than less protection, even if that "protection" is completely bogus under some other scenarios. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Wed Feb 26 20:18:15 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 733221A0380 for ; Wed, 26 Feb 2014 20:18:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 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.547, 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 JejT4NymsVVp for ; Wed, 26 Feb 2014 20:18:12 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id EA2E11A03D6 for ; Wed, 26 Feb 2014 20:18:11 -0800 (PST) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id CFEC7C9424; Thu, 27 Feb 2014 04:17:56 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1393474690; bh=s/Ytzbz/3um78Dxxx4SjzCTA9WZPCb5EQW6bXNpBdYU=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=BC1d/xwp/sZD6CIFYLyfK0A+JBlHnt3WC+LUfk4ekLTYX92IK10ZvrWP062fvY0OV sxVD8fv5fZ5eKDkLJelupoJviAjoWPH+uwgbjq6sF27esgpBxkL/PUts4BevbbgZtf 3EJU0OvXHhT+w5megFBKtKVphskBe9/YOnwCyJZQ= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Thu, 27 Feb 2014 04:17:56 +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 8A5AE16004C; Thu, 27 Feb 2014 04:18:49 +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 5ACAF16004A; Thu, 27 Feb 2014 04:18:48 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 3509810773A8; Thu, 27 Feb 2014 15:17:53 +1100 (EST) To: Andrew Sullivan From: Mark Andrews References: <20140227022347.GC73737@mx1.yitter.info> <20140227031628.B4A1610765F9@rock.dv.isc.org> <20140227034723.GA73861@mx1.yitter.info> In-reply-to: Your message of "Wed, 26 Feb 2014 22:47:23 -0500." <20140227034723.GA73861@mx1.yitter.info> Date: Thu, 27 Feb 2014 15:17:53 +1100 Message-Id: <20140227041753.3509810773A8@rock.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Archived-At: http://mailarchive.ietf.org/arch/msg/dane/Uj-IeTbBrK_XuWNeDUX1TZwbzdQ Cc: dane@ietf.org Subject: Re: [dane] An AD bit discussion 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: Thu, 27 Feb 2014 04:18:13 -0000 In message <20140227034723.GA73861@mx1.yitter.info>, Andrew Sullivan writes: > Hi, > > On Thu, Feb 27, 2014 at 02:16:28PM +1100, Mark Andrews wrote: > > > Blindly trusting AD from anything other than 127.0.0.1 / ::1 is > > asking for trouble even if IPsec is being used. The problem is > > that you still need to trust the server and anything over the net > > should be untrusted by default. > > While I'm pleased as ever to know your personal preferences in this > matter, what I was asking was for information about what Microsoft is > actually shipping, and you seem not to have replied to that question > at all. But I am not sure about your assertion about "should" above, > in at least some scenarios: I think that's exactly what we're > discussing, so you can't just say that one of the possibilities is the > right answer (that would be circular). > > As I understood the deployment model implicit in what Microsoft > shipped (at least in the past), you were not "blindly" trusting the > server, but trusting the server that gave you your IP address, your > definition within the local SMB domain, and so on. In other words, > _not_ trusting the server in question is functionally equivalent to > "doesn't work", so the threat model you have in the above is > completely misaligned with the deployment scenario that I think was > implicit in the product Microsoft shipped. This is the reason for the > reliance on IPSec. I believe that that product was entirely > consistent with the DNSSEC specifications (though it might be subject > to certain kinds of attacks if the attacker can take over the relevant > server). Just because a server gave you IP addresses doesn't make it trust worthy for DNSSEC. Just because a server gave you credentials which allow you to register is AD doesn't make it trust worthy for DNSSEC. You can trust something for A but not B. Now you can tell a machine if you get A you should also trust it for B but one should be very careful about it. As for not working, if you don't trust the AD bit you are left with the status quo, which isn't everything is not working. I walk into a coffee shop. I get a address. I manage to get IPsec running between the server and myself because both ends are configured for opportunistic IPsec. This does not mean I should trust the AD bit. > I think that it is quite similar to the issue that Paul was raising > with his "virtual servers" scenario. In some virtualized environment, > if you can't trust other systems that share the same physical hardware > as you, you're hosed anyway. Additional protection is going to get > you nothing, and in that case as Paul was arguing it's better to have > the default provide more rather than less protection, even if that > "protection" is completely bogus under some other scenarios. > > Best regards, > > A > > -- > Andrew Sullivan > ajs@anvilwalrusden.com > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Wed Feb 26 20:23:47 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 09BA11A0726 for ; Wed, 26 Feb 2014 20:23:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.758 X-Spam-Level: * X-Spam-Status: No, score=1.758 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] 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 OaKU1Fj1KFPV for ; Wed, 26 Feb 2014 20:23:44 -0800 (PST) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id D25C21A0246 for ; Wed, 26 Feb 2014 20:23:44 -0800 (PST) Received: from mx1.yitter.info (c-75-69-155-67.hsd1.nh.comcast.net [75.69.155.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id D5B148A031 for ; Thu, 27 Feb 2014 04:23:42 +0000 (UTC) Date: Wed, 26 Feb 2014 23:23:35 -0500 From: Andrew Sullivan To: dane@ietf.org Message-ID: <20140227042335.GA1726@mx1.yitter.info> References: <20140227022347.GC73737@mx1.yitter.info> <20140227031628.B4A1610765F9@rock.dv.isc.org> <20140227034723.GA73861@mx1.yitter.info> <20140227041753.3509810773A8@rock.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140227041753.3509810773A8@rock.dv.isc.org> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/dNNY7f_vtDazemxwMobVISOG2Wo Subject: Re: [dane] An AD bit discussion 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: Thu, 27 Feb 2014 04:23:46 -0000 On Thu, Feb 27, 2014 at 03:17:53PM +1100, Mark Andrews wrote: > I walk into a coffee shop. I get a address. I manage to get IPsec > running between the server and myself because both ends are configured > for opportunistic IPsec. What does that have to do with the deployment scenario I was asking about in the Microsoft case, or the one I understood Paul to be asking about? Those cases are entirely to do with managed infrastructure, and the question is, _if_ you have that kind of managed infrastructure scenario and _if_ you accept that someone could subvert your management model (but you don't care because if they can do that then you're screwed anyway), then is there any value in the AD bit? I think the answer is, "Maybe," but we're never going to sort that out if people persist with arguments about scenarios that have nothing to do with the one under discussion. Yes, you should not trust the AD bit from random parts of the Internet or opportunistic IPsec or whatever. But that's not the case we're talking about, I think. A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Wed Feb 26 20:29: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 65F7F1A0284 for ; Wed, 26 Feb 2014 20:29:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 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.547, 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 AN6o350rw3WZ for ; Wed, 26 Feb 2014 20:29:49 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id E7DC51A027A for ; Wed, 26 Feb 2014 20:29:49 -0800 (PST) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 779BBC9424; Thu, 27 Feb 2014 04:29:35 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1393475388; bh=mqqjbE3n21NhhN1LaJoiqHOu3KW2X4lcLhceLe2BdJI=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=mluFrTfcO3kHARWd98TiUFJvkkPDWlyopCUQ1mzQSxc8L6oLc2ZGZvSACG6roHonZ K71RJG8Ru3YbonYIDWQ66WTgJ7ZgdVx6MZNUN94MT1pDjlv7cukPz8FXT3hOXXjSAd i1ifrF16H6jj8aEY6/4gIg6Kvk51euQr6ymSDK9c= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Thu, 27 Feb 2014 04:29:35 +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 345BA16004C; Thu, 27 Feb 2014 04:30:28 +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 03CA016004A; Thu, 27 Feb 2014 04:30:28 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 15C4610785F3; Thu, 27 Feb 2014 15:29:33 +1100 (EST) To: Andrew Sullivan From: Mark Andrews References: <20140227022347.GC73737@mx1.yitter.info> <20140227031628.B4A1610765F9@rock.dv.isc.org> <20140227034723.GA73861@mx1.yitter.info> <20140227041753.3509810773A8@rock.dv.isc.org> <20140227042335.GA1726@mx1.yitter.info> In-reply-to: Your message of "Wed, 26 Feb 2014 23:23:35 -0500." <20140227042335.GA1726@mx1.yitter.info> Date: Thu, 27 Feb 2014 15:29:33 +1100 Message-Id: <20140227042933.15C4610785F3@rock.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Archived-At: http://mailarchive.ietf.org/arch/msg/dane/RGyapIeP_fJEByvHdvLkG2eFc7Q Cc: dane@ietf.org Subject: Re: [dane] An AD bit discussion 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: Thu, 27 Feb 2014 04:29:51 -0000 In message <20140227042335.GA1726@mx1.yitter.info>, Andrew Sullivan writes: > On Thu, Feb 27, 2014 at 03:17:53PM +1100, Mark Andrews wrote: > > I walk into a coffee shop. I get a address. I manage to get IPsec > > running between the server and myself because both ends are configured > > for opportunistic IPsec. > > What does that have to do with the deployment scenario I was asking > about in the Microsoft case, or the one I understood Paul to be asking > about? Those cases are entirely to do with managed infrastructure, > and the question is, _if_ you have that kind of managed infrastructure > scenario and _if_ you accept that someone could subvert your > management model (but you don't care because if they can do that then > you're screwed anyway), then is there any value in the AD bit? I > think the answer is, "Maybe," but we're never going to sort that out > if people persist with arguments about scenarios that have nothing to > do with the one under discussion. > > Yes, you should not trust the AD bit from random parts of the Internet > or opportunistic IPsec or whatever. But that's not the case we're > talking about, I think. s/coffee shop/BYOD and access to the AD DOMAIN resources/ Should you still trust the nameservers to not corrupt DNS responses? My answer to that is NO, by default. If MS have the machines configured to do that by default they are leaving the owner of the machine exposed. > A > > -- > Andrew Sullivan > ajs@anvilwalrusden.com > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Wed Feb 26 20:42: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 CDC0B1A06B8 for ; Wed, 26 Feb 2014 20:42:17 -0800 (PST) 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 28I-Ort3M_Qy for ; Wed, 26 Feb 2014 20:42:15 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id BC24A1A03F5 for ; Wed, 26 Feb 2014 20:42:15 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id EFBC22AAD0C; Thu, 27 Feb 2014 04:42:13 +0000 (UTC) Date: Thu, 27 Feb 2014 04:42:13 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140227044213.GO21390@mournblade.imrryr.org> References: <20140227022347.GC73737@mx1.yitter.info> <20140227031628.B4A1610765F9@rock.dv.isc.org> <20140227034723.GA73861@mx1.yitter.info> <20140227041753.3509810773A8@rock.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140227041753.3509810773A8@rock.dv.isc.org> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/QH9ijhOOa2XBc65gYJ6X2P30ZLo Subject: Re: [dane] An AD bit discussion 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, 27 Feb 2014 04:42:18 -0000 On Thu, Feb 27, 2014 at 03:17:53PM +1100, Mark Andrews wrote: > I walk into a coffee shop. I get a address. I manage to get IPsec > running between the server and myself because both ends are configured > for opportunistic IPsec. This does not mean I should trust the AD > bit. We are starting to veer off-track. The original discussion is about stub resolver policy choices, which I read to be broadly: - Sensible defaults absent any configuration to the contrary? - Where should non-default configuration be specified? * System configuration files? * Application? * Both? - What mechanisms are appropriate for stub-resolver users to express the application security requirements (AD only, AD + RRSIGs for in-application validation)? It sounds like there is no strong objection to defaulting to no trust. Either there is a default white-list of trusted nameservers (127.1, ::1) or the administrator has to explicitly bless the full list in /etc/resolv.conf. I've not heard many clear preferences from others in one direction or the other. I personally, prefer a global "trust the nameserver list" predicate over a white-list. I am hoping that folks here agree that generally the person or program that writes /etc/resolv.conf is in a better position to set the default policy than most applications, and so the stub resolver should takes its cues from /etc/resolv.conf first. Naturally, given appropriate APIs, applications may be able to override this. Thus an application that sets the nameserver list explicitly and then asks for the AD bit, should reasonably expect that its chosen list will not be second-guessed by the stub resolver library. Beyond that are API design issues, for specifying the application's desire for AD only, AD + RRSIGs. It would be best in libresolv to include support for res_ninit(), res_nsearch(), res_setservers() and so on. Support for "getdns" would be nice if deemed ready to be a libresolv replacement or alternative. So likely RedHat should proceed with extensions to resolv.conf to express the trust status of the nameserver list, and improvements to libresolv. The default stub-resolver policy can reasonably be non-trust of all nameservers (typically from DHCP). Applications should be aware that mixing DNSSEC with RES_DNSRCH is likely non-deterministic and unsafe. While RES_DEFNAMES may be less problematic, it still should be avoided. Applications that need to process the security status of particular RRsets, should be particular about those RRsets and specify then precisely. It may be more prudent to use res_[n]query() rather than res_search(). -- Viktor. From nobody Wed Feb 26 21:30: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 79FF61A03D4 for ; Wed, 26 Feb 2014 21:30:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.547 X-Spam-Level: X-Spam-Status: No, score=-2.547 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.547] 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 OE0-EeEr5AlA for ; Wed, 26 Feb 2014 21:30:02 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 0BA271A02CE for ; Wed, 26 Feb 2014 21:30:01 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 5167F80D7E for ; Thu, 27 Feb 2014 00:29:58 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1393478998; bh=lglVGsOc1fHnPIW25LN9ab35eJVAa8RxRAZk/hURio8=; h=Date:From:To:Subject:In-Reply-To:References; b=EoTH8a+FpE7HaIdRsi5rT+CRfIDAEa/+iVfJmb+1gIC1KPyOS8OifKtfG1GWFI4Sw j28WKsleUGq6Zrh3vGqsK9KK8MQ7wL16D8a1eDqVrq2Ru6Ldw8HQRYPAvOA7JEF0PL i8zF356BQfh+WD/VOSMeWXCG8ZBmlyveurHPNAjs= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s1R5TvWA012572 for ; Thu, 27 Feb 2014 00:29:57 -0500 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Thu, 27 Feb 2014 00:29:57 -0500 (EST) From: Paul Wouters To: dane@ietf.org In-Reply-To: <20140227044213.GO21390@mournblade.imrryr.org> Message-ID: References: <20140227022347.GC73737@mx1.yitter.info> <20140227031628.B4A1610765F9@rock.dv.isc.org> <20140227034723.GA73861@mx1.yitter.info> <20140227041753.3509810773A8@rock.dv.isc.org> <20140227044213.GO21390@mournblade.imrryr.org> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/dane/-_CgJ4_LqIGIljNEo-hxZcXYf30 Subject: Re: [dane] An AD bit discussion 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: Thu, 27 Feb 2014 05:30:04 -0000 On Thu, 27 Feb 2014, Viktor Dukhovni wrote: > It sounds like there is no strong objection to defaulting to no > trust. Well, Andrew and I voiced concerns about breaking current common deployments. > So likely RedHat should proceed with extensions to resolv.conf to > express the trust status of the nameserver list, and improvements > to libresolv. The default stub-resolver policy can reasonably be > non-trust of all nameservers (typically from DHCP). But it is so much better for all server installs to just install a validating resolver, point resolv.conf to localhost, and use the DHCP obtained DNS servers (or admin configured DNS servers) as forwarders. Then all applications can trust the AD bit. That's a simply a reality that's possible today. Even upgrading machines to this is not that hard. The only really difficult case is the roaming device that has to deal with captive portals. dnssec-trigger+unbound isn't cutting it for the average user yet. While the glibc change would protect them, without dnssec-trigger+unbound they are in a complete insecure dns mess anyway, that I think a bogus AD flag is the least of the trouble. That's why I'm not really in favour of adding legacy to glibc or resolv.conf. Especially because there are also so few applications that actually do anything with AD bits, plus we are still working on API and DNSOP documents on how to improve/secure the DNS transport for talking to remote servers. Paul From nobody Wed Feb 26 21:46:22 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 97BBA1A0409 for ; Wed, 26 Feb 2014 21:46:20 -0800 (PST) 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 VcTG1PmZHoIY for ; Wed, 26 Feb 2014 21:46:19 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id DA3D51A01B3 for ; Wed, 26 Feb 2014 21:46:18 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 27FFB2AAD0C; Thu, 27 Feb 2014 05:46:17 +0000 (UTC) Date: Thu, 27 Feb 2014 05:46:17 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140227054617.GP21390@mournblade.imrryr.org> References: <20140227022347.GC73737@mx1.yitter.info> <20140227031628.B4A1610765F9@rock.dv.isc.org> <20140227034723.GA73861@mx1.yitter.info> <20140227041753.3509810773A8@rock.dv.isc.org> <20140227044213.GO21390@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.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/iYWzSexXTuYOg_sDJZs7Uqik7Wg Subject: Re: [dane] An AD bit discussion 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, 27 Feb 2014 05:46:20 -0000 On Thu, Feb 27, 2014 at 12:29:57AM -0500, Paul Wouters wrote: > >So likely RedHat should proceed with extensions to resolv.conf to > >express the trust status of the nameserver list, and improvements > >to libresolv. The default stub-resolver policy can reasonably be > >non-trust of all nameservers (typically from DHCP). > > But it is so much better for all server installs to just install a > validating resolver, point resolv.conf to localhost, and use the DHCP > obtained DNS servers (or admin configured DNS servers) as forwarders. > > Then all applications can trust the AD bit. That's a simply a reality > that's possible today. Even upgrading machines to this is not that hard. Yes, up-thread, this my ideal future world too. > That's why I'm not really in favour of adding legacy to glibc or > resolv.conf. Especially because there are also so few applications that > actually do anything with AD bits, plus we are still working on API and > DNSOP documents on how to improve/secure the DNS transport for talking > to remote servers. But what to do when things are not ideal, perhaps because someone disagrees with our ideal. How do we let them assert that AD should be trusted? One could always trust AD, and leave up to the platform vendor and system administrator to make it so. Or one could default to not trust AD unless resolv.conf says so, and the out-of-the-box "experience" could be made to include a 127.1 nameserver and the the right new predicate in /etc/resolv.conf, and glue to have DHCP tweak forwarders (subject to relevant DHCP configuration) rather than mess with resolv.conf (much better for reasons beyond DNSSEC IMHO). Then it is up to adventurous administrators to mess this up. Some will want to bless "remote" resolvers, that we might not want to bless by default. As to the question of whether always trusting AD when the recursive resolvers are not "secure" is OK? I don't know. Depends what applications do with that trust. For Postfix with "smtp_tls_security_level = dane", the worst thing that happens is misleading logs that claim more security than you got. Postfix also has a "dane-only" security level, for folks who want stronger security to designated destinations. In this case trusting an "insecure" AD bit is not so good. This said, the Postfix administrator is assumed to be involved in administration of the platform it runs on (needs root for various Postfix activities anyway). So Postfix always trusts AD, and documents that it is the administrators job to ensure that this is justified. Can you take the same view across all future applications? Or is more caution warranted? I'm reluctant to claim that good enough for Postfix, is good enough for everything... -- Viktor. From nobody Thu Feb 27 05:15:27 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 3A87D1A026D for ; Thu, 27 Feb 2014 05:15:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.049 X-Spam-Level: X-Spam-Status: No, score=-6.049 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, 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 IGIHOnTUXd6M for ; Thu, 27 Feb 2014 05:15:22 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id C807D1A021A for ; Thu, 27 Feb 2014 05:15:22 -0800 (PST) Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s1RDFJJc026599 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 27 Feb 2014 08:15:20 -0500 Received: from pspacek.brq.redhat.com (pspacek.brq.redhat.com [10.34.4.156]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s1RDFHVK024821 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Thu, 27 Feb 2014 08:15:19 -0500 Message-ID: <530F3A64.2000001@redhat.com> Date: Thu, 27 Feb 2014 14:15:16 +0100 From: Petr Spacek Organization: Red Hat User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: dane@ietf.org References: <20140227022347.GC73737@mx1.yitter.info> <20140227031628.B4A1610765F9@rock.dv.isc.org> <20140227034723.GA73861@mx1.yitter.info> <20140227041753.3509810773A8@rock.dv.isc.org> <20140227044213.GO21390@mournblade.imrryr.org> <20140227054617.GP21390@mournblade.imrryr.org> In-Reply-To: <20140227054617.GP21390@mournblade.imrryr.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/jQCfm37Nw-fu-0HIg9KsR9ktS_I Subject: Re: [dane] An AD bit discussion 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: Thu, 27 Feb 2014 13:15:25 -0000 On 27.2.2014 06:46, Viktor Dukhovni wrote: > On Thu, Feb 27, 2014 at 12:29:57AM -0500, Paul Wouters wrote: >>> So likely RedHat should proceed with extensions to resolv.conf to >>> express the trust status of the nameserver list, and improvements >>> to libresolv. The default stub-resolver policy can reasonably be Note that we don't want to hack resolvers in Red Hat's software. We really want to reach a consensus about this problem so we (Red Hat) can work upstream with stub-resolver developers to add support for the new behavior as designed here. Please do not limit the discussion to glibc/libresolv/ldns/anything else. We are interested in resolver-behavior in general not in one particular implementation. >>> non-trust of all nameservers (typically from DHCP). >> >> But it is so much better for all server installs to just install a >> validating resolver, point resolv.conf to localhost, and use the DHCP >> obtained DNS servers (or admin configured DNS servers) as forwarders. >> >> Then all applications can trust the AD bit. That's a simply a reality >> that's possible today. Even upgrading machines to this is not that hard. > > Yes, up-thread, this my ideal future world too. Sure, this is ideal, it is absolutely clear that (local) validating resolver is the best option (when possible). Now we need to discuss 'a temporary solution' for the case where a validating resolver is not available for whatever reason. Please let's concentrate on following situation: - Crypto libraries like GnuTLS/OpenSSL/NSS have DANE support compiled and enabled by default out-of-the-box. - GnuTLS/OpenSSL/NSS libraries use AD bit as received from stub-resolver. - A random application (e.g. Firefox/Thunderbird/offlineimap) use DANE-enabled crypto library and have no clue about DNSSEC. (That is what we want, right? Just use it without modifying all crypto-enabled applications in the world!) - The whole set is running on machine with plain stub-resolver without validator. Result => It is completely insecure because attacker can use DANE for effective man-in-the-middle attack: The crypto library will trust to fake TLSA records because attacker send fake TLSA record with AD=1. One opinion is 'use a new shiny API for DNS and do not hack existing resolver APIs' and the other option is to 'do validation yourself'. I'm afraid that this do not belong to category 'temporary solution'. It can take too long to design API, then to develop libraries and then *to convince application developers to use this new API*. I definitely agree that old resolver from BIND8 is "not the best" but we have to count with existing applications. It is easier to push small patches like - res_init() + res_init_trusted() It is *much much* harder to push patches rewriting code related to DNS to some completely new library. We want to add DANE support to existing applications not only to new ones. The proposed approach with a new initialization call (*for example* res_init_trusted()) have two (desired) side-effects: - It prevents an application relaying on AD bit from running on old system which does not guarantee trustworthiness of the AD bit. Otherwise we would have to invent some way how to check at run-time that special handling for AD bit is supported. (Think about cases where application was compiled on newer system and somebody tries to run it on older system etc.) - It doesn't affect applications which do not care/do not use new initialization call. For example current software like Postfix or OpenSSH client will 'just work' without any change. AD bit will be handled in special way only if the resolver library is initialized with the new call. >> That's why I'm not really in favour of adding legacy to glibc or >> resolv.conf. Especially because there are also so few applications that >> actually do anything with AD bits, plus we are still working on API and The main idea is 'to make DNSSEC easy for application developers - today'. It doesn't surprise me that very few applications use AD bit because nowadays it requires adding a new configuration option "resolver is un/trusted" to the application. It is not easy neither for programmer nor for administrator. >> DNSOP documents on how to improve/secure the DNS transport for talking >> to remote servers. I'm sorry, this also sounds like a long-term plan. We are looking for something workable today. The plan is to push DANE support as much as possible and as soon as possible - not to wait (potentially long time) for standardization and adoption of new APIs etc. > But what to do when things are not ideal, perhaps because someone > disagrees with our ideal. How do we let them assert that AD should > be trusted? > > One could always trust AD, and leave up to the platform vendor and > system administrator to make it so. Or one could default to not > trust AD unless resolv.conf says so, and the out-of-the-box > "experience" could be made to include a 127.1 nameserver and the > the right new predicate in /etc/resolv.conf, and glue to have DHCP > tweak forwarders (subject to relevant DHCP configuration) rather > than mess with resolv.conf (much better for reasons beyond DNSSEC > IMHO). > > Then it is up to adventurous administrators to mess this up. Some > will want to bless "remote" resolvers, that we might not want > to bless by default. > > As to the question of whether always trusting AD when the recursive > resolvers are not "secure" is OK? I don't know. Depends what > applications do with that trust. Please see the example with DANE-enabled crypto library above. Have a nice day! -- Petr^2 Spacek From nobody Thu Feb 27 08:40: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 742D81A0348 for ; Thu, 27 Feb 2014 08:40:20 -0800 (PST) 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 5QDxMjfGzwlr for ; Thu, 27 Feb 2014 08:40:18 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id C36491A03B4 for ; Thu, 27 Feb 2014 08:40:17 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id BADD72AAC73; Thu, 27 Feb 2014 16:40:14 +0000 (UTC) Date: Thu, 27 Feb 2014 16:40:14 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140227164014.GT21390@mournblade.imrryr.org> References: <20140227022347.GC73737@mx1.yitter.info> <20140227031628.B4A1610765F9@rock.dv.isc.org> <20140227034723.GA73861@mx1.yitter.info> <20140227041753.3509810773A8@rock.dv.isc.org> <20140227044213.GO21390@mournblade.imrryr.org> <20140227054617.GP21390@mournblade.imrryr.org> <530F3A64.2000001@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <530F3A64.2000001@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/2Xq1AJusBvCWP_9RhzXWlZro4Nw Subject: Re: [dane] An AD bit discussion 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, 27 Feb 2014 16:40:20 -0000 On Thu, Feb 27, 2014 at 02:15:16PM +0100, Petr Spacek wrote: > Please let's concentrate on following situation: > - Crypto libraries like GnuTLS/OpenSSL/NSS have DANE support > compiled and enabled by default out-of-the-box. The enabled by default part would be most likely. It is not up to the libraries to enable DANE support. They don't know which application protocol they're riding on top of, and how/whether DANE applies to that application protocol. For example, DANE for SMTP will be rather different from DANE for various other app-layer protocols. For example SMTP adds the MX domains to the list of valid peer names to be found in an MX host certificate. SMTP does not support usages 0/1, ... At this time 2 of the above libraries have no DANE support, and GnuTLS DANE support is substantially incomplete (TLSA trust anchors must be immediate issuers of the leaf certificate, and possibly other limitations). > - GnuTLS/OpenSSL/NSS libraries use AD bit as received from stub-resolver. Which stub resolver API would you suggest they use? Given the multiplicity of interfaces, and the fact that applications may want an asynchronous DNS interface, but none is as yet as entrenched as libresolv, I would expect these toolkits to punt on TLSA record resolution and leave this up to the application. Especially because policy about DNSSEC validation (AD bit vs. in-app trust anchors, which nameservers, ...) don't belong in the underlying SSL library. > - A random application (e.g. Firefox/Thunderbird/offlineimap) use > DANE-enabled crypto library and have no clue about DNSSEC. (That is > what we want, right? Just use it without modifying all > crypto-enabled applications in the world!) It is not so simple. The application sets trust policy, including whether DANE applies, which root CAs to trust, ... Completely transparent DANE assumes no application-specific DANE-related policy, this seems unlikely. For example, with SMTP, the SSL library won't be doing MX resolution, but the security of the MX RRset determines whether DANE applies to any of the MX hosts. > - The whole set is running on machine with plain stub-resolver > without validator. > Result => It is completely insecure because attacker can use DANE > for effective man-in-the-middle attack: The crypto library will > trust to fake TLSA records because attacker send fake TLSA record > with AD=1. Your model is too naive. Crypto libraries should not and won't set application protocol policy. MTAs and so on, have lots of knobs to enable DANE (in Postfix it is NOT on by default), and the administrator is responsible for making sure the platform is suitably configured before relying on DANE. > One opinion is 'use a new shiny API for DNS and do not hack existing > resolver APIs' and the other option is to 'do validation yourself'. > I'm afraid that this do not belong to category 'temporary solution'. Postfix does neither. The administrator sets up a trusted recursor and then enables DANE. DANE support in interactive applications operated on multi-user machines by non-administrators may need to know whether the stub resolver is trustworthy. This requires a new predicate in resolv.conf (or whatever). > It can take too long to design API, then to develop libraries and > then *to convince application developers to use this new API*. Yep, 5-10 year deployment horizons for brand new stuff. > I definitely agree that old resolver from BIND8 is "not the best" > but we have to count with existing applications. It is easier to > push small patches like > - res_init() > + res_init_trusted() > It is *much much* harder to push patches rewriting code related to > DNS to some completely new library. We want to add DANE support to > existing applications not only to new ones. Yes, that's why I am recommending adoption of BSD libresolv, which is a superset of the traditional libresolv, and offers more of what is required to support DANE. In particular, just having res_setservers() and res_nsearch()/res_nquery would be major progress. Beyond that, an application interface to ask whether the system list of recursors is deemed secure would be helpful. Work with the various upstream library maintainers to make that happen. > The proposed approach with a new initialization call (*for example* > res_init_trusted()) have two (desired) side-effects: This is I think a mistake. Without resolver contexts as with res_ninit(), this applies to all resolver clients in the same address space, not just the caller. Applications are usually not in a good position to define trusted recursors. Instead of saying which resolvers are trusted, they want to ask whether the default resolvers *are* trustworthy. > - It prevents an application relying on AD bit from running on old > system which does not guarantee trustworthiness of the AD bit. There are no such legacy applications. If you get ahead of DANE adoption with suitable libraries, the applications can start directly with the new plumbing. > Otherwise we would have to invent some way how to check at run-time > that special handling for AD bit is supported. (Think about cases > where application was compiled on newer system and somebody tries to > run it on older system etc.) Run-time checks are required, and support for these will be missing from older systems, so the code won't run there for lack of required dependencies. > For example current software like Postfix or OpenSSH client will > 'just work' without any change. AD bit will be handled in special > way only if the resolver library is initialized with the new call. As the developer of the Postfix DANE interface, I'd rather Postfix AD bit handling were subject to default system policy, and would ask the administrator to set system policy accordingly. Once APIs for querying the stub-resolver behaviour (AD suppressed or trusted) become widely available, Postfix will start using them to sanity check its TLS policy settings (can't use DANE when stub resolver suppresses AD support). > It doesn't surprise me that very few applications use AD bit because > nowadays it requires adding a new configuration option "resolver is > un/trusted" to the application. It is not easy neither for > programmer nor for administrator. It is the administrator's job, but the platform can make that as easy as possible. I don't know which applications you have in mind that are the ones doing DNSSEC and avoid using the AD bit. Very few applications use DANE, period. The Exim folks are planning to implement DANE (as soon as one or two of them are less cycle starved), and to trust the AD bit (that code is partly there already per Tony's post). Which DANE libraries are these apps using? There is no DANE support in OpenSSL or NSS yet, and GnuTLS is sufficiently incomplete, that it is not ready for production use. > I'm sorry, this also sounds like a long-term plan. We are looking > for something workable today. The plan is to push DANE support as > much as possible and as soon as possible - not to wait (potentially > long time) for standardization and adoption of new APIs etc. Today, DANE is essentially unusable. Postfix DANE support took a year of development and resulting in a new IETF draft plus proposed changes that I hope will lead to DANEbis. We're not there *today*. > >As to the question of whether always trusting AD when the recursive > >resolvers are not "secure" is OK? I don't know. Depends what > >applications do with that trust. > > Please see the example with DANE-enabled crypto library above. The example is largely naive. It is not going to work that way for quite some time. DANE will be enabled by the code that performs the application protocol (which may sit a few layers below the business logic), but it will not any time soon be automatically enabled by the transport security library due to insufficient context. For example, the application has to confirm that the transport endpoint name is secure (e.g. after MX or SRV lookups) and configure fallback behaviour when all TLSA records are unusable (e.g. mandatory unauthenticated TLS, ...). -- Viktor. From nobody Thu Feb 27 08:42: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 545191A0348 for ; Thu, 27 Feb 2014 08:42:04 -0800 (PST) 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 ZdmsJDCVwJCx for ; Thu, 27 Feb 2014 08:42:03 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id C99741A03E3 for ; Thu, 27 Feb 2014 08:42:02 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 2E9E72AAC73; Thu, 27 Feb 2014 16:42:01 +0000 (UTC) Date: Thu, 27 Feb 2014 16:42:01 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140227164201.GU21390@mournblade.imrryr.org> References: <20140227022347.GC73737@mx1.yitter.info> <20140227031628.B4A1610765F9@rock.dv.isc.org> <20140227034723.GA73861@mx1.yitter.info> <20140227041753.3509810773A8@rock.dv.isc.org> <20140227044213.GO21390@mournblade.imrryr.org> <20140227054617.GP21390@mournblade.imrryr.org> <530F3A64.2000001@redhat.com> <20140227164014.GT21390@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140227164014.GT21390@mournblade.imrryr.org> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/uF7q-_vs26v8IWWH80IjPNKMHj4 Subject: Re: [dane] An AD bit discussion (correction) 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, 27 Feb 2014 16:42:04 -0000 On Thu, Feb 27, 2014 at 04:40:14PM +0000, Viktor Dukhovni wrote: > On Thu, Feb 27, 2014 at 02:15:16PM +0100, Petr Spacek wrote: > > > Please let's concentrate on following situation: > > - Crypto libraries like GnuTLS/OpenSSL/NSS have DANE support > > compiled and enabled by default out-of-the-box. > > The enabled by default part would be most likely. It is not up to Oops, s/most likely/most UNLIKELY/. -- Viktor. From nobody Thu Feb 27 09:01:50 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 D45C01A0353 for ; Thu, 27 Feb 2014 09:01:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.547 X-Spam-Level: X-Spam-Status: No, score=-2.547 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.547] 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 7kOv-YTYNd7s for ; Thu, 27 Feb 2014 09:01:47 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 818D21A034A for ; Thu, 27 Feb 2014 09:01:47 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id D87FE80DA8; Thu, 27 Feb 2014 12:01:44 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1393520504; bh=au83m/zYDQiC0JcJicz1gOi9piA7RjHFrnu+83m9BsA=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=EUhe58MwZFfO2wt46+9F4XoCKLOsi/JcsXRW0QmsY+YzgPH1uBQ8aNtnt0hD+LZ/o c/Bw1pkCSjHQ05hHoiML09xSkQqi5M2Tr8KUD4aiYzBzgFsFyDL35patTkWRS+8UUM OLyU+eTZW+q8LYfjBkYyUKbI9YgtozsxdWf+cQA4= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s1RH1i0C024558; Thu, 27 Feb 2014 12:01:44 -0500 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Thu, 27 Feb 2014 12:01:44 -0500 (EST) From: Paul Wouters To: Petr Spacek In-Reply-To: <530F3A64.2000001@redhat.com> Message-ID: References: <20140227022347.GC73737@mx1.yitter.info> <20140227031628.B4A1610765F9@rock.dv.isc.org> <20140227034723.GA73861@mx1.yitter.info> <20140227041753.3509810773A8@rock.dv.isc.org> <20140227044213.GO21390@mournblade.imrryr.org> <20140227054617.GP21390@mournblade.imrryr.org> <530F3A64.2000001@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/yo4LEN-xTo7ZxbKBT08ae5juh88 Cc: dane@ietf.org Subject: Re: [dane] An AD bit discussion 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: Thu, 27 Feb 2014 17:01:50 -0000 On Thu, 27 Feb 2014, Petr Spacek wrote: > Now we need to discuss 'a temporary solution' for the case where a validating > resolver is not available for whatever reason. I don't agree with this premise, but those applications can be changed to use (most error handling removed for clarity): /* one time setup */ dnsctx = ub_ctx_create(); /* create unbound resolver context */ ub_ctx_hosts(dnsctx, "/etc/hosts") /* emulate POSIX */ ub_ctx_resolvconf(dnsctx, "/etc/resolv.conf") /* use nameservers from resolv.conf */ ub_ctx_add_ta(dnsctx, rootanchor); /* root key auto-updates via /var/lib/unbound/root.anchor */ ub_ctx_set_option(dnsctx, "dlv-anchor:", dlvanchor); /* activate DLV */ /* example query */ const int qtype = (af == AF_INET6) ? 28 : 1; struct ub_result *result; ub_resolve(dnsctx, qname, qtype, 1 /* CLASS IN */, &result); if (result->bogus) { log("ERROR: %s failed DNSSEC valdation!\n", result->qname); ub_resolve_free(result); [ do application is under attack defense ] } if (!result->havedata) { if (result->secure) { /* look, a real AD bit! */ [ do application stuff that trusts AD bit ] } else { [ do application stuff with no AD bit ] } } This has the same effect as stripping out forged AD bits, except real AD bits survive. It uses whatever nameservers the system has in /etc/resolv.conf. It supports overrides in /etc/hosts. It does not require glibc modification. It does not require various applications read new keywords in resolv.conf or new config files. It has no race conditions. It's a great band-aid until "tomorrow". And possibly, the getdns API has an even simpler way of doing this. Is this really too hard to do today for those old applications that need to be fixed and for the new applications you will write tomorrow? From nobody Thu Feb 27 09:05: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 0B8211A030B for ; Thu, 27 Feb 2014 09:05:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.547 X-Spam-Level: X-Spam-Status: No, score=-2.547 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.547] 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 n8WySp7gJZhc for ; Thu, 27 Feb 2014 09:05:47 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 8AF091A0104 for ; Thu, 27 Feb 2014 09:05:47 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id E3FFC80DA8; Thu, 27 Feb 2014 12:05:45 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1393520745; bh=y9dm+Ng9dgZj8YjV5eKlWA1hLC6MdmbP0AImUQwVfrQ=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=CgycDwV1zimFXcAKBZyN2R9sGApoQNnqzirn/u1bSb+GPPUDiBGu2GDAboyqQhuVv YUYksR5lnpYfwUI5kgJa5NOZtrl6TdhiI/yKaDnfCNEsYvbfvkbQE32NG5Kl+IuI1s zlOs4875dub+xqJsUkqSsL69Ym/17Fpy4TfwkkSw= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s1RH5jBs025455; Thu, 27 Feb 2014 12:05:45 -0500 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Thu, 27 Feb 2014 12:05:45 -0500 (EST) From: Paul Wouters To: Petr Spacek In-Reply-To: Message-ID: References: <20140227022347.GC73737@mx1.yitter.info> <20140227031628.B4A1610765F9@rock.dv.isc.org> <20140227034723.GA73861@mx1.yitter.info> <20140227041753.3509810773A8@rock.dv.isc.org> <20140227044213.GO21390@mournblade.imrryr.org> <20140227054617.GP21390@mournblade.imrryr.org> <530F3A64.2000001@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/SIaxtWy9pSET9XmW-zroqX6ueU8 Cc: dane@ietf.org Subject: Re: [dane] An AD bit discussion 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: Thu, 27 Feb 2014 17:05:49 -0000 On Thu, 27 Feb 2014, Paul Wouters wrote: > if (!result->havedata) { No "!" there obviously, it was copied from more elaborate checks :) Paul From nobody Thu Feb 27 10:15:22 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 2780A1A0163 for ; Thu, 27 Feb 2014 10:15:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PgZnZv0vZBA1 for ; Thu, 27 Feb 2014 10:15:19 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 600EF1A015A for ; Thu, 27 Feb 2014 10:15:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=907; q=dns/txt; s=iport; t=1393524918; x=1394734518; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=pzUFCNa3IS5CVpiBO3h4SdN8hIVY+F/L4PGrRRUC9fc=; b=YYGaXJw3Afsp4ZijyL8qRtheJ/Le6lkCEFdO3WNpd/mItPUu8v2OzTvT qVQT26wjzi9KABVTP1LUnW2Agd+GcrH0RQOWfqFPKOjRT8MeG54L11QAd YkWtpIVZDNR1TjTp4ysuTUj7LtzZdnRDOMFvEW3HEktaFeTNhC/ADwQFg 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlsRAMR/D1OtJV2d/2dsb2JhbABaFoJwO1eoKQQGmXUWdIIqej0WGAMCAQIBSw0GAgEBh3UNmmqwDheOAXGEIQSJEjiObpIqg02CCg X-IronPort-AV: E=Sophos;i="4.97,556,1389744000"; d="scan'208";a="307069467" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-4.cisco.com with ESMTP; 27 Feb 2014 18:15:17 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s1RIFHtw002258 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 27 Feb 2014 18:15:17 GMT Received: from MAMILLE2-M-T03K.local (10.129.24.73) by xhc-rcd-x05.cisco.com (173.37.183.79) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 27 Feb 2014 12:15:17 -0600 Message-ID: <530F80B4.7010600@cisco.com> Date: Thu, 27 Feb 2014 11:15:16 -0700 From: Matt Miller User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.129.24.73] Archived-At: http://mailarchive.ietf.org/arch/msg/dane/D4pP1enjVhHveZ2NyiW3ag6xqE4 Subject: [dane] Slides for IETF 89 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: Thu, 27 Feb 2014 18:15:21 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 My slides for the DANE session are available at < https://outer-planes.net/~linuxwolf/ietf/ietf89-danewg-srv.pdf >. Feedback is welcome. See you in London! - -- - - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTD4C0AAoJEDWi+S0W7cO1ZLIIAJ20MpLv/PbjJ5TDs7u33CAY b5ER7GGhn+13IJS/aFeX54iWassIA4PNi9756/5KY9jMWDePESb6uNEsEC6pU6uY eVVL6FWLtB0PYtZx23Scm9qYLGsddiy9Mqvcc76DBqc2Zs0iqd61h35rxwQ1a8ZX T1jDBC3gYSYToCiDN42ydXsnbEcwY4BWPNCRsHnLbm43cgCm5PkOLpKXmmD0YV4X K7SYNnEZb2znzWNWiCBkWYg4SeVtpV9CfCFYB4H1iaVJdFVUg1UfGIvT5BuanSrA h6UcpDbgjbqlygOhtoqcOwHJL3drSJ9GihUgsu3GQMETb2fKS9Nq8rh/pWgz1Xs= =dj3j -----END PGP SIGNATURE----- From nobody Thu Feb 27 10:16: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 C6CD81A0309 for ; Thu, 27 Feb 2014 10:16:47 -0800 (PST) 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 WnGO3XGmajox for ; Thu, 27 Feb 2014 10:16:46 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id E48E31A0163 for ; Thu, 27 Feb 2014 10:16:45 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 052022AAC73; Thu, 27 Feb 2014 18:16:44 +0000 (UTC) Date: Thu, 27 Feb 2014 18:16:43 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140227181643.GV21390@mournblade.imrryr.org> References: <20140227022347.GC73737@mx1.yitter.info> <20140227031628.B4A1610765F9@rock.dv.isc.org> <20140227034723.GA73861@mx1.yitter.info> <20140227041753.3509810773A8@rock.dv.isc.org> <20140227044213.GO21390@mournblade.imrryr.org> <20140227054617.GP21390@mournblade.imrryr.org> <530F3A64.2000001@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/iUA6jsGklkJaApmrK5c8zlplHHE Subject: Re: [dane] An AD bit discussion 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, 27 Feb 2014 18:16:48 -0000 On Thu, Feb 27, 2014 at 12:01:44PM -0500, Paul Wouters wrote: > On Thu, 27 Feb 2014, Petr Spacek wrote: > > >Now we need to discuss 'a temporary solution' for the case where a > >validating resolver is not available for whatever reason. > > I don't agree with this premise, but those applications can be changed > to use (most error handling removed for clarity): Can *in principle* be changed, but in practice this is often unlikely. Postfix works well enough with libresolv, and supports many older platforms. Moving to libunbound, which is not as widely deployed is not worth the benefit. The base libresolv library should be enhanced to at least catch up with BSD-like systems and offer res_ninit(), res_nsearch(), ... Beyond that it would be good to be able to tell libresolv: * I want AD without RRSIG and to ask libresolv: - Do you trust the AD bit from your nameservers? with that and an appropriate administrator-settable predicate in resolv.conf we're largely set. Applications which call res_setservers() should automatically receive AD=1. -- Viktor. From nobody Thu Feb 27 10:25: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 D24941A0163 for ; Thu, 27 Feb 2014 10:25:30 -0800 (PST) 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 EKpAHb96wxJa for ; Thu, 27 Feb 2014 10:25:29 -0800 (PST) Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) by ietfa.amsl.com (Postfix) with ESMTP id 126661A0119 for ; Thu, 27 Feb 2014 10:25:28 -0800 (PST) Received: by mail-wi0-f176.google.com with SMTP id hi5so7611633wib.9 for ; Thu, 27 Feb 2014 10:25:26 -0800 (PST) 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=/PjHbPMTah2S1wE9v7E2bYUj+E06iHp/D4u6mY+ZPIM=; b=S5JAZK4Fwhz7aa3hlnKcXQVFN4aps5mSKQ2ZH3bFRGKRRYkgclzaHeqeAeMuxUF/QL 5oqraPeBifGPvDCqyzx9wnZgX/CY1QRx72WMGdX9vQxAAc6jmd/9bNttAN2G4hGNFjtF 1PnOlPsMSRkbH3sZEJhtfi5BAIYtEV2TUgWBJfWG/On2zJeDzZCVqQvtFtsZevLNpYVQ aJ1XwHbLXG73bykAvE3wufbuQmq16KmbaHkr0p+/vgLuyPnTrW3TK0h4mpuL2m7BTrKs +Vhq3DPjiMsEQjMg4I4a3x1FPNKZ7tj0nt3i2qv5VL5C7ia7NkYlfJja2ICpjSToa/Cq liMQ== X-Gm-Message-State: ALoCoQmzdWpTEOZUHJMCnRhAiTQ5asVvbzLWrzWsEq90BfCvT9Yj7ujHKQ4GgWMOa/q6o/9fWjJ+ MIME-Version: 1.0 X-Received: by 10.180.73.173 with SMTP id m13mr11297218wiv.52.1393525526849; Thu, 27 Feb 2014 10:25:26 -0800 (PST) Received: by 10.194.54.167 with HTTP; Thu, 27 Feb 2014 10:25:26 -0800 (PST) X-Originating-IP: [2001:67c:370:0:c2e:bda1:fedf:380c] In-Reply-To: <530F80B4.7010600@cisco.com> References: <530F80B4.7010600@cisco.com> Date: Thu, 27 Feb 2014 18:25:26 +0000 Message-ID: From: Warren Kumari To: Matt Miller Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/YE89FbKDhakMNwnOoS4qgZ3DrcA Cc: "" Subject: Re: [dane] Slides for IETF 89 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: Thu, 27 Feb 2014 18:25:31 -0000 And I've posted them :-) W On Thu, Feb 27, 2014 at 6:15 PM, Matt Miller wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > My slides for the DANE session are available at < > https://outer-planes.net/~linuxwolf/ietf/ietf89-danewg-srv.pdf >. > Feedback is welcome. > > See you in London! > > > - -- > - - m&m > > Matt Miller < mamille2@cisco.com > > Cisco Systems, Inc. > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.22 (Darwin) > Comment: GPGTools - https://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQEcBAEBCgAGBQJTD4C0AAoJEDWi+S0W7cO1ZLIIAJ20MpLv/PbjJ5TDs7u33CAY > b5ER7GGhn+13IJS/aFeX54iWassIA4PNi9756/5KY9jMWDePESb6uNEsEC6pU6uY > eVVL6FWLtB0PYtZx23Scm9qYLGsddiy9Mqvcc76DBqc2Zs0iqd61h35rxwQ1a8ZX > T1jDBC3gYSYToCiDN42ydXsnbEcwY4BWPNCRsHnLbm43cgCm5PkOLpKXmmD0YV4X > K7SYNnEZb2znzWNWiCBkWYg4SeVtpV9CfCFYB4H1iaVJdFVUg1UfGIvT5BuanSrA > h6UcpDbgjbqlygOhtoqcOwHJL3drSJ9GihUgsu3GQMETb2fKS9Nq8rh/pWgz1Xs= > =dj3j > -----END PGP SIGNATURE----- > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From nobody Thu Feb 27 10:37: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 48F0E1A0547 for ; Thu, 27 Feb 2014 10:37:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] 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 RMVazSgdqb_q for ; Thu, 27 Feb 2014 10:37:27 -0800 (PST) Received: from ppsw-41.csi.cam.ac.uk (ppsw-41-v6.csi.cam.ac.uk [IPv6:2001:630:212:8::e:f41]) by ietfa.amsl.com (Postfix) with ESMTP id 68BF81A04F8 for ; Thu, 27 Feb 2014 10:37:27 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:43469) by ppsw-41.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1WJ5pi-0003eS-S5 (Exim 4.82_3-c0e5623) (return-path ); Thu, 27 Feb 2014 18:37:22 +0000 Received: from fanf2 by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1WJ5pi-0002wY-Ks (Exim 4.72) (return-path ); Thu, 27 Feb 2014 18:37:22 +0000 Date: Thu, 27 Feb 2014 18:37:22 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Mark Andrews In-Reply-To: <20140227031628.B4A1610765F9@rock.dv.isc.org> Message-ID: References: <20140227022347.GC73737@mx1.yitter.info> <20140227031628.B4A1610765F9@rock.dv.isc.org> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Archived-At: http://mailarchive.ietf.org/arch/msg/dane/IT8Mh1VblNUPnOnbudPXD532vmo Cc: dane@ietf.org Subject: Re: [dane] An AD bit discussion 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: Thu, 27 Feb 2014 18:37:29 -0000 Mark Andrews wrote: > > Adding a trusted key clause to resolv.conf would work e.g. > > trusted-key start-date end-date . 257 3 8 "AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjFFVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoXbfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaDX6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpzW5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relSQageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulqQxA+Uk1ihz0=" ldns uses the syntax anchor /path/to/file and you can use unbound-anchor to keep the file up-to-date. Tony. -- f.anthony.n.finch http://dotat.at/ Viking, North Utsire: Southeasterly 7 to severe gale 9, decreasing 5 or 6. Rough or very rough. Rain then showers. Poor becoming good. From nobody Thu Feb 27 10:40:29 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 7AB5D1A0410 for ; Thu, 27 Feb 2014 10:40:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.449 X-Spam-Level: X-Spam-Status: No, score=-7.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, 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 4e4STRF2NvhY for ; Thu, 27 Feb 2014 10:40:26 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id CF23D1A0176 for ; Thu, 27 Feb 2014 10:40:26 -0800 (PST) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s1RIKJdt000835 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 27 Feb 2014 13:20:19 -0500 Received: from pspacek.brq.redhat.com (vpn1-7-193.ams2.redhat.com [10.36.7.193]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s1RIKGhx031540 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 27 Feb 2014 13:20:18 -0500 Message-ID: <530F81DF.6010401@redhat.com> Date: Thu, 27 Feb 2014 19:20:15 +0100 From: Petr Spacek Organization: Red Hat User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Paul Wouters References: <20140227022347.GC73737@mx1.yitter.info> <20140227031628.B4A1610765F9@rock.dv.isc.org> <20140227034723.GA73861@mx1.yitter.info> <20140227041753.3509810773A8@rock.dv.isc.org> <20140227044213.GO21390@mournblade.imrryr.org> <20140227054617.GP21390@mournblade.imrryr.org> <530F3A64.2000001@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/k_p9C6oByXXIzMQ27cWryQhK_Ls Cc: dane@ietf.org Subject: Re: [dane] An AD bit discussion 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: Thu, 27 Feb 2014 18:40:28 -0000 On 27.2.2014 18:01, Paul Wouters wrote: > On Thu, 27 Feb 2014, Petr Spacek wrote: >> Now we need to discuss 'a temporary solution' for the case where a >> validating resolver is not available for whatever reason. > > I don't agree with this premise, but those applications can be changed > to use (most error handling removed for clarity): > > /* one time setup */ > dnsctx = ub_ctx_create(); /* create unbound resolver context */ Please correct me if I'm wrong but I'm afraid that this snippet effectively bakes a security policy to applications: > ub_ctx_hosts(dnsctx, "/etc/hosts") /* emulate POSIX */ > ub_ctx_resolvconf(dnsctx, "/etc/resolv.conf") /* use nameservers from > resolv.conf */ > ub_ctx_add_ta(dnsctx, rootanchor); /* root key auto-updates via > /var/lib/unbound/root.anchor */ > ub_ctx_set_option(dnsctx, "dlv-anchor:", dlvanchor); /* activate DLV */ How can I install my own trust anchors? (E.g. I have internal zones and I want to use DNSSEC for them...) How can I disable DLV on system-wide level? All this should be system-wide configuration otherwise it will create problems for tightly controlled environments. > This has the same effect as stripping out forged AD bits, except real AD > bits survive. It uses whatever nameservers the system has in > /etc/resolv.conf. It supports overrides in /etc/hosts. It does not > require glibc modification. It does not require various applications > read new keywords in resolv.conf or new config files. It has no race > conditions. It's a great band-aid until "tomorrow". > > And possibly, the getdns API has an even simpler way of doing this. I agree that new DNS API is a great idea, I have said that many times already. > Is this really too hard to do today for those old applications that need > to be fixed and for the new applications you will write tomorrow? Will you patch every application doing TLS to link with libunbound? (Upstream developers are always happy to accept patches introducing new dependencies.) Are you going to convince OpenStack people (accepting only pure Python code and nothing else) to use this? Please see the other branch of this thread, I will reply there about crypto libraries. -- Petr^2 Spacek From nobody Thu Feb 27 12:04:26 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 2758D1A0656 for ; Thu, 27 Feb 2014 12:04:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.449 X-Spam-Level: X-Spam-Status: No, score=-7.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, 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 arIwFq8x_7YV for ; Thu, 27 Feb 2014 12:04:21 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 50BEC1A01F4 for ; Thu, 27 Feb 2014 12:04:21 -0800 (PST) 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 s1RK4Fua008657 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 27 Feb 2014 15:04:17 -0500 Received: from pspacek.brq.redhat.com (vpn1-7-193.ams2.redhat.com [10.36.7.193]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s1RK4DeM011419 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Thu, 27 Feb 2014 15:04:15 -0500 Message-ID: <530F9A3D.3070008@redhat.com> Date: Thu, 27 Feb 2014 21:04:13 +0100 From: Petr Spacek Organization: Red Hat User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: dane@ietf.org References: <20140227022347.GC73737@mx1.yitter.info> <20140227031628.B4A1610765F9@rock.dv.isc.org> <20140227034723.GA73861@mx1.yitter.info> <20140227041753.3509810773A8@rock.dv.isc.org> <20140227044213.GO21390@mournblade.imrryr.org> <20140227054617.GP21390@mournblade.imrryr.org> <530F3A64.2000001@redhat.com> <20140227164014.GT21390@mournblade.imrryr.org> <20140227164201.GU21390@mournblade.imrryr.org> In-Reply-To: <20140227164201.GU21390@mournblade.imrryr.org> 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/T4Qw-a1SILepDAU0rDQzPqA4avY Subject: Re: [dane] An AD bit discussion (correction) 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: Thu, 27 Feb 2014 20:04:25 -0000 On 27.2.2014 17:42, Viktor Dukhovni wrote: > On 27.2.2014 17:40, Viktor Dukhovni wrote: > On Thu, Feb 27, 2014 at 02:15:16PM +0100, Petr Spacek wrote: >> >>> Please let's concentrate on following situation: >>> - Crypto libraries like GnuTLS/OpenSSL/NSS have DANE support >>> compiled and enabled by default out-of-the-box. >> >> The enabled by default part would be most likely. It is not up to > Oops, s/most likely/most UNLIKELY/. >> the libraries to enable DANE support. They don't know which [...] Feel free to skip handwaving about crypto libraries and jump straight to the matter - DNS stub-resolvers. /Disclaimer: Please read following text about crypto libraries as a long-term vision. I'm adding it here just to add some context information. I'm aware that it will take long and that is not *that* simple./ >> multiplicity of interfaces, and the fact that applications may want >> an asynchronous DNS interface, but none is as yet as entrenched as >> libresolv, I would expect these toolkits to punt on TLSA record >> resolution and leave this up to the application. Especially because >> policy about DNSSEC validation (AD bit vs. in-app trust anchors, >> which nameservers, ...) don't belong in the underlying SSL library. I have talked with NSS developers at Red Hat's Developer Conference this year (devconf.cz) and their (personal and not-that-thorough) opinion was that it seems feasible to do DANE for pure TLS directly in crypto library. If everything you need is to open a TLS connection to a server with given name then *in theory* the crypto library can do all the work for you. Of course, there are applications with special requirements but easy cases could be (we hope) handled in crypto library and special case over appropriate APIs. The discussion ended with statement that we need to solve API for resolvers first and then we can open discussion about DANE in NSS again. <<< --- We are here :-) >>> - A random application (e.g. Firefox/Thunderbird/offlineimap) use >>> DANE-enabled crypto library and have no clue about DNSSEC. (That is >>> what we want, right? Just use it without modifying all >>> crypto-enabled applications in the world!) >> >> It is not so simple. The application sets trust policy, including >> whether DANE applies, which root CAs to trust, ... Completely >> transparent DANE assumes no application-specific DANE-related policy, >> this seems unlikely. Yes, that is a problem (in a little bit different area). Generally, we want to move crypto/security policies from applications to system level. Current situation is an administrative nightmare. The 'Vision' (highly naive, *please* do not comment on API itself but on the idea) is to convert (as much as possible) applications to APIs like: open_tls_connection('hostname', port, &conn); send_enc_data(conn &buff, len); recv_enc_data(conn, &buff, len); close_tls_connection(&conn); ... and separate applications from DNS/connection handling/crypto stuff. Think about DNSSEC + happy eyeballs + TLS. That is a lot for an application to do for mere connection establishment! That will allow us to control security policy on system-wide level where it belongs. We already do work in this field and direction. This is long-term goal and adding application-controlled policies for DANE goes in opposite direction. That is the reason why we are trying to move 'policy logic' to system level/library level and do not pollute applications with policy processing. (We have to at least *try* that.) >>> - The whole set is running on machine with plain stub-resolver >>> without validator. >> >>> Result => It is completely insecure because attacker can use DANE >>> for effective man-in-the-middle attack: The crypto library will >>> trust to fake TLSA records because attacker send fake TLSA record >>> with AD=1. >> >> Your model is too naive. Crypto libraries should not and won't >> set application protocol policy. MTAs and so on, have lots of >> knobs to enable DANE (in Postfix it is NOT on by default), and the >> administrator is responsible for making sure the platform is suitably >> configured before relying on DANE. That is exactly the point. We don't want to configure everything again and again per-application, we want system-wide configuration. Of course, it can't work today and there always be some special cases. MTAs can be one of them. You are expert in this area and I trust you. The intent is to avoid adding more and more application specific knobs because it will be hard to get rid of them in future. (There are exceptions - as always.) >>> One opinion is 'use a new shiny API for DNS and do not hack existing >>> resolver APIs' and the other option is to 'do validation yourself'. >>> I'm afraid that this do not belong to category 'temporary solution'. >> >> Postfix does neither. The administrator sets up a trusted recursor >> and then enables DANE. DANE support in interactive applications >> operated on multi-user machines by non-administrators may need to >> know whether the stub resolver is trustworthy. This requires >> a new predicate in resolv.conf (or whatever). I 100 % agree. >>> I definitely agree that old resolver from BIND8 is "not the best" >>> but we have to count with existing applications. It is easier to >>> push small patches like >>> - res_init() >>> + res_init_trusted() >>> It is *much much* harder to push patches rewriting code related to >>> DNS to some completely new library. We want to add DANE support to >>> existing applications not only to new ones. >> >> Yes, that's why I am recommending adoption of BSD libresolv, which >> is a superset of the traditional libresolv, and offers more of what >> is required to support DANE. In particular, just having res_setservers() >> and res_nsearch()/res_nquery would be major progress. Again, we are not interested in a single library but in a general approach. Please consider that vanilla Fedora distro contains > 40 000 packages. I can name 5 different DNS libraries I use daily *only from top of my head*. We want to open DNSSEC/DANE potential for all of them, not only some small subset. Of course, this idea (nameserver whitelisting/AD bit masking) has to be widely adopted in rest of the ecosystem otherwise we can give it up right now. We don't want and can't go against the whole world. >> Beyond that, an application interface to ask whether the system >> list of recursors is deemed secure would be helpful. Work with >> the various upstream library maintainers to make that happen. I'm glad that we agree on that. Do you have some specific proposal in your mind? You have proposed new option in /etc/resolv.conf, something like resolvers_trusted = no/yes, right? What behavior is 'the best' in your opinion? Would it be okay to always set AD bit to 0 if option "resolvers_trusted" is set to "no"? Are you okay with default "no"? (If the new option is not present.) >>> The proposed approach with a new initialization call (*for example* >>> res_init_trusted()) have two (desired) side-effects: >> >> This is I think a mistake. Without resolver contexts as with >> res_ninit(), this applies to all resolver clients in the same >> address space, not just the caller. Applications are usually not >> in a good position to define trusted recursors. Instead of saying >> which resolvers are trusted, they want to ask whether the default >> resolvers *are* trustworthy. I agree. What do you think about AD bit masking configured system-wide? Please keep in mind that this needs to be universal behavior implement-able even in old glibc resolver and any other DNS library. >>> - It prevents an application relying on AD bit from running on old >>> system which does not guarantee trustworthiness of the AD bit. >> >> There are no such legacy applications. If you get ahead of DANE >> adoption with suitable libraries, the applications can start directly >> with the new plumbing. I personally agree but please read concerns expressed by glibc maintainer below. >>> Otherwise we would have to invent some way how to check at run-time >>> that special handling for AD bit is supported. (Think about cases >>> where application was compiled on newer system and somebody tries to >>> run it on older system etc.) >> >> Run-time checks are required, and support for these will be missing >> from older systems, so the code won't run there for lack of required >> dependencies. I'm personally okay with that. >>> For example current software like Postfix or OpenSSH client will >>> 'just work' without any change. AD bit will be handled in special >>> way only if the resolver library is initialized with the new call. >> >> As the developer of the Postfix DANE interface, I'd rather Postfix >> AD bit handling were subject to default system policy, and would >> ask the administrator to set system policy accordingly. Once APIs >> for querying the stub-resolver behaviour (AD suppressed or trusted) >> become widely available, Postfix will start using them to sanity >> check its TLS policy settings (can't use DANE when stub resolver >> suppresses AD support). I 100 % agree with your point of view. The problem is that our glibc maintainer explicitly refused to change default behavior (i.e. mask AD bit until admin white-lists given resolver in /etc/resolv.conf) because it could break some (potentially) existing applications. That is a reason why we invented "init_trusted()" concept. Could you give us some detailed thoughts about compatibility? I guess that we will have the same discussion about compatibility again and again with many upstream developers from many DNS libraries so any detailed analysis will be handy. >> Today, DANE is essentially unusable. Postfix DANE support took a >> year of development and resulting in a new IETF draft plus proposed >> changes that I hope will lead to DANEbis. We're not there *today*. Okay, let's find a way how we can move things forward on client side! :-) Thank you very much for your time. -- Petr^2 Spacek From nobody Thu Feb 27 12:44:09 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 11EFD1A0649 for ; Thu, 27 Feb 2014 12:44:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.449 X-Spam-Level: X-Spam-Status: No, score=-7.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, 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 nAMJEpncLTxa for ; Thu, 27 Feb 2014 12:44:06 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 19DA01A0141 for ; Thu, 27 Feb 2014 12:44:06 -0800 (PST) Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s1RKi3bl027164 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 27 Feb 2014 15:44:03 -0500 Received: from pspacek.brq.redhat.com (vpn1-7-193.ams2.redhat.com [10.36.7.193]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s1RKi1TY018679 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Thu, 27 Feb 2014 15:44:03 -0500 Message-ID: <530FA391.1070604@redhat.com> Date: Thu, 27 Feb 2014 21:44:01 +0100 From: Petr Spacek Organization: Red Hat User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: dane@ietf.org References: <20140227022347.GC73737@mx1.yitter.info> <20140227031628.B4A1610765F9@rock.dv.isc.org> <20140227034723.GA73861@mx1.yitter.info> <20140227041753.3509810773A8@rock.dv.isc.org> <20140227044213.GO21390@mournblade.imrryr.org> <20140227054617.GP21390@mournblade.imrryr.org> <530F3A64.2000001@redhat.com> <20140227164014.GT21390@mournblade.imrryr.org> <20140227164201.GU21390@mournblade.imrryr.org> <530F9A3D.3070008@redhat.com> In-Reply-To: <530F9A3D.3070008@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.25 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/8pF_6G1j-lqB0ktzeWe7PeP51as Subject: Re: [dane] An AD bit discussion (+concerns from glibc camp) 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: Thu, 27 Feb 2014 20:44:08 -0000 On 27.2.2014 21:04, Petr Spacek wrote: >>>> For example current software like Postfix or OpenSSH client will >>>> 'just work' without any change. AD bit will be handled in special >>>> way only if the resolver library is initialized with the new call. >>> >>> As the developer of the Postfix DANE interface, I'd rather Postfix >>> AD bit handling were subject to default system policy, and would >>> ask the administrator to set system policy accordingly. Once APIs >>> for querying the stub-resolver behaviour (AD suppressed or trusted) >>> become widely available, Postfix will start using them to sanity >>> check its TLS policy settings (can't use DANE when stub resolver >>> suppresses AD support). > I 100 % agree with your point of view. > > The problem is that our glibc maintainer explicitly refused to change default > behavior (i.e. mask AD bit until admin white-lists given resolver in > /etc/resolv.conf) because it could break some (potentially) existing > applications. That is a reason why we invented "init_trusted()" concept. > > Could you give us some detailed thoughts about compatibility? > > I guess that we will have the same discussion about compatibility again and > again with many upstream developers from many DNS libraries so any detailed > analysis will be handy. I'm adding quote from our glibc maintainer: >>>> Carlos O'Donell wrote: >>>>> Consider a RHEL7 or RHEL6 system using the present meaning of >>>>> `nameserver' in /etc/resolv.conf, on a secure network with a trusted >>>>> recursive resolver using DNSSEC for some given domains. In this >>>>> configuration any application using the AD bit works as expected. >>>>> The system administrators ensured there was trust between the recursive >>>>> resolver and the client stub resolver. This is how a user might configure >>>>> their corporate network, and even better they might also use 802.1x >>>>> with no rogue or untrusted systems on their network. >>>>> >>>>> If we release a z-stream or y-stream glibc that inverts the definition >>>>> of `nameserver' from trusted to untrusted (doesn't use EDNS0+DO for >>>>> a query, and clears the AD bit) then applications in such a configuration >>>>> as described above that rely on the AD bit forwarding may cease to >>>>> function correctly. >>>>> >>>>> That is why I do not want to change the existing meaning of `nameserver' >>>>> and why we should not change any of the existing meanings of entries in >>>>> /etc/resolv.conf. Thus for compatibility I suggest adding a new option >>>>> `untrusted' for use by such applications as NetworkManager to put >>>>> untrusted DNS server (acquired from untrusted DHCP results) into. >>>>> >>>>> Let me be clear though, if I didn't care about breaking customer >>>>> configurations, I'd make this change, but I think we would be doing >>>>> a disservice to our users by breaking valid existing DNSSEC uses. -- Petr^2 Spacek From nobody Thu Feb 27 13:26:22 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 963B61A0228 for ; Thu, 27 Feb 2014 13:26:20 -0800 (PST) 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 djMunRrf8lTi for ; Thu, 27 Feb 2014 13:26:17 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 6E5911A035B for ; Thu, 27 Feb 2014 13:26:17 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 54D402AAC73; Thu, 27 Feb 2014 21:26:14 +0000 (UTC) Date: Thu, 27 Feb 2014 21:26:14 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140227212614.GY21390@mournblade.imrryr.org> References: <20140227031628.B4A1610765F9@rock.dv.isc.org> <20140227034723.GA73861@mx1.yitter.info> <20140227041753.3509810773A8@rock.dv.isc.org> <20140227044213.GO21390@mournblade.imrryr.org> <20140227054617.GP21390@mournblade.imrryr.org> <530F3A64.2000001@redhat.com> <20140227164014.GT21390@mournblade.imrryr.org> <20140227164201.GU21390@mournblade.imrryr.org> <530F9A3D.3070008@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <530F9A3D.3070008@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/CnOZKZW6bs3XTg-PFxA12Bhjf5o Subject: Re: [dane] An AD bit discussion (correction) 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, 27 Feb 2014 21:26:20 -0000 On Thu, Feb 27, 2014 at 09:04:13PM +0100, Petr Spacek wrote: > Of course, there are applications with special requirements but easy > cases could be (we hope) handled in crypto library and special case > over appropriate APIs. > > The discussion ended with statement that we need to solve API for > resolvers first and then we can open discussion about DANE in NSS > again. > > <<< --- We are here :-) Almost, because some of the DANE requirements are not set in stone. For example, interaction with CNAME records is not yet a done deal. Likewise digest agility, support for multiple peer names, semantics of CU=3, ... Early implementations are raising issues that clarify or extend the standard, and so even if the resolver API were a solved problem, it would be a bit early to bake a complete DANE implementation, including all the policy issues around TLSA records, into a TLS toolkit. It is a good time to be thinking about how to validate certificate chains via a given set of TLSA records and get the basics right (subtle enough in itself, that almost every implementation I've seen has serious flaws). So progress can be made by implementing code in such toolkits: - To validate a remote server's certificate chain against a set of TLSA records provided by the application - To integrate this with name checks (off for CU=3) that support multiple application-provided names. - To think about the semantics of "IN TLSA 2 1 0" and whether such bare keys in DNS are usable without a corresponding chain element in the server TLS "certificate message". - To think about how to support digest agility - To provide an API for applications that want to do their own DNS lookups, and pass them to the librarary, rather than asking the TLS library to perform DNS lookups. > This is long-term goal and adding application-controlled policies > for DANE goes in opposite direction. That is the reason why we are > trying to move 'policy logic' to system level/library level and do > not pollute applications with policy processing. (We have to at > least *try* that.) For the simplest applications that have a single secure hostname, and want to use some shiny new simplified API, which promises DANE as a default enabled connection security mechanism, sure we can assume there's a role for that. Complications arise quickly if needs of more complex applications are not anticipated and one need to be careful of complex dependency chains if the crypto library depends on DNSSEC libraries which in turn depend on crypto libraries. > That is exactly the point. We don't want to configure everything > again and again per-application, we want system-wide configuration. Yes. > The intent is to avoid adding more and more application specific > knobs because it will be hard to get rid of them in future. (There > are exceptions - as always.) I vote for a stub resolver whose configuration combines a list of recursive resolvers with a trust predicate that specifies whether the AD bit should be passed to stub resolver applications. I further vote for a way to query this predicate and to set the recursor list, all via an extended libresolv. > >>Yes, that's why I am recommending adoption of BSD libresolv, which > >>is a superset of the traditional libresolv, and offers more of what > >>is required to support DANE. In particular, just having res_setservers() > >>and res_nsearch()/res_nquery would be major progress. > > Again, we are not interested in a single library but in a general > approach. Please consider that vanilla Fedora distro contains > 40 > 000 packages. I can name 5 different DNS libraries I use daily *only > from top of my head*. Then add the requisite functionality to each of the relevant libraries. But for your simple application API you only need to care about the DNS libraries used by: OpenSSL (if any) GnuTLS (if any) NSS (if any) you can help direct those toolkits at the preferred DNS library, at which point behaviour of other DNS libraries is less important. > We want to open DNSSEC/DANE potential for all of them, not only > some small subset. I would recommend a bit of focus at the outset. > Of course, this idea (nameserver whitelisting/AD bit masking) has to > be widely adopted in rest of the ecosystem otherwise we can give it > up right now. We don't want and can't go against the whole world. I am still not sold on "whitelisting", as opposed to "blessing" a configuration as a whole, but this is not critical. Yes work with library designers to come to agreement on the approach. > I'm glad that we agree on that. Do you have some specific proposal > in your mind? You have proposed new option in /etc/resolv.conf, > something like > > resolvers_trusted = no/yes, right? Something like that, without suggesting any particular name. > What behavior is 'the best' in your opinion? Would it be okay to > always set AD bit to 0 if option "resolvers_trusted" is set to "no"? That would be fine. Fail closed. If some DHCP client unaware of the new predicate generates a resolv.conf file, it should I think be considered insecure. > Are you okay with default "no"? (If the new option is not present.) Yes. I am of course not the entirety of this group (even if lately I am responsible for ~50% of the traffic). So perhaps this view is not widely held. > I agree. What do you think about AD bit masking configured > system-wide? Please keep in mind that this needs to be universal > behavior implement-able even in old glibc resolver and any other DNS > library. Fine by me, I prefer it in fact, provided the administrator can unmask it, and an application can find out whether the masking is taking place. > The problem is that our glibc maintainer explicitly refused to > change default behavior (i.e. mask AD bit until admin white-lists > given resolver in /etc/resolv.conf) because it could break some > (potentially) existing applications. That is a reason why we > invented "init_trusted()" concept. I think he's wrong. Precisely because applications might be using the AD bit, it *should* be masked when unsafe. Polluting the library with useless initializers (and still no resolver context as with res_ninit(), ...) would be lame. > Could you give us some detailed thoughts about compatibility? Go ahead, PLEASE, break Postfix DANE support on systems using insecure upstead resolvers on which the administrator does not arrange for the right predicate in /etc/resolv.conf. I want the AD bit to be more than blind faith. -- Viktor. From nobody Thu Feb 27 13: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 B086C1A02F5 for ; Thu, 27 Feb 2014 13:38:35 -0800 (PST) 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 BUr8PDWMXVMA for ; Thu, 27 Feb 2014 13:38:34 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 3CD871A0292 for ; Thu, 27 Feb 2014 13:38:34 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 427482AAC73; Thu, 27 Feb 2014 21:38:32 +0000 (UTC) Date: Thu, 27 Feb 2014 21:38:32 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140227213832.GZ21390@mournblade.imrryr.org> References: <20140227034723.GA73861@mx1.yitter.info> <20140227041753.3509810773A8@rock.dv.isc.org> <20140227044213.GO21390@mournblade.imrryr.org> <20140227054617.GP21390@mournblade.imrryr.org> <530F3A64.2000001@redhat.com> <20140227164014.GT21390@mournblade.imrryr.org> <20140227164201.GU21390@mournblade.imrryr.org> <530F9A3D.3070008@redhat.com> <530FA391.1070604@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <530FA391.1070604@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/o_PqimwC9HWTT60QfkolTnAXVxQ Subject: Re: [dane] An AD bit discussion (+concerns from glibc camp) 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, 27 Feb 2014 21:38:35 -0000 On Thu, Feb 27, 2014 at 09:44:01PM +0100, Petr Spacek wrote: >>If we release a z-stream or y-stream glibc that inverts the definition >>of `nameserver' from trusted to untrusted (doesn't use EDNS0+DO for >>a query, and clears the AD bit) then applications in such a configuration >>as described above that rely on the AD bit forwarding may cease to >>function correctly. A feature IMHO. Document the change, and tell administrators how to mark the resolver list trusted. Enhance NetworkManager to be able to write trusted resolv.conf files when the DNS server list comes from a secure source. >>That is why I do not want to change the existing meaning of `nameserver' >>and why we should not change any of the existing meanings of entries in >>/etc/resolv.conf. Thus for compatibility I suggest adding a new option >>`untrusted' for use by such applications as NetworkManager to put >>untrusted DNS server (acquired from untrusted DHCP results) into. This fails open. Given the dearth of DNSSEC applications that rely on the AD bit, this is I think the right time to get the right semantics. No changes are required in end-applications, just system configuration management, this is an easy problem that should be addressed. Marking /etc/resolv.conf explicitly untrusted, in every case where it is not, is I think too fragile. -- Viktor. From nobody Thu Feb 27 13:56:51 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 00B5B1A0262 for ; Thu, 27 Feb 2014 13:56:50 -0800 (PST) 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 4nwWl4grdWPH for ; Thu, 27 Feb 2014 13:56:48 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 5B60B1A0139 for ; Thu, 27 Feb 2014 13:56:48 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 6F37C2AAC73; Thu, 27 Feb 2014 21:56:45 +0000 (UTC) Date: Thu, 27 Feb 2014 21:56:45 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140227215645.GB21390@mournblade.imrryr.org> References: <20140227022347.GC73737@mx1.yitter.info> <20140227031628.B4A1610765F9@rock.dv.isc.org> <20140227034723.GA73861@mx1.yitter.info> <20140227041753.3509810773A8@rock.dv.isc.org> <20140227044213.GO21390@mournblade.imrryr.org> <20140227054617.GP21390@mournblade.imrryr.org> <530F3A64.2000001@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/1_b6SEL1OK5nPJ17fwJKS8gyqj8 Subject: Re: [dane] An AD bit discussion 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, 27 Feb 2014 21:56:50 -0000 On Thu, Feb 27, 2014 at 12:01:44PM -0500, Paul Wouters wrote: > This has the same effect as stripping out forged AD bits, except real AD > bits survive. It uses whatever nameservers the system has in > /etc/resolv.conf. It supports overrides in /etc/hosts. It does not > require glibc modification. It does not require various applications > read new keywords in resolv.conf or new config files. It has no race > conditions. It's a great band-aid until "tomorrow". Oddly enough, unrelated to this thread, someone asked me today whether there exist stub resolver libraries that can be configured to trust AD=1, but *otherwise* perform local validation when AD=0. Perhaps the local recursor is non-validating, or Petr's idea is implemented and the AD bit is suppressed. Either way, the application can recover at the cost of performing internal verification, but only when "necessary". Anyone know of a library that can support this mode of operation? -- Viktor. From nobody Thu Feb 27 15:09:29 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 674991A02C4 for ; Thu, 27 Feb 2014 15:09:27 -0800 (PST) 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 DwHkoYlrb7_a for ; Thu, 27 Feb 2014 15:09:25 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 763C91A015E for ; Thu, 27 Feb 2014 15:09:25 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 25DBF2AAC73; Thu, 27 Feb 2014 23:09:22 +0000 (UTC) Date: Thu, 27 Feb 2014 23:09:22 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140227230922.GD21390@mournblade.imrryr.org> References: <20140227041753.3509810773A8@rock.dv.isc.org> <20140227044213.GO21390@mournblade.imrryr.org> <20140227054617.GP21390@mournblade.imrryr.org> <530F3A64.2000001@redhat.com> <20140227164014.GT21390@mournblade.imrryr.org> <20140227164201.GU21390@mournblade.imrryr.org> <530F9A3D.3070008@redhat.com> <20140227212614.GY21390@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.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/3nQSWohZazvjN-xrPPf-VpX-NHw Subject: Re: [dane] An AD bit discussion (correction) 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, 27 Feb 2014 23:09:27 -0000 On Thu, Feb 27, 2014 at 05:49:54PM -0500, Paul Wouters wrote: > >I want the AD bit to be more than blind faith. > > - Make unbound part of every install > > - Modify Anaconda/kickstart to take user's static DNS input and store > it somewhere (e.g. /etc/sysconfig/unbound or something) > and put 127.0.0.1 in resolv.conf > > - Modify unbound systemd service to run unbound-control forward_add > . in ExecStartPost= > > - Modify NM to run unbound-control forward_add . > instead of modifying resolv.conf > > no crypto library and no glibc modifications needed. I agree, but one of the more vocal Postfix users does not. Perhaps we can ignore him as an unrepresentative zealot. Objectively, I see no reason to say no to a local validating cache. If RedHat can standardize on a local validating cache on every machine, that *is* better than hacking the AD bit, provided you can ignore the zealots who insist that with a few LAN-local caches, adding local caches on each machine is somehow bad. My point that with virtual machines context switching to a different VM is likely much more expensive than context switching to a local process did not make much of an impression. So *if* there is a local resolver and it is the only one used, great! No need to disable the AD bit. If there is not, perhaps "failing safe" is sensible. It may be enough to design systems that default to local resolvers, and users who change that are free to shoot themselves in both feet. -- Viktor. From nobody Fri Feb 28 04:12:44 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 5BCB31A026A for ; Fri, 28 Feb 2014 04:12:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.449 X-Spam-Level: X-Spam-Status: No, score=-7.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, 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 L2tqUWl1SAXe for ; Fri, 28 Feb 2014 04:12:41 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id D46E11A022F for ; Fri, 28 Feb 2014 04:12:41 -0800 (PST) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s1SCCd0a001477 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 28 Feb 2014 07:12:39 -0500 Received: from pspacek.brq.redhat.com (pspacek.brq.redhat.com [10.34.4.156]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s1SCCbiH003924 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 28 Feb 2014 07:12:38 -0500 Message-ID: <53107D34.1030409@redhat.com> Date: Fri, 28 Feb 2014 13:12:36 +0100 From: Petr Spacek Organization: Red Hat User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: dane@ietf.org References: <20140227041753.3509810773A8@rock.dv.isc.org> <20140227044213.GO21390@mournblade.imrryr.org> <20140227054617.GP21390@mournblade.imrryr.org> <530F3A64.2000001@redhat.com> <20140227164014.GT21390@mournblade.imrryr.org> <20140227164201.GU21390@mournblade.imrryr.org> <530F9A3D.3070008@redhat.com> <20140227212614.GY21390@mournblade.imrryr.org> <20140227230922.GD21390@mournblade.imrryr.org> In-Reply-To: <20140227230922.GD21390@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.22 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/5EncyDxW8BwRQDG61KY0_-_XF8w Subject: [dane] Proposal: AD bit handling in stub-resolvers (ACK/amend/NACK) 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, 28 Feb 2014 12:12:43 -0000 Hello, please comment on the following proposal. Paul and Viktor are most active in this discussion but we would like to hear opinions from other experts! Let's agree on the very basic principle, please do not recommend particular libraries etc. The Goal ======== On 28.2.2014 00:09, Viktor Dukhovni wrote: >> On 27.2.2014 22:26, Viktor Dukhovni wrote: >>> I want the AD bit to be more than blind faith. (This means AD bit as seen by applications in responses from generic DNS API.) Long-term solution ================== Paul Wouters pushes hard for validating recursor on each host. Viktor and me agree with that: > So *if* there is a local resolver and it is the only one used, > great! No need to disable the AD bit. If there is not, perhaps > "failing safe" is sensible. However, we want to find some intermediate solution deployable today. > It may be enough to design systems that default to local resolvers, > and users who change that are free to shoot themselves in both feet. Proposal for short-term solution - please comment ================================================= All names are completely "random". Please propose better names and/or semantics. 1) Add a new boolean to /etc/resolv.conf: options resolvers-trusted - If present, this option states that "admin ensured that recursor is trustworthy and the communication link between recursor and stub-resolver is secure". - If present, the AD bit will be passed from recursors to applications as-is. - If not present, the AD bit sent to a applications will be always 0. - E.g. the option will be present on a system with locally running Unbound. - E.g. the option *will not* be present on thin client, compute node in data centre, a random laptop installed today with default configuration etc. Objections: - There is a chance that dhcp client copies "options" from old resolv.conf to new one. In that case simplest variant "options resolvers-trusted" is insecure if one configured e.g. local trusted recursor and DHCP client was started after that. - Many applications mess with resolv.conf so the new boolean should be somewhere else. E.g. /etc/resolv.trusted. - Because of the first objection, the file /etc/resolv.trusted should contain explicit whitelist with IP addresses of trusted recursors. That lowers the probability that admin sets option "resolvers-trusted" to /etc/resolv.trusted but some application (like DHCP client) will change name servers in /etc/resolv.conf. 2) Add a function call for run-time check (for library users): boolean dns_resolvers_trusted(resolver); - TRUE if admin declared resolvers as trusted. AD bit is unchanged. - FALSE otherwise. AD bit is always set to 0. Applications can detect that AD bit masking is enabled. - If the function is not defined then DNS library doesn't support AD bit masking as described here. Naturally, this can be replaced by any other mechanism for run-time checks if a library in question has such mechanism already. 3) Usage from applications: - Call run-time check: /* WARNING! This call can't be skipped: It ensures that your DNS the library supports the new behavior. */ dns_trusted = dns_resolvers_trusted(resolver); if (dns_trusted) Enable code depending on DNSSEC else Fallback - Decide if you want to use the data from DNS or not: dns_query(resolver, query, answer); if (answer->ad_bit) Use data from DNS (answer->data) else Fallback Please add what I have missed, what is wrong etc. Thank you very much for your time! -- Petr^2 Spacek From nobody Fri Feb 28 06:45:24 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 C2EB81A02C1 for ; Fri, 28 Feb 2014 06:45:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1H2NEu-m7nXN for ; Fri, 28 Feb 2014 06:45:17 -0800 (PST) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) by ietfa.amsl.com (Postfix) with ESMTP id C93791A080A for ; Fri, 28 Feb 2014 06:45:15 -0800 (PST) Received: by mail-wg0-f44.google.com with SMTP id a1so640570wgh.27 for ; Fri, 28 Feb 2014 06:45:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=t0tP4vbUkrdzsV+XAPQv/Uiq2ucoJvnvPUxGx4Rw/Bk=; b=OkUlaH5naztCGz6SdsLia42zmCUiuDRCk2YIIBjPu95vlAEZVgGKMYNx4FyT5EvPwL zJLhIMZ5dHz1azdAaajHWc3Xix3kMMwKERrQIGBpF20ZNvAhe9PzbvBpXups5DkqZIEY ynCaKV3uh/Y4oQCXZZRvsEQEH51cTwA5glnsg1AWZQqyNNZWBZGfDV5wwL/RDCGN2JIi 7ToUJNIUvY7a75cGw335yGix6ViPu/S1VGlfERkY3d/RnakhGq6E9HvwC7fwDQJ+PXYx K5nm38PRBzNtjceKxp/H0As79N1uXz8Y0/EUeGcTxOmQMFZLcOv3aZ5FSjUuE08f/aya fZZA== X-Received: by 10.181.8.66 with SMTP id di2mr2889522wid.43.1393598713218; Fri, 28 Feb 2014 06:45:13 -0800 (PST) Received: from [192.168.3.111] ([41.87.105.66]) by mx.google.com with ESMTPSA id ux5sm4892138wjc.6.2014.02.28.06.45.11 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 28 Feb 2014 06:45:12 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_1A385CB4-D8B3-428A-A890-6F5F55A873CA"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Paul M In-Reply-To: Date: Fri, 28 Feb 2014 17:45:07 +0300 Message-Id: <6063E219-33FC-421B-9E46-F194638B6BAA@gmail.com> References: To: Warren Kumari X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/sa-9XnHZDGlq8CbCxnFeS1CbuC4 Cc: "" Subject: Re: [dane] DANE Agenda 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, 28 Feb 2014 14:45:21 -0000 --Apple-Mail=_1A385CB4-D8B3-428A-A890-6F5F55A873CA Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Thanks Warren! will do. On 18/02/2014, at 6:30 pm, Warren Kumari wrote: > Hi all. > > Please find the updated agenda. > > We have 6 or 7 drafts on the agenda this time. Please read them ahead > of time so you can be primed with (intelligent!) questions :-) > > W > > DANE > ------------- > Administrivia > (Sit down, blue-sheets, agenda bashing) > Warren / Ondrej - 5 minutes. > > DANE - key acquisition, service discovery or usage assurance? > Paul Hoffman - 30 minutes > > Using DANE to Associate OpenPGP public keys with email addresses > draft-wouters-dane-openpgp-01 > Discuss draft updates / issues, quick demo > Paul Wouters - 10 minutes > > IPSECKEY / Auth_none > draft-smyslov-ipsecme-ikev2-null-auth-00 > Paul Wouters - 20 minutes > > Using DNS-Based Authentication of Named Entities (DANE) TLSA records > with SRV and MX records. > draft-ietf-dane-srv-05 > Peter Saint-Andre or Matt Miller - 20 min > > Harmonizing how applications specify DANE-like usage > draft-ogud-dane-vocabulary-01 > (Quick update) > Olafur - 5 min > > SMTP security via opportunistic DANE TLS > draft-ietf-dane-smtp-with-dane-06 > (NOTE: This is in WGLC.) > Wes Hardaker - 20 minutes. > > DANE TLSA implementation and operational guidance > draft-ietf-dane-ops-02 > Wes Hardaker - 15 minutes. > > Provisional: > Opportunistic Encryption with DANE Semantics and IPsec: IPSECA > draft-osterweil-dane-ipsec > Eric Osterweil - 10 minutes. > (Only if we have time remaining). > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane --Apple-Mail=_1A385CB4-D8B3-428A-A890-6F5F55A873CA Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBAgAGBQJTEKD0AAoJEMoHare3umgsL6IQAInAAWkOoVCJdLKVNrccMtoj ZslMkll2qYlJ9DEFuF7mcV4l6SWC7/jOEJOrgh7BN/G0h4JUA1ChzTXegcxPlC9A FJ7CdumSZFPKA23rCBzY9EIGUbZwYf3xsNixw8cnMEgbqgvjR/In5eH+tyBiL2kN EJSJwH11pfG0GfnBiGSYma65fXAq8CVfg26S+Dt/60z3xV7WE/VsScFERwzfHGMh Zs+P/eCpfo9bgoJlSAGb3y0y+jv8MAmj+/61b5e/XvxWmzBg/XG2uoi0tDPgfaBJ Za98kInXrSavYaMg7OIGoCSH+zNWD1GqGM6ifIo4rKLHqIVTicp+b2M3rN59otEt bVSZLsR1JCf0mcUjNCvdMUkqU9f+8weZE4TvGHVaFzwepS80yjhUzTVH+FxEPW18 1YZz9NujSSVh3PBxC8ICQdVVoj6ni7cB9ZX+xeVzuhfXQVsPROSB0XjfliT9qbbM gw3TquqOKAhsMATHMKmHkMCW+ibyuxjWF3SMLHqfelzjJajmy1f/6s2ZYs5DWBTJ DEadhXoRbf6fym1e5uKl9/1k+ajEHRs0nFpjm6aO9i70kL5J+k52b4iKvKl4NSPx ODw15c4GF3qgYEc5YqxyMQ2Wyyg/PgQO8E3AD9VNNQDuxgn8tdsUzl6lwgVnB3QD gby4yuRJuMCkTjcfzHrI =thNc -----END PGP SIGNATURE----- --Apple-Mail=_1A385CB4-D8B3-428A-A890-6F5F55A873CA-- From nobody Fri Feb 28 11:05:09 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 4188E1A01EF for ; Fri, 28 Feb 2014 11:05:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.019 X-Spam-Level: * X-Spam-Status: No, score=1.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, RDNS_NONE=0.793, SPF_SOFTFAIL=0.665, T_TVD_MIME_NO_HEADERS=0.01] 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 ChLth6iUK7GA for ; Fri, 28 Feb 2014 11:05:05 -0800 (PST) Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id D0F771A016C for ; Fri, 28 Feb 2014 11:05:04 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 8F6B02002C for ; Fri, 28 Feb 2014 15:23:20 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 0863F647C9; Fri, 28 Feb 2014 14:05:00 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id E142463AB2 for ; Fri, 28 Feb 2014 14:05:00 -0500 (EST) From: Michael Richardson To: dane WG list In-Reply-To: References: X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/dane/HCu1FeI-evKnr8N0Cf8okVZIbjc Subject: Re: [dane] An AD bit discussion 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, 28 Feb 2014 19:05:08 -0000 --=-=-= Paul Wouters wrote: > 1 Applications can either do dnssec validation themselves, or trust the > AD bit. > 2 It is undesirable that each application has its own DNSSEC validation > code, trust anchors and DNS cache. > 3 It is undesirable that applications blindly trust the AD bit when > resolv.conf points to another host as the AD bit could have been modified > on the network. > 4 In the ideal world tomorrow, each host has its own automatically > configured, perfectly working validing DNS server and resolv.conf can > be ignored or is always hardcoded with nameserver 127.0.0.1 My problem isn't that the AD is insecure, but that it isn't very useful. Going back 10 years to the various DNSSEC workshops, one of the things that I wanted was more information about why there was a validation failure. For instance, if I have previously contacted example.com, and I have it's A/AAAA or more interestingly, the DANE borne public key for the service I want to reach cached, or leap-of-faith'ed, I don't care as much if the DNSSEC fails to validate because a signature expired. If it fails to validate because the data is correct, I expect the bad data to be discarded, and for it to try again. At some point (<<5s) the application needs to get some kind of report that name is not presently available. (Happy eyeballs, or some other mechanism might want to try something else) This is doubly true if I have contact with the user who can I can: a) advise of the specific reason for the failure (which up to now, would be followed by facepalm and one of geeks goes to fix the problem....) b) find out what they want to do now. SERVFAIL / "Host now found" is simply not acceptable information. For this reason, I think that applications should not set or depend upon the AD bit, even if the resolver is ::1. They either understand DNS(SEC), or they use an API call way more sophisticated than getaddrinfo() to do their connections. Java had the right idea, but the implementation and error reporting was very poor. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting for hire =- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUxDd2oqHRg3pndX9AQJrUAP+L8UBp3l5jZHPKVS2AaMDED4wFVc168+j AGXCnO5YCKH2FVVSQq0UU7P+f+LCOwkAcpD11hbnaIBJdv4eaAdCcd6ljRSSlTJ0 Ck+D94gfEz4hQn9jMRQeYmr4hwIRXHwgaCgsiXuHiuHanDZo7jMU/Uv1c3H9+LMI HoIGSz6NoBE= =CECB -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Feb 28 11:56: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 F05591A0286 for ; Fri, 28 Feb 2014 11:56:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.55 X-Spam-Level: X-Spam-Status: No, score=-5.55 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, 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 ZasCFKks_DIK for ; Fri, 28 Feb 2014 11:56:15 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 3496F1A01F6 for ; Fri, 28 Feb 2014 11:56:15 -0800 (PST) Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s1SJuB3H021705 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 28 Feb 2014 14:56:12 -0500 Received: from [10.3.113.6] ([10.3.113.6]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s1SJuAja003273; Fri, 28 Feb 2014 14:56:10 -0500 From: Simo Sorce To: Michael Richardson In-Reply-To: <912.1393614300@sandelman.ca> References: <912.1393614300@sandelman.ca> Content-Type: text/plain; charset="UTF-8" Organization: Red Hat, Inc. Date: Fri, 28 Feb 2014 14:56:10 -0500 Message-ID: <1393617370.22047.22.camel@willson.li.ssimo.org> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/3AhTJqhJ2bDLdgQWSxCSiZc5Yqc Cc: dane WG list Subject: Re: [dane] An AD bit discussion 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, 28 Feb 2014 19:56:17 -0000 On Fri, 2014-02-28 at 14:05 -0500, Michael Richardson wrote: > Paul Wouters wrote: > > 1 Applications can either do dnssec validation themselves, or trust the > > AD bit. > > > 2 It is undesirable that each application has its own DNSSEC validation > > code, trust anchors and DNS cache. > > > 3 It is undesirable that applications blindly trust the AD bit when > > resolv.conf points to another host as the AD bit could have been modified > > on the network. > > > 4 In the ideal world tomorrow, each host has its own automatically > > configured, perfectly working validing DNS server and resolv.conf can > > be ignored or is always hardcoded with nameserver 127.0.0.1 > > My problem isn't that the AD is insecure, but that it isn't very useful. > Going back 10 years to the various DNSSEC workshops, one of the things that I > wanted was more information about why there was a validation failure. > > For instance, if I have previously contacted example.com, and I have > it's A/AAAA or more interestingly, the DANE borne public key for the service > I want to reach cached, or leap-of-faith'ed, I don't care as much if the > DNSSEC fails to validate because a signature expired. > > If it fails to validate because the data is correct, I expect the bad data to > be discarded, and for it to try again. At some point (<<5s) the application > needs to get some kind of report that name is not presently available. > (Happy eyeballs, or some other mechanism might want to try something else) > > This is doubly true if I have contact with the user who > can I can: > a) advise of the specific reason for the failure > (which up to now, would be followed by facepalm and one of geeks > goes to fix the problem....) > > b) find out what they want to do now. > > SERVFAIL / "Host now found" is simply not acceptable information. > > For this reason, I think that applications should not set or depend upon the > AD bit, even if the resolver is ::1. They either understand DNS(SEC), or > they use an API call way more sophisticated than getaddrinfo() to do their > connections. Java had the right idea, but the implementation and error > reporting was very poor. Nothing in this proposal prevents you from doing that for applications you care about. OTOH forcing applications to a completely new API by refusing this proposal on your grounds will guarantee less applications will use DNSSEC. And DNSEC support will rapidly fragment making system-wide management a lot more difficult. I think that prospect is a much worse evil. Simo. -- Simo Sorce * Red Hat, Inc * New York From nobody Fri Feb 28 17:48:54 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 5477E1A03A1 for ; Fri, 28 Feb 2014 17:48:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.569 X-Spam-Level: X-Spam-Status: No, score=-0.569 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_MISMATCH_NET=0.311, MISSING_HEADERS=1.021, 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 RU_vvcX5HFqL for ; Fri, 28 Feb 2014 17:48:52 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) by ietfa.amsl.com (Postfix) with ESMTP id 8AE051A0389 for ; Fri, 28 Feb 2014 17:48:52 -0800 (PST) Received: from sandelman.ca (CPE001b2128d5c4-CM185933427c47.cpe.net.cable.rogers.com [99.240.152.175]) by relay.sandelman.ca (Postfix) with ESMTPS id 146492207A for ; Fri, 28 Feb 2014 20:48:50 -0500 (EST) Received: from sandelman.ca (quigon.sandelman.ca [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 5D388CA0D7 for ; Fri, 28 Feb 2014 20:48:49 -0500 (EST) From: Michael Richardson cc: dane WG list In-reply-to: <912.1393614300@sandelman.ca> References: <912.1393614300@sandelman.ca> Comments: In-reply-to Michael Richardson message dated "Fri, 28 Feb 2014 14:05:00 -0500." X-Mailer: MH-E 8.2; nmh 1.3; GNU Emacs 23.4.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Fri, 28 Feb 2014 20:48:49 -0500 Message-ID: <16661.1393638529@sandelman.ca> Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/dane/ai_045857tSZVC8_wlzFu98ACJA Subject: Re: [dane] An AD bit discussion 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, 01 Mar 2014 01:48:53 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable Michael Richardson wrote: > If it fails to validate because the data is correct, I expect the bad should read; > If it fails to validate because the data is corrupt, I expect the bad =2D-=20 Michael Richardson =2Don the road- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBAgAGBQJTETx/AAoJEKD0KQ7Gj3P2whYH/iBz28u4dzprfrTrJQpaXjxV ZGIRiz92HU1EL1/8ReGDew4LN7XS8+HYgjR+XhybMP08+vqXjXX1wsLcg8RZW1/k rhr58/2UMK0/1U99fUPvFA70FFkU9obxf6ga76yHIMHCMGYOYWshMlC7MkobgmTN S05QDpdGIWl2gM1k8hX7UFeCFxw8M6IV2DcOphcwAy3ZPfxJmWlnGVxCXg+q3fP6 3FAJSLE5ebBFpHk9HraAYv+POWjahSjSBSasiIUe2wWpsFHl9iIZ5DkZiqY2rbPh 3REAF2Nvsn1GNHgy4Q3CbQEMjLyJW3sUgsYv8eGZqhCScUgzIGjuL6wTi5sKSkk= =ZS/x -----END PGP SIGNATURE----- --=-=-=--