From nobody Sat Nov 1 13:38: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 F01C11A00BF for ; Sat, 1 Nov 2014 13:38:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.079 X-Spam-Level: X-Spam-Status: No, score=-3.079 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URI_HEX=1.122] 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 IDWwpjqMVuMA for ; Sat, 1 Nov 2014 13:38:47 -0700 (PDT) Received: from exprod6og117.obsmtp.com (exprod6og117.obsmtp.com [64.18.1.39]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D59071A0016 for ; Sat, 1 Nov 2014 13:38:46 -0700 (PDT) Received: from brn1lxmailout02.vcorp.ad.vrsn.com ([72.13.63.42]) (using TLSv1) by exprod6ob117.postini.com ([64.18.5.12]) with SMTP ID DSNKVFVE1qUv5XmPXpAHrHD61zgsFaElh58K@postini.com; Sat, 01 Nov 2014 13:38:46 PDT Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02.vcorp.ad.vrsn.com [10.173.152.206]) by brn1lxmailout02.vcorp.ad.vrsn.com (8.13.8/8.13.8) with ESMTP id sA1KcjCp031888 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sat, 1 Nov 2014 16:38:45 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Sat, 1 Nov 2014 16:38:44 -0400 From: "Osterweil, Eric" To: "dane@ietf.org" Thread-Topic: [dane] draft-ietf-dane-smime Thread-Index: AQHP2+CXduy9obN06UaH3lWvHXXI5ZxKvpuAgAAs6gCAAcejgA== Date: Sat, 1 Nov 2014 20:38:44 +0000 Message-ID: References: <273F9612-13AF-4CB8-B15C-912AAD04C738@verisign.com> <39C76846-F695-435D-9A5C-6989D06E9573@verisign.com> <20141031172840.GM19103@mournblade.imrryr.org> In-Reply-To: <20141031172840.GM19103@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: <5A31BEFFB988AE4D87859BC899046FCC@verisign.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/QCD6YWKks_3la82kjIAO3NZWHNI Subject: Re: [dane] 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, 01 Nov 2014 20:38:50 -0000 On Oct 31, 2014, at 1:28 PM, Viktor Dukhovni wrote= : > On Fri, Oct 31, 2014 at 02:47:19PM +0000, Osterweil, Eric wrote: >=20 >> 4 or REJECT -- REJECT is used by the domain owner to assert that at >> the time of querying the DNS, this user's certificate MUST be consider= ed >> invalid for the requested function (i.e. signature or encryption). >> This is a stronger assertion than a failed certificate validation chec= k. >> Possible usage scenarios include de-authorizing stale employee >> credentials by selectively overriding TAs that are used to authorize >> entire organizations. >=20 > Which certificate is being invalidated? Why is this needed? What's > wrong with publishing a "3 1 1" association with an impossible key? Thanks for sending this note! The idea here is to say, ``this specific key= (which an RP may or may not have used before) is not to be used for this i= nbox, at this time.'' An impossible key just means _that_ key can=92t be u= sed. This idea isn=92t trying to disable an email inbox, just ensure that = a key that may pass (or may have passed, once upon a time) other verificati= on is unambiguously de-authorized. >=20 > $ openssl dgst -sha256 (stdin)=3D e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b785= 2b855 >=20 > ;; User's public key cannot be empty, so will never match this record. > ;; > 1c190a039a9c355fba9eb653eb52cd64e2fbe76db2588fc5a2b5c5d4._sign._smimec= ert.example.com. IN SMIMEA ( DANE-EE SPKI SHA2-256 e3b0c44298fc1c149afbf4c= 8996fb92427ae41e4649b934ca495991b7852b855 ) >=20 >> 2.1.4. Certificate Access Field >>=20 >> This one octet value indicates an alternative method for certificate >> discovery. Some domain owners may not want to publish user >> certificates via DNS but may want to use the DNS to advertise the >> means to access them. If full user certificates are not included in >> the Certificate Association Data this field MAY be used to indicate >> how the user's certificate can be obtained. The RDATA certificate >> association data MUST be used to validate certificates obtained by >> the alternative method. >>=20 >> 0 or NO: No alternative method advertised. >>=20 >> 1 or NAPTR : NAPTR record available. The same domain name used >> for this SMIMEA request MAY be used again with type NAPTR >> [RFC3403] to retrieve the URI for certificate access. >>=20 >> 2 or WF: X.509 certificates available in WebFinger [RFC7033]. >=20 > Once this field is not "NO", what is the meaning of the associated > data field carried with such a record? Is it still providing a > valid DANE association? Yeah, I would say so. I think this is the case most akin to the TLSA model= . I would say: 0 =3D=3D use TLSA-style DANE 1 =3D=3D look for info from a service that is described by NAPTR 2 =3D=3D Look for info served from a WebFinger service. > If so, when would one also need to use the "alternative access=94? I think this would allow the provisioning system to either put certs in DNS= , or put them elsewhere and have DNS point to where. I=92m not sure I=92m = answering your question though? > If not, how is this a DANE SMIMEA record? At the very least changing > the semantics of the associated data should lead to a new selector > or usage, but more likely an entirely separate DNSSEC validated > record, at which point the application can just query for these > alternative records if it sees fit. Why does SMIMEA need to > explicitly signal the use of other mechanisms? I don=92t understand this comment, but I think it stems from a miscommunica= tion above. This field would be used to say, ``look over there for the cer= t.=92=92 If the cert info is encoded in SMIMEA, or its retrieval is outsid= e of the DANE scope (i.e., the cert is included in an email message), then = this field is left as 0 (not used). Does that make more sense? Eric= From nobody Sat Nov 1 16:33: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 5E6501A1BA4 for ; Sat, 1 Nov 2014 16:33:26 -0700 (PDT) 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_31=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 ntWoKBPjYmUu for ; Sat, 1 Nov 2014 16:33:24 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B37CE1A1B9E for ; Sat, 1 Nov 2014 16:33:24 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id BE3552AAD9C; Sat, 1 Nov 2014 23:33:22 +0000 (UTC) Date: Sat, 1 Nov 2014 23:33:22 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20141101233322.GU19103@mournblade.imrryr.org> References: <273F9612-13AF-4CB8-B15C-912AAD04C738@verisign.com> <39C76846-F695-435D-9A5C-6989D06E9573@verisign.com> <20141031172840.GM19103@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/iNW2LhsZSE5vTHO25anwFkETbwk Subject: Re: [dane] 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: Sat, 01 Nov 2014 23:33:26 -0000 On Sat, Nov 01, 2014 at 08:38:44PM +0000, Osterweil, Eric wrote: > > Which certificate is being invalidated? Why is this needed? What's > > wrong with publishing a "3 1 1" association with an impossible key? > > Thanks for sending this note! The idea here is to say, ``this > specific key (which an RP may or may not have used before) is not > to be used for this inbox, at this time.'' An impossible key just > means _that_ key can?t be used. This idea isn?t trying to disable > an email inbox, just ensure that a key that may pass (or may have > passed, once upon a time) other verification is unambiguously > de-authorized. Well, in *that* case the association data MUST be the leaf digest! At least that would comport much better with the other DANE usages, and allow selective "revocation" of one or more records. However, it seems to me that *any* record which does not match the current SMIME RR is implicitly invalid to valid new messages. What purpose does "reject" serve? > > Once this field is not "NO", what is the meaning of the associated > > data field carried with such a record? Is it still providing a > > valid DANE association? > > Yeah, I would say so. I think this is the case most akin to the TLSA model. I would say: > 0 == use TLSA-style DANE > 1 == look for info from a service that is described by NAPTR > 2 == Look for info served from a WebFinger service. What is the meaning of the associated *DATA* field? Why should this be an SMIMEA record. I think this is misuse of that record. > I don?t understand this comment, but I think it stems from a miscommunication above. This field would be used to say, ``look over there for the cert.?? If the cert info is encoded in SMIMEA, or its retrieval is outside of the DANE scope (i.e., the cert is included in an email message), then this field is left as 0 (not used). > > Does that make more sense? No. The alternate sources can be published and the application can look there if it sees fit. -- Viktor. From nobody Fri Nov 7 14:18: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 AC1A91A07BE for ; Fri, 7 Nov 2014 14:18:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.895 X-Spam-Level: X-Spam-Status: No, score=-2.895 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594] 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 OHer7YEHbqsq for ; Fri, 7 Nov 2014 14:18:20 -0800 (PST) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B09A51A1B62 for ; Fri, 7 Nov 2014 14:18:19 -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.210.2; Fri, 7 Nov 2014 17:17:49 -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.377.0; Fri, 7 Nov 2014 17:18:14 -0500 Received: from [127.0.0.1] (114-140.antd.nist.gov [129.6.140.114]) by postmark.nist.gov (8.13.8/8.13.1) with ESMTP id sA7MI4kT029515; Fri, 7 Nov 2014 17:18:06 -0500 Message-ID: <545D451C.60507@nist.gov> Date: Fri, 7 Nov 2014 17:18:04 -0500 From: Stephen Nightingale User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-NIST-MailScanner-Information: Archived-At: http://mailarchive.ietf.org/arch/msg/dane/TqiNpnycCd2GUwC0lL2gOIgg4Tk Cc: proj-had , =?ISO-8859-1?Q?Sm=E1ri_McCarthy?= Subject: [dane] DANE/OpenPGP Test System 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 Nov 2014 22:18:22 -0000 The DANE/OpenPGP test system at https://www.had-pilot.com/openpgp/himitsu.html is operational. It has been tested against enigmail with Thunderbird, Mailvelope with Gmail, and a local Pythonic wrapper around GnuPG. We would like interaction with many, many more OpenPGP capable clients. Anybody who has Mailpile.is going is especially encouraged to test here. Ideally you will feel encouraged to implement the IETF draft for OpenPGP, deploy your public key in an RRtype 61 record, and fire off tests from your client. But you can also test by sending your public key in an email to tester@openpgp.had-pilot.biz with subject: openpgp pubkey, and you will get the tester's public key in return. Other tests are specified by the subject: openpgp ping openpgp pubkey openpgp request mykey openpgp delete mykey openpgp signed openpgp encrypted openpgp signed and encrypted openpgp request sign openpgp request encrypt openpgp request sign and encrypt At best, this will be a DANE tester, and at least it will be an exerciser for your use of a new or existing openpgp capable email client. Feedback to stephen.nightingale@nist.gov please. Also let me know if you want to bring additional mail clients to our attention. Cheers, Sn. From nobody Fri Nov 7 16:08: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 C64231A0032 for ; Fri, 7 Nov 2014 16:08:04 -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 41GZ00lQ846z for ; Fri, 7 Nov 2014 16:08:00 -0800 (PST) Received: from mail.bortzmeyer.org (aetius.bortzmeyer.org [IPv6:2001:4b98:dc0:41:216:3eff:fece:1902]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52B6A1A0049 for ; Fri, 7 Nov 2014 16:08:00 -0800 (PST) Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 4A2BF3BA49; Sat, 8 Nov 2014 01:07:58 +0100 (CET) Received: by tyrion (Postfix, from userid 1000) id 9B02FF01300; Sat, 8 Nov 2014 00:29:15 +0100 (CET) Date: Fri, 7 Nov 2014 15:29:15 -0800 From: Stephane Bortzmeyer To: dane@ietf.org Message-ID: <20141107232915.GA31913@laperouse.bortzmeyer.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Transport: UUCP rules X-Operating-System: Ubuntu 14.04 (trusty) User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/Gjy_JCWszwjODK0gYO9-T9gw5Cs Subject: [dane] Two additions to draft-york-dane-deployment-observations-00 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 Nov 2014 00:08:05 -0000 I've just read draft-york-dane-deployment-observations-00 and I would like to add two things to the list in section 2, "Observations", list of reasons why people don't deploy DANE. These additions come from my experience trying to promote the use of DANE. The first one is that some people distrust the domain name industry and feel that it is not safe to exchange the CA for the domain name actors (some of them having bad reputations like G... D...). Now, we all know it is more complicated than that (usages PKIX-* do not required that you drop the CA system, but on the other hand, some people fear that, if DANE is in the browser, the registrar, registry or the DNS hoster may be able to divert your users to a false site, something they could not do before). I don't say that I follow this reasoning but I've heard it several times so it could be documented. The second one is the lack of monitoring solutions. DANE brings some new risks of discrepancies (people renewing the certificate and forgetting to update the TLSA record for the *-EE usages...) since the people who manage the certs may not be the same who manage the DNS. We really need Nagios plugins to monitor DANE sites. Unlike the first reason given above, I strongly buy this one. From nobody Fri Nov 7 18:40: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 EE82A1A0145 for ; Fri, 7 Nov 2014 18:40:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.1 X-Spam-Level: X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, J_CHICKENPOX_65=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 HCmWXJ9g48G6 for ; Fri, 7 Nov 2014 18:40:19 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32E771A0143 for ; Fri, 7 Nov 2014 18:40:19 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 6FEA32AAC96; Sat, 8 Nov 2014 02:40:18 +0000 (UTC) Date: Sat, 8 Nov 2014 02:40:18 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20141108024018.GD161@mournblade.imrryr.org> References: <20141107232915.GA31913@laperouse.bortzmeyer.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141107232915.GA31913@laperouse.bortzmeyer.org> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/ax1ZSBQAActI-Bc_5pCzW7NfnnU Subject: Re: [dane] Two additions to draft-york-dane-deployment-observations-00 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 Nov 2014 02:40:21 -0000 On Fri, Nov 07, 2014 at 03:29:15PM -0800, Stephane Bortzmeyer wrote: > The second one is the lack of monitoring solutions. DANE brings some > new risks of discrepancies (people renewing the certificate and > forgetting to update the TLSA record for the *-EE usages...) since the > people who manage the certs may not be the same who manage the DNS. We > really need Nagios plugins to monitor DANE sites. Unlike the first > reason given above, I strongly buy this one. Funny you should mention that. That's something I'm working on, and at least for SMTP with DANE. Some of the early adopter domains I've been curating are getting DNSSEC wrong. The forget to re-sign, or secondaries fall out of sync, or nameservers are buggy, ... I've also seen some validation failures with BIND 9.10.1 as the validating resolver that I don't see with unbound. The monitoring is at the DANE layer, getting detailed diagnostics from DNSSEC validation errors would also be useful, but I don't have the tools handy for that, "drill -S" is almost the right tool, but I'm open for recommendations of validators that describe problems more simply and concisely than: $ drill -S -D -t tlsa _25._tcp.fuhrt.de. ;; Number of trusted keys: 1 ;; Chasing: _25._tcp.fuhrt.de. TLSA DNSSEC Trust tree: _25._tcp.fuhrt.de. (TLSA) |---Error in denial of existence: RR not covered by the given NSEC RRs |---cgokmsudli89pi41egv37cvqrq5bfug3.fuhrt.de. (NSEC3) | |---fuhrt.de. (DNSKEY keytag: 22118 alg: 7 flags: 256) | |---fuhrt.de. (DNSKEY keytag: 10069 alg: 7 flags: 257) | |---fuhrt.de. (DS keytag: 10069 digest type: 2) | |---de. (DNSKEY keytag: 56395 alg: 8 flags: 256) | |---de. (DNSKEY keytag: 24220 alg: 8 flags: 257) | |---de. (DS keytag: 24220 digest type: 2) | |---. (DNSKEY keytag: 22603 alg: 8 flags: 256) | |---. (DNSKEY keytag: 19036 alg: 8 flags: 257) |---Error in denial of existence: RR not covered by the given NSEC RRs |---2q3imqr0q2dntoohifcm0a6or78lropv.fuhrt.de. (NSEC3) |---fuhrt.de. (DNSKEY keytag: 22118 alg: 7 flags: 256) |---fuhrt.de. (DNSKEY keytag: 10069 alg: 7 flags: 257) |---fuhrt.de. (DS keytag: 10069 digest type: 2) |---de. (DNSKEY keytag: 56395 alg: 8 flags: 256) |---de. (DNSKEY keytag: 24220 alg: 8 flags: 257) |---de. (DS keytag: 24220 digest type: 2) |---. (DNSKEY keytag: 22603 alg: 8 flags: 256) |---. (DNSKEY keytag: 19036 alg: 8 flags: 257) No trusted keys found in tree: first error was: RR not covered by the given NSEC RRs ;; Chase failed. So we've not yet shaken out all the DNSSEC implementation and operational errors. On the DANE front, some users are confused about the difference between the Cert(0) vs SPKI(1) selector, and occasionally forget to update TLSA RRs when keys are rotated. The raw scan for ietf.org reads: ietf.org. IN MX 0 mail.ietf.org. mail.ietf.org. IN A 4.31.198.44 _25._tcp.mail.ietf.org. IN TLSA 3 1 1 0c72ac70b745ac19998811b131d662c9ac69dbdbe7cb23e5b514b56664c5d3d6 ;; SSL: protocol = TLSv1.2, cipher = ECDHE-RSA-AES256-GCM-SHA384 (256 bits) ;; Passed(depth 0): mail.ietf.org. IN TLSA 3 1 1 0c72ac70b745ac19998811b131d662c9ac69dbdbe7cb23e5b514b56664c5d3d6 -- Viktor. From nobody Fri Nov 7 23:17: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 B2F601A1A27 for ; Fri, 7 Nov 2014 23:17:22 -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 bvuybBn1E_jk for ; Fri, 7 Nov 2014 23:17:21 -0800 (PST) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id D2E781A1A07 for ; Fri, 7 Nov 2014 23:17:18 -0800 (PST) Received: from [192.168.40.29] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 7933F93C1AF; Sat, 8 Nov 2014 07:16:56 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: "Olle E. Johansson" In-Reply-To: <20141107232915.GA31913@laperouse.bortzmeyer.org> Date: Sat, 8 Nov 2014 08:17:15 +0100 Content-Transfer-Encoding: 7bit Message-Id: <6DB8CC95-E47A-4C0B-BC0B-7D9A4F8F65B5@edvina.net> References: <20141107232915.GA31913@laperouse.bortzmeyer.org> To: Stephane Bortzmeyer X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/mt3ZsO3A9edNMOCahMOPwcIfvEQ Cc: dane@ietf.org Subject: Re: [dane] Two additions to draft-york-dane-deployment-observations-00 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 Nov 2014 07:17:22 -0000 On 08 Nov 2014, at 00:29, Stephane Bortzmeyer wrote: > We > really need Nagios plugins to monitor DANE sites https://github.com/opendnssec/dnssec-monitor Nagios scripts to monitor DNSsec zones :-) /O From nobody Sat Nov 8 19:33: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 36A851A017E for ; Sat, 8 Nov 2014 19:33:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.346 X-Spam-Level: X-Spam-Status: No, score=-0.346 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_SE=0.35, RP_MATCHES_RCVD=-0.594, 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 lZruDOZJU_6s for ; Sat, 8 Nov 2014 19:33:21 -0800 (PST) Received: from spg.kirei.se (spg.kirei.se [IPv6:2001:67c:394:15::9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E658B1A0113 for ; Sat, 8 Nov 2014 19:33:20 -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=uJITlCBWbt2KcPInsGu/jTCh9BYRCINFupp3m+x2fLo=; b=y10WHv5xzrvPIMpy2Huda8vKQrn50BKlF/PSch/JgwRbFz2pR/32wafkR8KsSubbhlQYFwVyE3mbr EVSZXeBpSKFDvGXl1CK3Lo3WzhxVllmANGBgt40MtZ6RpEP5tP/8R8l1Sn89kUfHzdL+an0JL/2jLA 2TSZ3DCDSXLptRYo= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg-relay.kirei.se (Halon Mail Gateway) with ESMTPS for ; Sun, 9 Nov 2014 04:33:02 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Jakob Schlyter In-Reply-To: <20141101233322.GU19103@mournblade.imrryr.org> Date: Sat, 8 Nov 2014 17:32:57 -1000 Content-Transfer-Encoding: quoted-printable Message-Id: <798620D7-6F0A-445B-98D4-A90362711D47@kirei.se> References: <273F9612-13AF-4CB8-B15C-912AAD04C738@verisign.com> <39C76846-F695-435D-9A5C-6989D06E9573@verisign.com> <20141031172840.GM19103@mournblade.imrryr.org> <20141101233322.GU19103@mournblade.imrryr.org> To: dane@ietf.org X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/Z8ioRPoXBauJZiBRJJPGW2MyYfo Subject: Re: [dane] 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: Sun, 09 Nov 2014 03:33:23 -0000 On 1 nov 2014, at 13:33, Viktor Dukhovni wrote: >> Yeah, I would say so. I think this is the case most akin to the TLSA = model. I would say: >> 0 =3D=3D use TLSA-style DANE >> 1 =3D=3D look for info from a service that is described by NAPTR >> 2 =3D=3D Look for info served from a WebFinger service. >=20 > What is the meaning of the associated *DATA* field? Why should > this be an SMIMEA record. I think this is misuse of that record. I believe the CERT RR would be more appropriate for redirects to other = access methods. Or perhaps the proposed URI RR (draft-faltstrom-uri). The proposal is similar to publishing an MX RR with an extra option to = indicate that X.400 should be used for delivery. jakob From nobody Sat Nov 8 20:02: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 E7F7D1A033B for ; Sat, 8 Nov 2014 20:02:31 -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 UgwXHcR8HooL for ; Sat, 8 Nov 2014 20:02:29 -0800 (PST) Received: from mail.bortzmeyer.org (aetius.bortzmeyer.org [IPv6:2001:4b98:dc0:41:216:3eff:fece:1902]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EB4B1A0179 for ; Sat, 8 Nov 2014 20:02:29 -0800 (PST) Received: by mail.bortzmeyer.org (Postfix, from userid 10) id BA8CD3BC30; Sun, 9 Nov 2014 05:02:27 +0100 (CET) Received: by tyrion (Postfix, from userid 1000) id 58F3CF00CDB; Sat, 8 Nov 2014 19:59:25 -0800 (PST) Date: Sat, 8 Nov 2014 17:59:25 -1000 From: Stephane Bortzmeyer To: "Olle E. Johansson" Message-ID: <20141109035925.GA20946@laperouse.bortzmeyer.org> References: <20141107232915.GA31913@laperouse.bortzmeyer.org> <6DB8CC95-E47A-4C0B-BC0B-7D9A4F8F65B5@edvina.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6DB8CC95-E47A-4C0B-BC0B-7D9A4F8F65B5@edvina.net> X-Transport: UUCP rules X-Operating-System: Ubuntu 14.04 (trusty) User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/hkZuX0XQh8qNyt9FPAFKww65DQY Cc: dane@ietf.org Subject: Re: [dane] Two additions to draft-york-dane-deployment-observations-00 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, 09 Nov 2014 04:02:32 -0000 On Sat, Nov 08, 2014 at 08:17:15AM +0100, Olle E. Johansson wrote a message of 10 lines which said: > Nagios scripts to monitor DNSsec zones :-) I was not talking about DNSsec monitoring (I already use it, otherwise I would never have deployed DNSsec in production for serious domains) but about DANE monitoring: get the TLSA record, open a TLS connection, get the certificate, check that it is consistent with what the TLSA record announces. As far as I know, there is currently no software for that. From nobody Sat Nov 8 20:07: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 5E8841A034F for ; Sat, 8 Nov 2014 20:07:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.486 X-Spam-Level: X-Spam-Status: No, score=-0.486 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, URIBL_RHS_DOB=1.514] 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 DjAbSQJBQRFy for ; Sat, 8 Nov 2014 20:07:15 -0800 (PST) Received: from mail-pd0-x22c.google.com (mail-pd0-x22c.google.com [IPv6:2607:f8b0:400e:c02::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB0611A0278 for ; Sat, 8 Nov 2014 20:07:14 -0800 (PST) Received: by mail-pd0-f172.google.com with SMTP id r10so5704983pdi.17 for ; Sat, 08 Nov 2014 20:07:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=j8LtugJsb+wvxwz1oYh063GIvJwTwa7S8Lq8bQm4kjQ=; b=Hx+4GcG8csEi3kTW7fnEY6i+62KClbdaDuvwKzFFXipAw0g0ZDfb6GolV2s9jqhMzo p5IZA3zjqjdF0S2JS5vmO0RdbHoXyR8wE69Xf4JpfYFceCuuDVGCHAe/uDBtbxlPq+d3 1r07vKsVRNv9xhQzqX7mG5Ru8/2DADtCClKeekeFcNnaSwEcY05SMNWWJ6uz/4ffPupG RCVkchZvK4L38G1WtAV6kCsJpqAbCuu1X0ea9hCpPDRAPc8tVJdPwh1IR7Sp6xMlGP4j 7n2AGaKYHHShutz9ChWKnAKBXiiW2zQRwxGZ80gs/mJSmSNKAr/Wn79YSLDapY9J1JPJ TGOw== X-Received: by 10.66.160.74 with SMTP id xi10mr2771746pab.72.1415506034069; Sat, 08 Nov 2014 20:07:14 -0800 (PST) Received: from spandex.local (69-161-3-100-rb2.sol.dsl.dynamic.acsalaska.net. [69.161.3.100]) by mx.google.com with ESMTPSA id u1sm12792272pdj.29.2014.11.08.20.07.12 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 08 Nov 2014 20:07:12 -0800 (PST) Message-ID: <545EE86E.9050007@gmail.com> Date: Sat, 08 Nov 2014 19:07:10 -0900 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: dane@ietf.org References: <20141107232915.GA31913@laperouse.bortzmeyer.org> <6DB8CC95-E47A-4C0B-BC0B-7D9A4F8F65B5@edvina.net> <20141109035925.GA20946@laperouse.bortzmeyer.org> In-Reply-To: <20141109035925.GA20946@laperouse.bortzmeyer.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dane/y5YJvIAEYQ8pB7VJhHvW7ptDaeo Subject: Re: [dane] Two additions to draft-york-dane-deployment-observations-00 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, 09 Nov 2014 04:07:17 -0000 On 11/8/14 6:59 PM, Stephane Bortzmeyer wrote: > I was not talking about DNSsec monitoring (I already use it, otherwise > I would never have deployed DNSsec in production for serious domains) > but about DANE monitoring: get the TLSA record, open a TLS connection, > get the certificate, check that it is consistent with what the TLSA > record announces. Shumon Huque wrote something using the getdns Python bindings that may be close to what you're asking about: https://github.com/getdnsapi/getdns-python-bindings/blob/master/examples/checkdanecert.py Melinda From nobody Sat Nov 8 20:14: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 6674C1A0366 for ; Sat, 8 Nov 2014 20:14: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 Bp29RE6oyZPE for ; Sat, 8 Nov 2014 20:14:46 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49A0D1A0364 for ; Sat, 8 Nov 2014 20:14:46 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 4D8222AB109; Sun, 9 Nov 2014 04:14:44 +0000 (UTC) Date: Sun, 9 Nov 2014 04:14:44 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20141109041443.GJ161@mournblade.imrryr.org> References: <20141107232915.GA31913@laperouse.bortzmeyer.org> <6DB8CC95-E47A-4C0B-BC0B-7D9A4F8F65B5@edvina.net> <20141109035925.GA20946@laperouse.bortzmeyer.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141109035925.GA20946@laperouse.bortzmeyer.org> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/tfqBad7Ok3MuroFPvxcISciAV0o Subject: Re: [dane] Two additions to draft-york-dane-deployment-observations-00 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, 09 Nov 2014 04:14:47 -0000 On Sat, Nov 08, 2014 at 05:59:25PM -1000, Stephane Bortzmeyer wrote: > As far as I know, there is currently no software for that. I have code for that. It establishes the TLS connection via SMTP + STARTTLS, after finding TLSA RRs for a domain's MX hosts. Delete all the SMTP logic and you can test pure TLS too, though I'm aware of any real applications that combine straight TLS with DANE. What application protocols did you have in mind? -- Viktor. From nobody Sun Nov 9 16:55: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 A90641A87C3 for ; Sun, 9 Nov 2014 16:55:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.594 X-Spam-Level: X-Spam-Status: No, score=-2.594 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.594] 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 hnIHoh96b367 for ; Sun, 9 Nov 2014 16:55:09 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0AEE1A87E8 for ; Sun, 9 Nov 2014 16:55:09 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 95552817C1; Sun, 9 Nov 2014 19:55:08 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1415580908; bh=6Q52/dKSclKEOajpxRGzK/mRMWULBMf3ufzrZUwITjA=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=vHFHgn23YPks019pRqpcNRlLX5vAFwq/3reKBdr/6RHJ3wLJU8AN8uhSTPDIlpG6Z cPgFrqrCBDXNUicTwpZ9JYw278tsmegDoqgY/tLykLW0qyY/HZr5oawXDc01dBySHE 3NKQPso2rPyvA1t2L3uK1Va3xa4hNqTJEZy7ivL8= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id sAA0t8Ll010182; Sun, 9 Nov 2014 19:55:08 -0500 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Sun, 9 Nov 2014 19:55:07 -0500 (EST) From: Paul Wouters To: Stephane Bortzmeyer In-Reply-To: <20141107232915.GA31913@laperouse.bortzmeyer.org> Message-ID: References: <20141107232915.GA31913@laperouse.bortzmeyer.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/6CR_hL8qqYdsIipxg6vZ0nxBgwM Cc: dane@ietf.org Subject: Re: [dane] Two additions to draft-york-dane-deployment-observations-00 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, 10 Nov 2014 00:55:12 -0000 On Fri, 7 Nov 2014, Stephane Bortzmeyer wrote: > The first one is that some people distrust the domain name industry > and feel that it is not safe to exchange the CA for the domain name > actors (some of them having bad reputations like G... D...). Now, we > all know it is more complicated than that (usages PKIX-* do not > required that you drop the CA system, but on the other hand, some > people fear that, if DANE is in the browser, the registrar, registry > or the DNS hoster may be able to divert your users to a false site, > something they could not do before). I don't say that I follow this > reasoning but I've heard it several times so it could be documented. And for that, we bring you CT for DNSSEC. Go look at the presentation and be ready to give us feedback this monday at TRANS :) http://www.ietf.org/proceedings/91/slides/slides-91-trans-3.pdf Paul From nobody Sun Nov 9 21:36: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 4D8EF1A890D for ; Sun, 9 Nov 2014 21:36:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.594 X-Spam-Level: X-Spam-Status: No, score=-2.594 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.594] 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 TvNHK556xKab for ; Sun, 9 Nov 2014 21:36:43 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EDD61A040B for ; Sun, 9 Nov 2014 21:36:43 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 56A4D817C1; Mon, 10 Nov 2014 00:36:42 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1415597802; bh=C5IQE9Kg417vlQWOyPTBqbt1LNOEhLoQbErXWPFb02o=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=eAsIPHebGcYv+/u1MSzFvse1nAZy5EXdHDhKqLd0bqLyY+HbXSb31qK6hVKjrROZp KeaSqLxz+TbYmlnrhrbDdKKshNURy2ZaghbcsoFdJotwKRR4ycby142NndtksJpm1z nkMxAaEkY4OzLdcjONtsEwPON3M4cg7J6DKuX2tM= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id sAA5afsA012071; Mon, 10 Nov 2014 00:36:41 -0500 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Mon, 10 Nov 2014 00:36:41 -0500 (EST) From: Paul Wouters To: Stephane Bortzmeyer In-Reply-To: <20141109035925.GA20946@laperouse.bortzmeyer.org> Message-ID: References: <20141107232915.GA31913@laperouse.bortzmeyer.org> <6DB8CC95-E47A-4C0B-BC0B-7D9A4F8F65B5@edvina.net> <20141109035925.GA20946@laperouse.bortzmeyer.org> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-7; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: http://mailarchive.ietf.org/arch/msg/dane/q2d3ynKCt2gYpTV8g-0lxB7BiwU Cc: dane WG list Subject: Re: [dane] Two additions to draft-york-dane-deployment-observations-00 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, 10 Nov 2014 05:36:45 -0000 On Sat, 8 Nov 2014, Stephane Bortzmeyer wrote: > I was not talking about DNSsec monitoring (I already use it, otherwise > I would never have deployed DNSsec in production for serious domains) > but about DANE monitoring: get the TLSA record, open a TLS connection, > get the certificate, check that it is consistent with what the TLSA > record announces. https://www.dnssec-validator.cz/ DNSSEC/TLSA Validator is a web browser add-on which allows you to check the existence and validity of DNS Security Extensions (DNSSEC) records and Transport Layer Security Association (TLSA) records related to domain names. Results of these checks are displayed by using icons and information texts in the page˘s address-bar or browser tool-bar. Currently, Internet Explorer (IE), Mozilla Firefox (MF), Google Chrome/Chromium (GC), Opera (OP), Apple Safari (AS) are supported. From nobody Sun Nov 9 22:06: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 468111A8914 for ; Sun, 9 Nov 2014 22:05: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 twQXg4Sks3rZ for ; Sun, 9 Nov 2014 22:05:57 -0800 (PST) Received: from mail.bortzmeyer.org (aetius.bortzmeyer.org [217.70.190.232]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D29F1A8911 for ; Sun, 9 Nov 2014 22:05:57 -0800 (PST) Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 494CF3B95A; Mon, 10 Nov 2014 07:05:55 +0100 (CET) Received: by tyrion (Postfix, from userid 1000) id B9599F00992; Sun, 9 Nov 2014 22:00:54 -0800 (PST) Date: Sun, 9 Nov 2014 20:00:54 -1000 From: Stephane Bortzmeyer To: Paul Wouters Message-ID: <20141110060054.GA18320@laperouse.bortzmeyer.org> References: <20141107232915.GA31913@laperouse.bortzmeyer.org> <6DB8CC95-E47A-4C0B-BC0B-7D9A4F8F65B5@edvina.net> <20141109035925.GA20946@laperouse.bortzmeyer.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Transport: UUCP rules X-Operating-System: Ubuntu 14.04 (trusty) User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/BL3n6IJpgMthaam7VXqRr2E8_eA Cc: dane WG list Subject: Re: [dane] Two additions to draft-york-dane-deployment-observations-00 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, 10 Nov 2014 06:05:58 -0000 On Mon, Nov 10, 2014 at 12:36:41AM -0500, Paul Wouters wrote a message of 17 lines which said: > DNSSEC/TLSA Validator is a web browser add-on Not very practical to run automated and unattended tests, for instance from Nagios or similar. From nobody Sun Nov 9 22:28: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 CD6261A879F for ; Sun, 9 Nov 2014 22:28: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 651uaqCsK-Bl for ; Sun, 9 Nov 2014 22:28:10 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7858B1A88AE for ; Sun, 9 Nov 2014 22:28:10 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 80BB42AB109; Mon, 10 Nov 2014 06:28:08 +0000 (UTC) Date: Mon, 10 Nov 2014 06:28:08 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20141110062808.GQ161@mournblade.imrryr.org> References: <20141107232915.GA31913@laperouse.bortzmeyer.org> <6DB8CC95-E47A-4C0B-BC0B-7D9A4F8F65B5@edvina.net> <20141109035925.GA20946@laperouse.bortzmeyer.org> <20141110060054.GA18320@laperouse.bortzmeyer.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141110060054.GA18320@laperouse.bortzmeyer.org> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/1Am0vjKs1NbmnoyEtv5XqB_2OmU Subject: Re: [dane] Two additions to draft-york-dane-deployment-observations-00 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 Nov 2014 06:28:12 -0000 On Sun, Nov 09, 2014 at 08:00:54PM -1000, Stephane Bortzmeyer wrote: > On Mon, Nov 10, 2014 at 12:36:41AM -0500, > Paul Wouters wrote > a message of 17 lines which said: > > > DNSSEC/TLSA Validator is a web browser add-on > > Not very practical to run automated and unattended tests, for instance > from Nagios or similar. Are you going to test SMTP servers, HTTPS servers, or something else? And if HTTPS servers, why? (Despite lack of evidence of any substantive support for DANE in browsers, various experimental plugins notwithstanding). -- Viktor. From nobody Mon Nov 10 00:53: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 07F8F1A898C for ; Mon, 10 Nov 2014 00:53:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_41=0.6, J_CHICKENPOX_65=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 2AZUR2ZUg-x8 for ; Mon, 10 Nov 2014 00:53:08 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DAD01A894A for ; Mon, 10 Nov 2014 00:53:06 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id F41042AB109; Mon, 10 Nov 2014 08:53:03 +0000 (UTC) Date: Mon, 10 Nov 2014 08:53:03 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20141110085303.GS161@mournblade.imrryr.org> References: <20141107232915.GA31913@laperouse.bortzmeyer.org> <6DB8CC95-E47A-4C0B-BC0B-7D9A4F8F65B5@edvina.net> <20141109035925.GA20946@laperouse.bortzmeyer.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="zS7rBR6csb6tI2e1" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/2Hw2djM5uQRm1Zay1qDmFKH48zY Subject: Re: [dane] Two additions to draft-york-dane-deployment-observations-00 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 Nov 2014 08:53:10 -0000 --zS7rBR6csb6tI2e1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Nov 10, 2014 at 12:36:41AM -0500, Paul Wouters wrote: [ Speaking of deploy360, nobody is regularly testing the listed sites at: http://www.internetsociety.org/deploy360/resources/dane-test-sites/ For example, https://www.statdns.net/ no longer matches its TLSA record, presumably after key rotation without a TLSA RR update, since its certificate digest is different from the content of the "3 0 1" associated data. ] > https://www.dnssec-validator.cz/ > > DNSSEC/TLSA Validator is a web browser add-on which allows you to check > the existence and validity of DNS Security Extensions (DNSSEC) records > and Transport Layer Security Association (TLSA) records related to > domain names. Results of these checks are displayed by using icons and > information texts in the page?s address-bar or browser tool-bar. > Currently, Internet Explorer (IE), Mozilla Firefox (MF), Google > Chrome/Chromium (GC), Opera (OP), Apple Safari (AS) are supported. Browser plugins are a bit tricky to script. For scriptable code: $ git clone https://github.com/vdukhovni/ssl_dane $ git checkout wip-perl-module $ : edit Makefile if platform is not Linux $ make $ sudo make install $ cd Danessl $ : edit Makefile.PL if platform is not Linux $ perl Makefile.PL $ make $ sudo make install With the library and Perl module installed, the attached perl code can be used as shown in the shell fragment below: #! /bin/sh # At least one of SSL_CERT_FILE or SSL_CERT_DIR # must be set to a suitable cert store for PKIX-TA # and PKIX-EE to work. The OpenSSL built-in defaults # are disabled by ssldane.pl, you must elect them # explicitly. # export SSL_CERT_FILE=/etc/ssl/... # multi-cert CAfile export SSL_CERT_DIR=/etc/ssl/... # hashed CApath test_site() { echo "--- Testing $1..." perl ./ssldane.pl "$@" echo "--- Exit code: $?" echo } for site in good bad-hash bad-params bad-sig do test_site $site.dane.verisignlabs.com 443 done Note, the code requires a loopback (127.0.0.1) resolver that is a DNSSEC validating resolver (unbound is a good choice). Though for testing you can edit ssldane.pl and specify some other resolver address near the top of the file. Sample output: --- Testing good.dane.verisignlabs.com... ;; Passed(depth 0): good.dane.verisignlabs.com. IN TLSA 3 0 1 0332aa2d58b3e0544b65656438937068ba44ce2f14469c4f50c9cc6933c808d3 --- Exit code: 0 --- Testing bad-hash.dane.verisignlabs.com... ;; Failed: bad-hash.dane.verisignlabs.com. IN TLSA 3 0 1 9999999999999999999999999999999999999999999999999999999999999999: unable to get local issuer certificate: (20) --- Exit code: 1 --- Testing bad-params.dane.verisignlabs.com... ;; Failed: bad-params.dane.verisignlabs.com. IN TLSA 3 0 17 0332aa2d58b3e0544b65656438937068ba44ce2f14469c4f50c9cc6933c808d3: error processing TLSA RR ;; Failed: bad-params.dane.verisignlabs.com. IN TLSA 3 119 1 0332aa2d58b3e0544b65656438937068ba44ce2f14469c4f50c9cc6933c808d3: error processing TLSA RR ;; Failed: bad-params.dane.verisignlabs.com. IN TLSA 51 0 1 0332aa2d58b3e0544b65656438937068ba44ce2f14469c4f50c9cc6933c808d3: error processing TLSA RR --- Exit code: 1 --- Testing bad-sig.dane.verisignlabs.com... DNS Lookup failed: bad-sig.dane.verisignlabs.com IN A ?: SERVFAIL --- Exit code: 255 Digest agility support is not yet a feature of the underlying C library. So it should be added to the script, until the library support is in place. That's a TODO. -- Viktor. P.S. Your Net::SSLeay Perl module needs to be quite recent, get a newer one from CPAN if it does not understand the get_peer_cert_chain() method. The "Danessl.pm" Perl module is still in early development. Use at your own risk, no support or documentation beyond RTFS. The module code assumes (for no particular reason) that Perl is at least 5.12.5, likely earlier versions work too, adjust as necessary. --zS7rBR6csb6tI2e1 Content-Type: application/x-perl Content-Disposition: attachment; filename="ssldane.pl" Content-Transfer-Encoding: quoted-printable #! /usr/pkg/bin/perl -w=0A=0Ause warnings;=0Ause strict;=0A=0A# Set these t= o something else, otherwise PKIX-TA/PKIX-EE=0A# will always fail.=0A#=0A$EN= V{"SSL_CERT_FILE"} //=3D "/dev/null";=0A$ENV{"SSL_CERT_DIR"} //=3D "/dev/nu= ll";=0A=0Ause Socket qw(IPPROTO_TCP TCP_NODELAY);=0Ause IO::Socket;=0Ause I= O::Poll;=0Ause Time::HiRes qw(gettimeofday tv_interval);=0Ause Net::DNS;=0A= use Net::SSLeay qw(ERROR_WANT_READ ERROR_WANT_WRITE);=0Ause Danessl qw(USAG= E_DANE_TA USAGE_DANE_EE);=0A=0A# Delegate DNSSEC to local validating resolv= er!=0A#=0Amy @trustedns =3D qw(127.0.0.1); # Ideally 127.0.0.1=0Amy $ip6 = =3D 0; # ipv6 disabled=0A=0Ause constant {=0A NOTHOST =3D> 0,=0A = ISHOST =3D> 1,=0A SSL_CTRL_SET_TLSEXT_HOSTNAME =3D> 55,=0A};=0A=0Am= y $hostre =3D qr{^(?:xn--)?[a-z\d](?:-?[a-z\d]+)*$}io;=0Amy $domainre =3D q= r{^(?:xn--|_)?[a-z\d](?:-?[a-z\d]+)*$}io;=0A=0A# We ask for TYPE52 for port= ability, but might get "TLSA" in=0A# respose records from sufficiently mode= rn Net::DNS versions.=0A# This maps us back to the requested type.=0A#=0Amy= %DNSTYPE =3D ( "TLSA" =3D> "TYPE52", );=0A=0Amy $resolver =3D Net::DNS::Re= solver->new(nameservers =3D> [@trustedns]);=0A$resolver->defnames(0);=0A$re= solver->dnsrch(0);=0A$resolver->udppacketsize(8192); # Safe for local looku= ps=0A=0ANet::SSLeay::load_error_strings();=0ANet::SSLeay::SSLeay_add_ssl_al= gorithms();=0ANet::SSLeay::randomize();=0Amy $sslctx =3D Net::SSLeay::CTX_n= ew();=0Adie sprintf "Error creating SSL context: %s\n", ssl_error() if (! $= sslctx);=0A=0A# No legacy SSL 2.0/3.0 protocols.=0Amy $ssl_options =3D &Net= ::SSLeay::OP_ALL;=0A$ssl_options |=3D &Net::SSLeay::OP_NO_SSLv2;=0A$ssl_opt= ions |=3D &Net::SSLeay::OP_NO_SSLv3;=0ANet::SSLeay::CTX_set_options($sslctx= , $ssl_options);=0A=0A# We test with a restricted cipher suite list. While= some excluded=0A# cipher suites may work in some cases, servers should avo= id=0A# relying on them, and it is better to fail the test outright=0A# than= to fail with significant odds in real life.=0A#=0ANet::SSLeay::CTX_set_cip= her_list($sslctx, join(":",=0A "DEFAULT", # ALL:+RC4:!aNULL:!eNULL:@STR= ENGTH=0A "!RC4", # But not RC4=0A "!EXPORT", # At least medium= =0A "!LOW", # -"-=0A "!MD5", # Rules out all SSLv2 ciphers=0A= "!DSS", # Nobody should be using DSS/DSA by now=0A "!SEED", #= Too exotic=0A "!IDEA", # -"-=0A "!RC2", # -"-=0A "!kDHr", = # -"-=0A "!kDHd", # -"-=0A "!kECDHr", # -"-=0A "!kECDHe", = # -"-=0A));=0A=0Asub poll_wait {=0A my ($conn, $ev, $why) =3D @_;=0A = my $p =3D IO::Poll->new();=0A=0A die "$why\n" if $conn->{timeout} <=3D 0= ;=0A=0A my $t0 =3D [gettimeofday];=0A $p->mask($conn->{sock} =3D> $ev= );=0A $p->poll($conn->{timeout});=0A my $elapsed =3D int(1000 * tv_in= terval($t0));=0A $conn->{timeout} -=3D $elapsed if ($elapsed > 0);=0A=0A= $ev =3D $p->events($conn->{sock});=0A die "$why\n" if !defined($ev);= =0A}=0A=0Asub ssl_error {=0A Net::SSLeay::ERR_error_string(Net::SSLeay::= ERR_get_error());=0A}=0A=0Asub sslconnect {=0A my ($conn, $ssl) =3D @_;= =0A=0A $conn->{timeout} =3D 10000; # 10 sec deadline timer=0A LOOP: {= =0A return if ((my $status =3D Net::SSLeay::connect($ssl)) > 0);=0A die "SS= L shutdown on connect\n" if ($status =3D=3D 0);=0A my $err =3D Net::SSLeay:= :get_error($ssl, $status);=0A if ($err =3D=3D ERROR_WANT_READ) {=0A pol= l_wait($conn, POLLIN, "SSL connect timeout");=0A redo LOOP;=0A } elsif = ($err =3D=3D ERROR_WANT_WRITE) {=0A poll_wait($conn, POLLOUT, "SSL conn= ect timeout");=0A redo LOOP;=0A } else {=0A die sprintf "SSL connec= t error: %d: %s\n", $err, ssl_error();=0A }=0A }=0A}=0A=0Asub sslshutdow= n {=0A my ($conn) =3D @_;=0A my $ssl =3D delete $conn->{ssl};=0A m= y $once =3D 0;=0A=0A $conn->{timeout} =3D 10000; # 10 sec deadline timer= =0A LOOP: {=0A my $status =3D Net::SSLeay::shutdown($ssl);=0A last LOOP = if ($status =3D=3D 1);=0A redo LOOP if ($status =3D=3D 0 && ++$once =3D=3D = 1);=0A my $err =3D Net::SSLeay::get_error($ssl, $status);=0A if ($err =3D= =3D ERROR_WANT_READ) {=0A poll_wait($conn, POLLIN, "SSL shutdown timeou= t");=0A redo LOOP;=0A } elsif ($err =3D=3D ERROR_WANT_WRITE) {=0A p= oll_wait($conn, POLLOUT, "SSL shutdown timeout");=0A redo LOOP;=0A }=0A= }=0A Net::SSLeay::free($ssl);=0A}=0A=0Asub tls_version {=0A my ($= version) =3D @_;=0A=0A return "SSLv2" if ($version =3D=3D 0x0002);=0A = return "SSLv3" if ($version =3D=3D 0x0300);=0A return "TLSv1" if ($vers= ion =3D=3D 0x0301);=0A return sprintf "TLSv1.%d", ($version - 0x0301)=0A= if ($version > 0x0301 && $version <=3D 0x03FF);=0A return sprintf "unkn= own(%04x)", $version;=0A}=0A=0Asub dossl {=0A my ($conn, $sni) =3D @_;= =0A my $ssl =3D Net::SSLeay::new($sslctx);=0A die sprintf "Error crea= ting SSL handle: %s\n", ssl_error() if (! $ssl);=0A=0A Net::SSLeay::set_= fd($ssl, fileno($conn->{sock}));=0A # XXX: Gross!=0A Net::SSLeay::ctr= l($ssl, SSL_CTRL_SET_TLSEXT_HOSTNAME, 0, $sni);=0A $conn->{ssl} =3D $ssl= ;=0A=0A sslconnect($conn, $ssl);=0A $conn->{ssl} =3D $ssl;=0A my $= sslinfo =3D $conn->{sslinfo} =3D {};=0A=0A $sslinfo->{version} =3D tls_v= ersion(Net::SSLeay::version($ssl));=0A $sslinfo->{cipher} =3D Net::SSLea= y::get_cipher($ssl);=0A $sslinfo->{bits} =3D Net::SSLeay::get_cipher_bit= s($ssl);=0A=0A # This does not increment the chain cert reference counts= ,=0A # so we encode to PEM before closing the SSL connection.=0A #=0A= $sslinfo->{chain} =3D [ map { Net::SSLeay::PEM_get_string_X509($_) }=0A= Net::SSLeay::get_peer_cert_chain($ssl) ];=0A return;=0A}=0A=0Asub connc= lose {=0A my ($conn) =3D @_;=0A=0A sslshutdown($conn) if ($conn->{ssl= });=0A $conn->{sock}->close();=0A}=0A=0Asub tryssl {=0A my ($host, $p= ort, $sni) =3D @_;=0A=0A my $sock =3D eval {=0A IO::Socket::INET->new(= =0A PeerHost =3D> $host,=0A PeerPort =3D> $port,=0A Proto = =3D> "tcp",=0A Timeout =3D> 5,=0A Blocking =3D> 0,=0A );=0A = };=0A if ($@ || ! defined($sock)) {=0A die "Connection failed: $!\n";=0A= }=0A $sock->autoflush(1);=0A setsockopt($sock, SOL_SOCKET, SO_KEE= PALIVE, 1);=0A setsockopt($sock, IPPROTO_TCP, TCP_NODELAY, 1);=0A=0A = my $conn =3D { sock =3D> $sock };=0A=0A eval { dossl($conn, $sni); };=0A= my $err =3D $@;=0A connclose($conn);=0A die $err if $err;=0A r= eturn $conn->{sslinfo};=0A}=0A=0Asub check_dns_name {=0A my ($domain, $i= shost) =3D @_;=0A=0A my @labels =3D split(/\./, $domain);=0A die "emp= ty domain\n" if @labels =3D=3D 0;=0A die "top level domain\n" if (@label= s =3D=3D 1);=0A=0A my $re =3D $ishost ? $hostre : $domainre;=0A forea= ch my $label (@labels) {=0A die "empty label\n" if ($label eq "");=0A die s= printf "invalid label: %s\n", $label=0A unless ($label =3D~ m{$re});=0A= }=0A=0A do {=0A no warnings "numeric";=0A die sprintf "dns name is a= n IPv4 address\n"=0A if (@labels <=3D 4=0A && (grep {$_ eq 0 + $_ && $= _ < 256} @labels) =3D=3D @labels);=0A };=0A return;=0A}=0A=0Asub dns_= lookup {=0A my ($domain, $ishost, $type, $class) =3D @_;=0A $type //= =3D "A";=0A $class //=3D "IN";=0A my $rname =3D $domain;=0A my $qn= ame =3D $domain;=0A=0A check_dns_name($qname, $ishost);=0A=0A my @res= ult =3D ();=0A my $ad =3D 1;=0A my %seen =3D ();=0A=0A # Recursive= ly expand CNAME records.=0A #=0A for (my $i =3D 0; $i < 10; ++$i) {= =0A my $packet =3D Net::DNS::Packet->new($qname, $type, $class);=0A $packet= ->header->ad(1);=0A $packet =3D $resolver->send($packet);=0A my $header =3D= $packet->header;=0A my $rcode =3D $header->rcode;=0A if ($rcode ne "NOERRO= R" && $rcode ne "NXDOMAIN") {=0A die sprintf "DNS Lookup failed: %s %s = %s ?: %s\n",=0A $qname, $class, $type, $rcode;=0A }=0A $ad =3D 0 if ! $hea= der->ad;=0A my @answer =3D $packet->answer;=0A last if (@answer =3D=3D 0 ||= $rcode eq "NXDOMAIN");=0A=0A # Process answers=0A foreach my $answer (@ans= wer) {=0A my $_tmp =3D $answer->type;=0A my $atype =3D ($DNSTYPE{$_= tmp} or $_tmp);=0A my $aname =3D $answer->name;=0A if ($atype eq $t= ype && lc($aname) eq lc($rname)) {=0A push(@result, $answer);=0A } els= if (!@result && lc($aname) eq lc($rname)=0A && $answer->isa("Net::DNS= ::RR::CNAME")) {=0A $rname =3D $answer->cname;=0A }=0A }=0A last if (@= result || lc($qname) eq lc($rname));=0A $qname =3D $rname;=0A eval { check_= dns_name($qname, $ishost) };=0A if ($@) {=0A die sprintf "expands to in= valid alias: %s", $@;=0A }=0A last if ++$seen{lc($qname)} !=3D 1;=0A }= =0A return ($ad, $rname, @result);=0A}=0A=0Asub parsetlsa {=0A my ($r= data) =3D @_;=0A=0A my @bytes =3D split("", $rdata);=0A die sprintf "= Invalid TLSA RDATA length: %d\n", 0+@bytes if @bytes < 3;=0A=0A my (@usm= ) =3D splice(@bytes, 0, 3);=0A my ($u, $s, $m) =3D map { ord($_) } @usm;= =0A my $d =3D join("", map { sprintf("%02X", ord($_)) } @bytes);=0A=0A = return ($u, $s, $m, $d);=0A}=0A=0Asub get_secure_addresses {=0A my ($i= nfo) =3D @_;=0A my $host =3D $info->{host};=0A=0A my ($ad, $rname, @v= 4) =3D dns_lookup($host, ISHOST, "A");=0A ($ad, $rname, my @v6) =3D dns_= lookup($host, ISHOST, "AAAA") if $ip6;=0A=0A # Consider initial name sec= ure if a secure CNAME that resolves=0A # to insecure addresses.=0A #= =0A if (! $ad && (@v4 || @v6) && lc($host) ne lc($rname)) {=0A # Discard= result, keeping just the AD-bit side-effect.=0A #=0A ($ad) =3D dns_lookup(= $host, ISHOST, "CNAME");=0A $rname =3D $host if ($ad);=0A }=0A=0A die= sprintf "Address records insecure\n" if (! $ad);=0A $info->{rname} =3D = $rname if lc($rname) ne lc($host);=0A $info->{v4} =3D [ map { $_->addres= s } @v4 ];=0A $info->{v6} =3D [ map { $_->address } @v6 ];=0A return;= =0A}=0A=0Asub get_secure_tlsa {=0A my ($info) =3D @_;=0A my $base =3D= $info->{host};=0A my $port =3D $info->{port};=0A=0A my ($ad, $dummy,= @tlsa) =3D dns_lookup("_$port._tcp.$base", NOTHOST, "TYPE52");=0A if ((= ! $ad || @tlsa =3D=3D 0) && ($base =3D $info->{rname})) {=0A my ($ad, $dumm= y, @tlsa) =3D dns_lookup("_25._tcp.$base", NOTHOST, "TYPE52");=0A }=0A= =0A die "no TLSA records\n" if (@tlsa =3D=3D 0);=0A die "insecure TLS= A records\n" if (! $ad);=0A=0A $info->{tlsabase} =3D $base;=0A $info-= >{tlsa} =3D [ map { [=0A ($_->type eq "TLSA") ?=0A ($_->usage, $_->sele= ctor, $_->matchingtype, $_->cert) :=0A parsetlsa($_->rdata)=0A ] } @tls= a ];=0A return;=0A}=0A=0Amy ($host, $port) =3D @ARGV;=0Amy $info =3D { h= ost =3D> $host, port =3D> $port };=0A=0A# TLSA not queried if addresses not= secure!=0A#=0Aget_secure_addresses($info);=0Aif (! @{$info->{v4}} && ! @{$= info->{v6}}) {=0A die "Host has no addresses\n";=0A}=0Aget_secure_tlsa($= info);=0Amy $base =3D $info->{tlsabase};=0Amy $sslinfo =3D tryssl($host, $p= ort, $base);=0Amy $chain =3D join("\n", @{$sslinfo->{chain}});=0A=0Amy $ok = =3D 0;=0Aforeach my $tlsa (@{$info->{tlsa}}) {=0A my ($depth, $hostname)= =3D eval {=0A Danessl::verify(@{$tlsa}, $chain, $base,=0A $info->{host},= defined($info->{rname}) ?=0A $info->{rname} : ())=0A };=0A if ($@)= {=0A printf ";; Failed: %s. IN TLSA %d %d %d %s: %s",=0A $base, @$tlsa= , $@;=0A } else {=0A $ok =3D 1;=0A printf ";; Passed(depth %d%s): %s. IN= TLSA %d %d %d %s\n",=0A $depth, $hostname ? ", hostname $hostname" : "= ",=0A $base, @$tlsa;=0A }=0A}=0Aexit($ok ? 0 : 1);=0A --zS7rBR6csb6tI2e1-- From nobody Mon Nov 10 05: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 1D5BD1A8A72 for ; Mon, 10 Nov 2014 05:13:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.606 X-Spam-Level: *** X-Spam-Status: No, score=3.606 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_UK=1.749, HOST_EQ_STATIC=1.172, HOST_MISMATCH_NET=0.311, 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 afAAJJRPbA3L for ; Mon, 10 Nov 2014 05:13:19 -0800 (PST) Received: from server1.terryburton.co.uk (213-229-82-130.static.as29550.net [213.229.82.130]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9F871A8A49 for ; Mon, 10 Nov 2014 05:13:18 -0800 (PST) Received: from mail-lb0-f181.google.com ([209.85.217.181]) by server1.terryburton.co.uk with esmtpsa (TLS1.0:RSA_ARCFOUR_SHA1:128) (Exim 4.80) (envelope-from ) id 1XnomS-0002Ih-KR for dane@ietf.org; Mon, 10 Nov 2014 13:13:16 +0000 Received: by mail-lb0-f181.google.com with SMTP id l4so5701578lbv.40 for ; Mon, 10 Nov 2014 05:13:15 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.152.36.165 with SMTP id r5mr2257973laj.91.1415625195881; Mon, 10 Nov 2014 05:13:15 -0800 (PST) Received: by 10.25.165.75 with HTTP; Mon, 10 Nov 2014 05:13:15 -0800 (PST) In-Reply-To: <20141109035925.GA20946@laperouse.bortzmeyer.org> References: <20141107232915.GA31913@laperouse.bortzmeyer.org> <6DB8CC95-E47A-4C0B-BC0B-7D9A4F8F65B5@edvina.net> <20141109035925.GA20946@laperouse.bortzmeyer.org> Date: Mon, 10 Nov 2014 13:13:15 +0000 Message-ID: From: Terry Burton To: Stephane Bortzmeyer Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/xW4oLsG28ebFuGVTGciJHtlZqpk Cc: dane@ietf.org Subject: Re: [dane] Two additions to draft-york-dane-deployment-observations-00 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, 10 Nov 2014 13:13:20 -0000 On 9 November 2014 03:59, Stephane Bortzmeyer wrote: > On Sat, Nov 08, 2014 at 08:17:15AM +0100, > Olle E. Johansson wrote > a message of 10 lines which said: > >> Nagios scripts to monitor DNSsec zones :-) > > I was not talking about DNSsec monitoring (I already use it, otherwise > I would never have deployed DNSsec in production for serious domains) > but about DANE monitoring: get the TLSA record, open a TLS connection, > get the certificate, check that it is consistent with what the TLSA > record announces. Also for reference Swede [1] can be invoked from Nagios as follows: define command { command_name check_tlsa command_line cd [nagios]/etc/swede && [nagios]/bin/swede verify -q $HOSTADDRESS$ } with dlv.isc.org.key and root.key in [nagios]/etc/swede. [1] https://github.com/pieterlexis/swede From nobody Mon Nov 10 07:58: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 4EE401A000E for ; Mon, 10 Nov 2014 07:58: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 Zl0Li1JAVAbP for ; Mon, 10 Nov 2014 07:58:11 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2F831A0013 for ; Mon, 10 Nov 2014 07:58:11 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id D8B002AB2F8; Mon, 10 Nov 2014 15:58:09 +0000 (UTC) Date: Mon, 10 Nov 2014 15:58:09 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20141110155809.GV161@mournblade.imrryr.org> References: <20141107232915.GA31913@laperouse.bortzmeyer.org> <6DB8CC95-E47A-4C0B-BC0B-7D9A4F8F65B5@edvina.net> <20141109035925.GA20946@laperouse.bortzmeyer.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/TRRDNZAJzZMcS8aqC0ac7YmJxLI Subject: [dane] "Swede" likely not ready for production use 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 Nov 2014 15:58:13 -0000 On Mon, Nov 10, 2014 at 01:13:15PM +0000, Terry Burton wrote: > Also for reference Swede [1] can be invoked from Nagios as follows: > > define command { > command_name check_tlsa > command_line cd [nagios]/etc/swede && [nagios]/bin/swede > verify -q $HOSTADDRESS$ > } I don't believe that swede is sufficiently robust for this purpose: - No certificate signature checks or expiration checks for usage 2. (Invalid or expired chains pass) - Extraneous hostname check for usage 3. (Valid certs fail) [Yes, I know the OPS draft has not yet been through WGLC) so the new semantics of DANE-EE with respect to hostname and expiration checks are not yet "standard".] - Unsafe hostname checks for usages 0, 1, 2 (remote name is used after insufficient input validation as a regular expression!). The name checks are erroneously case sensitive for ASCII input. (Valid names fail, invalid names pass, and possibly security issues depending on safety of using remotely provided regexps in Python) Less critically, and for now also applicable to my Perl code: - Does not yet support UTF-8 (IDNA) hostnames. The SNI extension is supposed to be UTF-8. Name checks on DNS altNames are supposed to use ASCII-encoded A-labels. -- Viktor. From nobody Mon Nov 10 08: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 EE7E01A00A3 for ; Mon, 10 Nov 2014 08:46:21 -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_65=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 Uh2U5Hhc-_bS for ; Mon, 10 Nov 2014 08:46:20 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8BF51A00EA for ; Mon, 10 Nov 2014 08:46:19 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 0D62A2AB2F8; Mon, 10 Nov 2014 16:46:18 +0000 (UTC) Date: Mon, 10 Nov 2014 16:46:17 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20141110164617.GZ161@mournblade.imrryr.org> References: <20141027225310.29285.24437.idtracker@ietfa.amsl.com> <20141027233223.GL19158@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141027233223.GL19158@mournblade.imrryr.org> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/uYf-HqmP5iaPnAklVEIRA-vTNlc Subject: Re: [dane] Fwd: New Version Notification for draft-york-dane-deployment-observations-00.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 Nov 2014 16:46:22 -0000 On Mon, Oct 27, 2014 at 11:32:23PM +0000, Viktor Dukhovni wrote: > What would be even more helpful is a site that not only tests DNSSEC > validation and checks for the presence of TLSA RRs, but also connects > to the domain's MX hosts and reports whether the TLSA RRs match > reality! I may end up partnering with some folks to build this, > but if anyone wants to do it for us, that would be great. > > A 3-4% error rate in deploying TLSA records is too high, we need > better deployment validation tools. And more prominent guidance > to pick just either of "2 0 1" or "3 1 1" for SMTP. > > I'm also considering releasing a tool that validates a server's > off-line chain file against an off-line TLSA RRset. This would > allow folks to test before they break their server, rather than > immediately after. Speaking of testing, the Deploy360 site's list of test servers is in need of ongoing maintenance. A noticeable fraction behave differently than advertised. The data at http://www.internetsociety.org/deploy360/resources/dane-test-sites/ is quite dated. It should probably be kept up to date or withdrawn. -- Viktor. (The "Address records insecure" result below is how I avoid sending TLSA queries for unsigned zones where these are likely to be mishandled, and unlikely to be secure, see the SMTP draft for details). --- Testing fedoraproject.org... ;; Passed(depth 1, hostname fedoraproject.org): fedoraproject.org. IN TLSA 0 0 1 19400BE5B7A31FB733917700789D2F0A2471C0C9D506C0E504C06C16D7CB17C0 --- Exit code: 0 --- Testing www.freebsd.org... ;; Passed(depth 0): www.freebsd.org. IN TLSA 3 0 1 3F86A1FA85F6E5169CB27BF25C863805EBFD3225A16AADB75587804680992096 --- Exit code: 0 --- Testing torproject.org... ;; Passed(depth 0): torproject.org. IN TLSA 3 1 1 578582E6B4569A4627AEF5DFE876EEC0539388E605DB170217838B10D2A58DA5 --- Exit code: 0 --- Testing jhcloos.com... ;; Passed(depth 3, hostname jhcloos.com): jhcloos.com. IN TLSA 1 1 1 597CC279D90F0FB950B540921C4A76916590A2B7DEDDDDBC353C65337160E1A8 ;; Passed(depth 0): jhcloos.com. IN TLSA 3 1 1 597CC279D90F0FB950B540921C4A76916590A2B7DEDDDDBC353C65337160E1A8 --- Exit code: 0 --- Testing www.kumari.net... ;; Passed(depth 4, hostname *.kumari.net): www.kumari.net. IN TLSA 1 0 1 8D930A464843E08660E3FD1DDCE8ED4269CC0CD9CD53A8A306BCE8ABCF47AEF5 --- Exit code: 0 --- Testing good.dane.verisignlabs.com... ;; Passed(depth 0): good.dane.verisignlabs.com. IN TLSA 3 0 1 0332AA2D58B3E0544B65656438937068BA44CE2F14469C4F50C9CC6933C808D3 --- Exit code: 0 --- Testing www.statdns.net... ;; Failed: www.statdns.net. IN TLSA 3 0 1 C1D6431EAB897824E3A767A3CBE3B200D9160B20B0B5684C851C47782787D286: certificate not trusted: (27) --- Exit code: 1 --- Testing dougbarton.us... ;; Passed(depth 3, hostname dougbarton.us): dougbarton.us. IN TLSA 1 0 2 F994F42839BE5C864F143A037D4E96BB0F559AD7284C57EA09BF6A69D37C1D8359E57C604BB42A9A56586DB21E700404C38B8152365C03543BBF210A4FE30E08 --- Exit code: 0 --- Testing hacklab.to... Address records insecure --- Exit code: 255 --- Testing nohats.ca... ;; Passed(depth 0): nohats.ca. IN TLSA 3 1 1 462573195C86E861ABAB8ECCFBC7F0486958EFDFF9449AC10729B3A0F906F388 --- Exit code: 0 --- Testing www.nlnetlabs.nl... ;; Passed(depth 0): www.nlnetlabs.nl. IN TLSA 3 1 1 F7DB964ED80ED0773F82A21997B2DCBAE434AE821AB1E3E337AD0CCFBFE2359F --- Exit code: 0 --- Testing www.vulcano.cl... ;; Failed: www.vulcano.cl. IN TLSA 3 0 1 5F301AD10923161E74EC4951C052C97963FEBCCB093019618964D69CAF7B5B34: unable to get local issuer certificate: (20) --- Exit code: 1 --- Testing www.huque.com... ;; Passed(depth 0): www.huque.com. IN TLSA 3 0 1 0013BEF11B875A58F3B0B1D7A0D439A608277F58433BBB12245B2A28B398C281 --- Exit code: 0 --- Testing dane.nox.su... DNS Lookup failed: dane.nox.su IN A ?: SERVFAIL --- Exit code: 255 --- Testing rover.secure64.com... ;; Failed: rover.secure64.com. IN TLSA 3 0 1 D7D680E82EDA59B910D4CF37EC8398432251650A176A20E08ABE45DA728266EF: self signed certificate: (18) --- Exit code: 1 --- Testing rogue.nohats.ca... ;; Failed: rogue.nohats.ca. IN TLSA 3 0 1 0000000000000000000000000000000000000000000000000000000000000000: unable to get local issuer certificate: (20) --- Exit code: 1 --- Testing bad-hash.dane.verisignlabs.com... ;; Failed: bad-hash.dane.verisignlabs.com. IN TLSA 3 0 1 9999999999999999999999999999999999999999999999999999999999999999: certificate not trusted: (27) --- Exit code: 1 --- Testing bad-params.dane.verisignlabs.com... ;; Failed: bad-params.dane.verisignlabs.com. IN TLSA 3 119 1 0332AA2D58B3E0544B65656438937068BA44CE2F14469C4F50C9CC6933C808D3: error processing TLSA RR ;; Failed: bad-params.dane.verisignlabs.com. IN TLSA 51 0 1 0332AA2D58B3E0544B65656438937068BA44CE2F14469C4F50C9CC6933C808D3: error processing TLSA RR ;; Failed: bad-params.dane.verisignlabs.com. IN TLSA 3 0 17 0332AA2D58B3E0544B65656438937068BA44CE2F14469C4F50C9CC6933C808D3: error processing TLSA RR --- Exit code: 1 --- Testing bad-sig.dane.verisignlabs.com... DNS Lookup failed: bad-sig.dane.verisignlabs.com IN A ?: SERVFAIL --- Exit code: 255 From nobody Mon Nov 10 09:46: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 8CF271A1A36 for ; Mon, 10 Nov 2014 09:46:03 -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 GGZqfi0dhce6 for ; Mon, 10 Nov 2014 09:46:01 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B0941A1A48 for ; Mon, 10 Nov 2014 09:40:30 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 17D932AB2F5; Mon, 10 Nov 2014 17:40:28 +0000 (UTC) Date: Mon, 10 Nov 2014 17:40:28 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20141110174027.GD161@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/WE0MBX8Vhz3atErkU3_96b8xzsQ Subject: [dane] Timing of WGLC for the SMTP and OPS drafts? 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 Nov 2014 17:46:03 -0000 I believe that the SMTP and OPS drafts are ready for WGLC. During that time we can fine-tune the description of digest agility, and perhaps figure out where the DNS error handling language belongs. In any case, there are at this time no further planned updates to either draft until LC, so I hope the group and chairs are ready to move forward. -- Viktor. From nobody Mon Nov 10 09: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 02E0F1A06E9 for ; Mon, 10 Nov 2014 09:57:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 V8XMh6wx8Vz1 for ; Mon, 10 Nov 2014 09:57:44 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0074.outbound.protection.outlook.com [65.55.169.74]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF9EE1A038B for ; Mon, 10 Nov 2014 09:57:43 -0800 (PST) Received: from BLUPR06MB243.namprd06.prod.outlook.com (10.242.191.154) by BLUPR06MB242.namprd06.prod.outlook.com (10.242.191.142) with Microsoft SMTP Server (TLS) id 15.1.16.15; Mon, 10 Nov 2014 17:57:41 +0000 Received: from BLUPR06MB243.namprd06.prod.outlook.com ([169.254.7.121]) by BLUPR06MB243.namprd06.prod.outlook.com ([169.254.7.121]) with mapi id 15.01.0016.006; Mon, 10 Nov 2014 17:57:41 +0000 From: Dan York To: "dane@ietf.org" Thread-Topic: [dane] Fwd: New Version Notification for draft-york-dane-deployment-observations-00.txt Thread-Index: AQHP8jjOFMsq3jadb06FZXJoaiV9rJxEmBKAgBWPLYCAABP0Nw== Date: Mon, 10 Nov 2014 17:57:41 +0000 Message-ID: <13E839DB-BFC9-4165-A157-BC94CAE1188F@isoc.org> References: <20141027225310.29285.24437.idtracker@ietfa.amsl.com> <20141027233223.GL19158@mournblade.imrryr.org>, <20141110164617.GZ161@mournblade.imrryr.org> In-Reply-To: <20141110164617.GZ161@mournblade.imrryr.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [70.210.129.114] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BLUPR06MB242; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa: BCL:0;PCL:0;RULEID:;SRVR:BLUPR06MB242; x-forefront-prvs: 039178EF4A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(164054003)(189002)(199003)(51704005)(2473001)(101416001)(99396003)(77096003)(2501002)(62966003)(450100001)(77156002)(120916001)(2420400002)(54356999)(230783001)(20776003)(122556002)(40100003)(64706001)(66066001)(110136001)(19580395003)(82746002)(15975445006)(86362001)(46102003)(92726001)(4396001)(92566001)(87936001)(2656002)(83716003)(50986999)(33656002)(76176999)(93886004)(31966008)(107046002)(15202345003)(95666004)(106356001)(107886001)(2351001)(97736003)(106116001)(21056001)(105586002)(36756003)(99286002)(104396001); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR06MB242; H:BLUPR06MB243.namprd06.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: isoc.org Archived-At: http://mailarchive.ietf.org/arch/msg/dane/yRYpmAqtufUn5RpSJleca5kCG2I Subject: Re: [dane] Fwd: New Version Notification for draft-york-dane-deployment-observations-00.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: Mon, 10 Nov 2014 17:57:46 -0000 Viktor, > Speaking of testing, the Deploy360 site's list of test servers is > in need of ongoing maintenance. A noticeable fraction behave > differently than advertised. The data at > http://www.internetsociety.org/deploy360/resources/dane-test-sites/ >=20 > is quite dated. It should probably be kept up to date or withdrawn. As the guy responsible for that page, I am glad to update it. I set it up q= uite some time ago when there was no such list and people needed DANE test = sites. I don't yet have an automated test script but I am glad to use your = output! :-) Thanks for letting me know it had gotten out-of-date. I'll queue up a remin= der to check it periodically.=20 Thanks, Dan= From nobody Mon Nov 10 10:02: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 16C081A1AE2 for ; Mon, 10 Nov 2014 10:02:41 -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 07QFRHl4ZC9t for ; Mon, 10 Nov 2014 10:02:39 -0800 (PST) Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 065D51A03F9 for ; Mon, 10 Nov 2014 10:02:38 -0800 (PST) Received: by mail-ig0-f174.google.com with SMTP id hn18so17024120igb.7 for ; Mon, 10 Nov 2014 10:02:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=SAnZdGJM/eyNkU+Ti1Qio+xHHseR62uB8Cu4heBPZp4=; b=eks19V+UD/9E0U9zdQgSWRktthbwV0gMQ/dg15Wlg6XJBFjR4gKMXRsYJ87jcWjJHD m1DQc1Ch/ch88ot0etjahzbSyaf+lDw8CT5XPXbiOXGW1dsJAE4zCeqhdp31JOuPjQ6y 5gbG4zzA4RRL2kxAuJhmky9fXvyetsAxnMU8Jjo/qaayS7vpzUyNUmA2mYN4jEZtJ2iX bJOByhYuhWxp2hloGBj0kMZ0bV8HBHEJiyyrRMIwriva6+k6yRKeOu8xji6Y4pFJf8sZ cwG5mvn8xIrN9zhTzoNs0OORwFSwI+rtxm+m6NgqZ3FPR4TXcI1rSw6d+B+M0zlqcxWW GIMw== MIME-Version: 1.0 X-Received: by 10.107.3.163 with SMTP id e35mr35963773ioi.45.1415642558151; Mon, 10 Nov 2014 10:02:38 -0800 (PST) Received: by 10.64.225.197 with HTTP; Mon, 10 Nov 2014 10:02:38 -0800 (PST) In-Reply-To: <545EE86E.9050007@gmail.com> References: <20141107232915.GA31913@laperouse.bortzmeyer.org> <6DB8CC95-E47A-4C0B-BC0B-7D9A4F8F65B5@edvina.net> <20141109035925.GA20946@laperouse.bortzmeyer.org> <545EE86E.9050007@gmail.com> Date: Mon, 10 Nov 2014 08:02:38 -1000 Message-ID: From: Shumon Huque To: Melinda Shore Content-Type: multipart/alternative; boundary=001a113ecf7ccedd18050784f796 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/qyyZlROAvki1UAPvJT3SBR0tXlQ Cc: dane@ietf.org Subject: Re: [dane] Two additions to draft-york-dane-deployment-observations-00 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: shuque@gmail.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2014 18:02:41 -0000 --001a113ecf7ccedd18050784f796 Content-Type: text/plain; charset=UTF-8 On Sat, Nov 8, 2014 at 6:07 PM, Melinda Shore wrote: > On 11/8/14 6:59 PM, Stephane Bortzmeyer wrote: > > I was not talking about DNSsec monitoring (I already use it, otherwise > > I would never have deployed DNSsec in production for serious domains) > > but about DANE monitoring: get the TLSA record, open a TLS connection, > > get the certificate, check that it is consistent with what the TLSA > > record announces. > > Shumon Huque wrote something using the getdns Python bindings that > may be close to what you're asking about: > > https://github.com/getdnsapi/getdns-python-bindings/blob/master/examples/checkdanecert.py > > Melinda > > There's a slightly newer version of that script in the develop branch: https://github.com/getdnsapi/getdns-python-bindings/blob/develop/examples/checkdanecert.py Note that this script currently only does usage type 3, and it works for services that do SSL first (rather than negotiate STARTTLS). The Python M2Crypto SSL interface has some significant limitations. For example, it doesn't expose the function to set the TLS SNI extension, so on some multihomed servers, the server won't be able to figure out the correct certificate to present leading to the script failing the check. If there is a better python SSL module that folks would recommend, I'd glad to hear that. We have a more complete Python example that additionally does the PKIX-* mode checks (0 and 1), and we had slides on that example in our recent RIPE69 getdns tutorial (which we ran out of time to present during the session itself). I'll work on getting that example posted on the github site soon. --Shumon. --001a113ecf7ccedd18050784f796 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sat, Nov 8, 2014 at 6:07 PM, Melinda Shore <meli= nda.shore@gmail.com> wrote:
<= span>On 11/8/14 6:59 PM, Stephane Bortzmeyer wrote:
> I was not talking about DNSsec monitoring (I already use it, otherwise=
> I would never have deployed DNSsec in production for serious domains)<= br> > but about DANE monitoring: get the TLSA record, open a TLS connection,=
> get the certificate, check that it is consistent with what the TLSA > record announces.

Shumon Huque wrote something using the getdns Python bindings that may be close to what you're asking about:
https://github.com/getdnsapi/g= etdns-python-bindings/blob/master/examples/checkdanecert.py

Melinda


Th= ere's a slightly newer version of that script in the develop branch:
https://github.com/getdn= sapi/getdns-python-bindings/blob/develop/examples/checkdanecert.py
<= br>
Note that this script currently only does usage type 3, and i= t works for services that do SSL first (rather than negotiate STARTTLS). Th= e Python M2Crypto SSL interface has some significant limitations. For examp= le, it doesn't expose the function to set the TLS SNI extension, so on = some multihomed servers, the server won't be able to figure out the cor= rect certificate to present leading to the script failing the check. If the= re is a better python SSL module that folks would recommend, I'd glad t= o hear that.

We have a more complete Python example that = additionally does the PKIX-* mode checks (0 and 1), and we had slides on th= at example in our recent RIPE69 getdns tutorial (which we ran out of time t= o present during the session itself). I'll work on getting that example= posted on the github site soon.

--Shumon.
=
--001a113ecf7ccedd18050784f796-- From nobody Mon Nov 10 10:25: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 A04681A911F for ; Mon, 10 Nov 2014 10:25:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.594 X-Spam-Level: X-Spam-Status: No, score=-2.594 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.594] 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 MMmLwdZFWZmY for ; Mon, 10 Nov 2014 10:25:15 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 836F11A6F63 for ; Mon, 10 Nov 2014 10:21:48 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 827A482CBC; Mon, 10 Nov 2014 13:21:47 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1415643707; bh=EhLzabe6XoguMUhgxznEX6JuMrA1XpzLBlYvRqwsQvo=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=qxIbmQkrTq1wGy0QyjDnJfMBU/SYcY31UkAk8JnT/uYB+K0bQwtSTcUVFDtv6gPBS MUMyoBTRUbSQHVnZ6ZyJoTlHcpyXKSXB+ggTfUTt+MkdzUmjnO4VT/fcnpXKP0XDQk z9NAZ5zkvUmTzkmsuTlnNaGCnw6mG7fUai6px3FA= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id sAAILkBF008777; Mon, 10 Nov 2014 13:21:46 -0500 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Mon, 10 Nov 2014 13:21:46 -0500 (EST) From: Paul Wouters To: Terry Burton In-Reply-To: Message-ID: References: <20141107232915.GA31913@laperouse.bortzmeyer.org> <6DB8CC95-E47A-4C0B-BC0B-7D9A4F8F65B5@edvina.net> <20141109035925.GA20946@laperouse.bortzmeyer.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/Skw4Q_EdjHcDAbTP1LHzwZTDl64 Cc: dane@ietf.org Subject: Re: [dane] Two additions to draft-york-dane-deployment-observations-00 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, 10 Nov 2014 18:25:16 -0000 On Mon, 10 Nov 2014, Terry Burton wrote: > [1] https://github.com/pieterlexis/swede Note swede was folded into hash-slinger as the "tlsa" command. Paul From nobody Mon Nov 10 10:32: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 F162E1A6FF5 for ; Mon, 10 Nov 2014 10:32:31 -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 N-PAGRxWBk_B for ; Mon, 10 Nov 2014 10:32:30 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5AC61A9150 for ; Mon, 10 Nov 2014 10:30:49 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 96D482AB2F4; Mon, 10 Nov 2014 18:30:48 +0000 (UTC) Date: Mon, 10 Nov 2014 18:30:48 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20141110183048.GH161@mournblade.imrryr.org> References: <20141107232915.GA31913@laperouse.bortzmeyer.org> <6DB8CC95-E47A-4C0B-BC0B-7D9A4F8F65B5@edvina.net> <20141109035925.GA20946@laperouse.bortzmeyer.org> <545EE86E.9050007@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/MRi4nydlEITo91ucVS_mLhefuqI Subject: Re: [dane] Two additions to draft-york-dane-deployment-observations-00 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 Nov 2014 18:32:32 -0000 On Mon, Nov 10, 2014 at 08:02:38AM -1000, Shumon Huque wrote: > There's a slightly newer version of that script in the develop branch: > > https://github.com/getdnsapi/getdns-python-bindings/blob/develop/examples/checkdanecert.py > > Note that this script currently only does usage type 3, and it works for > services that do SSL first (rather than negotiate STARTTLS). The Python > M2Crypto SSL interface has some significant limitations. For example, it > doesn't expose the function to set the TLS SNI extension, so on some > multihomed servers, the server won't be able to figure out the correct > certificate to present leading to the script failing the check. The "swede" code on github, for all its faults, seems to suggest that M2Crypto does in fact support SNI. from M2Crypto import X509, SSL ... connection = SSL.Connection(ctx, sock=sock) # Try to use SNI for virtual hosts if available try: # We don't want the trailing dot here connection.set_tlsext_host_name(args.host[:-1]) Perhaps you need a sufficiently new version of the module. > We have a more complete Python example that additionally does the PKIX-* > mode checks (0 and 1), and we had slides on that example in our recent > RIPE69 getdns tutorial (which we ran out of time to present during the > session itself). I'll work on getting that example posted on the github > site soon. The ssl_dane library is easy to embed into Python (perhaps easier than into Perl). That may be a good approach, and would support all the parameter values and other fine details. It uses OpenSSL for the underlying non-DANE-specific bits. Though useful for online validation of peers with which you then communicate, in test mode it operates "off-line", give it a chain, TLSA record and a peername list, and it tells you whether the chain is matched or not. So you can use any SSL toolkit you want to grab the chain, and the library then handles the validation. Only known limitations are that digest agility currently belongs in the application layer outside the library and that IDNA hostnames are not yet supported. -- Viktor. From nobody Mon Nov 10 10:33: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 C32951A8546 for ; Mon, 10 Nov 2014 10:33:24 -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 w5JdPDZ-7M5t for ; Mon, 10 Nov 2014 10:33:23 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3C741A90F9 for ; Mon, 10 Nov 2014 10:31:55 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 3156E2AB2F4; Mon, 10 Nov 2014 18:31:55 +0000 (UTC) Date: Mon, 10 Nov 2014 18:31:55 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20141110183154.GI161@mournblade.imrryr.org> References: <20141107232915.GA31913@laperouse.bortzmeyer.org> <6DB8CC95-E47A-4C0B-BC0B-7D9A4F8F65B5@edvina.net> <20141109035925.GA20946@laperouse.bortzmeyer.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/UVc3pPtjpUG5vZ26Vgctr-1W8xE Subject: Re: [dane] Two additions to draft-york-dane-deployment-observations-00 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 Nov 2014 18:33:24 -0000 On Mon, Nov 10, 2014 at 01:21:46PM -0500, Paul Wouters wrote: > On Mon, 10 Nov 2014, Terry Burton wrote: > > >[1] https://github.com/pieterlexis/swede > > Note swede was folded into hash-slinger as the "tlsa" command. Did the implementation improve at that time or since? -- Viktor. From nobody Mon Nov 10 11:20: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 86BC01AC3F0 for ; Mon, 10 Nov 2014 11:20:34 -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 LIcxPJz-W50m for ; Mon, 10 Nov 2014 11:20:32 -0800 (PST) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E10DF1AC3B5 for ; Mon, 10 Nov 2014 11:20:31 -0800 (PST) Received: by mail-ie0-f179.google.com with SMTP id rl12so10024182iec.10 for ; Mon, 10 Nov 2014 11:20:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=/dieWd8vEI/B2zaGg8Q/pJuJq4yV8ugWlUKiud7ghdc=; b=ITQIHBqL9IpFQvkuuiefuOTjYumL17GoeGVpxL2kVkA8OctWgzDGquwXBDQApgPb/p 11Em5hvojYODIuckjbk8rqeS79EslUc2Tbz1WkXOW5HJaIPoIHDc1jcJRLS5G7hZ0L/P 2x/uaAVV3Pw3TrusamrX5C/IzJfLFr6q/qpo+AcTwQYaZq7eZLkiB7tJa9C2rKBXmjUB FwPRepbdrS7JCX2XhBQ5m7zb1FNzibTF2j+TFXHOawtUE8dFViJdPCz5/Zl3NunJPCVh 4lune3z82d4mEY05R7i8zpY8rrQ28N9LLO/8ytxTeusWjEpXghu0QVL7L9CkeLBMmSTR 6O3A== MIME-Version: 1.0 X-Received: by 10.50.43.167 with SMTP id x7mr27099498igl.41.1415647231095; Mon, 10 Nov 2014 11:20:31 -0800 (PST) Received: by 10.64.225.197 with HTTP; Mon, 10 Nov 2014 11:20:31 -0800 (PST) In-Reply-To: <20141110183048.GH161@mournblade.imrryr.org> References: <20141107232915.GA31913@laperouse.bortzmeyer.org> <6DB8CC95-E47A-4C0B-BC0B-7D9A4F8F65B5@edvina.net> <20141109035925.GA20946@laperouse.bortzmeyer.org> <545EE86E.9050007@gmail.com> <20141110183048.GH161@mournblade.imrryr.org> Date: Mon, 10 Nov 2014 09:20:31 -1000 Message-ID: From: Shumon Huque To: dane@ietf.org Content-Type: multipart/alternative; boundary=089e011602b2563b6b0507860e69 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/LpAFJbSvC0LLWRSqHlzD0YN-NwI Subject: Re: [dane] Two additions to draft-york-dane-deployment-observations-00 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: shuque@gmail.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2014 19:20:34 -0000 --089e011602b2563b6b0507860e69 Content-Type: text/plain; charset=UTF-8 On Mon, Nov 10, 2014 at 8:30 AM, Viktor Dukhovni wrote: > On Mon, Nov 10, 2014 at 08:02:38AM -1000, Shumon Huque wrote: > > > There's a slightly newer version of that script in the develop branch: > > > > > https://github.com/getdnsapi/getdns-python-bindings/blob/develop/examples/checkdanecert.py > > > > Note that this script currently only does usage type 3, and it works for > > services that do SSL first (rather than negotiate STARTTLS). The Python > > M2Crypto SSL interface has some significant limitations. For example, it > > doesn't expose the function to set the TLS SNI extension, so on some > > multihomed servers, the server won't be able to figure out the correct > > certificate to present leading to the script failing the check. > > The "swede" code on github, for all its faults, seems to suggest that > M2Crypto does in fact support SNI. > > > from M2Crypto import X509, SSL > ... > connection = SSL.Connection(ctx, sock=sock) > # Try to use SNI for virtual hosts if available > try: > # We don't want the trailing dot here > connection.set_tlsext_host_name(args.host[:-1]) > > Perhaps you need a sufficiently new version of the module. > The latest official release of M2Crypto doesn't support it (there is a long standing unaddressed bug report filed on the topic). Some OS distributions however (such as Fedora) have local patches that add it. My code currently does this (use it if available): # set TLS SNI extension if available in M2Crypto on this platform # Note: the official M2Crypto release does not yet (as of late 2014) # have support for SNI, sigh, but patches exist. try: connection.set_tlsext_host_name(hostname) except AttributeError: pass The Fedora patch also does it incompletely. It allows you to call the function and set the SNI extension but then doesn't use it properly in hostname matching checks (e.g. if you explicitly connect to an IP address it will complain). > > > We have a more complete Python example that additionally does the PKIX-* > > mode checks (0 and 1), and we had slides on that example in our recent > > RIPE69 getdns tutorial (which we ran out of time to present during the > > session itself). I'll work on getting that example posted on the github > > site soon. > > The ssl_dane library is easy to embed into Python (perhaps easier > than into Perl). That may be a good approach, and would support > all the parameter values and other fine details. It uses OpenSSL > for the underlying non-DANE-specific bits. > Thanks for the pointer. I'll take a look at ssl_dane. --Shumon. --089e011602b2563b6b0507860e69 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Nov 10, 2014 at 8:30 AM, Viktor Dukhovni <ie= tf-dane@dukhovni.org> wrote:
= On Mon, Nov 10, 2014 at 08:02:38AM -1000, Shumon Huque wro= te:

> There's a slightly newer version of that script in the develop bra= nch:
>
> https://github.com/getdn= sapi/getdns-python-bindings/blob/develop/examples/checkdanecert.py
>
> Note that this script currently only does usage type 3, and it works f= or
> services that do SSL first (rather than negotiate STARTTLS). The Pytho= n
> M2Crypto SSL interface has some significant limitations. For example, = it
> doesn't expose the function to set the TLS SNI extension, so on so= me
> multihomed servers, the server won't be able to figure out the cor= rect
> certificate to present leading to the script failing the check.

The "swede" code on github, for all its faults, seems to s= uggest that
M2Crypto does in fact support SNI.


=C2=A0 =C2=A0 from M2Crypto import X509, SSL
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ...
=C2=A0 =C2=A0 =C2=A0 =C2=A0 connection =3D SSL.Connection(ctx, sock=3Dsock)=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 # Try to use SNI for virtual hosts if available=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 try:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 # We don't want the trailing = dot here
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 connection.set_tlsext_host_name(a= rgs.host[:-1])

Perhaps you need a sufficiently new version of the module.
=

The latest official release of M2Crypto doesn't sup= port it (there is a long standing unaddressed bug report filed on the topic= ). Some OS distributions however (such as Fedora) have local patches that a= dd it.

My code currently does this (use it if available)= :

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 # set TLS SNI extension= if available in M2Crypto on this platform
=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 # Note: the official M2Crypto release does not yet (as of l= ate 2014)
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 # have support for = SNI, sigh, but patches exist.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= try:
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= connection.set_tlsext_host_name(hostname)
=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 except AttributeError:
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 pass

The Fedora patch a= lso does it incompletely. It allows you to call the function and set the SN= I extension but then doesn't use it properly in hostname matching check= s (e.g. if you explicitly connect to an IP address it will complain).
=C2=A0

> We have a more complete Python example that additionally does the PKIX= -*
> mode checks (0 and 1), and we had slides on that example in our recent=
> RIPE69 getdns tutorial (which we ran out of time to present during the=
> session itself). I'll work on getting that example posted on the g= ithub
> site soon.

The ssl_dane library is easy to embed into Python (perhaps easier than into Perl).=C2=A0 That may be a good approach, and would support
all the parameter values and other fine details.=C2=A0 It uses OpenSSL
for the underlying non-DANE-specific bits.

<= div>Thanks for the pointer. I'll take a look at ssl_dane.

=
--Shumon.


--089e011602b2563b6b0507860e69-- From nobody Mon Nov 10 13:39: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 0E4451A6F01 for ; Mon, 10 Nov 2014 13:39:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_65=0.6, J_CHICKENPOX_72=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 IgcgkC3Q8-2Y for ; Mon, 10 Nov 2014 13:39:34 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E58571A6F0A for ; Mon, 10 Nov 2014 13:39:33 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 078412AB2F4; Mon, 10 Nov 2014 21:39:32 +0000 (UTC) Date: Mon, 10 Nov 2014 21:39:31 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20141110213931.GJ161@mournblade.imrryr.org> References: <20141027225310.29285.24437.idtracker@ietfa.amsl.com> <20141027233223.GL19158@mournblade.imrryr.org> <20141110164617.GZ161@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141110164617.GZ161@mournblade.imrryr.org> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/i8ik9yD-H5du5EMveijEUBXyCCc Subject: Re: [dane] Fwd: New Version Notification for draft-york-dane-deployment-observations-00.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 Nov 2014 21:39:36 -0000 On Mon, Nov 10, 2014 at 04:46:17PM +0000, Viktor Dukhovni wrote: > Speaking of testing, the Deploy360 site's list of test servers is > in need of ongoing maintenance. A noticeable fraction behave > differently than advertised. > ;; Passed(depth 1, hostname fedoraproject.org): fedoraproject.org. IN TLSA 0 0 1 19400BE5B7A31FB733917700789D2F0A2471C0C9D506C0E504C06C16D7CB17C0 > ;; Passed(depth 0): www.freebsd.org. IN TLSA 3 0 1 3F86A1FA85F6E5169CB27BF25C863805EBFD3225A16AADB75587804680992096 > ;; Passed(depth 0): torproject.org. IN TLSA 3 1 1 578582E6B4569A4627AEF5DFE876EEC0539388E605DB170217838B10D2A58DA5 > ;; Passed(depth 0): good.dane.verisignlabs.com. IN TLSA 3 0 1 0332AA2D58B3E0544B65656438937068BA44CE2F14469C4F50C9CC6933C808D3 > ;; Passed(depth 0): nohats.ca. IN TLSA 3 1 1 462573195C86E861ABAB8ECCFBC7F0486958EFDFF9449AC10729B3A0F906F388 > ;; Passed(depth 0): www.nlnetlabs.nl. IN TLSA 3 1 1 F7DB964ED80ED0773F82A21997B2DCBAE434AE821AB1E3E337AD0CCFBFE2359F > ;; Passed(depth 0): www.huque.com. IN TLSA 3 0 1 0013BEF11B875A58F3B0B1D7A0D439A608277F58433BBB12245B2A28B398C281 As advertised. Mind you there should perhaps be a distinction in the classification of test sites between sites whose TLSA RRs actually leverage the CA they're signed by "usage 0, 1 or 2" vs. sites with a valid CA cert, but DANE-EE TLSA records. This would separate fedora and freebsd into separate categories. > ;; Passed(depth 3, hostname jhcloos.com): jhcloos.com. IN TLSA 1 1 1 597CC279D90F0FB950B540921C4A76916590A2B7DEDDDDBC353C65337160E1A8 > ;; Passed(depth 0): jhcloos.com. IN TLSA 3 1 1 597CC279D90F0FB950B540921C4A76916590A2B7DEDDDDBC353C65337160E1A8 > ;; Passed(depth 4, hostname *.kumari.net): www.kumari.net. IN TLSA 1 0 1 8D930A464843E08660E3FD1DDCE8ED4269CC0CD9CD53A8A306BCE8ABCF47AEF5 > ;; Passed(depth 3, hostname dougbarton.us): dougbarton.us. IN TLSA 1 0 2 F994F42839BE5C864F143A037D4E96BB0F559AD7284C57EA09BF6A69D37C1D8359E57C604BB42A9A56586DB21E700404C38B8152365C03543BBF210A4FE30E08 The jhcloos site is however, in both camps. Above, my code is misreporting the match depth for usage PKIX-EE(1) reporting the depth of the cert chain, not the match, I'll fix that shortly. > ;; Failed: rogue.nohats.ca. IN TLSA 3 0 1 0000000000000000000000000000000000000000000000000000000000000000: unable to get local issuer certificate: (20) > ;; Failed: bad-hash.dane.verisignlabs.com. IN TLSA 3 0 1 9999999999999999999999999999999999999999999999999999999999999999: certificate not trusted: (27) > ;; Failed: bad-params.dane.verisignlabs.com. IN TLSA 3 119 1 0332AA2D58B3E0544B65656438937068BA44CE2F14469C4F50C9CC6933C808D3: error processing TLSA RR > ;; Failed: bad-params.dane.verisignlabs.com. IN TLSA 51 0 1 0332AA2D58B3E0544B65656438937068BA44CE2F14469C4F50C9CC6933C808D3: error processing TLSA RR > ;; Failed: bad-params.dane.verisignlabs.com. IN TLSA 3 0 17 0332AA2D58B3E0544B65656438937068BA44CE2F14469C4F50C9CC6933C808D3: error processing TLSA RR > DNS Lookup failed: bad-sig.dane.verisignlabs.com IN A ?: SERVFAIL As advertised. === The 5 out of date sites below === > ;; Failed: www.statdns.net. IN TLSA 3 0 1 C1D6431EAB897824E3A767A3CBE3B200D9160B20B0B5684C851C47782787D286: certificate not trusted: (27) This site's TLSA RR asserts a certificate digest that does not actually match the presented certificate: $ (sleep 1) | openssl s_client -connect www.statdns.net:443 2>&1 | openssl x509 -subject -issuer -dates -sha256 -fingerprint -noout subject= /C=PL/CN=www.statdns.net/emailAddress=domains@statdns.com issuer= /C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Class 1 Primary Intermediate Server CA notBefore=Oct 31 00:37:02 2014 GMT notAfter=Nov 1 08:02:33 2015 GMT SHA256 Fingerprint=B8:00:50:18:A6:E7:75:FD:88:76:4B:5B:1D:3D:51:9F:89:1C:01:C7:FE:77:7E:74:A2:CF:22:37:B8:4A:43:B2 Recent key rotation, no corresponding TLSA RR update. > --- Testing hacklab.to... > Address records insecure The hacklab.to zone is unsigned, or if it is signed uses the ISC DLV, which my tests don't consult. I don't expect DNSSEC resolvers to generally support the ISC DLV service. > ;; Failed: www.vulcano.cl. IN TLSA 3 0 1 5F301AD10923161E74EC4951C052C97963FEBCCB093019618964D69CAF7B5B34: unable to get local issuer certificate: (20) $ (sleep 1) | openssl s_client -connect www.vulcano.cl:443 2>&1 | openssl x509 -subject -issuer -dates -sha256 -fingerprint -noout subject= /CN=www.vulcano.cl issuer= /O=CAcert Inc./OU=http://www.CAcert.org/CN=CAcert Class 3 Root notBefore=Oct 16 13:09:01 2014 GMT notAfter=Oct 15 13:09:01 2016 GMT SHA256 Fingerprint=2A:84:22:B0:BE:D6:96:07:AA:EB:7C:1A:75:2A:97:8E:22:EB:3E:C6:12:2E:A0:17:C8:67:89:48:67:36:A8:B0 Recent key rotation, no corresponding TLSA RR update. > --- Testing dane.nox.su... > DNS Lookup failed: dane.nox.su IN A ?: SERVFAIL $ perl ssldane.pl dane.nox.su 443 DNS Lookup failed: dane.nox.su IN A ?: SERVFAIL Validating "unbound" resolver fails for this domain, a DNSSEC issue. However, the A record exists, and is visible to non-validating resolver report: $ (sleep 1) | openssl s_client -connect dane.nox.su:443 2>&1 | openssl x509 -subject -issuer -dates -sha256 -fingerprint -noout subject= /C=RU/L=Moscow/O=NOX.SU/OU=Supervisors group 7/CN=dane.nox.su issuer= /C=RU/L=Moscow/O=NOX.SU/OU=Supervisors group 7/CN=dane.nox.su notBefore=Jul 2 12:19:19 2014 GMT notAfter=Jul 1 12:19:19 2016 GMT SHA256 Fingerprint=23:58:E8:10:27:F4:9C:39:47:92:49:93:51:80:30:B3:7F:4B:D6:19:1B:09:7D:44:4E:AF:07:29:FD:61:22:B5 Which matches the published TLSA RR, if one is willing to ignore the signature problem. $ dig +noall +ans -t TLSA _443._tcp.dane.nox.su _443._tcp.dane.nox.su. IN TLSA 3 0 1 2358E81027F49C3947924993518030B37F4BD6191B097D444EAF0729FD6122B5 > ;; Failed: rover.secure64.com. IN TLSA 3 0 1 D7D680E82EDA59B910D4CF37EC8398432251650A176A20E08ABE45DA728266EF: self signed certificate: (18) $ (sleep 1) | openssl s_client -connect rover.secure64.com:443 2>&1 | openssl x509 -subject -issuer -dates -sha256 -fingerprint -noout subject= /CN=ubuntu issuer= /CN=ubuntu notBefore=May 29 21:18:25 2012 GMT notAfter=May 27 21:18:25 2022 GMT SHA256 Fingerprint=5D:D8:53:6B:3F:6C:0D:FB:7D:CC:14:B0:AA:18:0A:13:D1:80:05:ED:CB:45:26:18:D5:4A:01:BB:69:AC:ED:9A Certificate unrelated to TLSA RR. -- Viktor. From nobody Mon Nov 10 14:06: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 637FE1A6FE8 for ; Mon, 10 Nov 2014 14:06:31 -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_65=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 6YxJRlRRC50A for ; Mon, 10 Nov 2014 14:06:30 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 359B71A1B9E for ; Mon, 10 Nov 2014 14:06:30 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id DD7352AB24B; Mon, 10 Nov 2014 22:06:28 +0000 (UTC) Date: Mon, 10 Nov 2014 22:06:28 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20141110220628.GK161@mournblade.imrryr.org> References: <20141027225310.29285.24437.idtracker@ietfa.amsl.com> <20141027233223.GL19158@mournblade.imrryr.org> <20141110164617.GZ161@mournblade.imrryr.org> <20141110213931.GJ161@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141110213931.GJ161@mournblade.imrryr.org> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/pw5cat66T98nRh-vHrkfSDI5GrM Subject: Re: [dane] Fwd: New Version Notification for draft-york-dane-deployment-observations-00.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 Nov 2014 22:06:31 -0000 On Mon, Nov 10, 2014 at 09:39:31PM +0000, Viktor Dukhovni wrote: > > ;; Passed(depth 3, hostname jhcloos.com): jhcloos.com. IN TLSA 1 1 1 597CC279D90F0FB950B540921C4A76916590A2B7DEDDDDBC353C65337160E1A8 > > ;; Passed(depth 0): jhcloos.com. IN TLSA 3 1 1 597CC279D90F0FB950B540921C4A76916590A2B7DEDDDDBC353C65337160E1A8 > > ;; Passed(depth 4, hostname *.kumari.net): www.kumari.net. IN TLSA 1 0 1 8D930A464843E08660E3FD1DDCE8ED4269CC0CD9CD53A8A306BCE8ABCF47AEF5 > > ;; Passed(depth 3, hostname dougbarton.us): dougbarton.us. IN TLSA 1 0 2 F994F42839BE5C864F143A037D4E96BB0F559AD7284C57EA09BF6A69D37C1D8359E57C604BB42A9A56586DB21E700404C38B8152365C03543BBF210A4FE30E08 > > The jhcloos site is however, in both camps. Above, my code is > misreporting the match depth for usage PKIX-EE(1) reporting the > depth of the cert chain, not the match, I'll fix that shortly. If anyone is already using the ssl_dane code, the fix for the above is below. I'll push it to github later this evening. diff --git a/danessl.c b/danessl.c index 5d1ead0..f7e5993 100644 --- a/danessl.c +++ b/danessl.c @@ -871,8 +871,8 @@ static int verify_chain(X509_STORE_CTX *ctx) * Check for an EE match, then a CA match at depths > 0, and * finally, if the EE cert is self-issued, for a depth 0 CA match. */ - if (leaf_rrs) - matched = match(leaf_rrs, xn, 0); + if (leaf_rrs && (matched = match(leaf_rrs, xn, 0)) > 0) + n = 0; while (!matched && issuer_rrs && --n >= 0) { xn = sk_X509_value(ctx->chain, n); -- Viktor. From nobody Mon Nov 10 15:18: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 1B0341ACFE3 for ; Mon, 10 Nov 2014 15:18:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 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, J_CHICKENPOX_65=0.6, 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 3gzM8qtzLKgT for ; Mon, 10 Nov 2014 15:18:40 -0800 (PST) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 802871ACFE1 for ; Mon, 10 Nov 2014 15:18:40 -0800 (PST) Received: by mail-ie0-f173.google.com with SMTP id tr6so10248662ieb.4 for ; Mon, 10 Nov 2014 15:18:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=2K7gAreG/4rjFv6ymwJ0xGm3g5cQxSiRFn1F0acfcIE=; b=w5/txxVWFAxcoje/P1qGZZgNe1ch0bKDYl+ho8ujT3jg8LylOn+RmD0xVpaHm/TLWK ItspvoXAYfOgJj3lUkBAlIrAxK94092v5xY0A9NaoFwiQPrsgh4X2gOZ5TuYRxaYFmOH y9kQ72qxlCB1zw+qb9yqo8c2AaK1gbbmsWpYTYZsRiM9/Bo69J3BA2KVgTNuigBl8l8H SUeAZMJd4buCCfif7yMDwPifSXaUwFKwzxXvbyrxJIkQGV9z4aDQBkK1NmdJ3AYyomIr CLs9/x48oa89lH1NEbZ2nLIXTgyLFKAAKmssBDrWHVCUPLJkCEB9yd/hnHvwV1KCdEkK 9rvQ== MIME-Version: 1.0 X-Received: by 10.50.93.98 with SMTP id ct2mr28089314igb.47.1415661519500; Mon, 10 Nov 2014 15:18:39 -0800 (PST) Received: by 10.64.225.197 with HTTP; Mon, 10 Nov 2014 15:18:39 -0800 (PST) In-Reply-To: <20141110213931.GJ161@mournblade.imrryr.org> References: <20141027225310.29285.24437.idtracker@ietfa.amsl.com> <20141027233223.GL19158@mournblade.imrryr.org> <20141110164617.GZ161@mournblade.imrryr.org> <20141110213931.GJ161@mournblade.imrryr.org> Date: Mon, 10 Nov 2014 13:18:39 -1000 Message-ID: From: Shumon Huque To: dane@ietf.org Content-Type: multipart/alternative; boundary=047d7b41432cfdfcaf05078961b5 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/9fgDMbQRTBWAGh1r6RUxVe9dHNM Subject: Re: [dane] Fwd: New Version Notification for draft-york-dane-deployment-observations-00.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: shuque@gmail.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2014 23:18:42 -0000 --047d7b41432cfdfcaf05078961b5 Content-Type: text/plain; charset=UTF-8 On Mon, Nov 10, 2014 at 11:39 AM, Viktor Dukhovni wrote: > On Mon, Nov 10, 2014 at 04:46:17PM +0000, Viktor Dukhovni wrote: > > > Speaking of testing, the Deploy360 site's list of test servers is > > in need of ongoing maintenance. A noticeable fraction behave > > differently than advertised. > > > ;; Passed(depth 1, hostname fedoraproject.org): fedoraproject.org. IN > TLSA 0 0 1 19400BE5B7A31FB733917700789D2F0A2471C0C9D506C0E504C06C16D7CB17C0 > > ;; Passed(depth 0): www.freebsd.org. IN TLSA 3 0 1 > 3F86A1FA85F6E5169CB27BF25C863805EBFD3225A16AADB75587804680992096 > > ;; Passed(depth 0): torproject.org. IN TLSA 3 1 1 > 578582E6B4569A4627AEF5DFE876EEC0539388E605DB170217838B10D2A58DA5 > > ;; Passed(depth 0): good.dane.verisignlabs.com. IN TLSA 3 0 1 > 0332AA2D58B3E0544B65656438937068BA44CE2F14469C4F50C9CC6933C808D3 > > ;; Passed(depth 0): nohats.ca. IN TLSA 3 1 1 > 462573195C86E861ABAB8ECCFBC7F0486958EFDFF9449AC10729B3A0F906F388 > > ;; Passed(depth 0): www.nlnetlabs.nl. IN TLSA 3 1 1 > F7DB964ED80ED0773F82A21997B2DCBAE434AE821AB1E3E337AD0CCFBFE2359F > > ;; Passed(depth 0): www.huque.com. IN TLSA 3 0 1 > 0013BEF11B875A58F3B0B1D7A0D439A608277F58433BBB12245B2A28B398C281 > > As advertised. Mind you there should perhaps be a distinction in > the classification of test sites between sites whose TLSA RRs > actually leverage the CA they're signed by "usage 0, 1 or 2" vs. > sites with a valid CA cert, but DANE-EE TLSA records. This would > separate fedora and freebsd into separate categories. > My site (www.huque.com.) also falls into that latter category. The annotation on Dan York's page should be updated - it currently says I don't have a secure delegation, which was true at one time in the past (blame a DNSSEC oblivious registrar), but no longer. --Shumon. --047d7b41432cfdfcaf05078961b5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Nov 10, 2014 at 11:39 AM, Viktor Dukhovni <i= etf-dane@dukhovni.org> wrote:
<= div class=3D"gmail_quote">
O= n Mon, Nov 10, 2014 at 04:46:17PM +0000, Viktor Dukhovni wrote:

> Speaking of testing, the Deploy360 site's list of test servers is<= br> > in need of ongoing maintenance.=C2=A0 A noticeable fraction behave
> differently than advertised.

> ;; Passed(depth 1, hostname fedoraproject.org): fedoraproject.org. IN TLSA 0 0= 1 19400BE5B7A31FB733917700789D2F0A2471C0C9D506C0E504C06C16D7CB17C0
> ;; Passed(depth 0): www.freebsd.org. IN TLSA 3 0 1 3F86A1FA85F6E= 5169CB27BF25C863805EBFD3225A16AADB75587804680992096
> ;; Passed(depth 0): torproject.org. IN TLSA 3 1 1 578582E6B4569A4= 627AEF5DFE876EEC0539388E605DB170217838B10D2A58DA5
> ;; Passed(depth 0): good.dane.verisignlabs.com. IN TL= SA 3 0 1 0332AA2D58B3E0544B65656438937068BA44CE2F14469C4F50C9CC6933C808D3 > ;; Passed(depth 0): nohats.ca. IN TLSA 3 1 1 462573195C86E861ABAB8ECCF= BC7F0486958EFDFF9449AC10729B3A0F906F388
> ;; Passed(depth 0): www.nlnetlabs.nl. IN TLSA 3 1 1 F7DB964ED80= ED0773F82A21997B2DCBAE434AE821AB1E3E337AD0CCFBFE2359F
> ;; Passed(depth 0): www.huque.com. IN TLSA 3 0 1 0013BEF11B875A58F= 3B0B1D7A0D439A608277F58433BBB12245B2A28B398C281

As advertised.=C2=A0 Mind you there should perhaps be a distinction = in
the classification of test sites between sites whose TLSA RRs
actually leverage the CA they're signed by "usage 0, 1 or 2" = vs.
sites with a valid CA cert, but DANE-EE TLSA records.=C2=A0 This would
separate fedora and freebsd into separate categories.
=
My site (www.huque.com.= ) also falls into that latter category. The annotation on Dan York's pa= ge should be updated - it currently says I don't have a secure delegati= on, which was true at one time in the past (blame a DNSSEC oblivious regist= rar), but no longer.

--Shumon.

--047d7b41432cfdfcaf05078961b5-- From nobody Mon Nov 10 15:49: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 230F01AD0BE for ; Mon, 10 Nov 2014 15:49:23 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 bo6xOLM9QyzK for ; Mon, 10 Nov 2014 15:49:18 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0075.outbound.protection.outlook.com [207.46.100.75]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D55B61AD0BB for ; Mon, 10 Nov 2014 15:49:17 -0800 (PST) Received: from BLUPR06MB244.namprd06.prod.outlook.com (10.242.191.153) by BLUPR06MB532.namprd06.prod.outlook.com (10.141.204.146) with Microsoft SMTP Server (TLS) id 15.1.16.15; Mon, 10 Nov 2014 23:49:16 +0000 Received: from BLUPR06MB243.namprd06.prod.outlook.com (10.242.191.154) by BLUPR06MB244.namprd06.prod.outlook.com (10.242.191.153) with Microsoft SMTP Server (TLS) id 15.1.16.15; Mon, 10 Nov 2014 23:49:16 +0000 Received: from BLUPR06MB243.namprd06.prod.outlook.com ([169.254.7.121]) by BLUPR06MB243.namprd06.prod.outlook.com ([169.254.7.121]) with mapi id 15.01.0016.006; Mon, 10 Nov 2014 23:49:15 +0000 From: Dan York To: "shuque@gmail.com" Thread-Topic: [dane] Fwd: New Version Notification for draft-york-dane-deployment-observations-00.txt Thread-Index: AQHP8jjOFMsq3jadb06FZXJoaiV9rJxEmBKAgBWPLYCAAFHugIAAG7OAgAAIiwA= Date: Mon, 10 Nov 2014 23:49:15 +0000 Message-ID: <6CBA9FB4-212E-4021-BDF5-5AF37A717556@isoc.org> References: <20141027225310.29285.24437.idtracker@ietfa.amsl.com> <20141027233223.GL19158@mournblade.imrryr.org> <20141110164617.GZ161@mournblade.imrryr.org> <20141110213931.GJ161@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: [31.133.161.90] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BLUPR06MB244;UriScan:; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa: BCL:0;PCL:0;RULEID:;SRVR:BLUPR06MB244; x-forefront-prvs: 039178EF4A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(199003)(2473001)(189002)(377454003)(24454002)(62966003)(36756003)(92566001)(77096003)(2420400002)(82746002)(15975445006)(122556002)(110136001)(77156002)(97736003)(19617315012)(16236675004)(19580405001)(19580395003)(83716003)(87936001)(33656002)(40100003)(76176999)(101416001)(2656002)(2501002)(50986999)(54356999)(99396003)(46102003)(66066001)(21056001)(4396001)(15202345003)(95666004)(1411001)(120916001)(99286002)(106356001)(106116001)(230783001)(92726001)(105586002)(64706001)(107046002)(93886004)(20776003)(2351001)(31966008)(86362001)(104396001); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR06MB244; H:BLUPR06MB243.namprd06.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_6CBA9FB4212E4021BDF55AF37A717556isocorg_" MIME-Version: 1.0 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BLUPR06MB532; X-OriginatorOrg: isoc.org Archived-At: http://mailarchive.ietf.org/arch/msg/dane/CclmA1A8jPrUWTYxXfJ5IsC0R4A Cc: "dane@ietf.org" Subject: Re: [dane] Fwd: New Version Notification for draft-york-dane-deployment-observations-00.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: Mon, 10 Nov 2014 23:49:23 -0000 --_000_6CBA9FB4212E4021BDF55AF37A717556isocorg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Shumon (& also replying to Viktor), On Nov 10, 2014, at 1:18 PM, Shumon Huque > wrote: My site (www.huque.com.) also falls into that latter= category. The annotation on Dan York's page should be updated - it current= ly says I don't have a secure delegation, which was true at one time in the= past (blame a DNSSEC oblivious registrar), but no longer. Yes, I noticed that when I looked at Viktor's test results this morning. I= updated the page to move your site into the appropriate category: http://www.internetsociety.org/deploy360/resources/dane-test-sites/ Based on Viktor's recent test (Thank you, Viktor!), I'm updating the page w= ith other information. I find it interesting that 3 of the 5 out-of-date sites would seem to be be= operational errors. Two of the sites Viktor tags as: - Recent key rotation, no corresponding TLSA RR update. and one is: - Certificate unrelated to TLSA RR. All of these would seem to be related to operational processes where some p= art of the security layers get updated without other corresponding layers b= eing also updated. I don't know that this is really anything that we as th= e IETF can do anything to help with... but it's interesting to understand w= here the breakdown in the process occurs. Dan --_000_6CBA9FB4212E4021BDF55AF37A717556isocorg_ Content-Type: text/html; charset="us-ascii" Content-ID: <867A42B9B2BA8143B61CDD534741B3E5@namprd06.prod.outlook.com> Content-Transfer-Encoding: quoted-printable Shumon (& also replying to Viktor),

On Nov 10, 2014, at 1:18 PM, Shumon Huque <shuque@gmail.com> wrote:

My site (www.huque.com.) also fa= lls into that latter category. The annotation on Dan York's page should be = updated - it currently says I don't have a secure delegation, which was tru= e at one time in the past (blame a DNSSEC oblivious registrar), but no longer.

Yes, I noticed that when I looked at Viktor's test results this morning. &n= bsp;I updated the page to move your site into the appropriate category:

Based on Viktor's recent test (Thank you, Viktor!), I'm updating the p= age with other information.

I find it interesting that 3 of the 5 out-of-date sites would seem to = be be operational errors.  Two of the sites Viktor tags as:

  - Recent key rotation, no corresponding TLSA RR update.

and one is:

  - Certificate unrelated to TLSA RR.

All of these would seem to be related to operational processes where s= ome part of the security layers get updated without other corresponding lay= ers being also updated.  I don't know that this is really anything tha= t we as the IETF can do anything to help with... but it's interesting to understand where the breakdown in the proc= ess occurs.

Dan
--_000_6CBA9FB4212E4021BDF55AF37A717556isocorg_-- From nobody Mon Nov 10 16:13: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 0FF901A6EE9 for ; Mon, 10 Nov 2014 16:13: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 P-tulfdz_3p2 for ; Mon, 10 Nov 2014 16:13:25 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EF3A1AC44C for ; Mon, 10 Nov 2014 16:13:25 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 3C1B42AB24B; Tue, 11 Nov 2014 00:13:24 +0000 (UTC) Date: Tue, 11 Nov 2014 00:13:24 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20141111001324.GN161@mournblade.imrryr.org> References: <20141027225310.29285.24437.idtracker@ietfa.amsl.com> <20141027233223.GL19158@mournblade.imrryr.org> <20141110164617.GZ161@mournblade.imrryr.org> <20141110213931.GJ161@mournblade.imrryr.org> <6CBA9FB4-212E-4021-BDF5-5AF37A717556@isoc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6CBA9FB4-212E-4021-BDF5-5AF37A717556@isoc.org> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/NMDEdBJuLWzGAZBYe28g9JWDF88 Subject: Re: [dane] Fwd: New Version Notification for draft-york-dane-deployment-observations-00.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 Nov 2014 00:13:27 -0000 On Mon, Nov 10, 2014 at 11:49:15PM +0000, Dan York wrote: > All of these would seem to be related to operational processes where some > part of the security layers get updated without other corresponding layers > being also updated. That's definitely the main problem. Though to be fair with HTTPS sites, nobody cares if they don't verify, browsers don't do DANE and seem unlikely to do so in the near future. [ Yes, folks like us might install a plugin, which may or may not work correctly. :-( ] I think more/better tools to validate the configuration, and awareness of those tools will help, as will the relevance of getting the records right. If TLSA records are just a fashion statement with no operational significance, the bits will rot. For SMTP at least, one of these days people getting their records wrong might actually feel some pain in the form of delayed mail, and then the problem may start to self-correct as people acquire the appropriate operational habits. That would be accelerated by a large sender or two enabling opportunistic DANE TLS for SMTP. No large providers appear in my curated list of 330 DANE-enabled SMTP domains. Though, IIRC, Unity Media in Germany has ~500,000 users, which is nice, but not quite the requisite scale. Speaking of SMTP, the same deploy360 site lists some SMTP test domains. I'd like to suggest removal of dougbarton.us, or (with his consent) adding that domain to a new category, his records are PKIX-EE(1), and are not aligned with the DANE SMTP draft. (Per the draft, these would be treated "unusable" in SMTP, resulting in a sender policy of mandatory unauthenticated TLS). -- Viktor. From nobody Mon Nov 10 16:40: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 0DB0D1AD365 for ; Mon, 10 Nov 2014 16:40:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.595 X-Spam-Level: X-Spam-Status: No, score=-2.595 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.594, 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 m8IK5IDCz3LS for ; Mon, 10 Nov 2014 16:40:21 -0800 (PST) Received: from ore.jhcloos.com (ore.jhcloos.com [198.147.23.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2088F1AD35D for ; Mon, 10 Nov 2014 16:40:21 -0800 (PST) Received: by ore.jhcloos.com (Postfix, from userid 10) id D94A11E0CD; Tue, 11 Nov 2014 00:40:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore14; t=1415666419; bh=2SLazPP2ckNuWaIkK9FZ0OLUiNjBUc6JrK9TYjm0ux4=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=PwK69/m1zLQvi1KnX/nKuIFHLodFcEBK1lyQcvS/y57EarHd2/4T5QluOaY3SGg4z gYlbCVtLiBdGWb1WVIASte0dobyFNO5wGx0rQFNAN+grTXtCAvOqyXanzRnBwppFf9 ve3wjt5c1maLMG+66lHJTmDXKHs3zMsqd48DQ55E= Received: by carbon.jhcloos.org (Postfix, from userid 500) id D047D60023; Tue, 11 Nov 2014 00:39:03 +0000 (UTC) From: James Cloos To: dane@ietf.org In-Reply-To: <20141110213931.GJ161@mournblade.imrryr.org> (Viktor Dukhovni's message of "Mon, 10 Nov 2014 21:39:31 +0000") References: <20141027225310.29285.24437.idtracker@ietfa.amsl.com> <20141027233223.GL19158@mournblade.imrryr.org> <20141110164617.GZ161@mournblade.imrryr.org> <20141110213931.GJ161@mournblade.imrryr.org> User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/24.4.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2014 James Cloos OpenPGP: 0x997A9F17ED7DAEA6; url=https://jhcloos.com/public_key/0x997A9F17ED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Mon, 10 Nov 2014 19:39:03 -0500 Message-ID: Lines: 15 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:28:141111:dane@ietf.org::N6glQ05MhHpk9nA4:000CDMPr X-Hashcash: 1:28:141111:ietf-dane@dukhovni.org::AYpifxwJoewRqSH+:00000000000000000000000000000000000000F36VK Archived-At: http://mailarchive.ietf.org/arch/msg/dane/c4lg9GFJ8Kqw-P9u092qR9xQDQU Subject: Re: [dane] Fwd: New Version Notification for draft-york-dane-deployment-observations-00.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 Nov 2014 00:40:25 -0000 >>>>> "VD" == Viktor Dukhovni writes: VD> The jhcloos site is however, in both camps. These days that is mostly just to help others test. I used 111 and 311 to make things easier for me, as both share the same hash. Another such is _5061._tcp.gate.jhcloos.com. (discoverable from jhcloos.com. naptr). -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 From nobody Mon Nov 10 17:30: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 A4FD31AD387 for ; Mon, 10 Nov 2014 17:30: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 Lja4dUdObEvE for ; Mon, 10 Nov 2014 17:30:37 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 690231AD383 for ; Mon, 10 Nov 2014 17:30:37 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 280C02AB24B; Tue, 11 Nov 2014 01:30:35 +0000 (UTC) Date: Tue, 11 Nov 2014 01:30:35 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20141111013034.GO161@mournblade.imrryr.org> References: <20141027225310.29285.24437.idtracker@ietfa.amsl.com> <20141027233223.GL19158@mournblade.imrryr.org> <20141110164617.GZ161@mournblade.imrryr.org> <20141110213931.GJ161@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/jHZNFs4l0lxgB7wnfU1J3UOESwU Subject: Re: [dane] Fwd: New Version Notification for draft-york-dane-deployment-observations-00.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 Nov 2014 01:30:38 -0000 On Mon, Nov 10, 2014 at 07:39:03PM -0500, James Cloos wrote: > VD> The jhcloos site is however, in both camps. > > These days that is mostly just to help others test. No problem with that on the server side. It is clients that should make up their mind. Your site could be listed twice. -- Viktor. From nobody Mon Nov 10 19: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 075701ACED8 for ; Mon, 10 Nov 2014 19:09:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, 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 pl79qBAibjtH for ; Mon, 10 Nov 2014 19:09:12 -0800 (PST) Received: from smtp124.iad3a.emailsrvr.com (smtp124.iad3a.emailsrvr.com [173.203.187.124]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B7031A9122 for ; Mon, 10 Nov 2014 19:09:11 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp32.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 859493801A9 for ; Mon, 10 Nov 2014 22:09:10 -0500 (EST) X-Virus-Scanned: OK Received: from app31.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp32.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 7021E380187 for ; Mon, 10 Nov 2014 22:09:10 -0500 (EST) X-Sender-Id: ogud@ogud.com Received: from app31.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by 0.0.0.0:25 (trex/5.3.2); Tue, 11 Nov 2014 03:09:10 GMT Received: from ogud.com (localhost.localdomain [127.0.0.1]) by app31.wa-webapps.iad3a (Postfix) with ESMTP id 50F0B8004B for ; Mon, 10 Nov 2014 22:09:10 -0500 (EST) Received: by apps.rackspace.com (Authenticated sender: ogud@ogud.com, from: ogud@ogud.com) with HTTP; Mon, 10 Nov 2014 22:09:10 -0500 (EST) Date: Mon, 10 Nov 2014 22:09:10 -0500 (EST) From: ogud@ogud.com To: dane@ietf.org MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: quoted-printable Importance: Normal X-Priority: 3 (Normal) X-Type: plain X-Auth-ID: ogud@ogud.com Message-ID: <1415675350.32919149@apps.rackspace.com> X-Mailer: webmail7.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/wencNFJMG1cFZbEbwzWibiTgkI0 Subject: [dane] Future working group documents 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 Nov 2014 03:09:14 -0000 =0ADear colleagues, =0A=0AThe chairs want to remind you of our milestones = =0AMilestones say:!=0AJan 2015! Advance DANE security model document to IE= SG!=0AMay 2015! Advance DANE IPSEC document to IESG!=0AJun 2015! Advance = DANE reverse binding (server to client) document to IESG!=0ASep 2015! Adva= nce DANE RFC6698 and DANE SRV RFC to Internet Standard!=0ANov 2015! Rechar= ter or close down!=0A=0A=0AI want to draw your attention to the fact that w= e need:=0AA: The above documents and=0AB: Editors for these documents...=0A= Send resume to chairs :-P=0A=0A Olafur & Warren =0A From nobody Mon Nov 10 21:18: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 093821A8853 for ; Mon, 10 Nov 2014 21:18:31 -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 IFOhed-e7qcu for ; Mon, 10 Nov 2014 21:18:29 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 964BA1A1BAD for ; Mon, 10 Nov 2014 21:18:29 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id CAE392AB2D0; Tue, 11 Nov 2014 05:18:27 +0000 (UTC) Date: Tue, 11 Nov 2014 05:18:27 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20141111051827.GR161@mournblade.imrryr.org> References: <1415675350.32919149@apps.rackspace.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1415675350.32919149@apps.rackspace.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/oV7CYgafzXq1xAbVQaYQg297Hjc Subject: Re: [dane] Future working group documents 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 Nov 2014 05:18:31 -0000 On Mon, Nov 10, 2014 at 10:09:10PM -0500, ogud@ogud.com wrote: > Jun 2015! Advance DANE reverse binding (server to client) document to IESG! I'll probably pitch in on this one, but it would nice if someone else took the lead for a change. > Sep 2015! Advance DANE RFC6698 and DANE SRV RFC to Internet Standard! Perhaps before we advance 6698 to full standard we really should do a TLSAbis, incorporating the relevant bits of OPS. The standard would be far more readable if it were not substantially refined by a second document that is not in turn a full replacement. -- Viktor. From nobody Tue Nov 11 01:00:17 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 9E8141A8549 for ; Tue, 11 Nov 2014 01:00:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.267 X-Spam-Level: X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, 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 8FChhLcbFnGU for ; Tue, 11 Nov 2014 01:00:12 -0800 (PST) Received: from smtp140.dfw.emailsrvr.com (smtp140.dfw.emailsrvr.com [67.192.241.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AD361A8978 for ; Tue, 11 Nov 2014 01:00:12 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp30.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id 9262D1800D7 for ; Tue, 11 Nov 2014 04:00:11 -0500 (EST) X-Virus-Scanned: OK Received: by smtp30.relay.dfw1a.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id 11E5E1801A1 for ; Tue, 11 Nov 2014 04:00:10 -0500 (EST) X-Sender-Id: ogud@ogud.com Received: from dhcp-8e21.meeting.ietf.org (dhcp-8e21.meeting.ietf.org [31.133.142.33]) (using TLSv1 with cipher AES128-SHA) by 0.0.0.0:465 (trex/5.3.2); Tue, 11 Nov 2014 09:00:11 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Olafur Gudmundsson In-Reply-To: <20141111051827.GR161@mournblade.imrryr.org> Date: Mon, 10 Nov 2014 23:00:09 -1000 Content-Transfer-Encoding: quoted-printable Message-Id: <8D065AE0-DF9B-45D2-AE9D-F964A8396EAF@ogud.com> References: <1415675350.32919149@apps.rackspace.com> <20141111051827.GR161@mournblade.imrryr.org> To: dane@ietf.org X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/Fcfe6F_omDjpEaieR8SbZJe8_Vg Subject: Re: [dane] Future working group documents 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 Nov 2014 09:00:15 -0000 On Nov 10, 2014, at 7:18 PM, Viktor Dukhovni = wrote: > On Mon, Nov 10, 2014 at 10:09:10PM -0500, ogud@ogud.com wrote: >=20 >> Jun 2015! Advance DANE reverse binding (server to client) document = to IESG! >=20 > I'll probably pitch in on this one, but it would nice if someone > else took the lead for a change. >=20 >> Sep 2015! Advance DANE RFC6698 and DANE SRV RFC to Internet = Standard! >=20 > Perhaps before we advance 6698 to full standard we really should > do a TLSAbis, incorporating the relevant bits of OPS. The standard > would be far more readable if it were not substantially refined by > a second document that is not in turn a full replacement. What that was meant to be a single document covering both of these=20 Olafur From nobody Tue Nov 11 09:43: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 2E13A1A00E5 for ; Tue, 11 Nov 2014 09:43: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 fJCFHwXUaXER for ; Tue, 11 Nov 2014 09:43:45 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B51441A0110 for ; Tue, 11 Nov 2014 09:43:21 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id E87202AB2F6; Tue, 11 Nov 2014 17:43:19 +0000 (UTC) Date: Tue, 11 Nov 2014 17:43:19 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20141111174319.GV161@mournblade.imrryr.org> References: <1415675350.32919149@apps.rackspace.com> <20141111051827.GR161@mournblade.imrryr.org> <8D065AE0-DF9B-45D2-AE9D-F964A8396EAF@ogud.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8D065AE0-DF9B-45D2-AE9D-F964A8396EAF@ogud.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/CHhOJorW5fzc19f3AnxKQ-jyC-8 Subject: Re: [dane] Future working group documents 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 Nov 2014 17:43:46 -0000 On Mon, Nov 10, 2014 at 11:00:09PM -1000, Olafur Gudmundsson wrote: > > Perhaps before we advance 6698 to full standard we really should > > do a TLSAbis, incorporating the relevant bits of OPS. The standard > > would be far more readable if it were not substantially refined by > > a second document that is not in turn a full replacement. > > What that was meant to be a single document covering both of these Is that a question or a statement? For my part, I'd like to see DANE TLSA (6698) bis, with the relevant bits from OPS inlined into the main document. Though first we need to get OPS published. -- Viktor. From nobody Tue Nov 11 11:12: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 830401A19EA for ; Tue, 11 Nov 2014 11:12:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.994 X-Spam-Level: X-Spam-Status: No, score=-1.994 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_72=0.6, RP_MATCHES_RCVD=-0.594] 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 S43y2O-4j5AN for ; Tue, 11 Nov 2014 11:12:07 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0B0C1A1AD3 for ; Tue, 11 Nov 2014 11:11:04 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 2F8BF817C1 for ; Tue, 11 Nov 2014 14:11:03 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1415733063; bh=vTo9rs1shKc1IjtAZcMW2ChsgvuGa4Krdfzc32rxVfI=; h=Date:From:To:Subject:In-Reply-To:References; b=bNGgLZIqnkbNx/vW5zRXWMuT6jYsY7CVRLX8kVchPKeP+SmLae1NQ1veUfZIkHNft 61jmEnSyFr5VbjAMCAQNG+Z5CoeWfRuXdkXbXztOOaBrsooRU4NPBtsYWnYRRIrkoE ZsjBmes9jkkNzf5yRz2TfQxIpP5V2uqhhnmjrKAo= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id sABJB3vs007383 for ; Tue, 11 Nov 2014 14:11:03 -0500 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Tue, 11 Nov 2014 14:11:02 -0500 (EST) From: Paul Wouters To: dane@ietf.org In-Reply-To: <20141110213931.GJ161@mournblade.imrryr.org> Message-ID: References: <20141027225310.29285.24437.idtracker@ietfa.amsl.com> <20141027233223.GL19158@mournblade.imrryr.org> <20141110164617.GZ161@mournblade.imrryr.org> <20141110213931.GJ161@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/ZY5JKXx4Ex0xqbEHa7qqt-wKqw0 Subject: Re: [dane] Fwd: New Version Notification for draft-york-dane-deployment-observations-00.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 Nov 2014 19:12:09 -0000 On Mon, 10 Nov 2014, Viktor Dukhovni wrote: >> --- Testing hacklab.to... >> Address records insecure > > The hacklab.to zone is unsigned, or if it is signed uses the ISC > DLV, which my tests don't consult. I don't expect DNSSEC resolvers > to generally support the ISC DLV service. The .to TLD is unsigned, so it has to rely on DLV. Paul ps. best TLD webpage ever: http://to/ pps. they should make http://to/infinity/and/beyond/ From nobody Wed Nov 12 15:46: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 135781A1B6A for ; Wed, 12 Nov 2014 15:43:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3] 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 EHd1Va2_NuKV for ; Wed, 12 Nov 2014 15:43:00 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81CB11A1B6E for ; Wed, 12 Nov 2014 15:43:00 -0800 (PST) Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net [76.218.8.156]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id sACNgu7F031167 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 12 Nov 2014 15:43:00 -0800 Message-ID: <5463F07A.5040804@dcrocker.net> Date: Wed, 12 Nov 2014 15:42:50 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Paul Hoffman , Jakob Schlyter Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Wed, 12 Nov 2014 15:43:00 -0800 (PST) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/ORTC4GfC61ffcEL6Cs-Oo8bJ8F0 X-Mailman-Approved-At: Wed, 12 Nov 2014 15:46:02 -0800 Cc: dane@ietf.org Subject: [dane] Suggests modifications to -dane-smime Section 3 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2014 23:43:02 -0000 I reflected on my confusions about per-user vs. per-domain keys for smime use and suggest the following changes to Section 3 of the -dane-smime draft: From: 3. Domain Names for S/MIME Certificate Associations Domain names are prepared for requests in the following manner. 1. ... 2. ... 3. ... To: 3. Email Address Key Lookup Keys are stored in the DNS on a per-user basis, underneath the the email address domain name. The general form of the lookup name is formulated from the user’s email address: .smimecert. The algorithm for formulating the lookup name is: 1. ... existing algorithm text 2. 3. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Nov 12 15:53: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 36DCA1A004C for ; Wed, 12 Nov 2014 15:53:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.473 X-Spam-Level: X-Spam-Status: No, score=-1.473 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.594] 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 nqzu8PHFjxHl for ; Wed, 12 Nov 2014 15:53:42 -0800 (PST) Received: from egssmtp01.att.com (egssmtp01.att.com [144.160.112.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 466F91A0016 for ; Wed, 12 Nov 2014 15:53:42 -0800 (PST) Received: from mailgw1.maillennium.att.com (maillennium.att.com [135.25.114.99]) by egssmtp01.att.com ( egs 8.14.5 TLS/8.14.5) with ESMTP id sACNrfeI009651 for ; Wed, 12 Nov 2014 17:53:41 -0600 Received: from vpn-135-70-97-201.vpn.swst.att.com ([135.70.97.201]) by maillennium.att.com (mailgw1) with ESMTP id <20141112235340gw100r93h8e>; Wed, 12 Nov 2014 23:53:40 +0000 X-Originating-IP: [135.70.97.201] Message-ID: <5463F300.1090008@att.com> Date: Wed, 12 Nov 2014 18:53:36 -0500 From: Tony Hansen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 CC: dane@ietf.org References: <5463F07A.5040804@dcrocker.net> In-Reply-To: <5463F07A.5040804@dcrocker.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/dane/iw_hVZXgyiTFxuVoBYqmHQc6cSU Subject: Re: [dane] Suggests modifications to -dane-smime Section 3 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 Nov 2014 23:53:43 -0000 On 11/12/14, 6:42 PM, Dave Crocker wrote: > I reflected on my confusions about per-user vs. per-domain keys for > smime use and suggest the following changes to Section 3 of the > -dane-smime draft: > > > From: > > 3. Domain Names for S/MIME Certificate Associations > > Domain names are prepared for requests in the following manner. > > 1. ... > > 2. ... > > 3. ... > > > To: > > 3. Email Address Key Lookup > > Keys are stored in the DNS on a per-user basis, underneath the > the email address domain name. > > The general form of the lookup name is formulated from the > user’s email address: > > .smimecert. > > The algorithm for formulating the lookup name is: > > 1. ... existing algorithm text > 2. > 3. +1 Tony Hansen From nobody Wed Nov 12 16:14: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 E7D7D1A0070 for ; Wed, 12 Nov 2014 16:14:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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_NONE=-0.0001, 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 xtuqCxzPphu7 for ; Wed, 12 Nov 2014 16:14:28 -0800 (PST) Received: from gproxy7-pub.mail.unifiedlayer.com (gproxy7-pub.mail.unifiedlayer.com [70.40.196.235]) by ietfa.amsl.com (Postfix) with SMTP id DC9D71A00B0 for ; Wed, 12 Nov 2014 16:14:07 -0800 (PST) Received: (qmail 3966 invoked by uid 0); 13 Nov 2014 00:14:07 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy7.mail.unifiedlayer.com with SMTP; 13 Nov 2014 00:14:07 -0000 Received: from box514.bluehost.com ([74.220.219.114]) by CMOut01 with id EoE31p00C2UhLwi01oE6MX; Wed, 12 Nov 2014 17:14:06 -0700 X-Authority-Analysis: v=2.1 cv=F5TEKMRN c=1 sm=1 tr=0 a=9W6Fsu4pMcyimqnCr1W0/w==:117 a=9W6Fsu4pMcyimqnCr1W0/w==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=xk8Vn6ZJdw4A:10 a=IkcTkHD0fZMA:10 a=ieNpE_y6AAAA:8 a=XYUc-DgfXtMA:10 a=4BreF0GzsJ0A:10 a=48vgC7mUAAAA:8 a=onaonInnSqXG-oUJHqkA:9 a=QEXdDO2ut3YA:10 a=49i606fQckQA:10 a=jeikEa7BQdYA:10 a=T-T6961LJCwA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=MZ6iwJpRjuT42TAHfa32olDPqaC4QDOqPZA1WAeVzus=; b=KsikWRT25OUK/plsoRMt8nCc4sns6WX0z7S/kCvoEj7Akw5ODk5mrQ4jnX20E9QKhFgHDnilWL/EUjWjK3WYMrsLWfjsuleN42bfPV0w6CDmAQlhI6WiJ9cozVkuAPta; Received: from [31.133.132.6] (port=51223) by box514.bluehost.com with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1Xoi32-0001J5-2Q for dane@ietf.org; Wed, 12 Nov 2014 17:14:04 -0700 Message-ID: <5463F7C5.9000204@KingsMountain.com> Date: Wed, 12 Nov 2014 16:13:57 -0800 From: =JeffH User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: IETF DANE WG list Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 31.133.132.6 authed with jeff.hodges+kingsmountain.com} Archived-At: http://mailarchive.ietf.org/arch/msg/dane/LmGRsnLUHyfV4jT-KteE6RPfUXc Subject: [dane] fyi: draft-agl-dane-serializechain-01 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 Nov 2014 00:14:31 -0000 fyi,this is the I-D mentioned (by Richard Barnes and EKR) in the discussion in the DANE session today... Serializing DNS Records with DNSSEC Authentication https://tools.ietf.org/html/draft-agl-dane-serializechain-01 'serialization' is what EKR referred to as 'pickling' HTH, =JeffH From nobody Wed Nov 12 20:09: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 4E8E31A1B53 for ; Wed, 12 Nov 2014 20:09:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.76 X-Spam-Level: X-Spam-Status: No, score=-0.76 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, SUBJ_ALL_CAPS=1.506] 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 64HyJEtNP2Zq for ; Wed, 12 Nov 2014 20:09:45 -0800 (PST) Received: from smtp148.dfw.emailsrvr.com (smtp148.dfw.emailsrvr.com [67.192.241.148]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 475F91A1B4A for ; Wed, 12 Nov 2014 20:09:44 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp11.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id C86B4280210 for ; Wed, 12 Nov 2014 23:09:43 -0500 (EST) X-Virus-Scanned: OK Received: by smtp11.relay.dfw1a.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id 5DF2128020E for ; Wed, 12 Nov 2014 23:09:43 -0500 (EST) X-Sender-Id: ogud@ogud.com Received: from dhcp-bbd3.meeting.ietf.org (dhcp-bbd3.meeting.ietf.org [31.133.187.211]) (using TLSv1 with cipher AES128-SHA) by 0.0.0.0:465 (trex/5.3.2); Thu, 13 Nov 2014 04:09:43 GMT From: Olafur Gudmundsson Content-Type: multipart/alternative; boundary="Apple-Mail=_D8B107A3-C4DF-441D-B482-EEAD1D63A098" Message-Id: <0DAFC2A8-A1E2-46F4-BA52-E8261CB09159@ogud.com> Date: Wed, 12 Nov 2014 18:09:41 -1000 To: "" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/gBy47merNKc76MqrNKEAbCQMPkY Subject: [dane] WGLC: DANE-SRV & DANE-SMTP 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 Nov 2014 04:09:46 -0000 --Apple-Mail=_D8B107A3-C4DF-441D-B482-EEAD1D63A098 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Dear wg members This email message starts a three week WGLC ending on December 4=92th at = 23:59 UTC.=20 http://tools.ietf.org/wg/dane/draft-ietf-dane-srv and=20 https://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-13 These two document are specifying related uses of DANE.=20 Please review the documents carefully, in particular we want to make = sure the documents have no=20 contradictions.=20 We need at least 5 members of the working group to state in public that = they have read the documents and=20 state what is needed to fixed before the documents are advanced.=20 I will act as document shepherd for these two documents.=20 Olafur & Warren= --Apple-Mail=_D8B107A3-C4DF-441D-B482-EEAD1D63A098 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Dear wg members

This email = message starts a three week WGLC ending on December 4=92th at 23:59 = UTC. 

http://tools.ie= tf.org/wg/dane/draft-ietf-dane-srv
and 
htt= ps://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-13

Thes= e two document are specifying related uses of DANE. 
Please = review the documents carefully, in particular we want to make sure the = documents have no 
contradictions. 

We need at least = 5 members of the working group to state in public that they have read = the documents and 
state what is needed to fixed before the = documents are advanced. 

I will act as document shepherd for = these two documents. 

Olafur & Warren= --Apple-Mail=_D8B107A3-C4DF-441D-B482-EEAD1D63A098-- From nobody Wed Nov 12 20:12: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 E4B351A1B62 for ; Wed, 12 Nov 2014 20:12:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.267 X-Spam-Level: X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, 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 6zj4CemL-MhQ for ; Wed, 12 Nov 2014 20:12:45 -0800 (PST) Received: from smtp140.dfw.emailsrvr.com (smtp140.dfw.emailsrvr.com [67.192.241.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 510EC1A1B68 for ; Wed, 12 Nov 2014 20:12:45 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp30.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id B4C8718014C for ; Wed, 12 Nov 2014 23:12:44 -0500 (EST) X-Virus-Scanned: OK Received: by smtp30.relay.dfw1a.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id 30107180146 for ; Wed, 12 Nov 2014 23:12:43 -0500 (EST) X-Sender-Id: ogud@ogud.com Received: from dhcp-bbd3.meeting.ietf.org (dhcp-bbd3.meeting.ietf.org [31.133.187.211]) (using TLSv1 with cipher AES128-SHA) by 0.0.0.0:465 (trex/5.3.2); Thu, 13 Nov 2014 04:12:44 GMT From: Olafur Gudmundsson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <8538820C-61E0-478A-9CB7-494ECB463C46@ogud.com> Date: Wed, 12 Nov 2014 18:12:42 -1000 To: "" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/XiZ4XO7ndKpCKo0-dK_lhCfwDzg Subject: [dane] interim virtual meeting Dec 2 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 Nov 2014 04:12:49 -0000 Just a heads up,=20 As announced in the WG session we will have a interim meeting to discuss = SMIME usage and requirements=20 Expect a formal announcement in few days.=20 Olafur & Warren From nobody Thu Nov 13 08:55: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 DE6AE1A8AAF for ; Thu, 13 Nov 2014 08:55:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.647 X-Spam-Level: X-Spam-Status: No, score=-3.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-2.3] 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 qnrYfdl9RJo7 for ; Thu, 13 Nov 2014 08:55:34 -0800 (PST) Received: from proper.com (Hoffman.Proper.COM [207.182.41.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A77BE1A8ABD for ; Thu, 13 Nov 2014 08:55:33 -0800 (PST) Received: from [192.168.14.159] (64-129-13-2.static.twtelecom.net [64.129.13.2] (may be forged)) (authenticated bits=0) by proper.com (8.14.9/8.14.7) with ESMTP id sADGtSov000120 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Nov 2014 09:55:29 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: proper.com: Host 64-129-13-2.static.twtelecom.net [64.129.13.2] (may be forged) claimed to be [192.168.14.159] Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Paul Hoffman In-Reply-To: <5463F07A.5040804@dcrocker.net> Date: Thu, 13 Nov 2014 06:55:28 -1000 Content-Transfer-Encoding: 7bit Message-Id: References: <5463F07A.5040804@dcrocker.net> To: Dave Crocker X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/FAa9Bf0bkvSJfrn_fxHvSiC_CtU Cc: dane@ietf.org, Jakob Schlyter Subject: Re: [dane] Suggests modifications to -dane-smime Section 3 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 Nov 2014 16:55:36 -0000 On Nov 12, 2014, at 1:42 PM, Dave Crocker wrote: > I reflected on my confusions about per-user vs. per-domain keys for > smime use and suggest the following changes to Section 3 of the > -dane-smime draft: Thanks, that sounds fine. --Paul Hoffman From nobody Thu Nov 13 11:59: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 31D9C1ACF09 for ; Thu, 13 Nov 2014 11:59:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.594 X-Spam-Level: X-Spam-Status: No, score=-2.594 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.594] 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 5a0RlmZ8jZoe for ; Thu, 13 Nov 2014 11:59:06 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0085C1ACE30 for ; Thu, 13 Nov 2014 11:59:05 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 2438E817C1 for ; Thu, 13 Nov 2014 14:59:05 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1415908745; bh=3j0xgMnOGNJxIdT4I9KHj8c/ggouAyuFg2NsRyLFOoU=; h=Date:From:To:Subject; b=iWZf5/SlEeqlOO5GQWUj6DWfiEGSpI1r9P4y7eqKWf+oWpd+JgY3X3p/5Vo3aj7V7 3nSUxR31xMgfG1Oe7ddkwYJJKCB4mNgi56n9YaRFgc5tK4q83KqqiH8vDDkXRP0Wie +e9SIAaZKklv5+79nNNfhErE+0ehOOKZQr2FjlFY= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id sADJx4ki026624 for ; Thu, 13 Nov 2014 14:59:04 -0500 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Thu, 13 Nov 2014 14:59: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; format=flowed; charset=UTF-8 Content-Transfer-Encoding: 8BIT Archived-At: http://mailarchive.ietf.org/arch/msg/dane/s2bEh8WlQFinBNghCh1YOOKkAqQ Subject: [dane] SMTP STARTTLS stripping in the wild 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 Nov 2014 19:59:08 -0000 https://www.eff.org/deeplinks/2014/11/starttls-downgrade-attacks "In recent months, researchers have reported ISPs in the US and Thailand intercepting their customers' data to strip a security flag—called STARTTLS—from email traffic." Thanks to Viktor, properly configured postfix clients deployed with DANE should detect this and refuse to send the email unencrypted. Paul From nobody Thu Nov 13 12:15: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 82E7A1ACF82; Thu, 13 Nov 2014 12:15:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dgRGTy3cYgrW; Thu, 13 Nov 2014 12:15:12 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 31B611ACF66; Thu, 13 Nov 2014 12:15:12 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: IESG Secretary To: IETF Announcement List X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141113201512.7739.99780.idtracker@ietfa.amsl.com> Date: Thu, 13 Nov 2014 12:15:12 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/NMLvuzvgwLBsf5x0ZDCCnkGOwEE Cc: dane@ietf.org Subject: [dane] DANE WG Interim Virtual Meeting, December 2, 2014 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 20:15:16 -0000 DANE WG Interim virtual Meeting: SMIME Usage cases and Requirements Date: December 2’nd at 10:00 Eastern The DANE WG will have a 1 hour long Interim meeting on December 2’nd to cover SMIME usage. The goal of the meeting is to facilitate discussion on what the actual requirements are, please send in drafts outlining how you envision SMIME to be used/supported, or send such statements to the working group mailing list for discussion in advance. A list of documents submitted for discussion will be posted to the list a week in advance. Olafur & Warren DANE Tuesday, December 2, 2014 10:00 am | Eastern Standard Time (New York, GMT-05:00) | 1 hr Join WebEx meeting: https://ietf.webex.com/ietf/j.php?MTID=md5def721def32dd731a704859cf83218 Meeting number: 640 822 261 Meeting password: 1234 Join by phone 1-877-668-4493 Call-in toll free number (US/Canada) 1-650-479-3208 Call-in toll number (US/Canada) Access code: 640 822 261 From nobody Thu Nov 13 16:43: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 6A8881A1A07 for ; Thu, 13 Nov 2014 16:43:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.037 X-Spam-Level: X-Spam-Status: No, score=-1.037 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, 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 NtL2xlDXWdQ8 for ; Thu, 13 Nov 2014 16:43:37 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0656B1A19F8 for ; Thu, 13 Nov 2014 16:43:36 -0800 (PST) Received: (qmail 48404 invoked from network); 14 Nov 2014 00:43:35 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 14 Nov 2014 00:43:35 -0000 Date: 14 Nov 2014 00:43:13 -0000 Message-ID: <20141114004313.8557.qmail@ary.lan> From: "John Levine" To: dane@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/dane/Yms5oVLjRgFXh28lKiyDXfhWQXA Cc: paul@nohats.ca Subject: Re: [dane] SMTP STARTTLS stripping in the wild 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 Nov 2014 00:43:38 -0000 >https://www.eff.org/deeplinks/2014/11/starttls-downgrade-attacks > > "In recent months, researchers have reported ISPs in the US and Thailand > intercepting their customers' data to strip a security flag—called > STARTTLS—from email traffic." > >Thanks to Viktor, properly configured postfix clients deployed with DANE should >detect this and refuse to send the email unencrypted. This is an anti-spam measure on port 25 traffic on a few mobile networks. I expect there aren't a lot of copies of Postfix running on mobile devices. For all those other mobile users, if they're configured correctly they're submitting over port 587 or 465, and nobody tries to filter that. R's, John From nobody Thu Nov 13 16:52: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 E2C491A1A32 for ; Thu, 13 Nov 2014 16:52: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 uPSRIEO02B0K for ; Thu, 13 Nov 2014 16:52:54 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 912151A1A75 for ; Thu, 13 Nov 2014 16:52:54 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 74CE5284AD6; Fri, 14 Nov 2014 00:52:53 +0000 (UTC) Date: Fri, 14 Nov 2014 00:52:53 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20141114005253.GW22498@mournblade.imrryr.org> References: <20141114004313.8557.qmail@ary.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141114004313.8557.qmail@ary.lan> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/kq9yHFVHc4lWunvSxz4B7QCssog Subject: Re: [dane] SMTP STARTTLS stripping in the wild 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 Nov 2014 00:52:57 -0000 On Fri, Nov 14, 2014 at 12:43:13AM -0000, John Levine wrote: > >https://www.eff.org/deeplinks/2014/11/starttls-downgrade-attacks > > This is an anti-spam measure on port 25 traffic on a few mobile > networks. I expect there aren't a lot of copies of Postfix running > on mobile devices. For all those other mobile users, if they're > configured correctly they're submitting over port 587 or 465, and > nobody tries to filter that. Indeed most such configurations are likely to have similarly mundane explanations. I used Paul's message as an excuse for a marketing message, but forgot to voice my skepticism as to whether this is an actual attack at work. I am far more curious about what happened to Google's outbound TLS mail stats around Oct 14th: https://www.google.com/transparencyreport/saferemail/ but this seems likely to remain a mystery. Perhaps some large peer botched their TLS settings? -- Viktor. From nobody Thu Nov 13 17:11: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 49AAE1A1ABB for ; Thu, 13 Nov 2014 17:11:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.594 X-Spam-Level: X-Spam-Status: No, score=-2.594 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.594] 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 N2l9sMTqQyyG for ; Thu, 13 Nov 2014 17:11:21 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52BE81A1ACF for ; Thu, 13 Nov 2014 17:11:18 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 17710817C1; Thu, 13 Nov 2014 20:11:17 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1415927477; bh=r9KrJbULz9hDIcsg980tIHKH6spqLtbPmi5IhUyZjUE=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=g47fpg9TclV57G2eL7u0L8c2Hjw4F0xNRX9ZvK04tzigYsBYLCxLC31kj7L2lv3zE qbX/So2QZyUQm0sjuboNeWWQNN3i1nhi4cfgNzl/+ARDSQ8Y1Wjb8L2lcw0Y9xNptO WceG+9Uj3H4BHaHesWhvXv4DojIvGGevRFBw4Sdg= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id sAE1BGES004815; Thu, 13 Nov 2014 20:11:16 -0500 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Thu, 13 Nov 2014 20:11:16 -0500 (EST) From: Paul Wouters To: John Levine In-Reply-To: <20141114004313.8557.qmail@ary.lan> Message-ID: References: <20141114004313.8557.qmail@ary.lan> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: http://mailarchive.ietf.org/arch/msg/dane/BRaoqICSn9oH1EHM6frfdEy7rNo Cc: dane@ietf.org Subject: Re: [dane] SMTP STARTTLS stripping in the wild 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 Nov 2014 01:11:30 -0000 On Thu, 14 Nov 2014, John Levine wrote: >> https://www.eff.org/deeplinks/2014/11/starttls-downgrade-attacks >> >> "In recent months, researchers have reported ISPs in the US and Thailand >> intercepting their customers' data to strip a security flag—called >> STARTTLS—from email traffic." >> >> Thanks to Viktor, properly configured postfix clients deployed with DANE should >> detect this and refuse to send the email unencrypted. > > This is an anti-spam measure on port 25 traffic on a few mobile > networks. With friends like these,.... It's time for opportunistic encryption to kick in against "helpful" rewriting of people's packets. This also fits in with today's human rights presentation at SAAG. This kind of downgrade attack would be candy for oppressive regimes. > I expect there aren't a lot of copies of Postfix running > on mobile devices. For all those other mobile users, if they're > configured correctly they're submitting over port 587 or 465, and > nobody tries to filter that. You are wrongly assuming all must clients relay via another location. (yes I know, you say reality, I say morality) Paul From nobody Thu Nov 13 17:19: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 D542D1A1A95 for ; Thu, 13 Nov 2014 17:19:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, 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 DQaVUyVdNkW7 for ; Thu, 13 Nov 2014 17:19:24 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9E8F1A1A8D for ; Thu, 13 Nov 2014 17:19:23 -0800 (PST) Received: (qmail 51807 invoked from network); 14 Nov 2014 01:19:22 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=ca5e.5465589a.k1411; bh=ES2cNj7nFs3MVSsEuisxrT3wJz63YX3MHMOzJMW+HZ8=; b=TlOZsUeiHwkCkYD2MQlawMPglusm1XZ2qJ0iWItorhhVuLaeCOrZn43K0VlZzLkbeInWgXW8dx8RpU9n+PjCkfcg54hgwwogUAhvrs/F5U2zpWVqbzA7LhQPXlfjrAXNQesOOvLw94D118lnXq7xTTc0fPdRrTjVGx9SLS74JFzvDsGWzbyKd+pbrwUeTHvms7KM21I2/MOFe+fuvN2s510mip+eMO/jflEqLG8rhICf53AAEny19FFMakp0BV2G DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=ca5e.5465589a.k1411; bh=ES2cNj7nFs3MVSsEuisxrT3wJz63YX3MHMOzJMW+HZ8=; b=RLZEy6v34y+RsC940aFbwG5sfIjQFqhshKqGEcTcnGVumOFlHPuK6XzDghIM2TUDKd9s4PekcBoaaO7v2la+0UGbUGMWfysvIU2GqDlfTnDLV2X2Cb0DAqgEoU29f1aweyOwuUtMVN8X0YoSyUti0azkyYXUwuSWqcP3bMAs0yvHBdxSSRzZRzqj+8Wm2by+Y6fO6P7B2FaVJldiEqSEIzal/KKJLxF6Uw3Q/pwRzFyxbB07C2wpwkjZ8DBHaU5a Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 14 Nov 2014 01:19:22 -0000 Date: 13 Nov 2014 15:19:19 -1000 Message-ID: From: "John R Levine" To: "Paul Wouters" In-Reply-To: References: <20141114004313.8557.qmail@ary.lan> User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/dane/OLoY-y6EQXbKjsuOK8sIbepeTcs Cc: dane@ietf.org Subject: Re: [dane] SMTP STARTTLS stripping in the wild 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 Nov 2014 01:19:25 -0000 > You are wrongly assuming all must clients relay via another location. > (yes I know, you say reality, I say morality) As I pointed out in another context, an ISP can trivially create an EFF-compatible spam filter by hijacking all port 25 sessions to its own mail server, which does STARTTLS. There are problems that need solving. This is not one of them. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Thu Nov 13 17:57: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 530061A03E3 for ; Thu, 13 Nov 2014 17:57:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.795 X-Spam-Level: X-Spam-Status: No, score=-4.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, 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 hwbV3TRgeM3I for ; Thu, 13 Nov 2014 17:57:10 -0800 (PST) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1A461A017A for ; Thu, 13 Nov 2014 17:57:10 -0800 (PST) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id sAE1v92W009735 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 14 Nov 2014 01:57:10 GMT Received: from hermes-fe-3.easd.brm.oracle.com (hermes-fe-3.easd.brm.oracle.com [10.79.248.12]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id sAE1v9PG013438 for ; Fri, 14 Nov 2014 01:57:09 GMT MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; CHARSET=US-ASCII Received: from [10.175.253.161] (dhcp-ukc1-twvpn-1-vpnpool-10-175-183-28.vpn.oracle.com [10.175.183.28]) by hermes-fe-3.easd.brm.oracle.com (Oracle Communications Messaging Server 7.0.5.31.0 64bit (built May 5 2014)) with ESMTPSA id <0NF000A6DAR53I00@hermes-fe-3.easd.brm.oracle.com> for dane@ietf.org; Thu, 13 Nov 2014 17:57:08 -0800 (PST) Date: Thu, 13 Nov 2014 15:57:05 -1000 From: Chris Newman To: dane@ietf.org Message-id: <2CCB417DB294C9CC79C32DC1@96B2F16665FF96BAE59E9B90> In-reply-to: <20141114005253.GW22498@mournblade.imrryr.org> References: <20141114004313.8557.qmail@ary.lan> <20141114005253.GW22498@mournblade.imrryr.org> X-Mailer: Mulberry/4.0.8 (Mac OS X) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Archived-At: http://mailarchive.ietf.org/arch/msg/dane/LBhr0kv_5UMCGXp20J3Ht6Vw8Tc Subject: Re: [dane] SMTP STARTTLS stripping in the wild 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 Nov 2014 01:57:17 -0000 --On November 14, 2014 0:52:53 +0000 Viktor Dukhovni wrote: > On Fri, Nov 14, 2014 at 12:43:13AM -0000, John Levine wrote: >> > https://www.eff.org/deeplinks/2014/11/starttls-downgrade-attacks >> This is an anti-spam measure on port 25 traffic on a few mobile >> networks. I expect there aren't a lot of copies of Postfix running >> on mobile devices. For all those other mobile users, if they're >> configured correctly they're submitting over port 587 or 465, and >> nobody tries to filter that. > > Indeed most such configurations are likely to have similarly mundane > explanations. I used Paul's message as an excuse for a marketing > message, but forgot to voice my skepticism as to whether this is > an actual attack at work. > > I am far more curious about what happened to Google's outbound > TLS mail stats around Oct 14th: > > https://www.google.com/transparencyreport/saferemail/ > > but this seems likely to remain a mystery. Perhaps some large peer > botched their TLS settings? My speculation: There's no specification for SMTP relay fallback from STARTTLS to cleartext. So if a provider turns on fully RFC 3207 client-side STARTTLS for relay and that software doesn't also implement the unspecified fallback, it will stop the flow of mail to peers that advertise STARTTLS but implement it incorrectly. Once the queue buildup is noticed, the client-side site has to: 1. turn off client-side STARTTLS 2. upgrade to a software version implementing the unspecified protocol, if available. 3. manually configure no-STARTTLS for each endpoint that has a broken STARTTLS implementation. 4. bounce mail to legitimate recipients with a bogus STARTTLS implementation. Incidentally, I suspect 1 is a common service provider response to this situation. - Chris From nobody Thu Nov 13 18:27: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 047671A019B for ; Thu, 13 Nov 2014 18:27: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 ZlRJb20Im2xj for ; Thu, 13 Nov 2014 18:27:17 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1C061A017C for ; Thu, 13 Nov 2014 18:27:17 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 741A8284AD6; Fri, 14 Nov 2014 02:27:16 +0000 (UTC) Date: Fri, 14 Nov 2014 02:27:16 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20141114022716.GZ22498@mournblade.imrryr.org> References: <20141114004313.8557.qmail@ary.lan> <20141114005253.GW22498@mournblade.imrryr.org> <2CCB417DB294C9CC79C32DC1@96B2F16665FF96BAE59E9B90> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2CCB417DB294C9CC79C32DC1@96B2F16665FF96BAE59E9B90> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/CBYhAHcvOwSYaPmfuLG2Qn90apE Subject: Re: [dane] SMTP STARTTLS stripping in the wild 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 Nov 2014 02:27:20 -0000 On Thu, Nov 13, 2014 at 03:57:05PM -1000, Chris Newman wrote: > > I am far more curious about what happened to Google's outbound > > TLS mail stats around Oct 14th: > > > > https://www.google.com/transparencyreport/saferemail/ > > > > but this seems likely to remain a mystery. Perhaps some large peer > > botched their TLS settings? > > My speculation: > > There's no specification for SMTP relay fallback from STARTTLS to cleartext. Correct, Sendmail defers the mail, while Postfix falls back to cleartext (eventually). > So if a provider turns on fully RFC 3207 client-side STARTTLS for relay Google is the sender in this case. The drop in TLS traffic started on Oct 7th, fell sharply on the 11th and ended on Oct 15th. Outbound TLS support at Google is far from new. > and that > software doesn't also implement the unspecified fallback, it will stop the flow > of mail to peers that advertise STARTTLS but implement it incorrectly. So I think you're saying that Google may have disabled its previous STARTTLS to cleartext fallback, and after a few days found that a lot of mail got deferred. And that point either selectively or globally re-enabled fallback? I'd have hoped they would notice a lot sooner, the drop is from 75% to 50% of mail using TLS. If the missing TLS mail is queued, that would rapidly lead to enourmous mail backlogs. It seems far more likely that some remote peer broke their TLS, or Google tried some fancy TLS settings, and ran into interoperability issues. In either case Google likely then delivered in cleartext. > Once the queue buildup is noticed, the client-side site has to: > > 1. turn off client-side STARTTLS Note what happened at Google, since the TLS rate did not go to zero. > 2. upgrade to a software version implementing the unspecified protocol, if > available. > 3. manually configure no-STARTTLS for each endpoint that has a broken STARTTLS > implementation. > 4. bounce mail to legitimate recipients with a bogus STARTTLS implementation. They probably had cleartext fallback all along, and I think deferred mail at that volume would have been noticed rather quickly. > Incidentally, I suspect 1 is a common service provider response to this > situation. That is rather plausible. -- Viktor. From nobody Thu Nov 13 19:22:17 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 8B1741A6EE0 for ; Thu, 13 Nov 2014 19:22:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594, 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 Z0bGPCfNoMBi for ; Thu, 13 Nov 2014 19:22:08 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66A571A6EDC for ; Thu, 13 Nov 2014 19:22:08 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id EC7BF20098 for ; Thu, 13 Nov 2014 22:24:19 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id AA2B4637F4; Thu, 13 Nov 2014 22:22:07 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 94FCE637EA for ; Thu, 13 Nov 2014 22:22:07 -0500 (EST) From: Michael Richardson To: dane@ietf.org In-Reply-To: <20141114004313.8557.qmail@ary.lan> References: <20141114004313.8557.qmail@ary.lan> 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/7ctZkt6Ml36Nu-zUz3vMPaqaqHM Subject: Re: [dane] SMTP STARTTLS stripping in the wild 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 Nov 2014 03:22:12 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable John Levine wrote: >> https://www.eff.org/deeplinks/2014/11/starttls-downgrade-attacks >>=20 >> "In recent months, researchers have reported ISPs in the US and >> Thailand intercepting their customers' data to strip a security >> flag=E2=80=94called STARTTLS=E2=80=94from email traffic." >>=20 >> Thanks to Viktor, properly configured postfix clients deployed with >> DANE should detect this and refuse to send the email unencrypted. > This is an anti-spam measure on port 25 traffic on a few mobile > networks. I expect there aren't a lot of copies of Postfix running on > mobile devices. For all those other mobile users, if they're Any person with a laptop with postfix on it being "tethered" might do this. I do it regularly; I don't do direct delivery, but do authenticated (via STARTTLS cert) relaying to a machine in the cloud... I have been using port 26 for this for a decade plus due to port 25 being blocked. While the submit port might make sense, it was easier to configure this as straight SMTP. At least, if this happened to me, the relay would refuse to accept my email, since it wasn't authenticated; I don't think that I force TLS on the client, but I probably could. It's not unusual for an entire office to wind up tethered to someone's mobi= le device (or mifi) when a backhoe event occurs. {and I'm happy to relay for friends and family} =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVGV1XICLcPvd0N1lAQJ5IQf/Zbcu/12QWLc3Nk04etJTI3SgexOEOOp5 DEeGfRkwPxi17ifwNC2iSnyB6VUn/XNTECh9G76iDc2Fo8sCrQ9seYfvfdlKdmS2 Lq83V/TQp9n7uqbYYJDYxMHfiw0pRTu7s8OWjdce9ewsyg1cRgGOgDIgHt96wvK5 SDKeIJP14SKs3heF255pB5XmOJtYG+wGw5jVOnvRvFw6toSpc+6aeFqB8hHOIMbr yQmNgkRfn7Eh9RRVBTSonNLZVL6Hd9NMNeb6weXppRw44StsTIF+yEN0I//Q5mcc X1VtvYt3R0jx0FZhuEGTLklA74HnnLwCiSDqxjjObSVKZpqxJdWZig== =Zt2z -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Nov 14 08:20: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 1A9D41A1A9B for ; Fri, 14 Nov 2014 08:20:01 -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 5juQyip5wE5y for ; Fri, 14 Nov 2014 08:19:58 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 975491A1A88 for ; Fri, 14 Nov 2014 08:19:58 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 72B54282FBE; Fri, 14 Nov 2014 16:19:57 +0000 (UTC) Date: Fri, 14 Nov 2014 16:19:57 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20141114161957.GF22498@mournblade.imrryr.org> References: <20141027225310.29285.24437.idtracker@ietfa.amsl.com> <20141027233223.GL19158@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141027233223.GL19158@mournblade.imrryr.org> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/0YChrXNeRxdoSXVpdRqA1sFGwkg Subject: Re: [dane] Fwd: New Version Notification for draft-york-dane-deployment-observations-00.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, 14 Nov 2014 16:20:01 -0000 On Mon, Oct 27, 2014 at 11:32:23PM +0000, Viktor Dukhovni wrote: > Out of ~280 domains that have TLSA RRs, 10 or so had erroneous > records: On a more positive note, my (not comprehensive) list of working SMTP with DANE domains crossed the 360 mark today. So for SMTP "Deploy 360" is done. :-) Top 10 SMTP with DANE TLDs: 121 de. 67 net. 35 org. 34 com. 15 eu. 13 ch. 9 cz. 5 uk. 5 nl. 5 info. As I mentioned before, many of net/com/org/eu/info domains are in fact registered by DE domain owners, so deployment is still substantially a DE phenomenon. It would be good to get some traction in other jurisdictions. In Germany Heise.de and other IT trade publications have written about DANE, and there have been presentations at multiple technical conferences for users. So DANE awareness is growing there. Perhaps there could be some similar articles in the US IT press? Do people still read the US trade rags? Perhaps it would be easier to market DANE to users if more MTAs than just Postfix had implementations. I'm working with the Exim developers, and they are close to having it done. It would be nice to have Microsoft also ship a DANE-capable Exchange SMTP server, and of course Sendmail. After that it is support in the various SMTP appliances, IronPort Barracuda, ... and last but not least the big providers Outlook.com, Gmail, Yahoo, AOL, ... I hope this will move faster once the draft is published as an RFC, but some additional marketing may be helpful if anyone on this list can pitch implementation to people in a position to make progress happen. -- Viktor. From nobody Mon Nov 17 15:26: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 431FD1ACE86 for ; Mon, 17 Nov 2014 15:26:02 -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 WtXjS6EFntiT for ; Mon, 17 Nov 2014 15:25:57 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64D851ACE73 for ; Mon, 17 Nov 2014 15:25:57 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 694D8284B10; Mon, 17 Nov 2014 23:25:56 +0000 (UTC) Date: Mon, 17 Nov 2014 23:25:56 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20141117232556.GO13179@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/Glyx6Yp___2TBRI9WyfnDE8LsmM Subject: [dane] had-pilot.com domain all nameservers down? 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 Nov 2014 23:26:02 -0000 Has the plug been pulled on had-pilot.com? $ dig +noall +ans +auth +add -t ns had-pilot.com @a.gtld-servers.net. had-pilot.com. 172800 IN NS ns1.had-pilot.com. had-pilot.com. 172800 IN NS ns2.had-pilot.com. ns1.had-pilot.com. 172800 IN A 129.6.100.200 ns2.had-pilot.com. 172800 IN A 129.6.100.202 $ dig +noall +add -t ns had-pilot.com @a.gtld-servers.net. | awk '{print $NF}' | while read ip; do echo "@$ip." dig +norecur +noall +comment +ans -t ns had-pilot.com @$ip done @129.6.100.200. ;; connection timed out; no servers could be reached @129.6.100.202. ;; connection timed out; no servers could be reached -- Viktor From nobody Tue Nov 18 06:00: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 EA7E51A040B for ; Tue, 18 Nov 2014 06:00:30 -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 jV0gke0tnuvJ for ; Tue, 18 Nov 2014 06:00:26 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0700.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:700]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CF151A03FF for ; Tue, 18 Nov 2014 06:00:26 -0800 (PST) Received: from BY1PR09MB0439.namprd09.prod.outlook.com (25.160.109.21) by BY1PR09MB0437.namprd09.prod.outlook.com (25.160.109.19) with Microsoft SMTP Server (TLS) id 15.1.26.15; Tue, 18 Nov 2014 14:00:03 +0000 Received: from BY1PR09MB0439.namprd09.prod.outlook.com ([25.160.109.21]) by BY1PR09MB0439.namprd09.prod.outlook.com ([25.160.109.21]) with mapi id 15.01.0016.006; Tue, 18 Nov 2014 14:00:03 +0000 From: "Rose, Scott" To: "dane@ietf.org" Thread-Topic: [dane] had-pilot.com domain all nameservers down? Thread-Index: AQHQAr3kFvaw8E6LWk2RFd7TCJeBeZxmamYA Date: Tue, 18 Nov 2014 14:00:03 +0000 Message-ID: <1A6FBE59-1170-4BCA-9B63-15E82CB67D15@nist.gov> References: <20141117232556.GO13179@mournblade.imrryr.org> In-Reply-To: <20141117232556.GO13179@mournblade.imrryr.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.6.140.6] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BY1PR09MB0437; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:BY1PR09MB0437; x-forefront-prvs: 039975700A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(51704005)(199003)(55674003)(377454003)(24454002)(21056001)(50986999)(54356999)(76176999)(101416001)(4396001)(33656002)(2501002)(122556002)(99396003)(97736003)(120916001)(106356001)(105586002)(95666004)(99286002)(20776003)(40100003)(77096003)(62966003)(77156002)(106116001)(36756003)(450100001)(107886001)(107046002)(2351001)(66066001)(64706001)(31966008)(92726001)(92566001)(86362001)(46102003)(19580405001)(19580395003)(82746002)(15975445006)(2656002)(110136001)(83716003)(87936001)(104396001)(47845001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR09MB0437; H:BY1PR09MB0439.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov Archived-At: http://mailarchive.ietf.org/arch/msg/dane/zPEwZwd9ZvwAWwEUAf44x9vRwhs Subject: Re: [dane] had-pilot.com domain all nameservers down? 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 Nov 2014 14:00:31 -0000 Something seems to be going on. Not sure what, but can't reach it anymore.= Working on it. In the meantime, another secondary should be reachable via 129.6.100.201 On= ce the updated glue propagates. Scott On Nov 17, 2014, at 6:25 PM, Viktor Dukhovni wrote= : >=20 > Has the plug been pulled on had-pilot.com? >=20 > $ dig +noall +ans +auth +add -t ns had-pilot.com @a.gtld-servers.net. > had-pilot.com. 172800 IN NS ns1.had-pilot.com. > had-pilot.com. 172800 IN NS ns2.had-pilot.com. > ns1.had-pilot.com. 172800 IN A 129.6.100.200 > ns2.had-pilot.com. 172800 IN A 129.6.100.202 >=20 > $ dig +noall +add -t ns had-pilot.com @a.gtld-servers.net. | > awk '{print $NF}' | > while read ip; do > echo "@$ip." > dig +norecur +noall +comment +ans -t ns had-pilot.com @$ip > done > @129.6.100.200. > ;; connection timed out; no servers could be reached > @129.6.100.202. > ;; connection timed out; no servers could be reached >=20 > --=20 > Viktor >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From nobody Wed Nov 19 22:29: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 08BC61A0074 for ; Wed, 19 Nov 2014 22:29:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.199 X-Spam-Level: * X-Spam-Status: No, score=1.199 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, J_CHICKENPOX_62=0.6, J_CHICKENPOX_72=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 kbsXh1v0WXKx for ; Wed, 19 Nov 2014 22:29:45 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD4D21A0071 for ; Wed, 19 Nov 2014 22:29:44 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 1F9F528304A; Thu, 20 Nov 2014 06:29:42 +0000 (UTC) Date: Thu, 20 Nov 2014 06:29:42 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20141120062942.GL13179@mournblade.imrryr.org> References: <20141027225310.29285.24437.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/zKYG1uOyQD3YxG1Woa1VFguRTzQ Subject: [dane] Please help to remediate broken DNSSEC hosting 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, 20 Nov 2014 06:29:47 -0000 On Mon, Oct 27, 2014 at 10:55:31PM +0000, Dan York wrote: > Feedback is very definitely welcome... I'm not intending anything > with this document other than using it as a catalyst for discussions. Dan, here's something you may be able to help with. A number of large DNS hosting providers have enabled DNSSEC support, but are using nameserver software that is not compatible with the specification with respect to authenticated denial of existence. In particular, given a zone containing the RRsets below *.example.com. IN A|CNAME|... RDATA example.com. IN MX 0 mail.example.com. mail.example.com. IN A 192.0.2.1 A query for the non-existent "_25._tcp.mail.example.com" is thrown off by the wildcard record, which has other data, but has no TLSA RRs, and returns "NODATA" rather than "NXDOMAIN". So TLSA queries for such hosted domains SERVFAIL, and mail delivery to these domains breaks from DANE-enabled MTAs. DNS provider Example domain -------------------------------- forpsi.cz gigacomputer.cz forpsi.cz websurf.cz -------------------------------- hosting2go.nl flashpatterns.nl hosting2go.nl informatieplatform.nl -------------------------------- hostnet.nl bergsalaenigma.nl hostnet.nl brandsupply.nl hostnet.nl expert.nl hostnet.nl foodness.nl hostnet.nl ikkijkonline.nl hostnet.nl leestrainer.nl hostnet.nl studeersnel.nl -------------------------------- transip.nl aanbodpagina.nl transip.nl androidworld.nl transip.nl bitonic.nl transip.nl codingunit.com transip.nl dresscode.nl transip.nl fonq.nl transip.nl gamesync.nl transip.nl headliner.nl transip.nl icheckmovies.com transip.nl kinderspiele.de transip.nl mediumchat.nl transip.nl notprovided.eu transip.nl performance.nl transip.nl redskillz.nl transip.nl refdag.nl transip.nl seoshop.nl transip.nl trendstats.nl transip.nl webshopapp.com transip.nl webwinkelsoftware.nl transip.nl wrts.nl transip.nl zipzoo.nl -------------------------------- For example: zipzoo.nl. IN MX 10 mail.zipzoo.nl. mail.zipzoo.nl. IN A 95.170.70.251 mail.zipzoo.nl. IN AAAA 2a01:7c8:eb:0:95:170:70:251 ;; _25._tcp.mail.zipzoo.nl IN TLSA ?: SERVFAIL The presence of such broken domains can deter deployment. Can the "Deploy360" effort coordinate remediation? Such hosting sites must do one of the below to avoid breaking DANE TLSA (at least for SMTP): * Deploy a non-broken nameserver. * Create kludgey defensive records that make the NODATA response correct. _25._tcp.mail.zipzoo.nl IN TXT "No TLSA RRs here" * Remove the zone's wildcard RRs. * Work with the domain owner to remove the DS records for the zone making it "insecure". I don't have the cycles to interface with each hosting provider and domain owner myself. We to get the message out to DNS hosting providers that their software needs to be a robust DNSSEC implementation, not an ad-hoc patch-set. At least in the case of forpsi.cz, I know they're using djbdns, which does not have fully functional DNSSEC support. On a related note, some nameservers are failing to provide proof of the non-existence of a "*._tcp" wildcard, along with the NXDOMAIN reply for "_25._tcp". fuhrt.de. IN NS ns2.remotedienst.de. fuhrt.de. IN NS ns1.remotedienst.de. fuhrt.de. IN MX 10 fuhrt.de. ;; _25._tcp.fuhrt.de IN TLSA ?: SERVFAIL On the other hand for other domains, some sort of firewall or nameserver bug causes "TLSA" queries to often be simply dropped, while "A" queries for the same node return NXDOMAIN: disa.mil fbi.gov nic.mil So I'm running into a non-trivial fraction of signed domains for which DNSSEC is not working right, and DANE will run into interop problems. Can you do anything to help. My basic plea is: * Do it right but failing that: * Don't do it at all. Neither DNSSEC nor DANE should be fashion statements about how "cool" a domain is. These should only be deployed when thoroughly tested and the ongoing operational responsibilities are under control. Finally, while "dnsviz.net" provides the most detailed information I've found at any testing site, its visual nature and the requirement to "mouse-over" things to get the key details is often a distraction, while due to space constraints, the text is often terse and difficult to understand. I'm looking for better tools, that non-cryptically explain what is wrong a query response fails to validate. A command-line tool I can run locally would be great, the web version can be for reports to remote admins so they can use the same tool to check that they've fixed the problem without needing to install anything. -- Viktor. From nobody Wed Nov 19 23:34: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 083711A00B0 for ; Wed, 19 Nov 2014 23:34:49 -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 BmIK44ZPzWEJ for ; Wed, 19 Nov 2014 23:34:47 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28BE01A00AE for ; Wed, 19 Nov 2014 23:34:47 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 89B47282F88; Thu, 20 Nov 2014 07:34:45 +0000 (UTC) Date: Thu, 20 Nov 2014 07:34:45 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20141120073445.GM13179@mournblade.imrryr.org> References: <20141027225310.29285.24437.idtracker@ietfa.amsl.com> <20141120062942.GL13179@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141120062942.GL13179@mournblade.imrryr.org> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/zpg8zh6NQjOLBxqk-uhsksaE6Sw Subject: Re: [dane] Please help to remediate broken DNSSEC hosting 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, 20 Nov 2014 07:34:49 -0000 On Thu, Nov 20, 2014 at 06:29:42AM +0000, Viktor Dukhovni wrote: > A number of large DNS hosting providers have enabled DNSSEC support, > but are using nameserver software that is not compatible with the > specification with respect to authenticated denial of existence. Note, by far the bulk of the problem is with transip. From their website: https://www.transip.co.uk/domain-name/transdns/ DNSSEC TransDNS is the foundation of our DNSSEC implementation, a DNS protocol security extension. Signing more than 500.000 domain names with DNSSEC was a challenge we gladly accepted. Because of TransDNS we were one of the first domain providers in The Netherlands that signed all our domain names. We are now the largest DNSSEC provider in the world. We could not have done this with third-party solutions. That is the reason why we develop everything in-house. Perhaps they have more problems that show up in interop tests because they indeed signed so many more domains that anyone else. In any case, they would be a good place to start remediation. If anyone has contacts there and can reach out that would be great. -- Viktor. From nobody Thu Nov 20 00:29: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 4C71C1A00CD for ; Thu, 20 Nov 2014 00:29:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 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.594, 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 1S8f8Y7UZ5mD for ; Thu, 20 Nov 2014 00:29:07 -0800 (PST) Received: from arn2-kamx.sidn.nl (kamx.sidn.nl [IPv6:2a00:d78:0:147:94:198:152:69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 113621A00C5 for ; Thu, 20 Nov 2014 00:29:06 -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:subject:references:in-reply-to:content-type:x-originating-ip; bh=G+ht2kmxJRWYOnOyFofrStU8jWOs1ZUWgM5FOflnVa4=; b=UUKMZXIvZMElo3zMbBfZVEjN0zYRWFSvRryUkDrB5GLxoL+lAhbREKDUARPslWZGCFuvypcCgws7AHyYxP2l6yMZWxTuSto5YMpu3qmMG+3TwSBXx4t1o4LHI3bGRhF9ULw4q9+2RM4Tnpk9z35xha8pBl1KUw52VGhYnTougnY= Received: from kahubcasn01.SIDN.local ([192.168.2.73]) by arn2-kamx.sidn.nl with ESMTP id sAK8T3Vo003460-sAK8T3Vq003460 (version=TLSv1.0 cipher=AES256-SHA bits=256 verify=CAFAIL) for ; Thu, 20 Nov 2014 09:29:03 +0100 Received: from rndhost215.sidn.nl (94.198.152.215) by kahubcasn01.SIDN.local (192.168.2.77) with Microsoft SMTP Server (TLS) id 14.3.174.1; Thu, 20 Nov 2014 09:29:02 +0100 Message-ID: <546DA64E.4010900@sidn.nl> Date: Thu, 20 Nov 2014 09:29:02 +0100 From: "Marco Davids (SIDN)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:35.0) Gecko/20100101 Thunderbird/35.0a2 MIME-Version: 1.0 To: References: <20141027225310.29285.24437.idtracker@ietfa.amsl.com> <20141120062942.GL13179@mournblade.imrryr.org> <20141120073445.GM13179@mournblade.imrryr.org> In-Reply-To: <20141120073445.GM13179@mournblade.imrryr.org> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070209010003030405030602" X-Originating-IP: [94.198.152.215] Archived-At: http://mailarchive.ietf.org/arch/msg/dane/CPbtJPc0oW3VzArkERe9RQlBihI Subject: Re: [dane] Please help to remediate broken DNSSEC hosting 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 Nov 2014 08:29:09 -0000 --------------ms070209010003030405030602 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi, At SIDN (registry for .nl) we are aware of these problems and we are in touch with the registrars involved. In particular TransIP is a bit of a challenge, because they run their own DNS-software and feel no rush to fix this issue. But rest assured that we will keep on trying to have them improve things. -- Marco On 20/11/14 08:34, Viktor Dukhovni wrote: > On Thu, Nov 20, 2014 at 06:29:42AM +0000, Viktor Dukhovni wrote: >=20 >> A number of large DNS hosting providers have enabled DNSSEC support, >> but are using nameserver software that is not compatible with the >> specification with respect to authenticated denial of existence. >=20 > Note, by far the bulk of the problem is with transip. From their > website: >=20 > https://www.transip.co.uk/domain-name/transdns/ >=20 > DNSSEC >=20 > TransDNS is the foundation of our DNSSEC implementation, a DNS > protocol security extension. Signing more than 500.000 domain > names with DNSSEC was a challenge we gladly accepted. Because > of TransDNS we were one of the first domain providers in The > Netherlands that signed all our domain names. We are now the > largest DNSSEC provider in the world. We could not have done > this with third-party solutions. That is the reason why we > develop everything in-house. >=20 > Perhaps they have more problems that show up in interop tests > because they indeed signed so many more domains that anyone else. > In any case, they would be a good place to start remediation. >=20 > If anyone has contacts there and can reach out that would be great. >=20 --------------ms070209010003030405030602 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMZjCC BiowggUSoAMCAQICAwoD4zANBgkqhkiG9w0BAQsFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRl IFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlh dGUgQ2xpZW50IENBMB4XDTE0MDUyMDE3NTUyOFoXDTE1MDUyMjAwMTc1NlowRDEdMBsGA1UE AwwUbWFyY28uZGF2aWRzQHNpZG4ubmwxIzAhBgkqhkiG9w0BCQEWFG1hcmNvLmRhdmlkc0Bz aWRuLm5sMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0tDXTB0Q5LVXcdRfAg/x 7Baw83FDEtt566NEjxSG0Q6xnexJtiXUl4bfGSE9PHN2Y9tT7NOGxXPNPjddChUJbKwGhH27 zmWA6LK/4AnNyew8seFGKMp3UFOkfVUGBcNPvtHQPDSAZnZuds50vhpqLqyxa+EA8rjttC93 8/dZAjjV7etpk24W1s/Ith+c5oSP6rqIfl+tUPc4s2ZOudq8ov6jAV2OQ53S/G1OFR9s9ZEl uYZohI2gQB7Fz5Xfij20YqWnZ9619JndU4b5Cqs4NCxhnO3Pgoba85LhVdvkxAbKq/cIv8zP 4FrsKUhdkjWBmWK+r+vU/GtdcmZkM2YCtQIDAQABo4IC2jCCAtYwCQYDVR0TBAIwADALBgNV HQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBTVD7Di X5HtXqiaF+DhqGiH2ixl1TAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhRgjAfBgNV HREEGDAWgRRtYXJjby5kYXZpZHNAc2lkbi5ubDCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYB BAGBtTcBAgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xp Y3kucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0 aGUgQ2xhc3MgMSBWYWxpZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0Eg cG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21w bGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCug KaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcB AQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNz MS9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRz L3N1Yi5jbGFzczEuY2xpZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS8wDQYJKoZIhvcNAQELBQADggEBAGjmOZpe/qYtBZy5VSP5JRKEKlwIpxGUDNQv YhvCp53aVXvALQmXO6X1v3Oia+hpMliCof9ymQXUCSfNaftKBYx4ROr6kgmVZUtTrb10f/eW xNDVV/5Jhy1mAyQ4ziMXoW7r8Mbji653p2ewbYLZd6mtXkzvM/SNdh4iG5+dD4x2ih9IzEl6 XO4WFTgNFu26/0YXSCzkyb3K3O2jAUzyHvYB4dMUjxryVNDcLPae1CxeAYgpZNNmUVZPiOyB Fr/NRKgC77X1Q2STwUbo8JTTXka/rZup1Huj2g2AMrBZ/fO8+HSWFF0OeioEWFvOpSc2c8hs cb8LAWbtf9XerJ/a1rgwggY0MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNV BAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRh bCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9u IEF1dGhvcml0eTAeFw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQG EwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwg Q2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5 IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDHCYPMzi3YGrEppC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zP f1Jwuk0tsvVCk6U9b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG /FaR/wpbfuIqu54qzHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvur yGaC/o2/ceD2uYDX9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSy rrSMTGKkDiXm6/3/4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIB qTAPBgNVHRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssB XHx+ljVO8tS4UYIwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUH AQEEWjBYMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYB BQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCeg JaAjhiFodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9j cmwuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBm MC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsG AQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqG SIb3DQEBBQUAA4ICAQAKgwh9eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95 CfegFJTwqBBmf8pyTUnFsukDFUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A +hKMIzEzcduRkIMmCeUTyMyikfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcL N5A0t4DkuVhTMXIzuQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/ O75CDUHDRHCCKBVmz/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI27 0g+5MYA8GfgI/EPT5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z 77U1uL7TelWO5lApsbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/Q vVNKbb43A43ny076khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8 BYtv9ePsXklAxtm8J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV 27ioRKbj/cIq7JRXun0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jGCA90wggPZAgEBMIGU MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwoD4zAJBgUrDgMCGgUAoIIC HTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDExMjAwODI5 MDJaMCMGCSqGSIb3DQEJBDEWBBSj96hqn0QT8KJj24BbA8gRtNF8+zBsBgkqhkiG9w0BCQ8x XzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGlBgkrBgEEAYI3 EAQxgZcwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDCgPjMIGnBgsq hkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0 ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMK A+MwDQYJKoZIhvcNAQEBBQAEggEAN1k+AT5BApRbKfsiHjqdfQCrl/y7zHnlUXIDK4fKXSJE H4B7/sPED24FGx1nWr3a+uXuFBeHTYbHI2zZ+vamR/c2zcV5Zb4evCcKgXMTVyLvqH9hIApZ H4S9c1+7P4PempbBTsqWTR5IrbutDZCfLO+PqIanGfHJZjqdZ1clRA/wbEMorFfutIPuI93W iUURAaRthhzAHglisYIB6scMs48tHuCHyGUSNlTkmKLZsjZmOPLkbS9Hvh/n007C4KH8f01S 0lmjZe8VvdjfTXB73Rc4nrbLK4oFlsyQFePgoYCp0ZtQGDeJd0Mvpm/fTTUm7oj5z3gVZ8Af ATjx/8HiaQAAAAAAAA== --------------ms070209010003030405030602-- From nobody Thu Nov 20 07:18: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 6B9F91A1A79 for ; Thu, 20 Nov 2014 07:18:15 -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 1VklyxplvZhh for ; Thu, 20 Nov 2014 07:18:13 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47D711A1AB2 for ; Thu, 20 Nov 2014 07:17:18 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 8E047282F88; Thu, 20 Nov 2014 15:17:16 +0000 (UTC) Date: Thu, 20 Nov 2014 15:17:16 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20141120151716.GQ13179@mournblade.imrryr.org> References: <20141027225310.29285.24437.idtracker@ietfa.amsl.com> <20141120062942.GL13179@mournblade.imrryr.org> <20141120073445.GM13179@mournblade.imrryr.org> <546DA64E.4010900@sidn.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <546DA64E.4010900@sidn.nl> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/XD9pgm5-Du0z9k0Yirdgh-z7jxA Subject: Re: [dane] Please help to remediate broken DNSSEC hosting 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, 20 Nov 2014 15:18:15 -0000 On Thu, Nov 20, 2014 at 09:29:02AM +0100, Marco Davids (SIDN) wrote: > In particular TransIP is a bit of a challenge, because they run their > own DNS-software and feel no rush to fix this issue. But rest assured > that we will keep on trying to have them improve things. At this point the "feel no rush" attitude will cause loss of email between SMTP with DANE early adopters to transip sites that employ wildcard records. They really need to get off their rear-ends and fix the problem. Otherwise, I may need to develop a new unbound feature that considers a zone insecure if all its NS records lie in a given blacklisted domain. I don't suppose it is possible to pressure transip with a threat of removal of the problem DS records from the '.nl' registry by say 6 months from now if the problem is not addressed? -- Viktor. From nobody Thu Nov 20 12:31: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 BACDE1A6EFE for ; Thu, 20 Nov 2014 12:31:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.495 X-Spam-Level: X-Spam-Status: No, score=-7.495 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, 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 6LPEsJKyTHyD for ; Thu, 20 Nov 2014 12:31:36 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CEFE1A1AEF for ; Thu, 20 Nov 2014 12:31:36 -0800 (PST) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.ams1.isc.org (Postfix) with ESMTP id 1D7D31FCAB6 for ; Thu, 20 Nov 2014 20:31:33 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id AF3B2160066 for ; Thu, 20 Nov 2014 20:34:58 +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 7F76016005A for ; Thu, 20 Nov 2014 20:34:58 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 6DC1323CE598 for ; Fri, 21 Nov 2014 07:31:30 +1100 (EST) To: dane@ietf.org From: Mark Andrews References: <20141027225310.29285.24437.idtracker@ietfa.amsl.com> <20141120062942.GL13179@mournblade.imrryr.org> <20141120073445.GM13179@mournblade.imrryr.org> <546DA64E.4010900@sidn.nl> <20141120151716.GQ13179@mournblade.imrryr.org> In-reply-to: Your message of "Thu, 20 Nov 2014 15:17:16 -0000." <20141120151716.GQ13179@mournblade.imrryr.org> Date: Fri, 21 Nov 2014 07:31:30 +1100 Message-Id: <20141120203130.6DC1323CE598@rock.dv.isc.org> Archived-At: http://mailarchive.ietf.org/arch/msg/dane/uEm9y0E-4S4mGmkvN0HUM8OtjyY Subject: Re: [dane] Please help to remediate broken DNSSEC hosting 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 Nov 2014 20:31:39 -0000 In message <20141120151716.GQ13179@mournblade.imrryr.org>, Viktor Dukhovni writ es: > On Thu, Nov 20, 2014 at 09:29:02AM +0100, Marco Davids (SIDN) wrote: > > > In particular TransIP is a bit of a challenge, because they run their > > own DNS-software and feel no rush to fix this issue. But rest assured > > that we will keep on trying to have them improve things. > > At this point the "feel no rush" attitude will cause loss of email > between SMTP with DANE early adopters to transip sites that employ > wildcard records. They really need to get off their rear-ends and > fix the problem. > > Otherwise, I may need to develop a new unbound feature that considers > a zone insecure if all its NS records lie in a given blacklisted > domain. > > I don't suppose it is possible to pressure transip with a threat > of removal of the problem DS records from the '.nl' registry by > say 6 months from now if the problem is not addressed? We have a documented complaints proceedure. We should follow it. RFC 1033 COMPLAINTS These are the suggested steps you should take if you are having problems that you believe are caused by someone else's name server: 1. Complain privately to the responsible person for the domain. You can find their mailing address in the SOA record for the domain. 2. Complain publicly to the responsible person for the domain. 3. Ask the NIC for the administrative person responsible for the domain. Complain. You can also find domain contacts on the NIC in the file NETINFO:DOMAIN-CONTACTS.TXT 4. Complain to the parent domain authorities. 5. Ask the parent authorities to excommunicate the domain. With a DNSSEC problem we may want to add a 4.5 step, ask the parent to remove the DS record. 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 Thu Nov 20 14:15: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 679031A87AB for ; Thu, 20 Nov 2014 14:15:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_72=0.6, J_CHICKENPOX_82=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 2VFFIMT9wcc8 for ; Thu, 20 Nov 2014 14:15:38 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CCDF1A87E0 for ; Thu, 20 Nov 2014 14:15:38 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 6A946284B10; Thu, 20 Nov 2014 22:15:36 +0000 (UTC) Date: Thu, 20 Nov 2014 22:15:36 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20141120221536.GF13179@mournblade.imrryr.org> References: <20141027225310.29285.24437.idtracker@ietfa.amsl.com> <20141120062942.GL13179@mournblade.imrryr.org> <20141120073445.GM13179@mournblade.imrryr.org> <546DA64E.4010900@sidn.nl> <20141120151716.GQ13179@mournblade.imrryr.org> <20141120203130.6DC1323CE598@rock.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141120203130.6DC1323CE598@rock.dv.isc.org> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/SInyglzvUYIAOY4RmgP36NrQuhU Subject: Re: [dane] Please help to remediate broken DNSSEC hosting 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, 20 Nov 2014 22:15:40 -0000 On Fri, Nov 21, 2014 at 07:31:30AM +1100, Mark Andrews wrote: > We have a documented complaints proceedure. We should follow it. > > RFC 1033 COMPLAINTS > > These are the suggested steps you should take if you are having > problems that you believe are caused by someone else's name server: > > > 1. Complain privately to the responsible person for the domain. You > can find their mailing address in the SOA record for the domain. > > 2. Complain publicly to the responsible person for the domain. > > 3. Ask the NIC for the administrative person responsible for the > domain. Complain. You can also find domain contacts on the NIC in > the file NETINFO:DOMAIN-CONTACTS.TXT > > 4. Complain to the parent domain authorities. > > 5. Ask the parent authorities to excommunicate the domain. > > With a DNSSEC problem we may want to add a 4.5 step, ask the parent > to remove the DS record. Thanks for the info. I guess we're not nearly up to steps 4.5 or 5 yet. And I did contacted off-list by transip, who I hope will follow-up on-list. I am however asking for help with cycles for this process. I can no longer keep up with the communication requirements. If anyone can help work the issue through the various domain contacts, registrars, and registries that'd be great! Below are the SOA RRs of the signed domains where MX host TLSA lookups SERVFAIL due to various nameserver bugs or zone signing problems. --- Likely systemic applying to many hosted domains --- aanbodpagina.nl. SOA ns0.transip.net. hostmaster.transip.nl. codingunit.com. SOA ns0.transip.net. hostmaster.transip.nl. connections-it.com. SOA ns0.transip.net. hostmaster.transip.nl. dresscode.nl. SOA ns0.transip.net. hostmaster.transip.nl. entix.nl. SOA ns0.transip.net. hostmaster.transip.nl. erdee.nl. SOA ns0.transip.net. hostmaster.transip.nl. fonq.nl. SOA ns0.transip.net. hostmaster.transip.nl. gamesync.nl. SOA ns0.transip.net. hostmaster.transip.nl. infonu.nl. SOA ns0.transip.net. hostmaster.transip.nl. kinderspiele.de. SOA ns0.transip.net. hostmaster.transip.nl. mediumchat.nl. SOA ns0.transip.net. hostmaster.transip.nl. notprovided.eu. SOA ns0.transip.net. hostmaster.transip.nl. ooshopping.nl. SOA ns0.transip.net. hostmaster.transip.nl. performance.nl. SOA ns0.transip.net. hostmaster.transip.nl. redskillz.nl. SOA ns0.transip.net. hostmaster.transip.nl. reviewspot.nl. SOA ns0.transip.net. hostmaster.transip.nl. seoshop.nl. SOA ns0.transip.net. hostmaster.transip.nl. splendense.nl. SOA ns0.transip.net. hostmaster.transip.nl. studio-donder.nl. SOA ns0.transip.net. hostmaster.transip.nl. trendstats.nl. SOA ns0.transip.net. hostmaster.transip.nl. trentt.com. SOA ns0.transip.net. hostmaster.transip.nl. webshopapp.com. SOA ns0.transip.net. hostmaster.transip.nl. webwinkelsoftware.nl. SOA ns0.transip.net. hostmaster.transip.nl. wrts.nl. SOA ns0.transip.net. hostmaster.transip.nl. zipzoo.nl. SOA ns0.transip.net. hostmaster.transip.nl. banoshop.eu. SOA ns1.hostnet.nl. hostmaster.hostnet.nl. bergsalaenigma.nl. SOA ns1.hostnet.nl. hostmaster.hostnet.nl. brandsupply.nl. SOA ns1.hostnet.nl. hostmaster.hostnet.nl. expert.nl. SOA ns1.hostnet.nl. hostmaster.hostnet.nl. foodness.nl. SOA ns1.hostnet.nl. hostmaster.hostnet.nl. ikkijkonline.nl. SOA ns1.hostnet.nl. hostmaster.hostnet.nl. leestrainer.nl. SOA ns1.hostnet.nl. hostmaster.hostnet.nl. studeersnel.nl. SOA ns1.hostnet.nl. hostmaster.hostnet.nl. utopiagekte.nl. SOA ns1.hostnet.nl. hostmaster.hostnet.nl. androidworld.nl. SOA ns0.transip.nl. hostmaster.transip.nl. gigacomputer.cz. SOA ns.forpsi.net. admin.forpsi.net. jursoft.cz. SOA ns.forpsi.net. admin.forpsi.net. --- Possibly sporadic applying to just the domains shown --- flashpatterns.nl. SOA ns1.hosting2go.nl. postmaster.flashpatterns.nl. informatieplatform.nl. SOA ns1.hosting2go.nl. postmaster.informatieplatform.nl. developmentaid.org. SOA ns0.transdns.eu. hostmaster.transip.eu. fuhrt.de. SOA ns1.remotedienst.de. natalie.fuhrt.de. fbi.gov. SOA ns1.fbi.gov. dns-admin.fbi.gov. nic.mil. SOA dns2.nipr.mil. disa\.columbus\.ns\.mbx\.hostmaster-dod-nic.mail.mil. disa.mil. SOA ns1.csd.disa.mil. disa\.meade\.esd\.list\.es312-ccc-hostmaster.mail.mil. stj.jus.br. SOA ns1.stj.jus.br. netmaster.stj.jus.br. dominion.ch. SOA ns.dominion.ch. hostmaster.dominion.ch. mec-import.de. SOA ns5.kp-dns.de. hostmaster.mec-import.de. -- Viktor. From nobody Sun Nov 23 12:23: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 84F041A1AAF for ; Sun, 23 Nov 2014 12:23:49 -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 I0Q4M0QTQVSj for ; Sun, 23 Nov 2014 12:23:47 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E8311A1AAD for ; Sun, 23 Nov 2014 12:23:46 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 95DFC282FCF; Sun, 23 Nov 2014 20:23:45 +0000 (UTC) Date: Sun, 23 Nov 2014 20:23:45 +0000 From: Viktor Dukhovni To: hostmaster@transip.nl Message-ID: <20141123202345.GI922@mournblade.imrryr.org> References: <20140908123910.GU26920@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140908123910.GU26920@mournblade.imrryr.org> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/Tr8Iv8xez1Znu5mEGABaFxtUmyQ Cc: "Deccio, Casey" , dane@ietf.org Subject: [dane] Problem with transip.{eu, net, nl} nameservers and DANE TLSA 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, 23 Nov 2014 20:23:49 -0000 As previously noted transip.nl domains emit incorrect denial of existence NSEC3 records for DANE TLSA queries. This will cause email delivery problems to your customers' domains if not resolved by fixing the nameserver software. My new (and surely incomplete) list of affected domains is below. The newly updated (thanks Casey!) dnsviz.net site now gives a very clear picture of the problem (just "mouse over" the NSEC3 record box). The NODATA response is not accompanied by any NSEC3 records that match the hash of the Qname: http://dnsviz.net/d/_25._tcp.mail.tekoopjes.be/dnssec/?rr=52&ds=all&a=all&doe=on&ta=. Queries for the TLSA records of all the MX hosts below similarly fail validation. What and when might be done to fully address this issue? Domain _25._tcp.mx-host. TLSA ? --------------------------------- --------------------------- tekoopjes.be. _25._tcp.mail.tekoopjes.be TLSA ? gryla.biz. _25._tcp.mail.gryla.biz TLSA ? aimyapp.com. _25._tcp.mail.aimyapp.com TLSA ? allofutopia.com. _25._tcp.mail.allofutopia.com TLSA ? bagatyou.com. _25._tcp.mail.bagatyou.com TLSA ? brunolinux.com. _25._tcp.mail.brunolinux.com TLSA ? chapterthemes.com. _25._tcp.mail.chapterthemes.com TLSA ? code-shop.com. _25._tcp.mail.code-shop.com TLSA ? codingunit.com. _25._tcp.mail.codingunit.com TLSA ? connections-it.com. _25._tcp.mail01.connections-it.com TLSA ? cultjer.com. _25._tcp.mail.cultjer.com TLSA ? cvgadget.com. _25._tcp.mail.cvgadget.com TLSA ? eminent-online.com. _25._tcp.mail.eminent-online.com TLSA ? gipsyfortuneteller.com. _25._tcp.mail.gipsyfortuneteller.com TLSA ? grasscompany.com. _25._tcp.mail.grasscompany.com TLSA ? inspirationalshops.com. _25._tcp.mail.inspirationalshops.com TLSA ? jolioriginals.com. _25._tcp.mail.jolioriginals.com TLSA ? kiiroo.com. _25._tcp.mail.kiiroo.com TLSA ? kivits.com. _25._tcp.mail.kivits.com TLSA ? mafiacontrol.com. _25._tcp.mail.mafiacontrol.com TLSA ? mtimpex.com. _25._tcp.mail.mtimpex.com TLSA ? onlinephpfunctions.com. _25._tcp.mail.onlinephpfunctions.com TLSA ? regularbolditalic.com. _25._tcp.mail.regularbolditalic.com TLSA ? sneltoetsen.com. _25._tcp.mail.sneltoetsen.com TLSA ? startupjuncture.com. _25._tcp.mail.startupjuncture.com TLSA ? statfetch.com. _25._tcp.mail.statfetch.com TLSA ? superfoodsi.com. _25._tcp.mail.superfoodsi.com TLSA ? toolshero.com. _25._tcp.mail.toolshero.com TLSA ? trentt.com. _25._tcp.mail.trentt.com TLSA ? villaxl.com. _25._tcp.mail.villaxl.com TLSA ? webshopapp.com. _25._tcp.mail.webshopapp.com TLSA ? zorgverzekering2015.com. _25._tcp.mail.zorgverzekering2015.com TLSA ? kinderspiele.de. _25._tcp.mail.kinderspiele.de TLSA ? makeupaktion.de. _25._tcp.mail.makeupaktion.de TLSA ? notprovided.eu. _25._tcp.mail.notprovided.eu TLSA ? cathair.net. _25._tcp.mail.cathair.net TLSA ? whatdoestheinternetthink.net. _25._tcp.mail.whatdoestheinternetthink.net TLSA ? 12gobiking.nl. _25._tcp.mail.12gobiking.nl TLSA ? 80db.nl. _25._tcp.office.80db.nl TLSA ? aanbodpagina.nl. _25._tcp.mail.aanbodpagina.nl TLSA ? alainotjens.nl. _25._tcp.mail.alainotjens.nl TLSA ? androidworld.nl. _25._tcp.old.androidworld.nl TLSA ? baby-slofje.nl. _25._tcp.mail.baby-slofje.nl TLSA ? beginspot.nl. _25._tcp.mail.beginspot.nl TLSA ? benchwarmers.nl. _25._tcp.mail.benchwarmers.nl TLSA ? besteld.nl. _25._tcp.mail.besteld.nl TLSA ? bitlabs.nl. _25._tcp.mail.bitlabs.nl TLSA ? bmwforum.nl. _25._tcp.mail.bmwforum.nl TLSA ? boatcruisesamsterdam.nl. _25._tcp.mail.boatcruisesamsterdam.nl TLSA ? boetiek.nl. _25._tcp.mail.boetiek.nl TLSA ? casade.nl. _25._tcp.mail.casade.nl TLSA ? celdomy.nl. _25._tcp.mx.celdomy.nl TLSA ? consentido.nl. _25._tcp.mail.consentido.nl TLSA ? creativegeeks.nl. _25._tcp.mail.creativegeeks.nl TLSA ? cybercell.nl. _25._tcp.mail.cybercell.nl TLSA ? debrugkrant.nl. _25._tcp.mail.debrugkrant.nl TLSA ? diannetemebel.nl. _25._tcp.mail.diannetemebel.nl TLSA ? discountoffice.nl. _25._tcp.mail.discountoffice.nl TLSA ? dresscode.nl. _25._tcp.mail.dresscode.nl TLSA ? droominfo.nl. _25._tcp.mail.droominfo.nl TLSA ? e-matching.nl. _25._tcp.mail.e-matching.nl TLSA ? energy4all.nl. _25._tcp.mail.energy4all.nl TLSA ? erdee.nl. _25._tcp.mx01.erdee.nl TLSA ? ervaringenreview.nl. _25._tcp.mail.ervaringenreview.nl TLSA ? etiquette.nl. _25._tcp.mail.etiquette.nl TLSA ? fonq.nl. _25._tcp.mail.fonq.nl TLSA ? g-vloeren.nl. _25._tcp.mail.g-vloeren.nl TLSA ? gamersnet.nl. _25._tcp.mail.gamersnet.nl TLSA ? gamesync.nl. _25._tcp.mail.gamesync.nl TLSA ? gfkintomart.nl. _25._tcp.mail.gfkintomart.nl TLSA ? google-plus-marketing.nl. _25._tcp.mail.google-plus-marketing.nl TLSA ? harmonieorkestamstelveen.nl. _25._tcp.mail.harmonieorkestamstelveen.nl TLSA ? headlines.nl. _25._tcp.mail.headlines.nl TLSA ? hvzeeland.nl. _25._tcp.mail.hvzeeland.nl TLSA ? hypoconcern.nl. _25._tcp.exchange.hypoconcern.nl TLSA ? indextra.nl. _25._tcp.mercurius.indextra.nl TLSA ? infonu.nl. _25._tcp.mail.infonu.nl TLSA ? interhouse.nl. _25._tcp.mail.interhouse.nl TLSA ? jasperalblas.nl. _25._tcp.mail.jasperalblas.nl TLSA ? koopjegedicht.nl. _25._tcp.mail.koopjegedicht.nl TLSA ? lansolutions.nl. _25._tcp.barracuda1.lansolutions.nl TLSA ? livewall.nl. _25._tcp.mail.livewall.nl TLSA ? managementgoeroes.nl. _25._tcp.mail.managementgoeroes.nl TLSA ? marcobax.nl. _25._tcp.mail.marcobax.nl TLSA ? marketingmed.nl. _25._tcp.mail.marketingmed.nl TLSA ? mediumchat.nl. _25._tcp.mail.mediumchat.nl TLSA ? mijnsportwinkels.nl. _25._tcp.mail.mijnsportwinkels.nl TLSA ? muziekgebouw.nl. _25._tcp.mail.muziekgebouw.nl TLSA ? nrccarriere.nl. _25._tcp.mail.nrccarriere.nl TLSA ? ohfashion.nl. _25._tcp.mail.ohfashion.nl TLSA ? oldwood.nl. _25._tcp.mail.oldwood.nl TLSA ? ooshopping.nl. _25._tcp.mail.ooshopping.nl TLSA ? oplaadpalen.nl. _25._tcp.mail.oplaadpalen.nl TLSA ? optimusad.nl. _25._tcp.mail.optimusad.nl TLSA ? otjensa.nl. _25._tcp.mail.otjensa.nl TLSA ? partycorner.nl. _25._tcp.mail.partycorner.nl TLSA ? pastoorkingma.nl. _25._tcp.mail.pastoorkingma.nl TLSA ? peekaas.nl. _25._tcp.mail.peekaas.nl TLSA ? penninkhofmode.nl. _25._tcp.mail.penninkhofmode.nl TLSA ? performance.nl. _25._tcp.mail.performance.nl TLSA ? poort3.nl. _25._tcp.cs03.poort3.nl TLSA ? proud2bme.nl. _25._tcp.mail.proud2bme.nl TLSA ? puurweb.nl. _25._tcp.mail.puurweb.nl TLSA ? radiocorp.nl. _25._tcp.mail.radiocorp.nl TLSA ? receptenvandaag.nl. _25._tcp.mail.receptenvandaag.nl TLSA ? redskillz.nl. _25._tcp.mail.redskillz.nl TLSA ? reviewspot.nl. _25._tcp.mail.reviewspot.nl TLSA ? sail-2015.nl. _25._tcp.mail.sail-2015.nl TLSA ? seoshop.nl. _25._tcp.mail.seoshop.nl TLSA ? shoeline.nl. _25._tcp.mail.shoeline.nl TLSA ? shopvilla.nl. _25._tcp.mail.shopvilla.nl TLSA ? showhome.nl. _25._tcp.mail.showhome.nl TLSA ? singerlaren.nl. _25._tcp.mail.singerlaren.nl TLSA ? sitepreview.nl. _25._tcp.mail.sitepreview.nl TLSA ? splendense.nl. _25._tcp.mailhost.splendense.nl TLSA ? sportnext.nl. _25._tcp.mail.sportnext.nl TLSA ? studio-donder.nl. _25._tcp.mail.studio-donder.nl TLSA ? tarwegraskoning.nl. _25._tcp.mail.tarwegraskoning.nl TLSA ? thatsgaming.nl. _25._tcp.mail.thatsgaming.nl TLSA ? thuiswerkvacatures.nl. _25._tcp.mail.thuiswerkvacatures.nl TLSA ? topprice24.nl. _25._tcp.mail.topprice24.nl TLSA ? trendstats.nl. _25._tcp.mail.trendstats.nl TLSA ? vindhetviahier.nl. _25._tcp.mail.vindhetviahier.nl TLSA ? webwinkelsoftware.nl. _25._tcp.mail.webwinkelsoftware.nl TLSA ? weeghals.nl. _25._tcp.mail.weeghals.nl TLSA ? why.nl. _25._tcp.mail.why.nl TLSA ? wordfeudpro.nl. _25._tcp.mail.wordfeudpro.nl TLSA ? wouterhol.nl. _25._tcp.mail.wouterhol.nl TLSA ? wrts.nl. _25._tcp.mail.wrts.nl TLSA ? wux.nl. _25._tcp.mailoud.wux.nl TLSA ? wymefa.nl. _25._tcp.mail.wymefa.nl TLSA ? xsarus.nl. _25._tcp.mail.xsarus.nl TLSA ? zipzoo.nl. _25._tcp.mail.zipzoo.nl TLSA ? cpkb.org. _25._tcp.mail.cpkb.org TLSA ? developmentaid.org. _25._tcp.mail-s01.developmentaid.org TLSA ? zim-wiki.org. _25._tcp.mail.zim-wiki.org TLSA ? consultancy.uk. _25._tcp.mail.consultancy.uk TLSA ? -- Viktor. From nobody Sun Nov 23 12:35: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 6EC0D1A1A8A for ; Sun, 23 Nov 2014 12:35:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_82=0.6, J_CHICKENPOX_92=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 SbZ20TXOMypC for ; Sun, 23 Nov 2014 12:35:17 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E09151A1A87 for ; Sun, 23 Nov 2014 12:35:16 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id D3470282FCF; Sun, 23 Nov 2014 20:35:15 +0000 (UTC) Date: Sun, 23 Nov 2014 20:35:15 +0000 From: Viktor Dukhovni To: hostmaster@hostnet.nl Message-ID: <20141123203515.GJ922@mournblade.imrryr.org> References: <20140908123910.GU26920@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140908123910.GU26920@mournblade.imrryr.org> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/o_tlvZ-sd5eAzJ2PdQDheUm9HVI Cc: "Deccio, Casey" , dane@ietf.org Subject: [dane] Problem with hostnet.nl/hostnetbv.{com, nl} nameservers and DANE TLSA 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, 23 Nov 2014 20:35:18 -0000 Many hostnet.nl domains emit incorrect denial of existence NSEC3 records for DANE TLSA queries. This will cause email delivery problems to your customers' domains if not resolved by fixing the nameserver software. My (surely incomplete) list of affected domains is below. The newly updated (thanks Casey!) dnsviz.net site now gives a very clear picture of the problem (just "mouse over" the NSEC3 record box). The NODATA response is not accompanied by any NSEC3 records that match the hash of the Qname, rather the NSEC3 records prove NXDOMAIN, but the RCODE is incorrectly NOERROR: http://dnsviz.net/d/_25._tcp.banoshop.eu/dnssec/?rr=52&ds=all&a=all&doe=on&ta=. Queries for the TLSA records of all the MX hosts below similarly fail validation. What and when might be done to fully address this issue? Domain _25._tcp.mx-host. IN TLSA ? --------------------------------- --------------------------- banoshop.eu. _25._tcp.banoshop.eu. IN TLSA ? cyclewear.eu. _25._tcp.mail.cyclewear.eu. IN TLSA ? motorcyclespareparts.eu. _25._tcp.mail.motorcyclespareparts.eu. IN TLSA ? 24uurshop.nl. _25._tcp.mail.24uurshop.nl. IN TLSA ? androididee.nl. _25._tcp.androididee.nl. IN TLSA ? astroblogs.nl. _25._tcp.astroblogs.nl. IN TLSA ? bedrijvenenwinkels.nl. _25._tcp.mail.bedrijvenenwinkels.nl. IN TLSA ? bergsalaenigma.nl. _25._tcp.mail.bergsalaenigma.nl. IN TLSA ? bijleszaanstad.nl. _25._tcp.mail.bijleszaanstad.nl. IN TLSA ? bitmagazine.nl. _25._tcp.bitmagazine.nl. IN TLSA ? bouwproducten.nl. _25._tcp.mail.bouwproducten.nl. IN TLSA ? brandsupply.nl. _25._tcp.mail.brandsupply.nl. IN TLSA ? completebeveiliging.nl. _25._tcp.mail.completebeveiliging.nl. IN TLSA ? content-hoster.nl. _25._tcp.content-hoster.nl. IN TLSA ? expert.nl. _25._tcp.mail.expert.nl. IN TLSA ? florijnmobiliteit.nl. _25._tcp.mail.florijnmobiliteit.nl. IN TLSA ? foodness.nl. _25._tcp.mail.foodness.nl. IN TLSA ? fotoklein.nl. _25._tcp.exchange.fotoklein.nl. IN TLSA ? gangbangstars.nl. _25._tcp.gangbangstars.nl. IN TLSA ? halloprisma.nl. _25._tcp.halloprisma.nl. IN TLSA ? hrdlpn.nl. _25._tcp.mail.hrdlpn.nl. IN TLSA ? ikkijkonline.nl. _25._tcp.ikkijkonline.nl. IN TLSA ? ikwoonfijn.nl. _25._tcp.ikwoonfijn.nl. IN TLSA ? inshared.nl. _25._tcp.mail5.inshared.nl. IN TLSA ? insomnia247.nl. _25._tcp.mail.insomnia247.nl. IN TLSA ? jacquelinelaats.nl. _25._tcp.jacquelinelaats.nl. IN TLSA ? jeffreyappel.nl. _25._tcp.jeffreyappel.nl. IN TLSA ? jobbsquare.nl. _25._tcp.jobbsquare.nl. IN TLSA ? joof.nl. _25._tcp.mail.joof.nl. IN TLSA ? kredietspotter.nl. _25._tcp.mail.kredietspotter.nl. IN TLSA ? leestrainer.nl. _25._tcp.mail.leestrainer.nl. IN TLSA ? minimumloon.nl. _25._tcp.minimumloon.nl. IN TLSA ? myshipper.nl. _25._tcp.mx.myshipper.nl. IN TLSA ? nrdbv.nl. _25._tcp.mail.nrdbv.nl. IN TLSA ? oilcontrolsystems.nl. _25._tcp.mail.oilcontrolsystems.nl. IN TLSA ? preferenso.nl. _25._tcp.mail.preferenso.nl. IN TLSA ? premiummotors.nl. _25._tcp.mail.premiummotors.nl. IN TLSA ? punkypet.nl. _25._tcp.mail.punkypet.nl. IN TLSA ? rotomdev.nl. _25._tcp.rotomdev.nl. IN TLSA ? sanisale.nl. _25._tcp.mail-1.sanisale.nl. IN TLSA ? showbiznewz.nl. _25._tcp.mail.showbiznewz.nl. IN TLSA ? skipiste-nieuwegein.nl. _25._tcp.skipiste-nieuwegein.nl. IN TLSA ? smokinbarrels.nl. _25._tcp.mail.smokinbarrels.nl. IN TLSA ? studeersnel.nl. _25._tcp.mail.studeersnel.nl. IN TLSA ? telefoondetective.nl. _25._tcp.mail.telefoondetective.nl. IN TLSA ? teocho.nl. _25._tcp.mail.teocho.nl. IN TLSA ? tijdvooralcoholvrij.nl. _25._tcp.mail.tijdvooralcoholvrij.nl. IN TLSA ? toilet-webshop.nl. _25._tcp.toilet-webshop.nl. IN TLSA ? topvitamins.nl. _25._tcp.topvitamins.nl. IN TLSA ? utopiagekte.nl. _25._tcp.utopiagekte.nl. IN TLSA ? vakantie-frankrijk.nl. _25._tcp.vakantie-frankrijk.nl. IN TLSA ? venduevoir.nl. _25._tcp.venduevoir.nl. IN TLSA ? werkenbijinventiv.nl. _25._tcp.mail.werkenbijinventiv.nl. IN TLSA ? xco-unlimited.nl. _25._tcp.mail.xco-unlimited.nl. IN TLSA ? zonnemarkt.nl. _25._tcp.newmail.zonnemarkt.nl. IN TLSA ? zwokbor.nl. _25._tcp.zwokbor.nl. IN TLSA ? -- Viktor. From nobody Sun Nov 23 14:03: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 99C961A1B1A for ; Sun, 23 Nov 2014 14:03:00 -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 hciQT5nG5AzC for ; Sun, 23 Nov 2014 14:02:58 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACD211A1B14 for ; Sun, 23 Nov 2014 14:02:58 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 25C81282FCF; Sun, 23 Nov 2014 22:02:57 +0000 (UTC) Date: Sun, 23 Nov 2014 22:02:57 +0000 From: Viktor Dukhovni To: postmaster@hosting2go.nl Message-ID: <20141123220256.GK922@mournblade.imrryr.org> References: <20140908123910.GU26920@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140908123910.GU26920@mournblade.imrryr.org> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/Nh1zeLtpmV9x32isBeSuYiR1-Ms Cc: "Deccio, Casey" , dane@ietf.org Subject: [dane] Problem with hosting2go.nl nameservers and DANE TLSA 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, 23 Nov 2014 22:03:00 -0000 [ Cc: to the dane WG list, in the hope that some here might be able to assist, if they have direct contacts at the provider. Please don't Cc: any follow-up list discussion to the ISP contact address. ] Many hosting2go.nl domains emit incorrect denial of existence NSEC records for DANE TLSA queries. This will cause email delivery problems to your customers' domains if not resolved by fixing the nameserver software. My (surely incomplete) list of affected domains is below. For example, the nameservers for albertplatje.nl return NODATA instead of NXDMAIN for the query below: $ dig +cd +dnssec -t tlsa _25._tcp.albertplatje.nl. +nocl +nottl | pcregrep 'status:|^;; flags|\.\s+NSEC' ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20796 ;; flags: qr rd ra cd; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1 *.albertplatje.nl. NSEC _autodiscover._tcp.albertplatje.nl. A RRSIG NSEC The NSEC record proves the presence of "_tcp.albertplatje.nl", and the absence of both "_25._tcp.albertplatje.nl" and "*._tcp.albertplatje.nl" which lie between the NSEC pair endpoints. Therefore, this record should be an NXDOMAIN, not NOERROR (aka NODATA when the answer count is 0). In this case I believe we have a bug in dnsviz, which fails to note that NSEC the record proves the existence of the empty non-terminal "_tcp", and thus the relevant closest encloser is "_tcp" and so the wildcard RRset is out of scope, and hence the RCODE should be NXDOMAIN. http://dnsviz.net/d/_25._tcp.albertplatje.nl/dnssec/?rr=52&ds=all&a=all&doe=on&ta=. Queries for the TLSA records of all the MX hosts below similarly fail validation. What and when might be done to fully address this issue? Domain _25._tcp.mx-host. IN TLSA ? --------------------------------- --------------------------- albertplatje.nl. _25._tcp.albertplatje.nl. IN TLSA ? azie4y.nl. _25._tcp.azie4y.nl. IN TLSA ? delta-hardware.nl. _25._tcp.delta-hardware.nl. IN TLSA ? digistrip.nl. _25._tcp.digistrip.nl. IN TLSA ? edwords.nl. _25._tcp.edwords.nl. IN TLSA ? flashpatterns.nl. _25._tcp.flashpatterns.nl. IN TLSA ? informatieplatform.nl. _25._tcp.informatieplatform.nl. IN TLSA ? kenney.nl. _25._tcp.kenney.nl. IN TLSA ? locdepot.nl. _25._tcp.locdepot.nl. IN TLSA ? mc4e.nl. _25._tcp.mc4e.nl. IN TLSA ? mega-save.nl. _25._tcp.mega-save.nl. IN TLSA ? netspecialist.nl. _25._tcp.netspecialist.nl. IN TLSA ? parfumsector.nl. _25._tcp.parfumsector.nl. IN TLSA ? portraitsbyrhalda.nl. _25._tcp.portraitsbyrhalda.nl. IN TLSA ? premiumsecurity.nl. _25._tcp.premiumsecurity.nl. IN TLSA ? rijschoolnaz.nl. _25._tcp.rijschoolnaz.nl. IN TLSA ? schaakzone.nl. _25._tcp.schaakzone.nl. IN TLSA ? straxlive.nl. _25._tcp.straxlive.nl. IN TLSA ? we12travel.nl. _25._tcp.we12travel.nl. IN TLSA ? winkelsector.nl. _25._tcp.winkelsector.nl. IN TLSA ? -- Viktor. From nobody Sun Nov 23 14:20: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 342BB1A1B27 for ; Sun, 23 Nov 2014 14:20:10 -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_00=-1.9, J_CHICKENPOX_45=0.6, URI_NOVOWEL=0.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 AbRAcL0xIZoO for ; Sun, 23 Nov 2014 14:20:09 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E073F1A1B14 for ; Sun, 23 Nov 2014 14:20:08 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 3B72C282FCF; Sun, 23 Nov 2014 22:20:08 +0000 (UTC) Date: Sun, 23 Nov 2014 22:20:08 +0000 From: Viktor Dukhovni To: hostmaster@ns0.nl Message-ID: <20141123222007.GL922@mournblade.imrryr.org> References: <20140908123910.GU26920@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140908123910.GU26920@mournblade.imrryr.org> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/pL70qqi71zND3DrxbnXKaBB-iC8 Cc: "Deccio, Casey" , dane@ietf.org Subject: [dane] Problem with ns0.nl nameservers and DANE TLSA 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, 23 Nov 2014 22:20:10 -0000 [ Cc: to the dane WG list, in the hope that some here might be able to assist, if they have direct contacts at the provider. Please don't Cc: any follow-up list discussion to the ISP contact address. This is the final report! Just 5 DNS hosting providers appear to account for all the non-sporadic failures of TLSA lookups. ] Many ns0.nl domains emit incorrect denial of existence NSEC3 records for DANE TLSA queries. This will cause email delivery problems to your customers' domains if not resolved by fixing the nameserver software. My (surely incomplete) list of affected domains is below. The newly updated (thanks Casey!) dnsviz.net site now gives a very clear picture of the problem (just "mouse over" the NSEC3 record box). The NODATA response is not accompanied by any NSEC3 records that match the hash of the Qname, rather the NSEC3 records prove NXDOMAIN, but the RCODE is incorrectly NOERROR: http://dnsviz.net/d/_25._tcp.mail.photoshoplayerstyle.com/dnssec/?rr=52&a=all&ds=all&doe=on&ta=.&tk= The closest encloser is "mail.photoshoplayerstyle.com", and the NSEC3 records return exclude the presence of "*mail.photoshoplayerstyle.com": $ dig +cd +dnssec -t tlsa _25._tcp.mail.photoshoplayerstyle.com. +nocl +nottl | pcregrep 'status:|^;; flags|\.\s+NSEC' ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43917 ;; flags: qr rd ra cd; QUERY: 1, ANSWER: 0, AUTHORITY: 8, ADDITIONAL: 1 s65rgcpqslu0ftooro2f1su7nd7ve67b.photoshoplayerstyle.com. NSEC3 1 0 100 57AE8C5E617F9173 40EEHCT3600L9LLE0HTHM25UKF4AKVPJ A NS SOA MX RRSIG DNSKEY NSEC3PARAM 40eehct3600l9lle0hthm25ukf4akvpj.photoshoplayerstyle.com. NSEC3 1 0 100 57AE8C5E617F9173 5DKJRL27ESVU3IV4EJR83HBJPPURER2K A RRSIG qn0r3962bhci2jsktqa29urqefoql1jk.photoshoplayerstyle.com. NSEC3 1 0 100 57AE8C5E617F9173 S65RGCPQSLU0FTOORO2F1SU7ND7VE67B A RRSIG $ ldns-nsec3-hash -t 100 -s 57AE8C5E617F9173 _25._tcp.mail.photoshoplayerstyle.com dr1og56r60uhgn6l1o81nmr1q71inas6. $ ldns-nsec3-hash -t 100 -s 57AE8C5E617F9173 _tcp.mail.photoshoplayerstyle.com 3launk5llo6614jm12c5si3fbq6td7uh. $ ldns-nsec3-hash -t 100 -s 57AE8C5E617F9173 mail.photoshoplayerstyle.com 40eehct3600l9lle0hthm25ukf4akvpj. $ ldns-nsec3-hash -t 100 -s 57AE8C5E617F9173 '*mail.photoshoplayerstyle.com' 4bkj4e34gpijvjbdfhn6t6urpj4gsb85. $ ldns-nsec3-hash -t 100 -s 57AE8C5E617F9173 '*.photoshoplayerstyle.com' qn0r3962bhci2jsktqa29urqefoql1jk. They do however prove the wildcard "*.photoshoplayerstyle.com" A record, so it seems this is erroneasly reported here despite the fact that mail.photoshoplayerstyle.com exists. Queries for the TLSA records of all the MX hosts below similarly fail validation. What and when might be done to fully address this issue? Domain _25._tcp.mx-host. IN TLSA ? --------------------------------- --------------------------- photoshoplayerstyle.com. _25._tcp.mail.photoshoplayerstyle.com. IN TLSA ? badpunt.nl. _25._tcp.mail.badpunt.nl. IN TLSA ? emij.nl. _25._tcp.emijx1.emij.nl. IN TLSA ? getinteractive.nl. _25._tcp.x9.getinteractive.nl. IN TLSA ? go4camp.nl. _25._tcp.mail.go4camp.nl. IN TLSA ? imageserve.nl. _25._tcp.mail.imageserve.nl. IN TLSA ? internet123.nl. _25._tcp.mail.internet123.nl. IN TLSA ? orionvolleybal.nl. _25._tcp.mail.orionvolleybal.nl. IN TLSA ? sollicitatiedokter.nl. _25._tcp.mail.sollicitatiedokter.nl. IN TLSA ? wpnet.nl. _25._tcp.mail01.wpnet.nl. IN TLSA ? -- Viktor. From nobody Sun Nov 23 14:32: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 838761A1B3D for ; Sun, 23 Nov 2014 14:32:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.947 X-Spam-Level: X-Spam-Status: No, score=-0.947 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-2.3] 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 jOD627TU7GGv for ; Sun, 23 Nov 2014 14:32:32 -0800 (PST) Received: from proper.com (Hoffman.Proper.COM [207.182.41.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81FC91A1B3B for ; Sun, 23 Nov 2014 14:32:32 -0800 (PST) Received: from [10.20.30.90] (142-254-17-143.dsl.dynamic.fusionbroadband.com [142.254.17.143]) (authenticated bits=0) by proper.com (8.14.9/8.14.7) with ESMTP id sANMWTre062345 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 23 Nov 2014 15:32:30 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: proper.com: Host 142-254-17-143.dsl.dynamic.fusionbroadband.com [142.254.17.143] claimed to be [10.20.30.90] From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Sun, 23 Nov 2014 14:32:28 -0800 To: dane@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/_gtG33G_AQMJAjJgN_1D_ZWN8Vg Subject: [dane] Follow-up on Viktor's bug reports 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, 23 Nov 2014 22:32:33 -0000 Greetings again. If any of you know the ISPs or DNS admins at the places = Viktor just send those bug reports to (where he CC'd this list), you can = help by giving those folks a nudge in the right direction. If you find = something useful to other admins, by all means write it down and send it = to Dan York for his work as well. Thanks! --Paul Hoffman= From nobody Sun Nov 23 15:59: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 BDA1A1A1B5E for ; Sun, 23 Nov 2014 15:59:44 -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_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 S7VorNudVjhs for ; Sun, 23 Nov 2014 15:59:43 -0800 (PST) Received: from mail-ig0-f182.google.com (mail-ig0-f182.google.com [209.85.213.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 242B41A1B5C for ; Sun, 23 Nov 2014 15:59:43 -0800 (PST) Received: by mail-ig0-f182.google.com with SMTP id hn15so2353055igb.3 for ; Sun, 23 Nov 2014 15:59: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:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=IdwF/0bSNVtu5KolZrKatv1g3KLkqIrwyJcrg4nM51E=; b=iZOAILI0Wbr7SLdRIOW1u1hakU/0QIsn+RwX4/KV4JqZOR3Du077Edmwr+oMXbaQoG cDAAa/JMCVYboLLTjQ+/3cwiENuHkArHhKV3r1ZfhiUCrSxgPX0CZfWpZmQMAo4LZg70 0t7C9RHMoyefSe0khG5JBBXYJPi2fYCW6v3nQ4g198A0ZBHCTUgqwQVpx/IEMij3ULCn 9g+C2FobD5+FS/ZoxYXy+Qfpcmj/NPQv6zcmDm/pJAy9uMmhtFFVbgfNd3wcU9LcnnwV kiyjgXvb38OKHJv4wBqFR84HcKfrQK3+orSp6MrSbPJSgFUXT0yhYG++66v6zbjz9c0x XwbA== X-Gm-Message-State: ALoCoQnlumuCTUyFKzvlZ7LrQjEApKv/AQDOrNQD9K/a0rpFjmEyaC2HFsvftllkag2fxNO+mrF+ X-Received: by 10.50.47.14 with SMTP id z14mr8859495igm.38.1416787182497; Sun, 23 Nov 2014 15:59:42 -0800 (PST) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id cy6sm3067986igc.21.2014.11.23.15.59.41 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 23 Nov 2014 15:59:41 -0800 (PST) Message-ID: <547274EC.70102@andyet.net> Date: Sun, 23 Nov 2014 16:59:40 -0700 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: dane@ietf.org References: <20140908123910.GU26920@mournblade.imrryr.org> <20141123202345.GI922@mournblade.imrryr.org> In-Reply-To: <20141123202345.GI922@mournblade.imrryr.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dane/SvNjSNrXdCTvWVbZXWj8YQ7pQ60 Subject: Re: [dane] Problem with transip.{eu, net, nl} nameservers and DANE TLSA 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, 23 Nov 2014 23:59:44 -0000 Viktor, I appreciate that you are passionate about this topic, but the DANE WG is (IMHO) for discussion about developing standards for DANE, not complaints about poor implementation or deployment. I for one would appreciate it if you would cease copying dane@ietf.org on these messages. Peter -- Peter Saint-Andre https://andyet.com/ From nobody Sun Nov 23 16:46: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 6C5A51A1B73 for ; Sun, 23 Nov 2014 16:46:24 -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 KAARhtXCNSkm for ; Sun, 23 Nov 2014 16:46:23 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 247A61A1B6D for ; Sun, 23 Nov 2014 16:46:23 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 01AB1282FCF; Mon, 24 Nov 2014 00:46:21 +0000 (UTC) Date: Mon, 24 Nov 2014 00:46:21 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20141124004621.GN922@mournblade.imrryr.org> References: <20140908123910.GU26920@mournblade.imrryr.org> <20141123202345.GI922@mournblade.imrryr.org> <547274EC.70102@andyet.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <547274EC.70102@andyet.net> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/chLcaI6FgpNIuTtwwxikC03e14o Subject: Re: [dane] Problem with transip.{eu, net, nl} nameservers and DANE TLSA 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, 24 Nov 2014 00:46:24 -0000 On Sun, Nov 23, 2014 at 04:59:40PM -0700, Peter Saint-Andre - &yet wrote: > Viktor, I appreciate that you are passionate about this topic, but the DANE > WG is (IMHO) for discussion about developing standards for DANE, not > complaints about poor implementation or deployment. I for one would > appreciate it if you would cease copying dane@ietf.org on these messages. Understood. No more such messages are planned. As a brief summary, we have some deployment hurdles to clear. If Dan York is willing, I'll keep him and anyone else who's interested on any progress reports from the ISPs. Just drop me a note if you want to stay in the loop. -- Viktor. From nobody Mon Nov 24 06:45: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 883001A6FA3 for ; Mon, 24 Nov 2014 06:45:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.084 X-Spam-Level: X-Spam-Status: No, score=0.084 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 twV0xtwytZ4Z for ; Mon, 24 Nov 2014 06:45:16 -0800 (PST) Received: from arn2-kamx.sidn.nl (kamx.sidn.nl [IPv6:2a00:d78:0:147:94:198:152:69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C65B31A6F92 for ; Mon, 24 Nov 2014 06:45:15 -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:subject:references:in-reply-to:content-type:x-originating-ip; bh=yVyLmGK/4xqnibbPb9NTesd6qDYtio+5f+JWKVpBdKE=; b=YwgC9JXJlvtTHcdh6vXHvyu0/Kp1KiGaPIR98OZYQPqJkLXJlD3rLqfA0ZMF2SG56ygW5fWQ3/+KJIER6MxWQZkNwB/70/eK8F+5+JZzDrkRjKdoLUqyxXer6IxQ8C1rCFKtXTKdGAUShvDGLdjhkxk37zOPId22GJbbBYoX5+M= Received: from kahubcasn02.SIDN.local ([192.168.2.74]) by arn2-kamx.sidn.nl with ESMTP id sAOEjDiv029876-sAOEjDix029876 (version=TLSv1.0 cipher=AES256-SHA bits=256 verify=CAFAIL) for ; Mon, 24 Nov 2014 15:45:13 +0100 Received: from rndhost215.sidn.nl (94.198.152.215) by kahubcasn02.SIDN.local (192.168.2.77) with Microsoft SMTP Server (TLS) id 14.3.174.1; Mon, 24 Nov 2014 15:45:09 +0100 Message-ID: <54734475.6080007@sidn.nl> Date: Mon, 24 Nov 2014 15:45:09 +0100 From: "Marco Davids (SIDN)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:35.0) Gecko/20100101 Thunderbird/35.0a2 MIME-Version: 1.0 To: References: In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090100080301010900080600" X-Originating-IP: [94.198.152.215] Archived-At: http://mailarchive.ietf.org/arch/msg/dane/IE19EmZUKQzAGqn3Y6S23sCX_j8 Subject: Re: [dane] Follow-up on Viktor's bug reports 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 Nov 2014 14:45:18 -0000 --------------ms090100080301010900080600 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Paul, On 23/11/14 23:32, Paul Hoffman wrote: > If any of you know the ISPs or DNS admins at the places Viktor just sen= d those bug reports to, you can help by giving those folks a nudge in the= right direction.=20 As indicated earlier; We are in close contact with TransIP and they have confirmed they are working on a solution. --=20 Marco --------------ms090100080301010900080600 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMZjCC BiowggUSoAMCAQICAwoD4zANBgkqhkiG9w0BAQsFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRl IFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlh dGUgQ2xpZW50IENBMB4XDTE0MDUyMDE3NTUyOFoXDTE1MDUyMjAwMTc1NlowRDEdMBsGA1UE AwwUbWFyY28uZGF2aWRzQHNpZG4ubmwxIzAhBgkqhkiG9w0BCQEWFG1hcmNvLmRhdmlkc0Bz aWRuLm5sMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0tDXTB0Q5LVXcdRfAg/x 7Baw83FDEtt566NEjxSG0Q6xnexJtiXUl4bfGSE9PHN2Y9tT7NOGxXPNPjddChUJbKwGhH27 zmWA6LK/4AnNyew8seFGKMp3UFOkfVUGBcNPvtHQPDSAZnZuds50vhpqLqyxa+EA8rjttC93 8/dZAjjV7etpk24W1s/Ith+c5oSP6rqIfl+tUPc4s2ZOudq8ov6jAV2OQ53S/G1OFR9s9ZEl uYZohI2gQB7Fz5Xfij20YqWnZ9619JndU4b5Cqs4NCxhnO3Pgoba85LhVdvkxAbKq/cIv8zP 4FrsKUhdkjWBmWK+r+vU/GtdcmZkM2YCtQIDAQABo4IC2jCCAtYwCQYDVR0TBAIwADALBgNV HQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBTVD7Di X5HtXqiaF+DhqGiH2ixl1TAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhRgjAfBgNV HREEGDAWgRRtYXJjby5kYXZpZHNAc2lkbi5ubDCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYB BAGBtTcBAgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xp Y3kucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0 aGUgQ2xhc3MgMSBWYWxpZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0Eg cG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21w bGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCug KaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcB AQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNz MS9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRz L3N1Yi5jbGFzczEuY2xpZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS8wDQYJKoZIhvcNAQELBQADggEBAGjmOZpe/qYtBZy5VSP5JRKEKlwIpxGUDNQv YhvCp53aVXvALQmXO6X1v3Oia+hpMliCof9ymQXUCSfNaftKBYx4ROr6kgmVZUtTrb10f/eW xNDVV/5Jhy1mAyQ4ziMXoW7r8Mbji653p2ewbYLZd6mtXkzvM/SNdh4iG5+dD4x2ih9IzEl6 XO4WFTgNFu26/0YXSCzkyb3K3O2jAUzyHvYB4dMUjxryVNDcLPae1CxeAYgpZNNmUVZPiOyB Fr/NRKgC77X1Q2STwUbo8JTTXka/rZup1Huj2g2AMrBZ/fO8+HSWFF0OeioEWFvOpSc2c8hs cb8LAWbtf9XerJ/a1rgwggY0MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNV BAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRh bCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9u IEF1dGhvcml0eTAeFw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQG EwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwg Q2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5 IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDHCYPMzi3YGrEppC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zP f1Jwuk0tsvVCk6U9b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG /FaR/wpbfuIqu54qzHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvur yGaC/o2/ceD2uYDX9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSy rrSMTGKkDiXm6/3/4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIB qTAPBgNVHRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssB XHx+ljVO8tS4UYIwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUH AQEEWjBYMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYB BQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCeg JaAjhiFodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9j cmwuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBm MC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsG AQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqG SIb3DQEBBQUAA4ICAQAKgwh9eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95 CfegFJTwqBBmf8pyTUnFsukDFUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A +hKMIzEzcduRkIMmCeUTyMyikfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcL N5A0t4DkuVhTMXIzuQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/ O75CDUHDRHCCKBVmz/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI27 0g+5MYA8GfgI/EPT5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z 77U1uL7TelWO5lApsbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/Q vVNKbb43A43ny076khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8 BYtv9ePsXklAxtm8J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV 27ioRKbj/cIq7JRXun0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jGCA90wggPZAgEBMIGU MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwoD4zAJBgUrDgMCGgUAoIIC HTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDExMjQxNDQ1 MDlaMCMGCSqGSIb3DQEJBDEWBBRxshn2LgTR31Md8rsJrOidpsMaxjBsBgkqhkiG9w0BCQ8x XzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGlBgkrBgEEAYI3 EAQxgZcwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDCgPjMIGnBgsq hkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0 ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMK A+MwDQYJKoZIhvcNAQEBBQAEggEAsylmRPlFskSpx7mxmQTbrklGmwLB7qvuPUcYzjGuwx6X TywK6tmuA5v5OocuwmD+Gl1xexZHHqmy7N9aFkVtVnjyREFGNJP1FZC4M9ouStHIuCbgP3wt ijaZ8i4AxWT+6Htb7GoaDz9gyAqMzz7YDo8WSuuAdzQ/JUojRoevSR+Ve+VEF18oHwID6w/Y hAfGK6HIkwma71ql20gaS5CUxBNY42MaFqiphaP18APQz/SiLJB03J+bPmN6FZj1L1v/U1s/ frd43HN65rLHDNGbe61XUOaZNu53IdS2SzAzlxYAinmWEB7K7RE99PBRdIVoFRwfiAgPmTT8 dLwwHuex/wAAAAAAAA== --------------ms090100080301010900080600-- From nobody Tue Nov 25 01:43: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 8CF941A00A3 for ; Tue, 25 Nov 2014 01:43:14 -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 Zll5xa60L-hE for ; Tue, 25 Nov 2014 01:43:12 -0800 (PST) Received: from mail.bortzmeyer.org (aetius.bortzmeyer.org [217.70.190.232]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B37081A00AA for ; Tue, 25 Nov 2014 01:43:09 -0800 (PST) Received: by mail.bortzmeyer.org (Postfix, from userid 10) id A818E3B9BF; Tue, 25 Nov 2014 10:43:06 +0100 (CET) Received: by mail.sources.org (Postfix, from userid 1000) id 4326E190AC2; Tue, 25 Nov 2014 10:41:18 +0100 (CET) Date: Tue, 25 Nov 2014 10:41:18 +0100 From: Stephane Bortzmeyer To: Olafur Gudmundsson Message-ID: <20141125094118.GA25246@sources.org> References: <0DAFC2A8-A1E2-46F4-BA52-E8261CB09159@ogud.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0DAFC2A8-A1E2-46F4-BA52-E8261CB09159@ogud.com> X-Transport: UUCP rules X-Operating-System: Debian GNU/Linux 7.7 User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/jZpMExHZx51gnQHBLbH4w-lUCTA Cc: "" Subject: Re: [dane] WGLC: DANE-SRV & DANE-SMTP 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 Nov 2014 09:43:15 -0000 On Wed, Nov 12, 2014 at 06:09:41PM -1000, Olafur Gudmundsson wrote a message of 71 lines which said: > http://tools.ietf.org/wg/dane/draft-ietf-dane-srv I have read and checked draft-ietf-dane-srv-08 and I think it is fine and ready. The main choice (checking the target domain rather than the service domain) seems reasonable and well explained in appendix B. Editorial : > Mail messages submitted for addresses at example.com are sent via > IMAP to imap.example.net. Sent via IMAP? Wouldn't it be better to write "Mail messages received for addresses at example.com are retrieved via IMAP to imap.example.net"? From nobody Tue Nov 25 06: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 067C81A1AC1 for ; Tue, 25 Nov 2014 06:27: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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 y_wqGf49TS_Q for ; Tue, 25 Nov 2014 06:27:35 -0800 (PST) Received: from smtp68.ord1c.emailsrvr.com (smtp68.ord1c.emailsrvr.com [108.166.43.68]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFEC71A1A76 for ; Tue, 25 Nov 2014 06:27:35 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp1.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 041C3380200 for ; Tue, 25 Nov 2014 09:27:35 -0500 (EST) X-Virus-Scanned: OK Received: by smtp1.relay.ord1c.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id 6F10B3802E3 for ; Tue, 25 Nov 2014 09:27:34 -0500 (EST) X-Sender-Id: ogud@ogud.com Received: from [10.20.30.43] (pool-74-96-189-180.washdc.fios.verizon.net [74.96.189.180]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:465 (trex/5.3.2); Tue, 25 Nov 2014 14:27:34 GMT From: Olafur Gudmundsson Content-Type: multipart/alternative; boundary="Apple-Mail=_B7CDBF45-AF53-4162-99FA-505BC2AFBA3B" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Date: Tue, 25 Nov 2014 09:27:33 -0500 References: <0DAFC2A8-A1E2-46F4-BA52-E8261CB09159@ogud.com> To: "" In-Reply-To: <0DAFC2A8-A1E2-46F4-BA52-E8261CB09159@ogud.com> X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/9Wo00JgP8Lc-VAekzQsEOy9ZGJI Subject: Re: [dane] WGLC: DANE-SRV & DANE-SMTP 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 Nov 2014 14:27:39 -0000 --Apple-Mail=_B7CDBF45-AF53-4162-99FA-505BC2AFBA3B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Reminder this WGLC is in process,=20 please review the documents=20 Olafur & Warren > On Nov 12, 2014, at 11:09 PM, Olafur Gudmundsson = wrote: >=20 > Dear wg members >=20 > This email message starts a three week WGLC ending on December 4=92th = at 23:59 UTC.=20 >=20 > http://tools.ietf.org/wg/dane/draft-ietf-dane-srv = > and=20 > https://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-13 = >=20 > These two document are specifying related uses of DANE.=20 > Please review the documents carefully, in particular we want to make = sure the documents have no=20 > contradictions.=20 >=20 > We need at least 5 members of the working group to state in public = that they have read the documents and=20 > state what is needed to fixed before the documents are advanced.=20 >=20 > I will act as document shepherd for these two documents.=20 >=20 > Olafur & Warren > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane --Apple-Mail=_B7CDBF45-AF53-4162-99FA-505BC2AFBA3B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Reminder this WGLC is in process, 
please = review the documents 

= Olafur & Warren

On = Nov 12, 2014, at 11:09 PM, Olafur Gudmundsson <ogud@ogud.com> = wrote:

Dear wg members

This = email message starts a three week WGLC ending on December 4=92th at = 23:59 UTC. 

http://tools.ietf.org/wg/dane/draft-ietf-dane-srv
and 
https://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-13

These two document are specifying = related uses of DANE. 
Please review the documents = carefully, in particular we want to make sure the documents have = no 
contradictions. 

We need at least 5 members of the working group to state in = public that they have read the documents and 
state = what is needed to fixed before the documents are advanced. 

I will act as document shepherd for these two = documents. 

Olafur & = Warren
_______________________________________________
dane mailing list
dane@ietf.org
https://www.ietf.org/mailman/listinfo/dane

= --Apple-Mail=_B7CDBF45-AF53-4162-99FA-505BC2AFBA3B-- From nobody Tue Nov 25 06:29: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 159DD1A1AC3 for ; Tue, 25 Nov 2014 06:29:47 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 EVW6dTtlYzIE for ; Tue, 25 Nov 2014 06:29:45 -0800 (PST) Received: from smtp76.ord1c.emailsrvr.com (smtp76.ord1c.emailsrvr.com [108.166.43.76]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75C701A1AB2 for ; Tue, 25 Nov 2014 06:29:45 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp10.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id C14DA3803D9 for ; Tue, 25 Nov 2014 09:29:44 -0500 (EST) X-Virus-Scanned: OK Received: by smtp10.relay.ord1c.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id 959043801C9 for ; Tue, 25 Nov 2014 09:29:44 -0500 (EST) X-Sender-Id: ogud@ogud.com Received: from [10.20.30.43] (pool-74-96-189-180.washdc.fios.verizon.net [74.96.189.180]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:465 (trex/5.3.2); Tue, 25 Nov 2014 14:29:44 GMT Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Olafur Gudmundsson In-Reply-To: <20141113201512.7739.99780.idtracker@ietfa.amsl.com> Date: Tue, 25 Nov 2014 09:29:44 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20141113201512.7739.99780.idtracker@ietfa.amsl.com> To: "" X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/M3HJrUNCtsEVJ9g576J_KcCm7k4 Subject: Re: [dane] DANE WG Interim Virtual Meeting, December 2, 2014 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 Nov 2014 14:29:47 -0000 Dear colleagues=20 Just a reminder that the virtual meeting is happening next week on = Tuesday.=20 Please send in usage statements ASAP, as that will help frame the = discussion=20 thanks Olafur & Warren=20 > On Nov 13, 2014, at 3:15 PM, IESG Secretary = wrote: >=20 > DANE WG Interim virtual Meeting: SMIME Usage cases and Requirements >=20 > Date: December 2=E2=80=99nd at 10:00 Eastern=20 >=20 > The DANE WG will have a 1 hour long Interim meeting on December 2=E2=80=99= nd to=20 > cover SMIME usage. >=20 > The goal of the meeting is to facilitate discussion on what the actual=20= > requirements are, please send in drafts outlining how you envision = SMIME=20 > to be used/supported, or send such statements to the working group=20 > mailing list for discussion in advance. >=20 > A list of documents submitted for discussion will be posted to the = list=20 > a week in advance. >=20 > Olafur & Warren=20 >=20 >=20 > DANE > Tuesday, December 2, 2014 > 10:00 am | Eastern Standard Time (New York, GMT-05:00) | 1 hr >=20 > Join WebEx meeting: > = https://ietf.webex.com/ietf/j.php?MTID=3Dmd5def721def32dd731a704859cf83218= > Meeting number: 640 822 261 > Meeting password: 1234 >=20 > Join by phone > 1-877-668-4493 Call-in toll free number (US/Canada) > 1-650-479-3208 Call-in toll number (US/Canada) > Access code: 640 822 261 >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From nobody Tue Nov 25 16:07: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 2D3481A0250 for ; Tue, 25 Nov 2014 16:07:12 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 vIk4HHolbmQ1 for ; Tue, 25 Nov 2014 16:07:09 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0126.outbound.protection.outlook.com [207.46.100.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 220801A89A6 for ; Tue, 25 Nov 2014 16:07:09 -0800 (PST) Received: from BY1PR09MB0439.namprd09.prod.outlook.com (25.160.109.21) by BLUPR09MB0166.namprd09.prod.outlook.com (10.255.216.20) with Microsoft SMTP Server (TLS) id 15.1.26.15; Wed, 26 Nov 2014 00:07:07 +0000 Received: from BY1PR09MB0439.namprd09.prod.outlook.com ([25.160.109.21]) by BY1PR09MB0439.namprd09.prod.outlook.com ([25.160.109.21]) with mapi id 15.01.0026.003; Wed, 26 Nov 2014 00:07:07 +0000 From: "Rose, Scott" To: dane WG list Thread-Topic: New Version Notification for draft-osterweil-dane-ent-email-reqs-01.txt Thread-Index: AQHQCQxuhVAIDz8BGEOTwo7dkZFy4Q== Date: Wed, 26 Nov 2014 00:07:06 +0000 Message-ID: References: <20141126000329.7972.72323.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [129.6.220.185] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BLUPR09MB0166; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:BLUPR09MB0166; x-forefront-prvs: 04073E895A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(199003)(2473001)(377454003)(51704005)(377424004)(106356001)(15202345003)(110136001)(2420400002)(77156002)(62966003)(77096003)(31966008)(230783001)(105586002)(97736003)(122556002)(95666004)(106116001)(101416001)(107046002)(40100003)(99396003)(120916001)(33656002)(46102003)(4396001)(92726001)(66066001)(92566001)(36756003)(64706001)(86362001)(20776003)(19580395003)(87936001)(19580405001)(54356999)(21056001)(2656002)(83716003)(76176999)(82746002)(50986999)(15975445006)(7059030)(104396001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR09MB0166; H:BY1PR09MB0439.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: <0E835DC45BE7224A990BFEE3C1BB12E0@namprd09.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov Archived-At: http://mailarchive.ietf.org/arch/msg/dane/-kBTuDA_k_F-we3vk0gn9IiDbYQ Cc: "Montgomery, Douglas" Subject: [dane] Fwd: New Version Notification for draft-osterweil-dane-ent-email-reqs-01.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, 26 Nov 2014 00:07:12 -0000 We submitted a new version of the email-reqs draft. This version is likely= not perfect, but I wanted it to appear before the US Thanksgiving holiday = so people have a chance to look at it before the interim meeting. =20 Text and requirements are cleaned up a bit and added example use cases for = non-trivial requirements. Also added a new section of requirements that ar= e not really DANE relevant, but added for completeness and just to have the= m documented somewhere. A new DANE type is probably not the ideal solution= for all of these requirements. Comments welcome, now or during/after the interim meeting, Scott Begin forwarded message: > From: > Subject: New Version Notification for draft-osterweil-dane-ent-email-reqs= -01.txt > Date: November 25, 2014 at 7:03:29 PM EST > To: Scott Rose , Doug Montgomery , "Doug= Montgomery" , Scott Rose >=20 >=20 > A new version of I-D, draft-osterweil-dane-ent-email-reqs-01.txt > has been successfully submitted by Scott Rose and posted to the > IETF repository. >=20 > Name: draft-osterweil-dane-ent-email-reqs > Revision: 01 > Title: Enterprise Requirements for Secure Email Key Management > Document date: 2014-11-25 > Group: Individual Submission > Pages: 7 > URL: http://www.ietf.org/internet-drafts/draft-osterweil-dane-= ent-email-reqs-01.txt > Status: https://datatracker.ietf.org/doc/draft-osterweil-dane-ent= -email-reqs/ > Htmlized: http://tools.ietf.org/html/draft-osterweil-dane-ent-email= -reqs-01 > Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-osterweil-dane-e= nt-email-reqs-01 >=20 > Abstract: > Individuals and organizations have expressed a wish to have the > ability to send encrypted and/or digitally signed email end-to-end. > One key obstacle to end-to-end email security is the difficulty in > discovering, obtaining, and validating email credentials across > administrative domains. This document addresses foreseeable adoption > obstacles for encrypted and digitally signed email in enterprises, > and outlines requirements. Some of the requirements below are not > DANE specific, and all may not be solvable with a DANE solution, but > are included for completeness and as an attempt to give a holistic > view of enterprise email security requirements. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Scott Rose NIST scott.rose@nist.gov +1 301-975-8439 Google Voice: +1 571-249-3671 http://www.dnsops.gov/ https://www.had-pilot.com/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D From nobody Tue Nov 25 16:33: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 85F761A89B3 for ; Tue, 25 Nov 2014 16:33:15 -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_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 rYcH8fNIKglX for ; Tue, 25 Nov 2014 16:33:13 -0800 (PST) Received: from mail-ie0-f179.google.com (mail-ie0-f179.google.com [209.85.223.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDAE11A89A6 for ; Tue, 25 Nov 2014 16:33:13 -0800 (PST) Received: by mail-ie0-f179.google.com with SMTP id rp18so1713430iec.10 for ; Tue, 25 Nov 2014 16:33:13 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=ff9bwuvly0YSVkD25Uugw+HRbtRfOn8gKUnYDuT/cLs=; b=GQU4hFLZYGbnqLDL7gmLcPx4tkDBOD+ebbDquJRlLLRrLX50E1AHOMJj+byEaeumBI 5ZSm+I6SYyw+frTksp1GKpp27UQ+z0LkOqthnmFovYK9UbDM7l2cEgRiDBTuu00Wff13 lNjvgPQDn6KrkuYhjZUkLvuw8GIdm1M+/mNHcTx25XHZBGiunI9+++r9i9ww8A3EVyuh x0NpjvNpiX3Jrvro9h8l7d5UN5pUbFKlcxa25FRIeV7iNmOkEuC4zfG1s1g8T0cRSPl6 6lbRTzvhrSPkXvMqDbdUTPpJaRwbA7A3DvTUPqjHaSkay2OlqGWtI2IeqKuUF0ViNnHb Y9Wg== X-Gm-Message-State: ALoCoQnVTXtCoz2olUm0ebL70l+0xwYchPXGrhrSK1UEo8mhvClpmOGdU0FdyMocG1uVR/l0bJxr X-Received: by 10.50.67.113 with SMTP id m17mr513502igt.4.1416961993260; Tue, 25 Nov 2014 16:33:13 -0800 (PST) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id d1sm1800438igz.13.2014.11.25.16.33.12 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 25 Nov 2014 16:33:12 -0800 (PST) Message-ID: <54751FC7.7010303@andyet.net> Date: Tue, 25 Nov 2014 17:33:11 -0700 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Stephane Bortzmeyer , Olafur Gudmundsson References: <0DAFC2A8-A1E2-46F4-BA52-E8261CB09159@ogud.com> <20141125094118.GA25246@sources.org> In-Reply-To: <20141125094118.GA25246@sources.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dane/9EjvrygxVPRa4aMuUmuNfoOLCVM Cc: "" Subject: Re: [dane] WGLC: DANE-SRV & DANE-SMTP 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 Nov 2014 00:33:15 -0000 On 11/25/14, 2:41 AM, Stephane Bortzmeyer wrote: > On Wed, Nov 12, 2014 at 06:09:41PM -1000, > Olafur Gudmundsson wrote > a message of 71 lines which said: > >> http://tools.ietf.org/wg/dane/draft-ietf-dane-srv > > I have read and checked draft-ietf-dane-srv-08 and I think it is fine > and ready. The main choice (checking the target domain rather than the > service domain) seems reasonable and well explained in appendix B. > > Editorial : > >> Mail messages submitted for addresses at example.com are sent via >> IMAP to imap.example.net. > > Sent via IMAP? Wouldn't it be better to write "Mail messages received > for addresses at example.com are retrieved via IMAP to > imap.example.net"? Yes, we'll fix that silly mistake. Peter -- Peter Saint-Andre https://andyet.com/ From nobody Tue Nov 25 17:05: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 4D4AB1A8759 for ; Tue, 25 Nov 2014 17:05:01 -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 ToyeVRc83udM for ; Tue, 25 Nov 2014 17:04:58 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A2961A86E1 for ; Tue, 25 Nov 2014 17:04:58 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id E7C9C28302F; Wed, 26 Nov 2014 01:04:56 +0000 (UTC) Date: Wed, 26 Nov 2014 01:04:56 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20141126010456.GB25114@mournblade.imrryr.org> References: <20141126000329.7972.72323.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/x6nSWWWhyd7USwGCL7A_z3CWu4Q Subject: Re: [dane] Fwd: New Version Notification for draft-osterweil-dane-ent-email-reqs-01.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, 26 Nov 2014 01:05:01 -0000 On Wed, Nov 26, 2014 at 12:07:06AM +0000, Rose, Scott wrote: > We submitted a new version of the email-reqs draft. This version is likely not perfect, but I wanted it to appear before the US Thanksgiving holiday so people have a chance to look at it before the interim meeting. > > Text and requirements are cleaned up a bit and added example use cases for non-trivial requirements. Also added a new section of requirements that are not really DANE relevant, but added for completeness and just to have them documented somewhere. A new DANE type is probably not the ideal solution for all of these requirements. > > Comments welcome, now or during/after the interim meeting, * REQ-2 seems to suggest DNAME in a context where I would generally expect CNAME (linking one leaf record to another). DNAMEs would far more likely be used when all users have addresses in each of two or more equivalent domains. * I think REQ-5 is a leap from the underlying desire of constraining credentials to specific uses. It states that it must be possible to convey negative assertions (don't use key K for purpose P'), while it may be quite sufficient to use positive assertions, which have better security semantics (use K for purpose P), and anything not asserted is by definition not valid. Thus the requirement ought to be implementation neutral, and whether it is implemented in positive or negative terms is an implementation choice not a requirement. * REQ-6 seems to be substantially the same as 5. * REQ-7 is I think too concise. What is it about? * REQ-8 feels wrong. It is turtles all the way down, the merging enterprise's applications may be using some other protocol. The protocol cannot encompass all competing protocols. Applications may need to support multiple protocols, and perhaps a meta protocol (obligatory xkcd reference anyone) could be used to signal which one to apply to which user. However it may simply be better for a new protocol to keep things simple and aim to displace rather than entrench legacy options. * I don't understand REQ-10. * Is REQ-11 confusing application implementing the protocol with the protocol? If not what is it saying? * REQ-12 is definitely an application and not a protocol requirement. * REQ-13 seems to be reprise of REQ-5/6. * REQ-15 feels like a derived "requirement" from some other unstated assumptions. What is its real purpose? The words "authenticated denial of existence" are I think unfortunate in this context, since they have a very specific meaning in DNSSEC, which likely differs from the intention here. * I see no discussion of case sensitivity. For example, a domain in which addresses are case insensitive could publish records (at a suitably encoded label) associated with a case-tagged email "address" that is not valid 5322 syntax: lowercase@joeuser@example.com (as distinct from "lowercase@joeuser"@example.com, and I would expect the quotes in quoted localparts to be part of the input to the encoded address). Then applications that don't find a match for the user supplied case could try the above variant instead, and not run into collisions at domains where addresses are case-sensitive, because such domains would not publish data for such prefixes. With a bit of cleverness we can handle case sensitivity without imposing on the freedom of the destination domain to be case sensitive or not. * Should there be some discussion of EAI? Are UTF-8 localparts also subject to attempts at case conversion? Any other EAI issues? -- Viktor. From nobody Wed Nov 26 09:39: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 A28761A0052 for ; Wed, 26 Nov 2014 09:39:03 -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 zmibx5RUroIN for ; Wed, 26 Nov 2014 09:39:02 -0800 (PST) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18E661A0173 for ; Wed, 26 Nov 2014 09:39:01 -0800 (PST) Received: by mail-wi0-f178.google.com with SMTP id hi2so5792066wib.11 for ; Wed, 26 Nov 2014 09:38:59 -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=gbwo3qm850GkkA7UwP4QItJfgrSV7OGHBjEcoASz1S4=; b=KVdqC9hNNcoVm1ZR3+++solxN6KPsm89AlNjwebmhhsDr2Nt38FDUbz+R84pvuV80Y UxigV9YPKwtSHPufZm9xB7UeV7mzln9gneSW33tbs9J4ZAxc6uou3LIwhXm/BrHjKXxj 5O+lXR9NW8LKXUqpeDK/8w2NVGvitTGKMYzJQxykcVO5p5/MoRSjC8FOmnsoD6y4MPSW 0xRzOqu0/MCdCEswiNm0ZXPVhHR01n0HB51oWlNbXPyz4wLx/gnG5o8fJnCskzdlQA70 2gWrJFz+6znRYCRfQXaXamsvIeBbbhr/vfJ3G2nY6OBuEdgDiSYMCWSaJDv1lHlEly3x mHzg== X-Gm-Message-State: ALoCoQkBDblylSt+0xugYCDaF5wTJ+dkjYxhBLPgsCjxy8rMZ3sl/tY9Y7EaA6hsLpB8iGXKU9zF MIME-Version: 1.0 X-Received: by 10.180.104.105 with SMTP id gd9mr43262718wib.65.1417023539804; Wed, 26 Nov 2014 09:38:59 -0800 (PST) Received: by 10.194.64.37 with HTTP; Wed, 26 Nov 2014 09:38:59 -0800 (PST) In-Reply-To: References: <20141113201512.7739.99780.idtracker@ietfa.amsl.com> Date: Wed, 26 Nov 2014 12:38:59 -0500 Message-ID: From: Warren Kumari To: Olafur Gudmundsson Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/dane/SU9ewnOCfM_koQaRd6u8s9ZRJyw Cc: "" Subject: Re: [dane] DANE WG Interim Virtual Meeting, December 2, 2014 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 Nov 2014 17:39:03 -0000 On Tue, Nov 25, 2014 at 9:29 AM, Olafur Gudmundsson wrote: > > Dear colleagues > Just a reminder that the virtual meeting is happening next week on Tuesda= y. > Please send in usage statements ASAP, as that will help frame the discuss= ion Also, please read https://datatracker.ietf.org/doc/draft-osterweil-dane-ent-email-reqs/ and https://tools.ietf.org/html/draft-ietf-dane-openpgpkey-usage-01 before the meeting[0]. Also worth considering / discussing is the whole "Bob writes a mail on March 1st and then leaves the Acme, Inc. on March 2nd. Alice finally gets around to opening the mail on April 10th - should it validate?" or "Bob gets fired on March 2nd and is understandably disgruntled. He has his laptop at home and sends mail on March 3rd. Can Acme, Inc prevent this / invalidate the keys?" and http://www.ietf.org/mail-archive/web/dane/current/msg07021.html [0]: For those folk in the USA - you might want to print these out / sync them to a reading device so you have something to do while recovering from too much turkey. W > > thanks > Olafur & Warren > >> On Nov 13, 2014, at 3:15 PM, IESG Secretary wr= ote: >> >> DANE WG Interim virtual Meeting: SMIME Usage cases and Requirements >> >> Date: December 2=E2=80=99nd at 10:00 Eastern >> >> The DANE WG will have a 1 hour long Interim meeting on December 2=E2=80= =99nd to >> cover SMIME usage. >> >> The goal of the meeting is to facilitate discussion on what the actual >> requirements are, please send in drafts outlining how you envision SMIME >> to be used/supported, or send such statements to the working group >> mailing list for discussion in advance. >> >> A list of documents submitted for discussion will be posted to the list >> a week in advance. >> >> Olafur & Warren >> >> >> DANE >> Tuesday, December 2, 2014 >> 10:00 am | Eastern Standard Time (New York, GMT-05:00) | 1 hr >> >> Join WebEx meeting: >> https://ietf.webex.com/ietf/j.php?MTID=3Dmd5def721def32dd731a704859cf832= 18 >> Meeting number: 640 822 261 >> Meeting password: 1234 >> >> Join by phone >> 1-877-668-4493 Call-in toll free number (US/Canada) >> 1-650-479-3208 Call-in toll number (US/Canada) >> Access code: 640 822 261 >> >> _______________________________________________ >> dane mailing list >> dane@ietf.org >> https://www.ietf.org/mailman/listinfo/dane > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane --=20 I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Wed Nov 26 10:30: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 783071A1B34 for ; Wed, 26 Nov 2014 10:30:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.661 X-Spam-Level: X-Spam-Status: No, score=-1.661 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 kBSnhTFTnkdT for ; Wed, 26 Nov 2014 10:30:27 -0800 (PST) Received: from spg.kirei.se (spg.kirei.se [IPv6:2001:67c:394:15::9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AC091A1B2F for ; Wed, 26 Nov 2014 10:30:26 -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=LclbLX1yFBIlOv3+AupD8SNoiT/DysnYw4NYCxLWYe0=; b=mYfNTmMD4Z5N19qzrS1HrLjsVK9QHy1kE573OThOd8l4o+3uXwdp/nLpr/IucjOfWTh+griGr4FO4 r5fBgiGgkd2NkLXPxdqLi8OYosp2kngiLDlTgnGUVkeA3QTkGYmlbyzqMNV63TXV2NUMFXfF588loT 3R5P1FrxSKC2xqiQ= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg-relay.kirei.se (Halon Mail Gateway) with ESMTPS for ; Wed, 26 Nov 2014 19:30:05 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Jakob Schlyter In-Reply-To: <20141126010456.GB25114@mournblade.imrryr.org> Date: Wed, 26 Nov 2014 19:30:23 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20141126000329.7972.72323.idtracker@ietfa.amsl.com> <20141126010456.GB25114@mournblade.imrryr.org> To: dane@ietf.org X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/0Df3xPVx95ruKdY-z-Xg25_RnFc Subject: Re: [dane] New Version Notification for draft-osterweil-dane-ent-email-reqs-01.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, 26 Nov 2014 18:30:29 -0000 On 26 nov 2014, at 02:04, Viktor Dukhovni = wrote: > * REQ-2 seems to suggest DNAME in a context where I would generally > expect CNAME (linking one leaf record to another). DNAMEs would > far more likely be used when all users have addresses in each of > two or more equivalent domains. Why? The following example makes sense for aliasing: _smimecert.example.com. IN DNAME _smimecert.example.net.=20 > * REQ-7 is I think too concise. What is it about? I believe something like this: _smimecert.example.com. IN DNAME _smimecert.example.com.provider.net. > * REQ-8 feels wrong. It is turtles all the way down, > the merging enterprise's applications may be using some other > protocol. The protocol cannot encompass all competing protocols. > Applications may need to support multiple protocols, and perhaps > a meta protocol (obligatory xkcd reference anyone) could be used > to signal which one to apply to which user. However it may simply > be better for a new protocol to keep things simple and aim to > displace rather than entrench legacy options. I agree. For me, this feels like optimizing for the publish side (of = which there are few) instead of optimizing for the client (of which = there any many). Also, this adds complexity. I can see that it would be = easier for an enterprise to say *._smimecert.example.com. IN SMIMEA = go-see-ldap, but if one can put one SMIMEA RR in the DNS, one can easily = loop through that LDAP thing and publish all the certs. I'd like to = optimize for simplicity in this case. jakob From nobody Wed Nov 26 10:30: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 65C841A1B2F for ; Wed, 26 Nov 2014 10:30:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.661 X-Spam-Level: X-Spam-Status: No, score=-1.661 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 2cpEZ7Iso0PG for ; Wed, 26 Nov 2014 10:30:37 -0800 (PST) Received: from spg.kirei.se (spg.kirei.se [IPv6:2001:67c:394:15::9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 333961A1B2C for ; Wed, 26 Nov 2014 10:30:37 -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=T7XH9cPqbojgOTuEuUtAXK133O+YDMudbU7Hhb17mBM=; b=v6ElVaE+OQ/NWJlhin/SXu5FO0V1UY4n1IJoi5oHvLoxVSxNw4cQQtVqNlPNjhGsNgpSuQTCAaoRE IJlZ4Ry71Zy8Fi61xZtskbcbHXKi5/WywwPfdVC3hdSth8W1dh3BtC7KeeilPtK669CLnPnyUg7QQH MQBvJNjh3cU0e/wA= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg-relay.kirei.se (Halon Mail Gateway) with ESMTPS for ; Wed, 26 Nov 2014 19:30:16 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Jakob Schlyter In-Reply-To: Date: Wed, 26 Nov 2014 19:30:34 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <7BAE5E4A-E08E-4B8D-B68E-8FCE16C51D53@kirei.se> References: <20141126000329.7972.72323.idtracker@ietfa.amsl.com> To: dane WG list X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/FpiQBGjGC-8-dGcn9VF0XMVTkdw Subject: Re: [dane] New Version Notification for draft-osterweil-dane-ent-email-reqs-01.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, 26 Nov 2014 18:30:38 -0000 REQ-5: Please elaborate on why normal certificate keyUsage is not usable = to distinguish between certificates used for encryption/signing. jakob From nobody Wed Nov 26 10:34: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 CF6971A1A6B for ; Wed, 26 Nov 2014 10: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 uZk_j7lahn3D for ; Wed, 26 Nov 2014 10:34:07 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 887A31A1AA7 for ; Wed, 26 Nov 2014 10:34:07 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 622EE284AD4; Wed, 26 Nov 2014 18:34:06 +0000 (UTC) Date: Wed, 26 Nov 2014 18:34:06 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20141126183406.GP25114@mournblade.imrryr.org> References: <20141126000329.7972.72323.idtracker@ietfa.amsl.com> <20141126010456.GB25114@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/GlkzWrxzdOxyeh1YtGQREiSdDlo Subject: Re: [dane] New Version Notification for draft-osterweil-dane-ent-email-reqs-01.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, 26 Nov 2014 18:34:09 -0000 On Wed, Nov 26, 2014 at 07:30:23PM +0100, Jakob Schlyter wrote: > On 26 nov 2014, at 02:04, Viktor Dukhovni wrote: > > > * REQ-2 seems to suggest DNAME in a context where I would generally > > expect CNAME (linking one leaf record to another). DNAMEs would > > far more likely be used when all users have addresses in each of > > two or more equivalent domains. > > Why? The following example makes sense for aliasing: > > _smimecert.example.com. IN DNAME _smimecert.example.net. > I thought the text was talking about a given user, not an entire domain. > > * REQ-7 is I think too concise. What is it about? > > I believe something like this: > > _smimecert.example.com. IN DNAME _smimecert.example.com.provider.net. Better text is perhaps needed to explain. -- Viktor. From nobody Thu Nov 27 12:00: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 F1CA71A01D8 for ; Thu, 27 Nov 2014 12:00:10 -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 e6iQpNjUKJq4 for ; Thu, 27 Nov 2014 12:00:09 -0800 (PST) Received: from mail-wg0-f47.google.com (mail-wg0-f47.google.com [74.125.82.47]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A899A1A0231 for ; Thu, 27 Nov 2014 12:00:08 -0800 (PST) Received: by mail-wg0-f47.google.com with SMTP id n12so7291854wgh.20 for ; Thu, 27 Nov 2014 12:00:07 -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=ljGpib7K2VLjRoppPwj85Tvlu4a7cUDe6EZTmEsm7Cc=; b=ZsnkEzQJXoVQJU2iUuhIGNfa9Iyhr0rqSy0191h3nPZLfPBvLCkypM2X/47glc/cb/ L8rqXZF+BUWdeA45oCkXjlERufDz87jCzecm1eCkI1CT3K/r5Baqxt5U+aOZcwD523CP 9W/Fx2uS/Q38NTXgLb7+CAx/byApg6on7BihGPAm73YxaYuE3vTI4eco+r+wZ83CteKg 6XEg+wzThKLPMNrmF2CAT1zQE1EwVea0e4s/7l3Uj1Y6KTmI+PKwY+bPSGu7hX2fAwcF lUBD6ml2/Ztq+gbUow+sOm2PvHfV+I6JK2GoiIZFHTW9vW55Ixes9bfdmDKTFQdV6uSI 3JUw== X-Gm-Message-State: ALoCoQmX93g0TAbuARn1meVnLFVOKzxUUjfYoDLR+yAS1fbztKzO+NBWjeHQevC8Gu7kBhIHXAKo MIME-Version: 1.0 X-Received: by 10.180.210.226 with SMTP id mx2mr53327793wic.42.1417118407365; Thu, 27 Nov 2014 12:00:07 -0800 (PST) Received: by 10.194.64.37 with HTTP; Thu, 27 Nov 2014 12:00:07 -0800 (PST) Date: Thu, 27 Nov 2014 15:00:07 -0500 Message-ID: From: Warren Kumari To: "" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/ZLvRMPXGLcFSXfRZXTNQ4sr10UI Subject: [dane] Draft minutes posted. 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 Nov 2014 20:00:11 -0000 Hi, First off, huge thanks to Allison Mankin for taking clear and detailed minutes. I have just posted them as *draft* minutes, please let me know within the next 7 days if you see any errors, or we'll count them as final. Posted here: http://www.ietf.org/proceedings/91/minutes/minutes-91-dane Also, if you are participating in the interim meeting, the section "Enterprises Viewpoint (one slide) - Scott Rose" summarizes many of the discussions (to jog your memory) W -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Fri Nov 28 17:11: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 5EC091A1BA3 for ; Fri, 28 Nov 2014 17:11:46 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 60fFXdcsdp7j for ; Fri, 28 Nov 2014 17:11:44 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0117.outbound.protection.outlook.com [65.55.169.117]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3901A1A032D for ; Fri, 28 Nov 2014 17:11:44 -0800 (PST) Received: from BY1PR09MB0439.namprd09.prod.outlook.com (25.160.109.21) by BY1PR09MB0438.namprd09.prod.outlook.com (25.160.109.20) with Microsoft SMTP Server (TLS) id 15.1.26.15; Sat, 29 Nov 2014 01:11:41 +0000 Received: from BY1PR09MB0439.namprd09.prod.outlook.com ([25.160.109.21]) by BY1PR09MB0439.namprd09.prod.outlook.com ([25.160.109.21]) with mapi id 15.01.0026.003; Sat, 29 Nov 2014 01:11:41 +0000 From: "Rose, Scott" To: dane WG list Thread-Topic: [dane] New Version Notification for draft-osterweil-dane-ent-email-reqs-01.txt Thread-Index: AQHQCQxuhVAIDz8BGEOTwo7dkZFy4ZxzPAgAgAOUuAA= Date: Sat, 29 Nov 2014 01:11:40 +0000 Message-ID: References: <20141126000329.7972.72323.idtracker@ietfa.amsl.com> <7BAE5E4A-E08E-4B8D-B68E-8FCE16C51D53@kirei.se> In-Reply-To: <7BAE5E4A-E08E-4B8D-B68E-8FCE16C51D53@kirei.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [129.6.222.137] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BY1PR09MB0438; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:BY1PR09MB0438; x-forefront-prvs: 041032FF37 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(377454003)(24454002)(51704005)(189002)(20776003)(107886001)(110136001)(107046002)(64706001)(230783001)(86362001)(33656002)(36756003)(46102003)(105586002)(106116001)(66066001)(97736003)(95666004)(99286002)(106356001)(101416001)(19580395003)(83716003)(19580405001)(87936001)(2656002)(54356999)(76176999)(82746002)(50986999)(15975445006)(21056001)(40100003)(92726001)(4396001)(120916001)(122556002)(99396003)(92566001)(77156002)(31966008)(450100001)(15202345003)(62966003)(77096004)(104396001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR09MB0438; H:BY1PR09MB0439.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: <1C81982082649E4289104DA8BE4F54BF@namprd09.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov Archived-At: http://mailarchive.ietf.org/arch/msg/dane/WDpdnhLjYiGZehXs1kThiTMK7sc Subject: Re: [dane] New Version Notification for draft-osterweil-dane-ent-email-reqs-01.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, 29 Nov 2014 01:11:46 -0000 The requirement comes from the desire to tie cert/keys with functionality. = Some enterprises may get their certs issued by CA's that set both keyUsage= flags, yet want two certs for different purposes. MUA's will have to decid= e how to handle situations when the keyUsage field does not match the usage= statement in the SMIMEA RR. It should be checked, but behavior when there= are discrepancies will need to be specified. Also, being able to specify signing and encrypting functions for raw keys m= ay come in handy. It also helps in the reject case, where a domain can rej= ect one usage for a cert. =20 Scott On Nov 26, 2014, at 1:30 PM, Jakob Schlyter wrote: > REQ-5: Please elaborate on why normal certificate keyUsage is not usable = to distinguish between certificates used for encryption/signing. >=20 > jakob >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Scott Rose NIST scott.rose@nist.gov +1 301-975-8439 Google Voice: +1 571-249-3671 http://www.dnsops.gov/ https://www.had-pilot.com/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D From nobody Fri Nov 28 21:18: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 320051A0030 for ; Fri, 28 Nov 2014 21:18:55 -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 b_nM1C09fIHb for ; Fri, 28 Nov 2014 21:18:53 -0800 (PST) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AF1B1A0027 for ; Fri, 28 Nov 2014 21:18:52 -0800 (PST) Received: by mail-lb0-f169.google.com with SMTP id p9so6451198lbv.28 for ; Fri, 28 Nov 2014 21:18:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=ekk/Vt+M514U1CUS+XqNYrs9OkMk9GLZNlXS2QhqHJA=; b=jhRevlNsJ2+KOtzPqJZrldqVdREcsv07Wa8p61oZ+HiYOvXWb5Mns845S5PVdAXge5 IqFuSZUWPWVHNBjPmDVHtqT/oQwYcxscN4hu59slJE5UJVTOgsFlPpAVgyXcqzUn+aIn iT7CI2ZVHLrRyXhW7/aMJyH+thvZZJcZ+GtxLHMzuZyfdr9YYsxSD8KZ6INuxfd6CSeF VlSDFzHTwCyjRO+siM+W8FP42Vgdht/vm+9fVXegxv4YTpJOl+6wJD0SVhnXd7Ehv+DR 2t1WL9pgqKVpozawg0hfWz/YIsXeQ+x1dNhh/DwTVopB1fQc2PUB7BfwDXIJmS8XvENs EsGQ== X-Received: by 10.152.120.73 with SMTP id la9mr47184721lab.23.1417238331061; Fri, 28 Nov 2014 21:18:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.26.16 with HTTP; Fri, 28 Nov 2014 21:18:30 -0800 (PST) In-Reply-To: <20141126010456.GB25114@mournblade.imrryr.org> References: <20141126000329.7972.72323.idtracker@ietfa.amsl.com> <20141126010456.GB25114@mournblade.imrryr.org> From: Doug Montgomery Date: Sat, 29 Nov 2014 00:18:30 -0500 Message-ID: To: dane WG list Content-Type: multipart/alternative; boundary=089e011766e548fd190508f883aa Archived-At: http://mailarchive.ietf.org/arch/msg/dane/qJDsanQVQ4Q68QzAchwU565VMpw Subject: Re: [dane] Fwd: New Version Notification for draft-osterweil-dane-ent-email-reqs-01.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, 29 Nov 2014 05:18:55 -0000 --089e011766e548fd190508f883aa Content-Type: text/plain; charset=UTF-8 On Tue, Nov 25, 2014 at 8:04 PM, Viktor Dukhovni wrote: > On Wed, Nov 26, 2014 at 12:07:06AM +0000, Rose, Scott wrote: > > > We submitted a new version of the email-reqs draft. This version is > likely not perfect, but I wanted it to appear before the US Thanksgiving > holiday so people have a chance to look at it before the interim meeting. > > > > Text and requirements are cleaned up a bit and added example use cases > for non-trivial requirements. Also added a new section of requirements > that are not really DANE relevant, but added for completeness and just to > have them documented somewhere. A new DANE type is probably not the ideal > solution for all of these requirements. > > > > Comments welcome, now or during/after the interim meeting, > > * REQ-2 seems to suggest DNAME in a context where I would generally > expect CNAME (linking one leaf record to another). DNAMEs would > far more likely be used when all users have addresses in each of > two or more equivalent domains. > > * I think REQ-5 is a leap from the underlying desire of constraining > credentials to specific uses. It states that it must be possible > to convey negative assertions (don't use key K for purpose P'), > while it may be quite sufficient to use positive assertions, > which have better security semantics (use K for purpose P), and > anything not asserted is by definition not valid. > > Thus the requirement ought to be implementation neutral, and whether > it is implemented in positive or negative terms is an implementation > choice not a requirement. > There are two issues that need to be addressed here. 1. Some enterprise identity management systems bind encryption and signing keys to network identities for other purposes (i.e., not specific to email). The requirement addressed the ability for domains to indicate that even though you might know of such keys through other means, they are not valid for end-to-end SMIME usage in this domain. 2. The semantics during incremental deployment, and persistent partial deployment must be well defined. i.e., one must be able to definitively determine if the lack of a positive assertion is a purposeful statement of key usage policy, or a transient condition of partial deployment. It was not apparent to us how the absence of positive assertions could address these requirements. dougm -- DougM at Work --089e011766e548fd190508f883aa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Nov 25, 2014 at 8:04 PM, Viktor Dukhovni <= ietf-dane@dukho= vni.org> wrote:
On Wed, Nov 26, 2014 at 12:07:06AM +0000, Rose, Scott wrote:

> We submitted a new version of the email-reqs draft.=C2=A0 This version= is likely not perfect, but I wanted it to appear before the US Thanksgivin= g holiday so people have a chance to look at it before the interim meeting.=
>
> Text and requirements are cleaned up a bit and added example use cases= for non-trivial requirements.=C2=A0 Also added a new section of requiremen= ts that are not really DANE relevant, but added for completeness and just t= o have them documented somewhere.=C2=A0 A new DANE type is probably not the= ideal solution for all of these requirements.
>
> Comments welcome, now or during/after the interim meeting,

* REQ-2 seems to suggest DNAME in a context where I would generally<= br> =C2=A0 expect CNAME (linking one leaf record to another).=C2=A0 DNAMEs woul= d
=C2=A0 far more likely be used when all users have addresses in each of
=C2=A0 two or more equivalent domains.

* I think REQ-5 is a leap from the underlying desire of constraining
=C2=A0 credentials to specific uses.=C2=A0 It states that it must be possib= le
=C2=A0 to convey negative assertions (don't use key K for purpose P'= ;),
=C2=A0 while it may be quite sufficient to use positive assertions,
=C2=A0 which have better security semantics (use K for purpose P), and
=C2=A0 anything not asserted is by definition not valid.

=C2=A0 Thus the requirement ought to be implementation neutral, and whether=
=C2=A0 it is implemented in positive or negative terms is an implementation=
=C2=A0 choice not a requirement.

There = are two issues that need to be addressed here.

1. = Some enterprise identity management systems bind encryption and signing key= s to network identities for other purposes (i.e., not specific to email). = =C2=A0 The requirement addressed the ability for domains to indicate that e= ven though you might know of such keys through other means, they are not va= lid for end-to-end SMIME usage in this domain.

2. = The semantics during incremental deployment, and persistent partial deploym= ent must be well defined. =C2=A0 i.e., one must be able to definitively det= ermine if the lack of a positive assertion is a purposeful statement of key= usage policy, or a transient condition of partial deployment.=C2=A0
<= div>
It was not apparent to us how the absence of positive as= sertions could address these requirements.

dougm
--
DougM at Work
--089e011766e548fd190508f883aa-- From nobody Sun Nov 30 10:27: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 7F87C1A1A64 for ; Sun, 30 Nov 2014 10:27:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 v4sts0ty14Wv for ; Sun, 30 Nov 2014 10:27:20 -0800 (PST) Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 944FD1A1A60 for ; Sun, 30 Nov 2014 10:27:19 -0800 (PST) Received: by mail-lb0-f173.google.com with SMTP id z12so7474391lbi.32 for ; Sun, 30 Nov 2014 10:27:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=b0JWw/CzgBVCC+Z03RlikMDf8cP1secKTsxojEMcy34=; b=hFIYYOhxG8ZmOKrUaKNdRKU+FJ/lm1hTPySOX5osr/xVHX944S+VNKPtHfhVOjOOPE LvsRnY65T6bstxGPLv7j4dHz1YE3Pyyto24kiL+7jHjmaumqS6uhtVsuKSDHReyfF+L1 8cohzcBhcwam3D0U+2CCGrnG9KwoSJ8sbEWh3dWTrF2SmN5YOKTuoFynnv8yPqwl1pod 5AlAfl/FI3aB1xPWcWkrQ83wrT6mi6J2qmHg2QfDcqCCz+C2ZzMUTJukpqRTDxOPl+9c 4Xhe7YqY2rp8CIHYAqhVPZ3gtlP19OxJXTm0iVLtyUdsYih4AqUq8IF0Iz17sVwzsG1i Q0hA== X-Received: by 10.112.160.137 with SMTP id xk9mr10723051lbb.99.1417372037979; Sun, 30 Nov 2014 10:27:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.26.16 with HTTP; Sun, 30 Nov 2014 10:26:57 -0800 (PST) In-Reply-To: References: <20141113201512.7739.99780.idtracker@ietfa.amsl.com> From: Doug Montgomery Date: Sun, 30 Nov 2014 13:26:57 -0500 Message-ID: To: Warren Kumari Content-Type: multipart/alternative; boundary=001a11c38c70d6a484050917a47c Archived-At: http://mailarchive.ietf.org/arch/msg/dane/S1RF7Ed2YEc-ALehdSvb5phD-CM Cc: "" Subject: Re: [dane] DANE WG Interim Virtual Meeting, December 2, 2014 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, 30 Nov 2014 18:27:22 -0000 --001a11c38c70d6a484050917a47c Content-Type: text/plain; charset=UTF-8 On Wed, Nov 26, 2014 at 12:38 PM, Warren Kumari wrote: > On Tue, Nov 25, 2014 at 9:29 AM, Olafur Gudmundsson wrote: > > > > Dear colleagues > > Just a reminder that the virtual meeting is happening next week on > Tuesday. > > Please send in usage statements ASAP, as that will help frame the > discussion > > Also, please read > https://datatracker.ietf.org/doc/draft-osterweil-dane-ent-email-reqs/ > and > https://tools.ietf.org/html/draft-ietf-dane-openpgpkey-usage-01 before > the meeting[0]. > > Also worth considering / discussing is the whole "Bob writes a mail on > March 1st and then leaves the Acme, Inc. on March 2nd. Alice finally > gets around to opening the mail on April 10th - should it validate?" > Not sure the notion of "to open" is well defined at a MUA. Given the models of POP vs IMAP vs webmail vs ..... it is not even clear to me that "delivered to MUA" is well defined. But, your MUA, or MTA if privy to your trust anchors, should mark if the message signatures were valid at time of first delivery. Optionally if the app wants to show if the signature is still valid, it could, but this is less important. A good test is to substitute "10 years later" for "on April 10th" above and see if it changes your thinking. or > "Bob gets fired on March 2nd and is understandably disgruntled. He has > his laptop at home and sends mail on March 3rd. Can Acme, Inc prevent > this / invalidate the keys?" > Not sure if your question is about the timing (1 day) or the capability at all. But in general if Acme can't revoke invalid or compromised credentials... then the system is next to useless. I know of very large IDM systems and supporting policies/laws that require credential revocation within 24 hours or less of employee termination. Ideally Acme would be able to publish (somewhere) a policy that says all Acme.com email is signed ... and would be able to insure there is no valid binding between Bob and a email signing key for the domain. Those two bits of information would be enough to enable receivers that care to check / enforce the ability to determine that Bob's disgruntled email does not come from a valid acme.com network identity. In a somewhat related point on historical keying material, I think MUAs should mark that encrypted messages were encrypted at time of first delivery and not store the message in its original encrypted form. The problem of historical key escrow so that I can go back and recover my old keys and read emails sent to me years ago seems bizarre, yet I know large IDM systems that do this. Store your inbox on an encrypted file store if you wish, but the idea that I should maintain an infinite historical key store to read the email you encrypted to me 10 years ago seems the wrong model ... but yet I know large IDM systems that do this. dougm --001a11c38c70d6a484050917a47c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Nov 26, 2014 at 12:38 PM, Warren Kumari <<= a href=3D"mailto:warren@kumari.net" target=3D"_blank">warren@kumari.net= > wrote:
On Tue, Nov 25, 201= 4 at 9:29 AM, Olafur Gudmundsson <ogud@= ogud.com> wrote:
>
> Dear colleagues
> Just a reminder that the virtual meeting is happening next week on Tue= sday.
> Please send in usage statements ASAP, as that will help frame the disc= ussion

Also, please read
https://datatracker.ietf.org/doc/draft-osterweil-d= ane-ent-email-reqs/
and
https://tools.ietf.org/html/draft-ietf-dane-openpgpkey-u= sage-01 before
the meeting[0].

Also worth considering / discussing is the whole "Bob writes a mail on=
March 1st and then leaves the Acme, Inc. on March 2nd. Alice finally
gets around to opening the mail on April 10th - should it validate?"

Not sure the notion of "to open&quo= t; is well defined at a MUA. =C2=A0 Given the models of POP vs IMAP vs webm= ail vs ..... it is not even clear to me that "delivered to MUA" i= s well defined.

But, your MUA, or MTA if privy to = your trust anchors, should mark if the message signatures were valid at tim= e of first delivery. =C2=A0 Optionally if the app wants to show if the sign= ature is still valid, it could, but this is less important.

<= /div>
A good test is to substitute "10 years later" for "= ;on April 10th" above and see if it changes your thinking.
<= br>


or
"Bob gets fired on March 2nd and is understandably disgruntled. He has=
his laptop at home and sends mail on March 3rd. Can Acme, Inc prevent
this / invalidate the keys?"

Not s= ure if your question is about the timing (1 day) or the capability at all.<= /div>

But in general if Acme can't revoke invalid or= compromised credentials... then the system is next to useless. =C2=A0 I kn= ow of very large IDM systems and supporting policies/laws that require cred= ential revocation within 24 hours or less of employee termination.

Ideally Acme would be able to publish (somewhere) a policy= that says all Acme.com email is signed ... and would be able to insure the= re is no valid binding between Bob and a email signing key for the domain.<= /div>

Those two bits of information would be enough to e= nable receivers that care to check / enforce the ability to determine that = Bob's disgruntled email does not come from a valid acme.com network identity.

In a somewh= at related point on historical keying material, I think MUAs should mark th= at encrypted messages were encrypted at time of first delivery and not stor= e the message in its original encrypted form. =C2=A0 =C2=A0The problem of h= istorical key escrow so that I can go back and recover my old keys and read= emails sent to me years ago seems bizarre, yet I know large IDM systems th= at do this. =C2=A0 Store your inbox on an encrypted file store if you wish,= but the idea that I should maintain an infinite historical key store to re= ad the email you encrypted to me 10 years ago seems the wrong model ... but= yet I know large IDM systems that do this.

do= ugm
=C2=A0
--001a11c38c70d6a484050917a47c-- From nobody Sun Nov 30 10:56: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 62DC71A1A69 for ; Sun, 30 Nov 2014 10:56: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 Juu16gSr5qur for ; Sun, 30 Nov 2014 10:56:38 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD39C1A1A67 for ; Sun, 30 Nov 2014 10:56:38 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 1F75628494C; Sun, 30 Nov 2014 18:56:37 +0000 (UTC) Date: Sun, 30 Nov 2014 18:56:37 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20141130185636.GU285@mournblade.imrryr.org> References: <20141113201512.7739.99780.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/du0gwiVhyN21v3bj_G1GsIct75Q Subject: Re: [dane] DANE WG Interim Virtual Meeting, December 2, 2014 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, 30 Nov 2014 18:56:40 -0000 On Sun, Nov 30, 2014 at 01:26:57PM -0500, Doug Montgomery wrote: > > Also worth considering / discussing is the whole "Bob writes a mail on > > March 1st and then leaves the Acme, Inc. on March 2nd. Alice finally > > gets around to opening the mail on April 10th - should it validate?" The correct answer is "no, it should not validate". Business processes can be applied to send Alice a new email signed by Bob's successor if that's required. Bob's signing key is no longer published at the time that Alice reads the mail. Alice has no way to know whether Bob's email was sent before or after Bob left Acme. Bob's S/MIME signature is not securely timestamped, all Alice knows is that the message was signed in the past. Signed time-of-receipt by Alice's mail system would be needed to do better, and no standard specifies these at present. > > Not sure the notion of "to open" is well defined at a MUA. Given the > models of POP vs IMAP vs webmail vs ..... it is not even clear to me that > "delivered to MUA" is well defined. User agents that support encryption and signing need to be able to distinguish "new" mail from "old". Otherwise, they are too crippled to usefully support end-to-end encryption. > A good test is to substitute "10 years later" for "on April 10th" above and > see if it changes your thinking. Actually, 10 years later is different if the mail was originally read in a timely manner, and is being re-read 10 years later. > > "Bob gets fired on March 2nd and is understandably disgruntled. He has > > his laptop at home and sends mail on March 3rd. Can Acme, Inc prevent > > this / invalidate the keys?" Just the same as the first case. Depublish Bob's keys. > Store your inbox on an encrypted file store if > you wish, but the idea that I should maintain an infinite historical key > store to read the email you encrypted to me 10 years ago seems the wrong > model ... but yet I know large IDM systems that do this. Secure local storage of decrypted email (with any signature verification status at time it was first read) is a local requirement for an MUA that adequately supports email encryption and signing. Out of scope for DANE, but inescapable for MUA usability. -- Viktor. From nobody Sun Nov 30 17:34: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 CA9121A00A2 for ; Sun, 30 Nov 2014 17:34:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.414 X-Spam-Level: X-Spam-Status: No, score=-0.414 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FAKE_REPLY_C=1.486] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w3jaY9j-warc for ; Sun, 30 Nov 2014 17:33:59 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B2961A008B for ; Sun, 30 Nov 2014 17:33:59 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 191B528494C; Mon, 1 Dec 2014 01:33:58 +0000 (UTC) Date: Mon, 1 Dec 2014 01:33:58 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20141201013357.GF285@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/MN5FxJFjRC2WwPYjmGFbXCCTcXA Subject: Re: [dane] WGLC: DANE-SRV 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, 01 Dec 2014 01:34:01 -0000 On Tue, Nov 25, 2014 at 10:41:18AM +0100, Stephane Bortzmeyer wrote: > http://tools.ietf.org/wg/dane/draft-ietf-dane-srv I have extensive comments throughout the document, but I don't know how to best process them. One comment-bomb message? A git repo with many commits? Off-list work with the authors? What should be done when proposing many changes? -- Viktor. From nobody Sun Nov 30 17:48: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 97B0C1A00A9 for ; Sun, 30 Nov 2014 17:48:44 -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_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 bK2tYrn21PKQ for ; Sun, 30 Nov 2014 17:48:43 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4825B1A00A2 for ; Sun, 30 Nov 2014 17:48:43 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id tr6so8627409ieb.17 for ; Sun, 30 Nov 2014 17:48: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:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Hq+DRG8fldlSWqmJ508MaOKzjJ2UXjvvNXxfBx+k++k=; b=T6ItFjMv0snDhjB2WBWlG4E7ImexjvLlCS28N0nYtwInZN8hBXswSRmT+gvKTl56Ca /0Xchl0K7K2SoNvyb8M3U+X/gatAbgJu5bd2fwEw9zEGxgANdjvufLYve83TgSRDW+1Y c6I3hRnqJc2HJOHo4+C8pf9qd/8ZZYOPKq1ais3VztHfhQqIb5tOzvwvgY8KonzFrZPO hCYbrl0wMyyeQHmCNVIsBEKfQ+96dj2fRuIvpix8hXq7qMxPZ1uBeiZr/MetstcuDalb J+pqLSqYNcZLN+WrEufYRxdGDB/tVgdCcL9BSuMu02RUV4wICZ9VK8mPeeEsp2UEzgqD x+9Q== X-Gm-Message-State: ALoCoQmeQzAgBEL0mFMw9TDatW0wbboLuXhsZSTTZSx06dyMHYtQ95HjXM5SAo3u6VM3uQnIXySg X-Received: by 10.107.14.208 with SMTP id 199mr36321177ioo.28.1417398522744; Sun, 30 Nov 2014 17:48:42 -0800 (PST) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id w7sm8834751iod.8.2014.11.30.17.48.41 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 30 Nov 2014 17:48:42 -0800 (PST) Message-ID: <547BC8F9.1070605@andyet.net> Date: Sun, 30 Nov 2014 18:48:41 -0700 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: dane@ietf.org References: <20141201013357.GF285@mournblade.imrryr.org> In-Reply-To: <20141201013357.GF285@mournblade.imrryr.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dane/_HVTlab1CjWFtrgS50EQIBmZB78 Subject: Re: [dane] WGLC: DANE-SRV 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, 01 Dec 2014 01:48:44 -0000 On 11/30/14, 6:33 PM, Viktor Dukhovni wrote: > On Tue, Nov 25, 2014 at 10:41:18AM +0100, Stephane Bortzmeyer wrote: > >> http://tools.ietf.org/wg/dane/draft-ietf-dane-srv > > I have extensive comments throughout the document, but I don't know > how to best process them. One comment-bomb message? Unfortunately, yes. > A git repo > with many commits? That is not covered by IETF IPR rules. > Off-list work with the authors? That does not conduce to transparency. > What should be done when proposing many changes? Propose fewer? ;-) Seriously, just post to the mailing list and we'll work through your feedback. Peter -- Peter Saint-Andre https://andyet.com/ From nobody Sun Nov 30 19:30: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 2823B1A039B for ; Sun, 30 Nov 2014 19:30:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.9 X-Spam-Level: X-Spam-Status: No, score=-0.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_BACKHAIR_23=1] 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 qKzxxDP_j-Im for ; Sun, 30 Nov 2014 19:30:11 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 129D21A034F for ; Sun, 30 Nov 2014 19:30:10 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 5D650282FBC; Mon, 1 Dec 2014 03:30:09 +0000 (UTC) Date: Mon, 1 Dec 2014 03:30:09 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20141201033009.GI285@mournblade.imrryr.org> References: <20141201013357.GF285@mournblade.imrryr.org> <547BC8F9.1070605@andyet.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <547BC8F9.1070605@andyet.net> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/_ysCoPQVePfFBSFgL3tB-ejLi2w Subject: [dane] WGLC: DANE-SRV (Abstract and introduction feedback) 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, 01 Dec 2014 03:30:13 -0000 On Sun, Nov 30, 2014 at 06:48:41PM -0700, Peter Saint-Andre - &yet wrote: > >>http://tools.ietf.org/wg/dane/draft-ietf-dane-srv > > > >I have extensive comments throughout the document, but I don't know > >how to best process them. One comment-bomb message? > > Unfortunately, yes. [ I'm splitting it into a few messages to keep it manageable, and in any case some of my comments are still pencil marks on a print-out, not yet transcribed. ] This message covers that abstract and introduction. General comment: The draft frequently talks about "hostnames", where what is really meant is a transport endpoint (port, transport protocol, host). With PKIX-EE or DANE-EE certificate usages, TLSA records are more precise than the Web PKI and can associate different, non-interchangeable key material with distinct services on a single host. So in many places I will be suggesting replacing statements about "hostnames" with statements about "transport endpoints". 1. Abstract: General comment, not just certificates, but also public keys, or more simply "key material". The new version is also more compact. OLD: 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, where the association is secured with DNSSEC. However, application protocols that use SRV records (RFC 2782) to indirectly name the target server host names for a service domain cannot apply the rules from RFC 6698. Therefore this document provides guidelines that enable such protocols to locate and use TLSA records. NEW: The DANE specification (RFC 6698) describes how to use DNSSEC secured TLSA resource records to associate a transport endpoint with corresponding TLS key material. This document builds on RFC 6698 to specify DANE for application protocols that use SRV records (RFC 2782) to indirectly locate the transport endpoints associated with a given service at a service domain. 2. Introduction first two paragraphs: Align with similar language in the abstract, deal with hostname versus transport endpoint. More concise. OLD: The base DANE specification describes how to use TLSA resource records in the DNS to associate a server's host name with its TLS certificate, where the association is secured using DNSSEC. That document "only relates to securely associating certificates for TLS and DTLS with host names" (see the last paragraph of section 1.2 of ). Some application protocols do not use host names directly; instead, they use a service domain, and the relevant target server host names are located indirectly via SRV records . Because of this intermediate resolution step, the normal DANE rules specified in cannot be applied to protocols that use SRV records. (Rules for SMTP , which uses MX records instead of SRV records, are described in .) New: The base DANE specification describes how to use DNSSEC secured TLSA resource records to associate a transport endpoint with corresponding TLS key material. Some application protocols locate transport endpoints indirectly via SRV records . As a result of this indirection, the rules specified in cannot be applied verbatim to protocols that use SRV records. (Rules for SMTP , which uses MX records instead of SRV records, are described in .) 2. Introduction summary: The most notable clarification below is that TLS is only mandatory, for a given transport endpoint, when DNSSEC validated TLSA records are present, whether usable or not. If at least one record is usable, the peer must be authenticated. If referencing OPS creates timing difficulties, because (for some reason not clear to me) OPS is being held back relative to SMTP and SRV, detailed CNAME language can be found in the SMTP draft (modulo MX<->SRV substitution). Add to references: OLD: We rely on DNSSEC to secure the association between the service domain and the target server host names (i.e., the host names that are discovered by the SRV query). The TLSA records are located using the port, protocol, and target server host name fields (not the service domain). Clients always use TLS when connecting to servers with TLSA records. Assuming that the association is secure, the server's certificate is expected to authenticate the target server host name, rather than the service domain. NEW: We rely on DNSSEC to secure SRV records that map the desired service, transport protocol and service domain to corresponding target transport endpoints (i.e., the host names and ports that are returned in the SRV records). TLSA records for each transport endpoint are located using the target port, tranport protocol, and target host name. In particular, TLSA records are not located directly via the service domain. When DNSSEC validated TLSA records are published for a particular transport endpoint, and the endpoint supports both cleartext and TLS communication, clients SHOULD use TLS when connecting to that endpoint. When at least one TLSA record is usable, the server's certificate or public key MUST match at least one of the usable TLSA records. The primary reference identity for peername checks is the TLSA base domain (generally the target host name) with the service domain also supported for compatibility with legacy deployments. Additional acceptable peer names may arise as a result of CNAME expansion of either the service domain or (if supported) the target hostname. See for details. -- Viktor.