From nobody Wed Sep 3 11:05:52 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A46A51A0462 for ; Wed, 3 Sep 2014 11:05:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dD935SgI97gW for ; Wed, 3 Sep 2014 11:05:47 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0241.outbound.protection.outlook.com [207.46.163.241]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AA241A042D for ; Wed, 3 Sep 2014 11:05:47 -0700 (PDT) Received: from BLUPR09MB117.namprd09.prod.outlook.com (10.255.213.14) by BLUPR09MB118.namprd09.prod.outlook.com (10.255.213.141) with Microsoft SMTP Server (TLS) id 15.0.1019.16; Wed, 3 Sep 2014 18:05:46 +0000 Received: from BLUPR09MB117.namprd09.prod.outlook.com ([10.255.213.14]) by BLUPR09MB117.namprd09.prod.outlook.com ([10.255.213.14]) with mapi id 15.00.1019.015; Wed, 3 Sep 2014 18:05:46 +0000 From: "Rose, Scott" To: dane WG list Thread-Topic: Enterprise email security reqs breakdown: REQ7 (signing/encryption certs) Thread-Index: AQHPx6Gv/dJnikS3MEKt0CG6PuebyQ== Date: Wed, 3 Sep 2014 18:05:46 +0000 Message-ID: <4ED17ED7-C9CC-40D8-A9B8-F46860A1D831@nist.gov> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [132.163.220.187] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:; x-forefront-prvs: 032334F434 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(189002)(199003)(99286002)(74662001)(74502001)(4396001)(95666004)(2656002)(33656002)(31966008)(81342001)(82746002)(229853001)(107886001)(15975445006)(107046002)(46102001)(83072002)(85306004)(92566001)(92726001)(85852003)(87936001)(86362001)(36756003)(81542001)(21056001)(76482001)(19580395003)(83322001)(110136001)(106116001)(105586002)(106356001)(79102001)(99396002)(15202345003)(19580405001)(50986999)(54356999)(80022001)(77982001)(66066001)(64706001)(20776003)(83716003)(101416001)(90102001)(104396001); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR09MB118; H:BLUPR09MB117.namprd09.prod.outlook.com; FPR:; 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/8Ut_ECvIA-x21qot6JvWcHK7h2U Subject: [dane] Enterprise email security reqs breakdown: REQ7 (signing/encryption certs) 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, 03 Sep 2014 18:05:49 -0000 This and following email will be an attempt to break down the requirements = in draft-osterweil-dane-ent-email-reqs-00 into separate threads in an attem= pt to make it manageable and keep issues separate. Each thread will handle= one (or two if similar) requirements and may include some strawman text to= start discussion. Most of the text and reqs deal with S/MIME as the targe= t technology but if it applies or could apply to other technologies, they s= hould be included. =20 I'm going to start using earlier text as the starting point. The resulting= text can either be incorporated into the existing SMIMEA draft, or a new d= raft if it looks like that is the direction the WG wants to go towards. REQ 7: The protocol MUST allow for separate management, publication, and learning of keys that are used for signing versus encryption. Strawman text using naming convention: Domain names are prepared for requests in the following manner. 1. The left-most label is the function specific label segment. It is selected based on the S/MIME function the MUA is performing. Values are: "_encr" for obtaining or validating a certificate or public key to be used to encrypt a message. "_sign" for certificate validation data to verify a digital signature. The function specific label SHOULD be consistent with the Key Usage field (defined in section 4.2.1.3 of [RFC5280]) of the associated certificate. This fu= ction specific label allows for clients to query for a particular certific= ate and keep the DNS response minimal. Having this the left-most label allo= ws=20 for the use of wildcards if only one certificate is used for both di= gital=20 signing and encryption if that is the policy of the organization. 1. The second left-most label is the user name (the "left-hand side" of = the=20 email address, called the "local-part" in the mail message format definition [RFC5322] and the "local part" in the specification for internationalized email [RFC6530]), as a SHA-224 hash. This does not include the=20 "@" character that separates the left and right sides of the email address. 3. The string "_smimecert" becomes the third left-most label in the prepared domain. The function specific label segment is separate to enable delegation of a single _smimecert zone cut. 4. The domain name (the "right-hand side" of the email address, called the "domain" in [RFC5322]) is appended to the result of step 3 to complete the prepared domain name. Questions: 1. is this requirement reasonable? =20 2. (if reasonable): Is the strawman text adequate? Should another method = be used other than a naming convention such as a different RRTYPE or usage = field? Scott =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/ =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 Thu Sep 4 13:21: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 B72381A0104 for ; Thu, 4 Sep 2014 13:21:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.4 X-Spam-Level: * X-Spam-Status: No, score=1.4 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_62=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 66bip8WhsoUr for ; Thu, 4 Sep 2014 13:21:39 -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 3A50B1A0102 for ; Thu, 4 Sep 2014 13:21:39 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 30B2D2AB2B7; Thu, 4 Sep 2014 20:21:37 +0000 (UTC) Date: Thu, 4 Sep 2014 20:21:37 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140904202137.GD26920@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/ZXTyZEqiVrhdSakC0fN5IdCyN4E Subject: [dane] DNSSEC debug advice (TLSA lookup problem). 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, 04 Sep 2014 20:21:40 -0000 Postfix with DANE enabled is unable to deliver mail to mailboxes in the "clarion-hotels.cz" domain (validating recursive resolvers SERVFAIL TLSA lookups). The domain is DNSSEC signed: $ dig +ad +noall +comment +ans -t mx clarion-hotels.cz ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25470 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 ;; ANSWER SECTION: clarion-hotels.cz. 1799 IN MX 10 mail.clarion-hotels.cz. clarion-hotels.cz. 1799 IN MX 20 mail2.clarion-hotels.cz. However, it also sports a wildcard CNAME: $ dig +cd +norecur +dnssec +vc -t CNAME "*.clarion-hotels.cz." @ns.forpsi.cz ; <<>> DiG 9.8.0rc1 <<>> +cd +norecur +dnssec +vc -t CNAME *.clarion-hotels.cz. @ns.forpsi.cz ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17866 ;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 6, ADDITIONAL: 8 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;*.clarion-hotels.cz. IN CNAME ;; ANSWER SECTION: *.clarion-hotels.cz. 1800 IN CNAME clarion-hotels.cz. *.clarion-hotels.cz. 1800 IN RRSIG CNAME 5 2 1800 20140924121306 20140825121306 13077 clarion-hotels.cz. M8OQ5fcnOYPX2XXvV9Cgefkjv2AHYFLAMeDfUpBuSk1PBFG6s/4tMSLb C/0r72TOjZupOHe5vizyzamAcE6m7dA4tlXGlWkTapf95lKFRokqjQow eRESgmZSS/b43jgxLv/+FRsu3rYnz77j3cC413qBn0PDDKLbepk0YEZC yTk= ;; AUTHORITY SECTION: clarion-hotels.cz. 3600 IN NS ns.forpsi.net. clarion-hotels.cz. 3600 IN NS ns.forpsi.it. clarion-hotels.cz. 3600 IN NS ns.forpsi.cz. clarion-hotels.cz. 3600 IN RRSIG NS 5 2 3600 20140924121306 20140825121306 13077 clarion-hotels.cz. E+Cj1pVvA9v/VP0b2AaOZpENNYiHScIVbXt+h5bpkkl6/iivoTxtORS3 xFCM+mcqkmgQf3xxo9eB0AwbKdf1Mjk4MB4GMn0m2XicWmdRPzHld57Y qr3vorVvOx1OKigLz3LHhYNzp4nC4qIZ1xqhTstgovnlr8I8QB6fhhnu wB4= *.clarion-hotels.cz. 3600 IN NSEC mail.clarion-hotels.cz. CNAME RRSIG NSEC *.clarion-hotels.cz. 3600 IN RRSIG NSEC 5 2 3600 20140924121306 20140825121306 13077 clarion-hotels.cz. jlZzNSRlMVDZ2YFPwJJLy7ba37h4w35+C3ge7iikVx03zIQWiBweU3hJ agqn/eCW8LnKGoDBvTUakvEenPnf9P4PUdOCL3/2trHLyLMv4NCafLaT n3d8OSbj6VWCKR1LWNSIcp3es3FbAsdWJtmcXe4oAKSP4i2dBmSEPq/F nS8= ;; ADDITIONAL SECTION: ns.forpsi.net. 1800 IN A 81.2.194.130 ns.forpsi.net. 1800 IN AAAA 2001:15e8:101:1::c282 ns.forpsi.it. 1800 IN A 62.149.230.87 ns.forpsi.cz. 1800 IN A 81.2.209.185 ns.forpsi.cz. 1800 IN RRSIG A 5 3 1800 20141004100806 20140904100806 27135 forpsi.cz. Nzo4Ma5iB8QFY6IERC3KLLRPkxsSQgBJgFMQHLl8AGuhaNwEeDLUaYz/ ZPjfiH2Rqchc5VV+nWV63gYhVGa4UB2fFLoFFn3L8Y6uTcBe3c7m3AaP ltUcrI2Wi7lR6Pf8DkncvtLLaumkRQ6FNkpYjyC/jkbVOMyP1r87TYXZ L78= ns.forpsi.cz. 1800 IN AAAA 2001:15e8:201:1::d1b9 ns.forpsi.cz. 1800 IN RRSIG AAAA 5 3 1800 20141004100806 20140904100806 27135 forpsi.cz. TF1AWJD3Wcun92QwS1+ZBy29Zi2qIkBWlYqUeFHGxyQhSlcSAWEt+oOr aTyqk79M38mH7TkFzrCBof+TAc6nM9JSOjm9RfmFQ0FVyM1cpmDxD79W coBeQcGStVofuvdKeuhZG2oiMyBKrbyUFZw1mgI0bupVs1daIy+zzdcQ 43c= ;; Query time: 104 msec ;; SERVER: 2001:15e8:201:1::d1b9#53(2001:15e8:201:1::d1b9) ;; WHEN: Thu Sep 4 19:57:58 2014 ;; MSG SIZE rcvd: 1156 I think the DNS servers in question don't correctly handle CNAMEs and DNSSEC and this impacts TLSA queries for non-existent records (SERVFAIL with many validating resolvers). The response does not include the "*.clarion-hotels.cz" RR and RRSIG). Instead we have, just the requested query name with an RRSIGS as below: _25._tcp.mail.clarion-hotels.cz. 1800 IN RRSIG CNAME 5 2 1800 \ 20140924121306 20140825121306 13077 clarion-hotels.cz. \ M8OQ5fcnOYPX2XXvV9Cgefkjv2AHYFLAMeDfUpBuSk1PBFG6s/4tMSLb \ C/0r72TOjZupOHe5vizyzamAcE6m7dA4tlXGlWkTapf95lKFRokqjQow \ eRESgmZSS/b43jgxLv/+FRsu3rYnz77j3cC413qBn0PDDKLbepk0YEZC yTk= _25._tcp.mail2.clarion-hotels.cz. 1800 IN RRSIG CNAME 5 2 1800 \ 20140924121306 20140825121306 13077 clarion-hotels.cz. \ M8OQ5fcnOYPX2XXvV9Cgefkjv2AHYFLAMeDfUpBuSk1PBFG6s/4tMSLb \ C/0r72TOjZupOHe5vizyzamAcE6m7dA4tlXGlWkTapf95lKFRokqjQow \ eRESgmZSS/b43jgxLv/+FRsu3rYnz77j3cC413qBn0PDDKLbepk0YEZC yTk= The suprising thing is that for two different qnames the RRSIG is the same, and in fact the same as for the wildcard qname! If RRSIGs depended only on the RDATA and not on the qname, surely there'd be serious integrity issues with DNSSEC. So I think that the authoritative servers for this domain are busted, is that correct? More complete server responses below (left out the authority and additional sections to avoid needless clutter): $ dig +cd +norecur +dnssec +vc -t tlsa "_25._tcp.mail.clarion-hotels.cz." @ns.forpsi.cz ; <<>> DiG 9.8.0rc1 <<>> +cd +norecur +dnssec +vc -t tlsa _25._tcp.mail.clarion-hotels.cz. @ns.forpsi.cz ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33941 ;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 6, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;_25._tcp.mail.clarion-hotels.cz. IN TLSA ;; ANSWER SECTION: _25._tcp.mail.clarion-hotels.cz. 1800 IN CNAME clarion-hotels.cz. _25._tcp.mail.clarion-hotels.cz. 1800 IN RRSIG CNAME 5 2 1800 20140924121306 20140825121306 13077 clarion-hotels.cz. M8OQ5fcnOYPX2XXvV9Cgefkjv2AHYFLAMeDfUpBuSk1PBFG6s/4tMSLb C/0r72TOjZupOHe5vizyzamAcE6m7dA4tlXGlWkTapf95lKFRokqjQow eRESgmZSS/b43jgxLv/+FRsu3rYnz77j3cC413qBn0PDDKLbepk0YEZC yTk= $ dig +cd +norecur +dnssec +vc -t tlsa "_25._tcp.mail2.clarion-hotels.cz." @ns.forpsi.cz ; <<>> DiG 9.8.0rc1 <<>> +cd +norecur +dnssec +vc -t tlsa _25._tcp.mail2.clarion-hotels.cz. @ns.forpsi.cz ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44567 ;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 6, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;_25._tcp.mail2.clarion-hotels.cz. IN TLSA ;; ANSWER SECTION: _25._tcp.mail2.clarion-hotels.cz. 1800 IN CNAME clarion-hotels.cz. _25._tcp.mail2.clarion-hotels.cz. 1800 IN RRSIG CNAME 5 2 1800 20140924121306 20140825121306 13077 clarion-hotels.cz. M8OQ5fcnOYPX2XXvV9Cgefkjv2AHYFLAMeDfUpBuSk1PBFG6s/4tMSLb C/0r72TOjZupOHe5vizyzamAcE6m7dA4tlXGlWkTapf95lKFRokqjQow eRESgmZSS/b43jgxLv/+FRsu3rYnz77j3cC413qBn0PDDKLbepk0YEZC yTk= -- Viktor. From nobody Thu Sep 4 14:00: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 C9F891A0184 for ; Thu, 4 Sep 2014 14:00:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.331 X-Spam-Level: * X-Spam-Status: No, score=1.331 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_22=0.6, J_CHICKENPOX_62=0.6, RP_MATCHES_RCVD=-0.668, 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 NtBeco0hIIPx for ; Thu, 4 Sep 2014 14:00:23 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C7291A0115 for ; Thu, 4 Sep 2014 14:00:23 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.ams1.isc.org (Postfix) with ESMTP id BF6451FCBA3 for ; Thu, 4 Sep 2014 21:00:18 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 9DCD5160068 for ; Thu, 4 Sep 2014 21:03:00 +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 3556F160052 for ; Thu, 4 Sep 2014 21:03:00 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 09E4D1E6A231 for ; Fri, 5 Sep 2014 07:00:17 +1000 (EST) To: dane@ietf.org From: Mark Andrews References: <20140904202137.GD26920@mournblade.imrryr.org> In-reply-to: Your message of "Thu, 04 Sep 2014 20:21:37 +0000." <20140904202137.GD26920@mournblade.imrryr.org> Date: Fri, 05 Sep 2014 07:00:16 +1000 Message-Id: <20140904210017.09E4D1E6A231@rock.dv.isc.org> Archived-At: http://mailarchive.ietf.org/arch/msg/dane/xTvPgTAbonk4BdgVhd1QVhapRsk Subject: Re: [dane] DNSSEC debug advice (TLSA lookup problem). 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, 04 Sep 2014 21:00:26 -0000 Just go and read how the DNS works first. This will tell you what rules DNSSEC has to prove were met for each answer. Then read how DNSSEC works. No. It doesn't just depend on the signature on the wildcard CNAME. That just proves the wildcard CNAME record itself was not tampered with. You also need to look at the NSEC/NSEC3 records to see if a CNAME match is valid or not. mail2.clarion-hotels.cz. 1788 IN NSEC clarion-hotels.cz. A RRSIG NSEC _tcp.clarion-hotels.cz. falls between mail2.clarion-hotels.cz and clarion-hotels.cz and it proves that there are names with records in that range once you verify its signature. The RRSIG for _25._tcp.mail2.clarion-hotels.cz says it was generated from a wildcard record which the validator proved by retaining the correct number of labels to form the suffix of the wildcard record and adding a '*' label. This gives the name of the record that was signed. The number of labels is also part of the data that is hashed to form the RRSIG. The following response has everything required to prove that there isn't a TLSA record for _25._tcp.mail2.clarion-hotels.cz. Firstly it has a CNAME which can be proved is generated from *.clarion-hotels.cz. Next it has a NSEC which says the wildcard response is valid. Next there is a NSEC which says that there isn't a TLSA record at the target of the CNAME which only has these records: A NS SOA MX RRSIG NSEC DNSKEY. The SOA record says for how long to cache the negative response. ; <<>> DiG 9.11.0pre-alpha <<>> _25._tcp.mail2.clarion-hotels.cz tlsa +dnssec ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52644 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 6, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;_25._tcp.mail2.clarion-hotels.cz. IN TLSA ;; ANSWER SECTION: _25._tcp.mail2.clarion-hotels.cz. 1773 IN CNAME clarion-hotels.cz. _25._tcp.mail2.clarion-hotels.cz. 1773 IN RRSIG CNAME 5 2 1800 20140924121306 20140825121306 13077 clarion-hotels.cz. M8OQ5fcnOYPX2XXvV9Cgefkjv2AHYFLAMeDfUpBuSk1PBFG6s/4tMSLb C/0r72TOjZupOHe5vizyzamAcE6m7dA4tlXGlWkTapf95lKFRokqjQow eRESgmZSS/b43jgxLv/+FRsu3rYnz77j3cC413qBn0PDDKLbepk0YEZC yTk= ;; AUTHORITY SECTION: mail2.clarion-hotels.cz. 1773 IN NSEC clarion-hotels.cz. A RRSIG NSEC mail2.clarion-hotels.cz. 1773 IN RRSIG NSEC 5 3 3600 20140924121306 20140825121306 13077 clarion-hotels.cz. WlUUsb1EqhP5mUfJ5DXpxvVs7Tw4h5802WCwXy4B2NByTbj3SfurhbV7 HBxPFA/I5OR4VkbWsFr7LlOpb93xRmEXt98afdrzzrKIgMIoNHu4oHDe ykeuV/7epjuHOxpZUKtfhe48ktKZ0NRievAyCUxiJA8evpgifR7AKKqS yGA= clarion-hotels.cz. 3574 IN SOA ns.forpsi.net. admin.forpsi.com. 2014082501 3600 1800 2592000 3600 clarion-hotels.cz. 3574 IN RRSIG SOA 5 2 3600 20140924121306 20140825121306 13077 clarion-hotels.cz. F5DurWWNlg9zQrvFMQrdNNjH58Zv/TTVBQSOtslMYlwXWp3ZcJGCC1Ra veDuerwFv5dQUsBQIJpQc5eZmyXXH8YA5rOLBK1x19ej0hl1T3yi3pG6 4SJFCrzSIIFVKzX7nKDtfnFK/Zq3X6db7oh9I+gpNnyojuDCccuQNwov kQw= clarion-hotels.cz. 3574 IN RRSIG NSEC 5 2 3600 20140924121306 20140825121306 13077 clarion-hotels.cz. OOeXzp0449w2dXf6zdvnidH69d27+9kPH6fJP9CK+coXuMiZ7WwheIn8 qZrhqYPu9xrnpgmYYkOeuaWDq2b+7rxKzzJTw/0hAjjO8vKRMr2sPyNi CpM2btBTM2FrKZvFJZegMYafo37QH05cg47hXAjEiyEYCMlJfNmMx+AN le8= clarion-hotels.cz. 3574 IN NSEC *.clarion-hotels.cz. A NS SOA MX RRSIG NSEC DNSKEY ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Fri Sep 05 06:45:10 EST 2014 ;; MSG SIZE rcvd: 929 Now can we please stop second guessing whether DNSSEC actually works. It does. Mark In message <20140904202137.GD26920@mournblade.imrryr.org>, Viktor Dukhovni writ es: > Postfix with DANE enabled is unable to deliver mail to mailboxes > in the "clarion-hotels.cz" domain (validating recursive resolvers > SERVFAIL TLSA lookups). The domain is DNSSEC signed: > > $ dig +ad +noall +comment +ans -t mx clarion-hotels.cz > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25470 > ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 > > ;; ANSWER SECTION: > clarion-hotels.cz. 1799 IN MX 10 mail.clarion-hotels.cz > . > clarion-hotels.cz. 1799 IN MX 20 mail2.clarion-hotels.c > z. > > However, it also sports a wildcard CNAME: > > $ dig +cd +norecur +dnssec +vc -t CNAME "*.clarion-hotels.cz." @ns.forpsi > .cz > ; <<>> DiG 9.8.0rc1 <<>> +cd +norecur +dnssec +vc -t CNAME *.clarion-hote > ls.cz. @ns.forpsi.cz > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17866 > ;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 6, ADDITIONAL: 8 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags: do; udp: 4096 > ;; QUESTION SECTION: > ;*.clarion-hotels.cz. IN CNAME > > ;; ANSWER SECTION: > *.clarion-hotels.cz. 1800 IN CNAME clarion-hotels.cz. > *.clarion-hotels.cz. 1800 IN RRSIG CNAME 5 2 1800 20140924 > 121306 20140825121306 13077 clarion-hotels.cz. M8OQ5fcnOYPX2XXvV9Cgefkjv2AHYF > LAMeDfUpBuSk1PBFG6s/4tMSLb C/0r72TOjZupOHe5vizyzamAcE6m7dA4tlXGlWkTapf95lKFRo > kqjQow eRESgmZSS/b43jgxLv/+FRsu3rYnz77j3cC413qBn0PDDKLbepk0YEZC yTk= > > ;; AUTHORITY SECTION: > clarion-hotels.cz. 3600 IN NS ns.forpsi.net. > clarion-hotels.cz. 3600 IN NS ns.forpsi.it. > clarion-hotels.cz. 3600 IN NS ns.forpsi.cz. > clarion-hotels.cz. 3600 IN RRSIG NS 5 2 3600 20140924121 > 306 20140825121306 13077 clarion-hotels.cz. E+Cj1pVvA9v/VP0b2AaOZpENNYiHScIVb > Xt+h5bpkkl6/iivoTxtORS3 xFCM+mcqkmgQf3xxo9eB0AwbKdf1Mjk4MB4GMn0m2XicWmdRPzHld > 57Y qr3vorVvOx1OKigLz3LHhYNzp4nC4qIZ1xqhTstgovnlr8I8QB6fhhnu wB4= > *.clarion-hotels.cz. 3600 IN NSEC mail.clarion-hotels.cz. > CNAME RRSIG NSEC > *.clarion-hotels.cz. 3600 IN RRSIG NSEC 5 2 3600 201409241 > 21306 20140825121306 13077 clarion-hotels.cz. jlZzNSRlMVDZ2YFPwJJLy7ba37h4w35 > +C3ge7iikVx03zIQWiBweU3hJ agqn/eCW8LnKGoDBvTUakvEenPnf9P4PUdOCL3/2trHLyLMv4NC > afLaT n3d8OSbj6VWCKR1LWNSIcp3es3FbAsdWJtmcXe4oAKSP4i2dBmSEPq/F nS8= > > ;; ADDITIONAL SECTION: > ns.forpsi.net. 1800 IN A 81.2.194.130 > ns.forpsi.net. 1800 IN AAAA 2001:15e8:101:1::c282 > ns.forpsi.it. 1800 IN A 62.149.230.87 > ns.forpsi.cz. 1800 IN A 81.2.209.185 > ns.forpsi.cz. 1800 IN RRSIG A 5 3 1800 201410041008 > 06 20140904100806 27135 forpsi.cz. Nzo4Ma5iB8QFY6IERC3KLLRPkxsSQgBJgFMQHLl8AG > uhaNwEeDLUaYz/ ZPjfiH2Rqchc5VV+nWV63gYhVGa4UB2fFLoFFn3L8Y6uTcBe3c7m3AaP ltUcr > I2Wi7lR6Pf8DkncvtLLaumkRQ6FNkpYjyC/jkbVOMyP1r87TYXZ L78= > ns.forpsi.cz. 1800 IN AAAA 2001:15e8:201:1::d1b9 > ns.forpsi.cz. 1800 IN RRSIG AAAA 5 3 1800 201410041 > 00806 20140904100806 27135 forpsi.cz. TF1AWJD3Wcun92QwS1+ZBy29Zi2qIkBWlYqUeFH > GxyQhSlcSAWEt+oOr aTyqk79M38mH7TkFzrCBof+TAc6nM9JSOjm9RfmFQ0FVyM1cpmDxD79W co > BeQcGStVofuvdKeuhZG2oiMyBKrbyUFZw1mgI0bupVs1daIy+zzdcQ 43c= > > ;; Query time: 104 msec > ;; SERVER: 2001:15e8:201:1::d1b9#53(2001:15e8:201:1::d1b9) > ;; WHEN: Thu Sep 4 19:57:58 2014 > ;; MSG SIZE rcvd: 1156 > > I think the DNS servers in question don't correctly handle CNAMEs > and DNSSEC and this impacts TLSA queries for non-existent records > (SERVFAIL with many validating resolvers). The response does not > include the "*.clarion-hotels.cz" RR and RRSIG). Instead we have, > just the requested query name with an RRSIGS as below: > > _25._tcp.mail.clarion-hotels.cz. 1800 IN RRSIG CNAME 5 2 1800 \ > 20140924121306 20140825121306 13077 clarion-hotels.cz. \ > M8OQ5fcnOYPX2XXvV9Cgefkjv2AHYFLAMeDfUpBuSk1PBFG6s/4tMSLb \ > C/0r72TOjZupOHe5vizyzamAcE6m7dA4tlXGlWkTapf95lKFRokqjQow \ > eRESgmZSS/b43jgxLv/+FRsu3rYnz77j3cC413qBn0PDDKLbepk0YEZC yTk= > > _25._tcp.mail2.clarion-hotels.cz. 1800 IN RRSIG CNAME 5 2 1800 \ > 20140924121306 20140825121306 13077 clarion-hotels.cz. \ > M8OQ5fcnOYPX2XXvV9Cgefkjv2AHYFLAMeDfUpBuSk1PBFG6s/4tMSLb \ > C/0r72TOjZupOHe5vizyzamAcE6m7dA4tlXGlWkTapf95lKFRokqjQow \ > eRESgmZSS/b43jgxLv/+FRsu3rYnz77j3cC413qBn0PDDKLbepk0YEZC yTk= > > The suprising thing is that for two different qnames the RRSIG is > the same, and in fact the same as for the wildcard qname! If RRSIGs > depended only on the RDATA and not on the qname, surely there'd be > serious integrity issues with DNSSEC. So I think that the > authoritative servers for this domain are busted, is that correct? > > More complete server responses below (left out the authority and > additional sections to avoid needless clutter): > > $ dig +cd +norecur +dnssec +vc -t tlsa "_25._tcp.mail.clarion-hotels.cz." > @ns.forpsi.cz > ; <<>> DiG 9.8.0rc1 <<>> +cd +norecur +dnssec +vc -t tlsa _25._tcp.mail.c > larion-hotels.cz. @ns.forpsi.cz > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33941 > ;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 6, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags: do; udp: 4096 > ;; QUESTION SECTION: > ;_25._tcp.mail.clarion-hotels.cz. IN TLSA > > ;; ANSWER SECTION: > _25._tcp.mail.clarion-hotels.cz. 1800 IN CNAME clarion-hotels.cz. > _25._tcp.mail.clarion-hotels.cz. 1800 IN RRSIG CNAME 5 2 1800 20140924 > 121306 20140825121306 13077 clarion-hotels.cz. M8OQ5fcnOYPX2XXvV9Cgefkjv2AHYF > LAMeDfUpBuSk1PBFG6s/4tMSLb C/0r72TOjZupOHe5vizyzamAcE6m7dA4tlXGlWkTapf95lKFRo > kqjQow eRESgmZSS/b43jgxLv/+FRsu3rYnz77j3cC413qBn0PDDKLbepk0YEZC yTk= > > > $ dig +cd +norecur +dnssec +vc -t tlsa "_25._tcp.mail2.clarion-hotels.cz. > " @ns.forpsi.cz > ; <<>> DiG 9.8.0rc1 <<>> +cd +norecur +dnssec +vc -t tlsa _25._tcp.mail2. > clarion-hotels.cz. @ns.forpsi.cz > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44567 > ;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 6, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags: do; udp: 4096 > ;; QUESTION SECTION: > ;_25._tcp.mail2.clarion-hotels.cz. IN TLSA > > ;; ANSWER SECTION: > _25._tcp.mail2.clarion-hotels.cz. 1800 IN CNAME clarion-hotels.cz. > _25._tcp.mail2.clarion-hotels.cz. 1800 IN RRSIG CNAME 5 2 1800 20140924 > 121306 20140825121306 13077 clarion-hotels.cz. M8OQ5fcnOYPX2XXvV9Cgefkjv2AHYF > LAMeDfUpBuSk1PBFG6s/4tMSLb C/0r72TOjZupOHe5vizyzamAcE6m7dA4tlXGlWkTapf95lKFRo > kqjQow eRESgmZSS/b43jgxLv/+FRsu3rYnz77j3cC413qBn0PDDKLbepk0YEZC yTk= > > -- > 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 Sep 4 14:37:36 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA4D11A0185 for ; Thu, 4 Sep 2014 14:37:34 -0700 (PDT) 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_05=-0.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3tx5NJkkR4_7 for ; Thu, 4 Sep 2014 14:37:33 -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 1F4BF1A00FF for ; Thu, 4 Sep 2014 14:37:33 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 298BB2AB2AC; Thu, 4 Sep 2014 21:37:31 +0000 (UTC) Date: Thu, 4 Sep 2014 21:37:31 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140904213730.GE26920@mournblade.imrryr.org> References: <20140904202137.GD26920@mournblade.imrryr.org> <20140904210017.09E4D1E6A231@rock.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140904210017.09E4D1E6A231@rock.dv.isc.org> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/o-Rhkkk7oAs3qnZ-FikdU6nvIeM Subject: Re: [dane] DNSSEC debug advice (TLSA lookup problem). 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, 04 Sep 2014 21:37:35 -0000 On Fri, Sep 05, 2014 at 07:00:16AM +1000, Mark Andrews wrote: > Just go and read how the DNS works first. This will tell you what > rules DNSSEC has to prove were met for each answer. Yes, in fact between posting and reading your answer, I went off and did some reading. The problem as I now understand it seems to be that: 1. *.clarion-hotels.cz IN CNAME exists. 2. mail2.clarion-hotels.cz exists. 3. _tcp.mail2.clarion-hotels.cz does not exist. and finally, the nameservers for clarion-hotels.cz incorrectly apply the wildcard CNAME to a child of an existing sibling node (mail2). This is detected as an error by various validating resolvers. Is this right? > The RRSIG for _25._tcp.mail2.clarion-hotels.cz says it was generated > from a wildcard record which the validator proved by retaining the > correct number of labels to form the suffix of the wildcard record > and adding a '*' label. This gives the name of the record that was > signed. The number of labels is also part of the data that is > hashed to form the RRSIG. Right, so along with this there needs to be a non-existence proof for the labels replaced with the wildcard, but there is no such proof, because "mail2" exists. > Now can we please stop second guessing whether DNSSEC actually > works. It does. Sorry, I was just surprised by the RRSIG values being the same for multiple qnames, but did not know about the RRSIG label count field. So my guess was way off, but it was a guess, and I did ask for advice from folks who actually know how this works. So now I need to figure out what manner of broken name servers are: ns.forpsi.cz ns.forpsi.it ns.forpsi.net -- Viktor. From nobody Thu Sep 4 16:05:43 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B82BC1A026F for ; Thu, 4 Sep 2014 16:05:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668, 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 KXdzhy3B_ca4 for ; Thu, 4 Sep 2014 16:05:39 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24D8D1A026C for ; Thu, 4 Sep 2014 16:05:39 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP id 94AB2349441 for ; Thu, 4 Sep 2014 23:05:35 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 12521160068 for ; Thu, 4 Sep 2014 23:08:18 +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 D7643160052 for ; Thu, 4 Sep 2014 23:08:17 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id ED33E1E6D2FC for ; Fri, 5 Sep 2014 09:05:33 +1000 (EST) To: dane@ietf.org From: Mark Andrews References: <20140904202137.GD26920@mournblade.imrryr.org> <20140904210017.09E4D1E6A231@rock.dv.isc.org> <20140904213730.GE26920@mournblade.imrryr.org> In-reply-to: Your message of "Thu, 04 Sep 2014 21:37:31 +0000." <20140904213730.GE26920@mournblade.imrryr.org> Date: Fri, 05 Sep 2014 09:05:33 +1000 Message-Id: <20140904230533.ED33E1E6D2FC@rock.dv.isc.org> Archived-At: http://mailarchive.ietf.org/arch/msg/dane/pzgAHBG6kl9zgBm0AQ0hyGtxGqQ Subject: Re: [dane] DNSSEC debug advice (TLSA lookup problem). 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, 04 Sep 2014 23:05:42 -0000 In message <20140904213730.GE26920@mournblade.imrryr.org>, Viktor Dukhovni writ es: > On Fri, Sep 05, 2014 at 07:00:16AM +1000, Mark Andrews wrote: > > > Just go and read how the DNS works first. This will tell you what > > rules DNSSEC has to prove were met for each answer. > > Yes, in fact between posting and reading your answer, I went off > and did some reading. The problem as I now understand it seems to > be that: > > 1. *.clarion-hotels.cz IN CNAME exists. > 2. mail2.clarion-hotels.cz exists. > 3. _tcp.mail2.clarion-hotels.cz does not exist. > > and finally, the nameservers for clarion-hotels.cz incorrectly > apply the wildcard CNAME to a child of an existing sibling node > (mail2). This is detected as an error by various validating > resolvers. > > Is this right? Yes. > > The RRSIG for _25._tcp.mail2.clarion-hotels.cz says it was generated > > from a wildcard record which the validator proved by retaining the > > correct number of labels to form the suffix of the wildcard record > > and adding a '*' label. This gives the name of the record that was > > signed. The number of labels is also part of the data that is > > hashed to form the RRSIG. > > Right, so along with this there needs to be a non-existence proof > for the labels replaced with the wildcard, but there is no such > proof, because "mail2" exists. > > > Now can we please stop second guessing whether DNSSEC actually > > works. It does. > > Sorry, I was just surprised by the RRSIG values being the same for > multiple qnames, but did not know about the RRSIG label count field. > So my guess was way off, but it was a guess, and I did ask for > advice from folks who actually know how this works. Ok. Sorry if I came on a bit strong. > So now I need to figure out what manner of broken name servers are: > > ns.forpsi.cz > ns.forpsi.it > ns.forpsi.net > > -- > 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 Fri Sep 5 02:30: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 9F05D1A05D1 for ; Fri, 5 Sep 2014 02:30:15 -0700 (PDT) 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_DE=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 OdqaUY0_Fm98 for ; Fri, 5 Sep 2014 02:30:13 -0700 (PDT) Received: from triangulum.uberspace.de (triangulum.uberspace.de [95.143.172.227]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE8801A00E7 for ; Fri, 5 Sep 2014 02:30:12 -0700 (PDT) Received: (qmail 30253 invoked from network); 5 Sep 2014 09:30:09 -0000 Received: from localhost (HELO www.bartschnet.de) (127.0.0.1) by triangulum.uberspace.de with SMTP; 5 Sep 2014 09:30:09 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 05 Sep 2014 11:30:06 +0200 From: Rene Bartsch To: IETF DANE Mailinglist In-Reply-To: <20140904230533.ED33E1E6D2FC@rock.dv.isc.org> References: <20140904202137.GD26920@mournblade.imrryr.org> <20140904210017.09E4D1E6A231@rock.dv.isc.org> <20140904213730.GE26920@mournblade.imrryr.org> <20140904230533.ED33E1E6D2FC@rock.dv.isc.org> Message-ID: X-Sender: ietf@bartschnet.de User-Agent: Roundcube Webmail/1.0.1 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/VFfRrToGdLCyj_v5h0_rM1g81B4 Subject: Re: [dane] DNSSEC debug advice (TLSA lookup problem). 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, 05 Sep 2014 09:30:15 -0000 When testing avoid to use Google Public DNS resolvers as they have a bug in wildcard resolution (https://groups.google.com/forum/#!topic/public-dns-discuss/M982l7Lz9uA). Am 2014-09-05 01:05, schrieb Mark Andrews: > In message <20140904213730.GE26920@mournblade.imrryr.org>, Viktor > Dukhovni writ > es: >> On Fri, Sep 05, 2014 at 07:00:16AM +1000, Mark Andrews wrote: >> >> > Just go and read how the DNS works first. This will tell you what >> > rules DNSSEC has to prove were met for each answer. >> >> Yes, in fact between posting and reading your answer, I went off >> and did some reading. The problem as I now understand it seems to >> be that: >> >> 1. *.clarion-hotels.cz IN CNAME exists. >> 2. mail2.clarion-hotels.cz exists. >> 3. _tcp.mail2.clarion-hotels.cz does not exist. >> >> and finally, the nameservers for clarion-hotels.cz incorrectly >> apply the wildcard CNAME to a child of an existing sibling node >> (mail2). This is detected as an error by various validating >> resolvers. >> >> Is this right? > > Yes. > >> > The RRSIG for _25._tcp.mail2.clarion-hotels.cz says it was generated >> > from a wildcard record which the validator proved by retaining the >> > correct number of labels to form the suffix of the wildcard record >> > and adding a '*' label. This gives the name of the record that was >> > signed. The number of labels is also part of the data that is >> > hashed to form the RRSIG. >> >> Right, so along with this there needs to be a non-existence proof >> for the labels replaced with the wildcard, but there is no such >> proof, because "mail2" exists. >> >> > Now can we please stop second guessing whether DNSSEC actually >> > works. It does. >> >> Sorry, I was just surprised by the RRSIG values being the same for >> multiple qnames, but did not know about the RRSIG label count field. >> So my guess was way off, but it was a guess, and I did ask for >> advice from folks who actually know how this works. > > Ok. Sorry if I came on a bit strong. > >> So now I need to figure out what manner of broken name servers are: >> >> ns.forpsi.cz >> ns.forpsi.it >> ns.forpsi.net >> >> -- >> Viktor. >> >> _______________________________________________ >> dane mailing list >> dane@ietf.org >> https://www.ietf.org/mailman/listinfo/dane -- Best regards, Rene Bartsch, B. Sc. Informatics From nobody Fri Sep 5 08:11: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 D55A91A06F6 for ; Fri, 5 Sep 2014 08:11:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qJqBvnE-DK2K for ; Fri, 5 Sep 2014 08:11:56 -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 195391A02FC for ; Fri, 5 Sep 2014 08:11:56 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 1748E2AB2C0; Fri, 5 Sep 2014 15:11:49 +0000 (UTC) Date: Fri, 5 Sep 2014 15:11:49 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140905151149.GO26920@mournblade.imrryr.org> References: <20140904202137.GD26920@mournblade.imrryr.org> <20140904210017.09E4D1E6A231@rock.dv.isc.org> <20140904213730.GE26920@mournblade.imrryr.org> <20140904230533.ED33E1E6D2FC@rock.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140904230533.ED33E1E6D2FC@rock.dv.isc.org> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/tX2lAi1k8PAjHTxgCbJTPmwMNqY Subject: Re: [dane] DNSSEC debug advice (TLSA lookup problem). 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, 05 Sep 2014 15:11:58 -0000 On Fri, Sep 05, 2014 at 09:05:33AM +1000, Mark Andrews wrote: > > Yes, in fact between posting and reading your answer, I went off > > and did some reading. The problem as I now understand it seems to > > be that: > > > > 1. *.clarion-hotels.cz IN CNAME exists. > > 2. mail2.clarion-hotels.cz exists. > > 3. _tcp.mail2.clarion-hotels.cz does not exist. > > > > and finally, the nameservers for clarion-hotels.cz incorrectly > > apply the wildcard CNAME to a child of an existing sibling node > > (mail2). This is detected as an error by various validating > > resolvers. > > > > Is this right? > > Yes. Thanks. I wrote to the operators of the DNS servers, and they are planning to fix the bug, but implemented a short-term work-around, where the wildcard CNAME was replaced by wildcard A record. However the work-around is not working to the satisfaction of my resolver, any idea why? $ dig +dnssec +norecur -t tlsa _25._tcp.mail2.clarion-hotels.cz @ns.forpsi.net ; <<>> DiG 9.8.3-P1 <<>> +dnssec +norecur -t tlsa _25._tcp.mail2.clarion-hotels.cz @ns.forpsi.net ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31810 ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;_25._tcp.mail2.clarion-hotels.cz. IN TLSA ;; AUTHORITY SECTION: clarion-hotels.cz. 3600 IN SOA ns.forpsi.net. admin.forpsi.com. 2014090502 3600 1800 2592000 3600 clarion-hotels.cz. 3600 IN RRSIG SOA 5 2 3600 20141005113302 20140905113302 13077 clarion-hotels.cz. Y4JCzy6U/fMI2tz+pLfQ1mFD2h1jxRMJ7nUwXS0cxlE9xcN8QFibwC75 BBivVbf3Xb2oPXJTRTvkkUAXR1wziOCy/qvK4LyNFX2ENn2aKGn3i93H LrHM/5u1IoeG4niXbS22Tue3FEgYKcSX7UA5PDDQAQs2o+jX9IbwYawC teM= *.clarion-hotels.cz. 3600 IN NSEC mail.clarion-hotels.cz. A RRSIG NSEC *.clarion-hotels.cz. 3600 IN RRSIG NSEC 5 2 3600 20141005113302 20140905113302 13077 clarion-hotels.cz. lSf+ySQxo+sXxtuEZEIy7YghFeQnFlDd7vkZA8XO/ahgAzgxHZkAsQXk RjoJVCLd3E3FgX55Pu0RA6IQVn1ynZFYp3l1P24bC93+l3vszNsnMKnD qqjNIIzeYanNfkI34kdPpj5C1HhtrC1ZUhRwryphsKXX9KYFB/B4i+47 U2E= mail2.clarion-hotels.cz. 3600 IN NSEC clarion-hotels.cz. A RRSIG NSEC mail2.clarion-hotels.cz. 3600 IN RRSIG NSEC 5 3 3600 20141005113302 20140905113302 13077 clarion-hotels.cz. lX8m4n9dL8/055WYsv5LW/D9L7257lzOv9QAynpBlJiShQkYRFsAc9rT ZFdrCeahWXg01/jGVrUNoxwJUUxUobt8GFcTiXHvI/w5ej6rsc80tUVT BCnW9WsJBNiz7hDN8Ac3V8gKE77Td2TZxJpPtRdAOTW4mc6E04XsLIL7 XmQ= ;; Query time: 130 msec ;; SERVER: 81.2.194.130#53(81.2.194.130) ;; WHEN: Fri Sep 5 11:04:38 2014 ;; MSG SIZE rcvd: 742 This time there is no erroneous wildcard CNAME response, just ANSWER:0, and some NSEC records in the authority section. In particular there is an NSEC record that should prove absense of anything after "mail2", thus denying "_tcp.mail2"... What's wrong now? Oddly enough when I ask for "mail3. IN TLSA ?" the resolver is happy with a "NODATA" response, containing exactly the same records. So these records constitute proof that "mail3" does not exist, but somehow fail to prove that "_tcp.mail2" does not? -- Viktor. From nobody Fri Sep 5 09:26: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 250B71A0ADC for ; Fri, 5 Sep 2014 09:26:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ekgO8bTAh229 for ; Fri, 5 Sep 2014 09:26:38 -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 9B4F21A0ADB for ; Fri, 5 Sep 2014 09:26:38 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id E35202AB2BB; Fri, 5 Sep 2014 16:26:36 +0000 (UTC) Date: Fri, 5 Sep 2014 16:26:36 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140905162636.GR26920@mournblade.imrryr.org> References: <20140904202137.GD26920@mournblade.imrryr.org> <20140904210017.09E4D1E6A231@rock.dv.isc.org> <20140904213730.GE26920@mournblade.imrryr.org> <20140904230533.ED33E1E6D2FC@rock.dv.isc.org> <20140905151149.GO26920@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140905151149.GO26920@mournblade.imrryr.org> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/BnWcRCWuB5_BJozgE8-dH2Mmh18 Subject: Re: [dane] DNSSEC debug advice (TLSA lookup problem). 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, 05 Sep 2014 16:26:40 -0000 On Fri, Sep 05, 2014 at 03:11:49PM +0000, Viktor Dukhovni wrote: > $ dig +dnssec +norecur -t tlsa _25._tcp.mail2.clarion-hotels.cz @ns.forpsi.net > ... > *.clarion-hotels.cz. 3600 IN NSEC mail.clarion-hotels.cz. A RRSIG NSEC > *.clarion-hotels.cz. 3600 IN RRSIG NSEC 5 2 3600 20141005113302 20140905113302 13077 clarion-hotels.cz. lSf+ySQxo+sXxtuEZEIy7YghFeQnFlDd7vkZA8XO/ahgAzgxHZkAsQXk RjoJVCLd3E3FgX55Pu0RA6IQVn1ynZFYp3l1P24bC93+l3vszNsnMKnD qqjNIIzeYanNfkI34kdPpj5C1HhtrC1ZUhRwryphsKXX9KYFB/B4i+47 U2E= The only slightly odd thing I see is the RRSIG above. Instead of binding all three labels of the wildcard, it binds only the last two. Is that how it should be? Anyone have better insight? -- Viktor. From nobody Fri Sep 5 11:45:34 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 996421A014E for ; Fri, 5 Sep 2014 11:45:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cxeue1A9pdym for ; Fri, 5 Sep 2014 11:45:30 -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 360B91A0149 for ; Fri, 5 Sep 2014 11:45:30 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 7711C2AB2C4; Fri, 5 Sep 2014 18:45:28 +0000 (UTC) Date: Fri, 5 Sep 2014 18:45:28 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140905184528.GT26920@mournblade.imrryr.org> References: <20140904202137.GD26920@mournblade.imrryr.org> <20140904210017.09E4D1E6A231@rock.dv.isc.org> <20140904213730.GE26920@mournblade.imrryr.org> <20140904230533.ED33E1E6D2FC@rock.dv.isc.org> <20140905151149.GO26920@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140905151149.GO26920@mournblade.imrryr.org> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/9gCWYbNzrwmDQux0AhvRPl9eq3s Subject: Re: [dane] DNSSEC debug advice (TLSA lookup problem). 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, 05 Sep 2014 18:45:31 -0000 On Fri, Sep 05, 2014 at 03:11:49PM +0000, Viktor Dukhovni wrote: > Thanks. I wrote to the operators of the DNS servers, and they are > planning to fix the bug, but implemented a short-term work-around, > where the wildcard CNAME was replaced by wildcard A record. However > the work-around is not working to the satisfaction of my resolver, > any idea why? OK, now I understand. The response is "NODATA", but is should be "NXDOMAIN". All that the change did was prevent the wildcard CNAME being returned incorrectly, but the wildcard record is still incorrectly processed for the query in question, and incorrectly returns "NODATA", rather than "NXDOMAIN". So the work-around is not sufficient. The real fix is to get the nameserver to not apply wildcards to subdomains of existent siblings. I'll try to find out what nameserer software this is, and if something mainstream, try to let operators know to avoid it. -- Viktor. From nobody Fri Sep 5 14:39: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 669011A02E7 for ; Fri, 5 Sep 2014 14:39:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.569 X-Spam-Level: X-Spam-Status: No, score=-7.569 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, 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 D0pZpyfYaEbW for ; Fri, 5 Sep 2014 14:39:39 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83DBD1A0144 for ; Fri, 5 Sep 2014 14:39:39 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP id 140E23493DE for ; Fri, 5 Sep 2014 21:39:37 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 09DCF160047 for ; Fri, 5 Sep 2014 21:42:20 +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 967A6160003 for ; Fri, 5 Sep 2014 21:42:19 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id E12C61E806B5 for ; Sat, 6 Sep 2014 07:39:34 +1000 (EST) To: dane@ietf.org From: Mark Andrews References: <20140904202137.GD26920@mournblade.imrryr.org> <20140904210017.09E4D1E6A231@rock.dv.isc.org> <20140904213730.GE26920@mournblade.imrryr.org> <20140904230533.ED33E1E6D2FC@rock.dv.isc.org> <20140905151149.GO26920@mournblade.imrryr.org> In-reply-to: Your message of "Fri, 05 Sep 2014 15:11:49 +0000." <20140905151149.GO26920@mournblade.imrryr.org> Date: Sat, 06 Sep 2014 07:39:34 +1000 Message-Id: <20140905213934.E12C61E806B5@rock.dv.isc.org> Archived-At: http://mailarchive.ietf.org/arch/msg/dane/6-9nVHQ5zzbiiyTgOUCrBR7EBTk Subject: Re: [dane] DNSSEC debug advice (TLSA lookup problem). 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, 05 Sep 2014 21:39:41 -0000 In message <20140905151149.GO26920@mournblade.imrryr.org>, Viktor Dukhovni writes: > On Fri, Sep 05, 2014 at 09:05:33AM +1000, Mark Andrews wrote: > > > > Yes, in fact between posting and reading your answer, I went off > > > and did some reading. The problem as I now understand it seems to > > > be that: > > > > > > 1. *.clarion-hotels.cz IN CNAME exists. > > > 2. mail2.clarion-hotels.cz exists. > > > 3. _tcp.mail2.clarion-hotels.cz does not exist. > > > > > > and finally, the nameservers for clarion-hotels.cz incorrectly > > > apply the wildcard CNAME to a child of an existing sibling node > > > (mail2). This is detected as an error by various validating > > > resolvers. > > > > > > Is this right? > > > > Yes. > > Thanks. I wrote to the operators of the DNS servers, and they are > planning to fix the bug, but implemented a short-term work-around, > where the wildcard CNAME was replaced by wildcard A record. However > the work-around is not working to the satisfaction of my resolver, > any idea why? The problem is the wildcard and the broken wildcard processing, not the CNAME. The rcode is wrong as a result, NOERROR != NXDOMAIN. Getting rid of the wild card and adding explict address records for every name the http server is configured fore plus anything else depending on the wildcard will work. Alternatively adding a non TLSA records at the expected TLSA names should work as it should prevent the attempted wilcard lookup in the server and the resulting mis-match. _tlsa._tcp.mail.clarion-hotels.cz TXT "-" _tlsa._tcp.mail2.clarion-hotels.cz TXT "-" Alternatively they could configure the MTAs to support STARTTLS and add TLSA records. Mark > $ dig +dnssec +norecur -t tlsa _25._tcp.mail2.clarion-hotels.cz @ns.forpsi.net > ; <<>> DiG 9.8.3-P1 <<>> +dnssec +norecur -t tlsa _25._tcp.mail2.clarion-hotels.cz @ns.forpsi.net > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31810 > ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags: do; udp: 4096 > ;; QUESTION SECTION: > ;_25._tcp.mail2.clarion-hotels.cz. IN TLSA > > ;; AUTHORITY SECTION: > clarion-hotels.cz. 3600 IN SOA ns.forpsi.net. admin.forpsi.com. 2014090502 3600 1800 2592000 3600 > clarion-hotels.cz. 3600 IN RRSIG SOA 5 2 3600 20141005113302 20140905113302 13077 clarion-hotels.cz. > Y4JCzy6U/fMI2tz+pLfQ1mFD2h1jxRMJ7nUwXS0cxlE9xcN8QFibwC75 BBivVbf3Xb2oPXJTRTvkkUAXR1wziOCy/qvK4LyNFX2ENn2aKGn3i93H LrHM > /5u1IoeG4niXbS22Tue3FEgYKcSX7UA5PDDQAQs2o+jX9IbwYawC teM= > *.clarion-hotels.cz. 3600 IN NSEC mail.clarion-hotels.cz. A RRSIG NSEC > *.clarion-hotels.cz. 3600 IN RRSIG NSEC 5 2 3600 20141005113302 20140905113302 13077 clarion-hotels.cz > . lSf+ySQxo+sXxtuEZEIy7YghFeQnFlDd7vkZA8XO/ahgAzgxHZkAsQXk RjoJVCLd3E3FgX55Pu0RA6IQVn1ynZFYp3l1P24bC93+l3vszNsnMKnD qqj > NIIzeYanNfkI34kdPpj5C1HhtrC1ZUhRwryphsKXX9KYFB/B4i+47 U2E= > mail2.clarion-hotels.cz. 3600 IN NSEC clarion-hotels.cz. A RRSIG NSEC > mail2.clarion-hotels.cz. 3600 IN RRSIG NSEC 5 3 3600 20141005113302 20140905113302 13077 clarion-hotels.cz > . lX8m4n9dL8/055WYsv5LW/D9L7257lzOv9QAynpBlJiShQkYRFsAc9rT ZFdrCeahWXg01/jGVrUNoxwJUUxUobt8GFcTiXHvI/w5ej6rsc80tUVT BCn > W9WsJBNiz7hDN8Ac3V8gKE77Td2TZxJpPtRdAOTW4mc6E04XsLIL7 XmQ= > > ;; Query time: 130 msec > ;; SERVER: 81.2.194.130#53(81.2.194.130) > ;; WHEN: Fri Sep 5 11:04:38 2014 > ;; MSG SIZE rcvd: 742 > > This time there is no erroneous wildcard CNAME response, just > ANSWER:0, and some NSEC records in the authority section. In > particular there is an NSEC record that should prove absense of > anything after "mail2", thus denying "_tcp.mail2"... > > What's wrong now? Oddly enough when I ask for "mail3. IN TLSA > ?" the resolver is happy with a "NODATA" response, containing > exactly the same records. So these records constitute proof that > "mail3" does not exist, but somehow fail to prove that "_tcp.mail2" > does not? > > -- > 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 Fri Sep 5 14:55:52 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CB8C1A01A5 for ; Fri, 5 Sep 2014 14:55:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eN8wLYzVu_6L for ; Fri, 5 Sep 2014 14:55:47 -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 CDA221A0352 for ; Fri, 5 Sep 2014 14:55:46 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 1CE5E2AB2C0; Fri, 5 Sep 2014 21:55:46 +0000 (UTC) Date: Fri, 5 Sep 2014 21:55:46 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140905215545.GA26920@mournblade.imrryr.org> References: <20140904202137.GD26920@mournblade.imrryr.org> <20140904210017.09E4D1E6A231@rock.dv.isc.org> <20140904213730.GE26920@mournblade.imrryr.org> <20140904230533.ED33E1E6D2FC@rock.dv.isc.org> <20140905151149.GO26920@mournblade.imrryr.org> <20140905213934.E12C61E806B5@rock.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140905213934.E12C61E806B5@rock.dv.isc.org> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/M7fzLBBLqfo_6pvcQhlIpqruoDE Subject: Re: [dane] DNSSEC debug advice (TLSA lookup problem). 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, 05 Sep 2014 21:55:50 -0000 On Sat, Sep 06, 2014 at 07:39:34AM +1000, Mark Andrews wrote: > The problem is the wildcard and the broken wildcard processing, not > the CNAME. The rcode is wrong as a result, NOERROR != NXDOMAIN. Yes, that's it, as I eventually also figured out... > Alternatively adding a non TLSA records at the expected TLSA names > should work as it should prevent the attempted wilcard lookup in > the server and the resulting mis-match. > > _tlsa._tcp.mail.clarion-hotels.cz TXT "-" > _tlsa._tcp.mail2.clarion-hotels.cz TXT "-" Right, indeed: _25._tcp.mail.clarion-hotels.cz IN TXT "No TLSA RRs here yet" _25._tcp.mail2.clarion-hotels.cz IN TXT "No TLSA RRs here yet" should do the job. Thanks, I'll suggest this to them as a better interim solution. -- Viktor. From nobody Mon Sep 8 06:38: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 6A3771A87E3 for ; Mon, 8 Sep 2014 06:38:16 -0700 (PDT) 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 iHicB_bjqT6s for ; Mon, 8 Sep 2014 06:38:14 -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 F13F91A87D1 for ; Mon, 8 Sep 2014 06:38:13 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 69E0F2AB2D3; Mon, 8 Sep 2014 13:38:12 +0000 (UTC) Date: Mon, 8 Sep 2014 13:38:12 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140908133812.GW26920@mournblade.imrryr.org> References: <20140904202137.GD26920@mournblade.imrryr.org> <20140904210017.09E4D1E6A231@rock.dv.isc.org> <20140904213730.GE26920@mournblade.imrryr.org> <20140904230533.ED33E1E6D2FC@rock.dv.isc.org> <20140905151149.GO26920@mournblade.imrryr.org> <20140905213934.E12C61E806B5@rock.dv.isc.org> <20140905215545.GA26920@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140905215545.GA26920@mournblade.imrryr.org> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/Jlcv8FGtJdji46oU6EwB6ai1C14 Subject: Re: [dane] DNSSEC debug advice (TLSA lookup problem). 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, 08 Sep 2014 13:38:16 -0000 On Fri, Sep 05, 2014 at 09:55:45PM +0000, Viktor Dukhovni wrote: > On Sat, Sep 06, 2014 at 07:39:34AM +1000, Mark Andrews wrote: > > > The problem is the wildcard and the broken wildcard processing, not > > the CNAME. The rcode is wrong as a result, NOERROR != NXDOMAIN. > > Yes, that's it, as I eventually also figured out... The DNS server in question is djbdns. Corrected wildcard processing may be available at , but I've not tested that software or looked at it in any detail beyond the claim in the list of improvements that the issue is resolved: The interpretation of wildcard records now matches the description in RFC-1034 section 4.3.3. Specifically, if there's a wildcard *.x and a record for a.x, then a query for y.a.x will not be answered using the wildcard (for a label 'a' and series of labels 'x' and 'y'). This change is required for signed domains, because authentication of negative responses requires a common understanding between client and server about the meaning of wildcards. There is an important note about running that software as a secondary: Be careful with publishing signed zones as a secondary nameserver: the modified tinydns/axfrdns require certain helper RRs in the database to simplify locating NSEC3 records. Without these helpers, tinydns cannot generate valid negative response nor valid wildcard responses. -- Viktor. From nobody Mon Sep 8 06:53: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 608491A8830 for ; Mon, 8 Sep 2014 06:53:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NZmKh3p92V4u for ; Mon, 8 Sep 2014 06:52:59 -0700 (PDT) Received: from exprod6og118.obsmtp.com (exprod6og118.obsmtp.com [64.18.1.233]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 356201A8831 for ; Mon, 8 Sep 2014 06:52:58 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob118.postini.com ([64.18.5.12]) with SMTP ID DSNKVA20uRl7IyNx/MkfpFhYakrqQI3Q84DI@postini.com; Mon, 08 Sep 2014 06:52:58 PDT Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id s88Dqvx4006074 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 8 Sep 2014 09:52:57 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Mon, 8 Sep 2014 09:52:56 -0400 From: "Osterweil, Eric" To: "Rose, Scott" Thread-Topic: [dane] Enterprise email security reqs breakdown: REQ7 (signing/encryption certs) Thread-Index: AQHPx6Gv/dJnikS3MEKt0CG6PuebyZv3jD+A Date: Mon, 8 Sep 2014 13:52:56 +0000 Message-ID: <8742EF43-2504-4AB9-9E38-03C20613DA18@verisign.com> References: <4ED17ED7-C9CC-40D8-A9B8-F46860A1D831@nist.gov> In-Reply-To: <4ED17ED7-C9CC-40D8-A9B8-F46860A1D831@nist.gov> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: multipart/signed; boundary="Apple-Mail=_0B133A8B-F5C5-4469-BFE6-E4C239BCAECD"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/m-bD2ueQEHEDk_IUXnslro8IbIQ Cc: dane WG list Subject: Re: [dane] Enterprise email security reqs breakdown: REQ7 (signing/encryption certs) 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, 08 Sep 2014 13:53:00 -0000 --Apple-Mail=_0B133A8B-F5C5-4469-BFE6-E4C239BCAECD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Sep 3, 2014, at 2:05 PM, "Rose, Scott" wrote: > Questions: >=20 > 1. is this requirement reasonable? =20 I believe it is. > 2. (if reasonable): Is the strawman text adequate? Should another = method be used other than a naming convention such as a different RRTYPE = or usage field? We have found this quite useful in our coding, fwiw. Eric= --Apple-Mail=_0B133A8B-F5C5-4469-BFE6-E4C239BCAECD Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN7DCCBmAw ggVIoAMCAQICEHaFyweo4MwP0sVNjzk1sxIwDQYJKoZIhvcNAQEFBQAwgcoxCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ug b25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMiBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eSAtIEczMB4XDTExMDYwNzAwMDAwMFoXDTIxMDYwNjIzNTk1OVowgckxCzAJ BgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50 ZWMgVHJ1c3QgTmV0d29yazE1MDMGA1UECxMsQ2xhc3MgMiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0ExQzBBBgNVBAMTOlN5bWFudGVjIENsYXNzIDIgU2hhcmVkIEludGVybWVk aWF0ZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQC3+D8MK4MjIIWmTUkBUTra3VAzvuMEpDo+o2FmTDTC6HRwdUmlt0ns3bOSnN15DeK5+rg5PL6F 44zvbXmjprcIv5xMvj6YjqzbfJor7AUoMF8pGzNNRNVw6FYimaY+nUJb6yOnY50tLLAuPxjzKc0a NomEksdXcFtwheY4oXxQ4zc4iGVba8s5KgSxgqoZBP+gfz+j25FFdmaja/OFI15O2YVddaegFffB AHTg5cqUQmWawjd6i6hQrL+XdGd30TKnr43Lk6klQrQwGnQK4iUQEMt0Z1UPyxT8QVAKpHxNCwv5 Bak1+UWnMfGAu6LJPs52OeEq/3ZQ5+hRIt8tz7gzAgMBAAGjggI/MIICOzASBgNVHRMBAf8ECDAG AQH/AgEAMDQGA1UdHwQtMCswKaAnoCWGI2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTItZzMu Y3JsMA4GA1UdDwEB/wQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRVmVyaVNpZ25NUEtJ LTItNTYwHQYDVR0OBBYEFNhIKahfKheS4vqee+9vYIP4uLjcMIHwBgNVHSMEgegwgeWhgdCkgc0w gcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3Ig YXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMiBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczghBhcMtJjF+YRSnnsKbZUFt6MDQGCCsG AQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AudmVyaXNpZ24uY29tMGwGA1UdIARl MGMwYQYLYIZIAYb4RQEHFwIwUjAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9j cHMwKAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9ycGEwDQYJKoZIhvcNAQEF BQADggEBAKYqmwdAyez/s4joRdo00RcPKC23pYVnMc3B5tUphjis4vBZGwzhoUXOJHjvacGwTGGi SNloT7r+dVQ3ulhp6sF2pTZC6p5meJAg2ZVqJHlUzd5aGoo7rhiVctAl2NJGvjQwp4Ce8VbOIB5s Z8lNT3mHieIugNae7SZhZaID0MXi8yi5K0lpgmfs1ek0pC7cYiKkhU1I42oClPLN/eRnyEm8qtXH 5zzeh7EQa10HXBnka6D0T5nL3LVbDMwy+WrkdMAqWDd5s/vNwzRv4XbdEAcAY4sHTicXkkebDr7e DROFEfyiL2V9zDqsHlRrVmfE7qWHIiMXK3BWw/Gud1wnwTkwggeEMIIGbKADAgECAhBcCMgDVFpl hwRR0TZyMUgoMA0GCSqGSIb3DQEBBQUAMIHJMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50 ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxNTAzBgNVBAsT LENsYXNzIDIgTWFuYWdlZCBQS0kgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBMUMwQQYDVQQDEzpT eW1hbnRlYyBDbGFzcyAyIFNoYXJlZCBJbnRlcm1lZGlhdGUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5 MB4XDTE0MDQxMDAwMDAwMFoXDTE1MDQxMDIzNTk1OVowczEmMCQGCSqGSIb3DQEJARYXZW9zdGVy d2VpbEB2ZXJpc2lnbi5jb20xGDAWBgNVBAMMD09zdGVyd2VpbCwgRXJpYzEWMBQGA1UECwwNRU5U RVJQUklTRSBJVDEXMBUGA1UECgwOVmVyaVNpZ24sIEluYy4wggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQCmK2/yLaprGu39usXztz6N7uLYDoKN4MNaDFGGj1eYfMkIfb6LDoYBs9qcnINg 8in4NxGwVQGIJU5AE/1wHe/V1qavpHEO2mVxRq94cBF0P8ETPpM1yhwBhU4QKhjNEDj9wov8RXzO hjqPy/uknZvBxfobQx22vhnEKpf7QEN0zfLDJON3tyYwsnrFZkmop4ni4ANI7ev5uqcI05ED7vSh K9AHAVjzjr2QvtmvqHAkOnpHgqkWJWhuw4f9Gx+8LmbC3tl8oxF7+E7WEwKTQG56BV0uR6PN/o0S O7VSbDCZyNoxxrjzw+CesWsigi2NvC5DnhkKlxP+JSfJxMDu+7MDAgMBAAGjggO7MIIDtzAMBgNV HRMBAf8EAjAAMA4GA1UdDwEB/wQEAwIFoDAWBgNVHSUBAf8EDDAKBggrBgEFBQcDBDAdBgNVHQ4E FgQUVoVKaC1xEPB9EWKq3dWrwskIufkwUAYDVR0RBEkwR4EXZW9zdGVyd2VpbEB2ZXJpc2lnbi5j b22gLAYKKwYBBAGCNxQCA6AeDBxlb3N0ZXJ3ZWlsQHZjb3JwLmFkLnZyc24uY29tMB8GA1UdIwQY MBaAFNhIKahfKheS4vqee+9vYIP4uLjcMIIBcQYIKwYBBQUHAQEEggFjMIIBXzAnBggrBgEFBQcw AYYbaHR0cDovL3BraS1vY3NwLnN5bWF1dGguY29tMIIBMgYIKwYBBQUHMAKGggEkbGRhcDovL2Rp cmVjdG9yeS52ZXJpc2lnbi5jb20vQ04lMjAlM0QlMjBTeW1hbnRlYyUyMENsYXNzJTIwMiUyMFNo YXJlZCUyMEludGVybWVkaWF0ZSUyMENlcnRpZmljYXRlJTIwQXV0aG9yaXR5JTJDT1UlMjAlM0Ql MjBDbGFzcyUyMDIlMjBNYW5hZ2VkJTIwUEtJJTIwSW5kaXZpZHVhbCUyMFN1YnNjcmliZXIlMjBD QSUyQ09VJTIwJTNEJTIwU3ltYW50ZWMlMjBUcnVzdCUyME5ldHdvcmslMkNPJTIwJTNEJTIwU3lt YW50ZWMlMjBDb3Jwb3JhdGlvbiUyQ0MlMjAlM0QlMjBVUz9jQUNlcnRpZmljYXRlO2JpbmFyeTBd BgNVHR8EVjBUMFKgUKBOhkxodHRwOi8vcGtpLWNybC5zeW1hdXRoLmNvbS9jYV8wN2JiN2Q2NDc3 Y2Y0ZjZiZTk2YWYxYjM2Y2FiZDMxNi9MYXRlc3RDUkwuY3JsMGwGA1UdIARlMGMwYQYLYIZIAYb4 RQEHFwIwUjAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9jcHMwKAYIKwYBBQUH AgIwHBoaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9ycGEwQgYJKoZIhvcNAQkPBDUwMzAKBggqhkiG 9w0DBzALBglghkgBZQMEAQIwCwYJYIZIAWUDBAEWMAsGCWCGSAFlAwQBKjAsBgpghkgBhvhFARAD BB4wHAYSYIZIAYb4RQEQAQICAQGL8cYJFgYyNDc2NjQwOQYKYIZIAYb4RQEQBQQrMCkCAQAWJGFI UjBjSE02THk5d2Eya3RjbUV1YzNsdFlYVjBhQzVqYjIwPTANBgkqhkiG9w0BAQUFAAOCAQEAXFTS ZEP9la6QYPlo6ybMEEpxVOADx082WRGtrYoU9ZEaC2IlxmwI9JprNfBlIy8FtyJAuWKBbe9/XKJF cukb2HNS0httHUIcSTfMEsAyc99/ba/SoMlhtvko/nCvx5brzhpQwop6AgMv9v5V7F1GUFO7db8L LSs1gIZYI8IeudznJOQGUBFGe0aJhA4cD/3OIZyItWpNtn94i1GJUFPMjYhGcy/r0fUQY/KFLwOi M6bT/m1RwAJKJI/mON/OshdzylAYqKOPoFTJD4qrbrpij1r1+e1VHKklAxTd+nOg9J1L0yRwlEDS 1boeOxqNXGnEYAa54k0ZWPh+8dFemteaLjGCBE0wggRJAgEBMIHeMIHJMQswCQYDVQQGEwJVUzEd MBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5l dHdvcmsxNTAzBgNVBAsTLENsYXNzIDIgTWFuYWdlZCBQS0kgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBMUMwQQYDVQQDEzpTeW1hbnRlYyBDbGFzcyAyIFNoYXJlZCBJbnRlcm1lZGlhdGUgQ2VydGlm aWNhdGUgQXV0aG9yaXR5AhBcCMgDVFplhwRR0TZyMUgoMAkGBSsOAwIaBQCgggJDMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE0MDkwODEzNTMxMVowIwYJKoZIhvcN AQkEMRYEFIE8ItQQ9gT9q4HS3omyM3T1cvcoMIHvBgkrBgEEAYI3EAQxgeEwgd4wgckxCzAJBgNV BAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMg VHJ1c3QgTmV0d29yazE1MDMGA1UECxMsQ2xhc3MgMiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFsIFN1 YnNjcmliZXIgQ0ExQzBBBgNVBAMTOlN5bWFudGVjIENsYXNzIDIgU2hhcmVkIEludGVybWVkaWF0 ZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkCEFwIyANUWmWHBFHRNnIxSCgwgfEGCyqGSIb3DQEJEAIL MYHhoIHeMIHJMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAd BgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxNTAzBgNVBAsTLENsYXNzIDIgTWFuYWdlZCBQ S0kgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBMUMwQQYDVQQDEzpTeW1hbnRlYyBDbGFzcyAyIFNo YXJlZCBJbnRlcm1lZGlhdGUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5AhBcCMgDVFplhwRR0TZyMUgo MA0GCSqGSIb3DQEBAQUABIIBAGsFWbMaLbMDv4BQp/hgCWozzTpVcDPitCbk7voivIAYeHc9eQPO A8rQOsQ49yBegxisi+RlMb9Qj5U+DNKo99r/6o+q3rgTNkTLE+6iY+Oo2hXD+ZdscvAleD4j/PAz 4sa094nNh2YekojDrwDmY+NyHcX+HT5hVE6Hh5YuWeW9lUAzWsyhHkDNXrw2z+rV8NWv55ltjXkd xexXF8nUGc0P2Zi5zqdOPtuw5R3eILO6QnzMM3INpQjAGZJoF3Z1/h83qoIVo3OjITKWw1ZVdj9h ebaZOebCe5oDl4NX2WYmrH+KYRg7NAIpfYNRmUH27uajLkxdbyWR+vJ7c2KVVSUAAAAAAAA= --Apple-Mail=_0B133A8B-F5C5-4469-BFE6-E4C239BCAECD-- From nobody Fri Sep 26 17:52: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 405A41A008D for ; Fri, 26 Sep 2014 17:52:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.722 X-Spam-Level: X-Spam-Status: No, score=0.722 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 HMkKmIiDvP11 for ; Fri, 26 Sep 2014 17:52:15 -0700 (PDT) Received: from mail-oi0-f45.google.com (mail-oi0-f45.google.com [209.85.218.45]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 417081A0085 for ; Fri, 26 Sep 2014 17:52:15 -0700 (PDT) Received: by mail-oi0-f45.google.com with SMTP id i138so2472892oig.4 for ; Fri, 26 Sep 2014 17:52:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=HmyUnjr8CaoEyiynV76fXpavfPw3wF69lbHm9JfHAHU=; b=UDd9Cl6DE1R4EkIaZzbZPjlsUleVuU4VBVkjSYEb25xz0aJCJU5LXVQ5u9STTsvIg0 /1i17xN+E5RZCkIDn/4NJ67W1HN+E7vZIcW2UsU02fLn46xEh+ahvnwqJLXnQ3kO8ADM WNZyu/HouGl4ndWf+UR9hzw9v6rhZmbtMBLLj2rs/RMU0wiX025y4GqIxH/DlzSec8qL MACz/rTvUdTjYbnz3NtUQejy7cWjt4NsELi+L9eEggRwczMLL1qpMVX5BsPmm/aAKfu/ bII/DDGJOJi+jz/P56Bf2TZ99+Ce7bmkO1YnVekjzeyS/iwJDJ9Fv28/ghTS59TtNlze Mi4Q== X-Gm-Message-State: ALoCoQlYZN4mcugMGRVVVutnx44kiWL3ztlLJYSWxdRuYroFRbpea50KnDVsmoAbXXrnOfYSV7lq MIME-Version: 1.0 X-Received: by 10.182.56.193 with SMTP id c1mr25614342obq.4.1411779134492; Fri, 26 Sep 2014 17:52:14 -0700 (PDT) Received: by 10.202.223.86 with HTTP; Fri, 26 Sep 2014 17:52:14 -0700 (PDT) Date: Fri, 26 Sep 2014 20:52:14 -0400 Message-ID: From: Warren Kumari To: "" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/2Af299Gj_FZf4RhgYlm7VOauAhQ Subject: [dane] Meeting in Hawaii? 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, 27 Sep 2014 00:52:17 -0000 Dear DANE, We have requested a 2 hour slot for Hawaii, however, we have not seen much activity since Toronto, and so are thinking of handing the time back. Please let us know if you'd really like to meet, and open issues on documents that need discussing. Also, if you have a doc, we'd like it revised *soon*. Remember, IETF meeting time is a precious resource. 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 Mon Sep 29 04:44: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 C99091A1A2C for ; Mon, 29 Sep 2014 04:44:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.302 X-Spam-Level: X-Spam-Status: No, score=-2.302 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k3S-PBr_3bCP for ; Mon, 29 Sep 2014 04:44:34 -0700 (PDT) Received: from exprod6og114.obsmtp.com (exprod6og114.obsmtp.com [64.18.1.33]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 045051A039D for ; Mon, 29 Sep 2014 04:44:33 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob114.postini.com ([64.18.5.12]) with SMTP ID DSNKVClGIV+8JwKosq9bT+3uce2AxNvQMmfF@postini.com; Mon, 29 Sep 2014 04:44:34 PDT Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02.vcorp.ad.vrsn.com [10.173.152.206]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id s8TBiWun003970 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 29 Sep 2014 07:44:32 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Mon, 29 Sep 2014 07:44:32 -0400 From: "Osterweil, Eric" To: dane WG list Thread-Topic: SMIMEA prototyping Thread-Index: AQHP29q7Y0Wg27e53U2QPZq9K7XNoA== Date: Mon, 29 Sep 2014 11:44:31 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: multipart/signed; boundary="Apple-Mail=_0B32CCC7-3FC0-4A05-9FF2-5F74089CE7B5"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/wj0rcpirR9KGOJak6ScFLntTJAk Subject: [dane] SMIMEA prototyping 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, 29 Sep 2014 11:44:36 -0000 --Apple-Mail=_0B32CCC7-3FC0-4A05-9FF2-5F74089CE7B5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hey everyone, A few of us at Verisign (actually, that would be Lynch Davis) have been = working on a prototype for the SMIMEA draft. We have written a general = library+API, we have integrated it into Thunderbird, and have begun = integrating into Mail.app. Our plans are to publish this as open source = at some point after the DANE workshop that will be taking place at ICANN = 51 (where we will be demo'ing it). We ran into numerous interesting = wrinkles and made some specific design choices, but at a high level the = S/MIME prototype: - can sign - can encrypt - can decrypt (without writing clear text to disk) - can verify - and supports several features that are enabled through suggested = additions. With the foresight that zones may need to be delegated to accommodate = churn and scale, some certificates may need to be selectively = authenticated or deauthenticated (perhaps on a per-user basis), and the = locations of certificate information may need to be managed in different = places (some in the DNS, some in external locations), etc. we have made = some operational choices to modify elements of the draft in our = prototype. We intend to detail these in a follow-on email. We're hoping to show this off at the upcoming IETF too. Eric --Apple-Mail=_0B32CCC7-3FC0-4A05-9FF2-5F74089CE7B5 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN7DCCBmAw ggVIoAMCAQICEHaFyweo4MwP0sVNjzk1sxIwDQYJKoZIhvcNAQEFBQAwgcoxCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ug b25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMiBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eSAtIEczMB4XDTExMDYwNzAwMDAwMFoXDTIxMDYwNjIzNTk1OVowgckxCzAJ BgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50 ZWMgVHJ1c3QgTmV0d29yazE1MDMGA1UECxMsQ2xhc3MgMiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0ExQzBBBgNVBAMTOlN5bWFudGVjIENsYXNzIDIgU2hhcmVkIEludGVybWVk aWF0ZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQC3+D8MK4MjIIWmTUkBUTra3VAzvuMEpDo+o2FmTDTC6HRwdUmlt0ns3bOSnN15DeK5+rg5PL6F 44zvbXmjprcIv5xMvj6YjqzbfJor7AUoMF8pGzNNRNVw6FYimaY+nUJb6yOnY50tLLAuPxjzKc0a NomEksdXcFtwheY4oXxQ4zc4iGVba8s5KgSxgqoZBP+gfz+j25FFdmaja/OFI15O2YVddaegFffB AHTg5cqUQmWawjd6i6hQrL+XdGd30TKnr43Lk6klQrQwGnQK4iUQEMt0Z1UPyxT8QVAKpHxNCwv5 Bak1+UWnMfGAu6LJPs52OeEq/3ZQ5+hRIt8tz7gzAgMBAAGjggI/MIICOzASBgNVHRMBAf8ECDAG AQH/AgEAMDQGA1UdHwQtMCswKaAnoCWGI2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTItZzMu Y3JsMA4GA1UdDwEB/wQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRVmVyaVNpZ25NUEtJ LTItNTYwHQYDVR0OBBYEFNhIKahfKheS4vqee+9vYIP4uLjcMIHwBgNVHSMEgegwgeWhgdCkgc0w gcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3Ig YXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMiBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczghBhcMtJjF+YRSnnsKbZUFt6MDQGCCsG AQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AudmVyaXNpZ24uY29tMGwGA1UdIARl MGMwYQYLYIZIAYb4RQEHFwIwUjAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9j cHMwKAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9ycGEwDQYJKoZIhvcNAQEF BQADggEBAKYqmwdAyez/s4joRdo00RcPKC23pYVnMc3B5tUphjis4vBZGwzhoUXOJHjvacGwTGGi SNloT7r+dVQ3ulhp6sF2pTZC6p5meJAg2ZVqJHlUzd5aGoo7rhiVctAl2NJGvjQwp4Ce8VbOIB5s Z8lNT3mHieIugNae7SZhZaID0MXi8yi5K0lpgmfs1ek0pC7cYiKkhU1I42oClPLN/eRnyEm8qtXH 5zzeh7EQa10HXBnka6D0T5nL3LVbDMwy+WrkdMAqWDd5s/vNwzRv4XbdEAcAY4sHTicXkkebDr7e DROFEfyiL2V9zDqsHlRrVmfE7qWHIiMXK3BWw/Gud1wnwTkwggeEMIIGbKADAgECAhBcCMgDVFpl hwRR0TZyMUgoMA0GCSqGSIb3DQEBBQUAMIHJMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50 ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxNTAzBgNVBAsT LENsYXNzIDIgTWFuYWdlZCBQS0kgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBMUMwQQYDVQQDEzpT eW1hbnRlYyBDbGFzcyAyIFNoYXJlZCBJbnRlcm1lZGlhdGUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5 MB4XDTE0MDQxMDAwMDAwMFoXDTE1MDQxMDIzNTk1OVowczEmMCQGCSqGSIb3DQEJARYXZW9zdGVy d2VpbEB2ZXJpc2lnbi5jb20xGDAWBgNVBAMMD09zdGVyd2VpbCwgRXJpYzEWMBQGA1UECwwNRU5U RVJQUklTRSBJVDEXMBUGA1UECgwOVmVyaVNpZ24sIEluYy4wggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQCmK2/yLaprGu39usXztz6N7uLYDoKN4MNaDFGGj1eYfMkIfb6LDoYBs9qcnINg 8in4NxGwVQGIJU5AE/1wHe/V1qavpHEO2mVxRq94cBF0P8ETPpM1yhwBhU4QKhjNEDj9wov8RXzO hjqPy/uknZvBxfobQx22vhnEKpf7QEN0zfLDJON3tyYwsnrFZkmop4ni4ANI7ev5uqcI05ED7vSh K9AHAVjzjr2QvtmvqHAkOnpHgqkWJWhuw4f9Gx+8LmbC3tl8oxF7+E7WEwKTQG56BV0uR6PN/o0S O7VSbDCZyNoxxrjzw+CesWsigi2NvC5DnhkKlxP+JSfJxMDu+7MDAgMBAAGjggO7MIIDtzAMBgNV HRMBAf8EAjAAMA4GA1UdDwEB/wQEAwIFoDAWBgNVHSUBAf8EDDAKBggrBgEFBQcDBDAdBgNVHQ4E FgQUVoVKaC1xEPB9EWKq3dWrwskIufkwUAYDVR0RBEkwR4EXZW9zdGVyd2VpbEB2ZXJpc2lnbi5j b22gLAYKKwYBBAGCNxQCA6AeDBxlb3N0ZXJ3ZWlsQHZjb3JwLmFkLnZyc24uY29tMB8GA1UdIwQY MBaAFNhIKahfKheS4vqee+9vYIP4uLjcMIIBcQYIKwYBBQUHAQEEggFjMIIBXzAnBggrBgEFBQcw AYYbaHR0cDovL3BraS1vY3NwLnN5bWF1dGguY29tMIIBMgYIKwYBBQUHMAKGggEkbGRhcDovL2Rp cmVjdG9yeS52ZXJpc2lnbi5jb20vQ04lMjAlM0QlMjBTeW1hbnRlYyUyMENsYXNzJTIwMiUyMFNo YXJlZCUyMEludGVybWVkaWF0ZSUyMENlcnRpZmljYXRlJTIwQXV0aG9yaXR5JTJDT1UlMjAlM0Ql MjBDbGFzcyUyMDIlMjBNYW5hZ2VkJTIwUEtJJTIwSW5kaXZpZHVhbCUyMFN1YnNjcmliZXIlMjBD QSUyQ09VJTIwJTNEJTIwU3ltYW50ZWMlMjBUcnVzdCUyME5ldHdvcmslMkNPJTIwJTNEJTIwU3lt YW50ZWMlMjBDb3Jwb3JhdGlvbiUyQ0MlMjAlM0QlMjBVUz9jQUNlcnRpZmljYXRlO2JpbmFyeTBd BgNVHR8EVjBUMFKgUKBOhkxodHRwOi8vcGtpLWNybC5zeW1hdXRoLmNvbS9jYV8wN2JiN2Q2NDc3 Y2Y0ZjZiZTk2YWYxYjM2Y2FiZDMxNi9MYXRlc3RDUkwuY3JsMGwGA1UdIARlMGMwYQYLYIZIAYb4 RQEHFwIwUjAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9jcHMwKAYIKwYBBQUH AgIwHBoaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9ycGEwQgYJKoZIhvcNAQkPBDUwMzAKBggqhkiG 9w0DBzALBglghkgBZQMEAQIwCwYJYIZIAWUDBAEWMAsGCWCGSAFlAwQBKjAsBgpghkgBhvhFARAD BB4wHAYSYIZIAYb4RQEQAQICAQGL8cYJFgYyNDc2NjQwOQYKYIZIAYb4RQEQBQQrMCkCAQAWJGFI UjBjSE02THk5d2Eya3RjbUV1YzNsdFlYVjBhQzVqYjIwPTANBgkqhkiG9w0BAQUFAAOCAQEAXFTS ZEP9la6QYPlo6ybMEEpxVOADx082WRGtrYoU9ZEaC2IlxmwI9JprNfBlIy8FtyJAuWKBbe9/XKJF cukb2HNS0httHUIcSTfMEsAyc99/ba/SoMlhtvko/nCvx5brzhpQwop6AgMv9v5V7F1GUFO7db8L LSs1gIZYI8IeudznJOQGUBFGe0aJhA4cD/3OIZyItWpNtn94i1GJUFPMjYhGcy/r0fUQY/KFLwOi M6bT/m1RwAJKJI/mON/OshdzylAYqKOPoFTJD4qrbrpij1r1+e1VHKklAxTd+nOg9J1L0yRwlEDS 1boeOxqNXGnEYAa54k0ZWPh+8dFemteaLjGCBE0wggRJAgEBMIHeMIHJMQswCQYDVQQGEwJVUzEd MBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5l dHdvcmsxNTAzBgNVBAsTLENsYXNzIDIgTWFuYWdlZCBQS0kgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBMUMwQQYDVQQDEzpTeW1hbnRlYyBDbGFzcyAyIFNoYXJlZCBJbnRlcm1lZGlhdGUgQ2VydGlm aWNhdGUgQXV0aG9yaXR5AhBcCMgDVFplhwRR0TZyMUgoMAkGBSsOAwIaBQCgggJDMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE0MDkyOTExNDQ0OVowIwYJKoZIhvcN AQkEMRYEFKquHEkduyuLeHOBW2F5afDGGyP7MIHvBgkrBgEEAYI3EAQxgeEwgd4wgckxCzAJBgNV BAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMg VHJ1c3QgTmV0d29yazE1MDMGA1UECxMsQ2xhc3MgMiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFsIFN1 YnNjcmliZXIgQ0ExQzBBBgNVBAMTOlN5bWFudGVjIENsYXNzIDIgU2hhcmVkIEludGVybWVkaWF0 ZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkCEFwIyANUWmWHBFHRNnIxSCgwgfEGCyqGSIb3DQEJEAIL MYHhoIHeMIHJMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAd BgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxNTAzBgNVBAsTLENsYXNzIDIgTWFuYWdlZCBQ S0kgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBMUMwQQYDVQQDEzpTeW1hbnRlYyBDbGFzcyAyIFNo YXJlZCBJbnRlcm1lZGlhdGUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5AhBcCMgDVFplhwRR0TZyMUgo MA0GCSqGSIb3DQEBAQUABIIBABebXztuf+VRQWlYQSFhJntZl+6FTapIQHeOGgtIV9f4xeVM4nRo WYOg9HNYE1xLlsWXEnYOaSLPLITyQ+Xh7R/r+PhQtzLocM0b+8hiyG9pv4FppYUxBE0PyaXOZef+ gUjMnJHdJohTk5AGPemBWXXOtsfkGoVLfqageQHQ/hbb611fuqLe7BZ5slmG4YCYxuzeA8A6PkQG vlDo8BT7wLhKQQQ2TO3NXv1sAOeUV/ggD1lvnkDtpt9I0ZdaaVw4H9pfAlh5NQ7VcSLcenOjgfzx xZq4vU+/8GxIFZGRTeoN6SnWjkJAyi0F8lFQtRzawp26cG08PYidM5yAbdDp088AAAAAAAA= --Apple-Mail=_0B32CCC7-3FC0-4A05-9FF2-5F74089CE7B5-- From nobody Mon Sep 29 05:26: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 CDB311A3B9E for ; Mon, 29 Sep 2014 05:26:34 -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 jERXG0LEJLX6 for ; Mon, 29 Sep 2014 05:26:31 -0700 (PDT) Received: from exprod6og121.obsmtp.com (exprod6og121.obsmtp.com [64.18.1.237]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24F0D1A3BA0 for ; Mon, 29 Sep 2014 05:26:31 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob121.postini.com ([64.18.5.12]) with SMTP ID DSNKVClP9gNluIXOSk0/in00wPPYOeMZZPFd@postini.com; Mon, 29 Sep 2014 05:26:31 PDT Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01.vcorp.ad.vrsn.com [10.173.152.255]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id s8TCQTSI005425 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 29 Sep 2014 08:26:30 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Mon, 29 Sep 2014 08:26:27 -0400 From: "Osterweil, Eric" To: dane WG list Thread-Topic: draft-ietf-dane-smime Thread-Index: AQHP2+CXduy9obN06UaH3lWvHXXI5Q== Date: Mon, 29 Sep 2014 12:26:28 +0000 Message-ID: <273F9612-13AF-4CB8-B15C-912AAD04C738@verisign.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: multipart/signed; boundary="Apple-Mail=_AB9CA192-AF13-43FB-B065-882640B2FB1C"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/OFdHo3mp91yHZdBclpVEuZhUMQc Subject: [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: Mon, 29 Sep 2014 12:26:35 -0000 --Apple-Mail=_AB9CA192-AF13-43FB-B065-882640B2FB1C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hey everyone, Based on our implementation experience we would like to suggest that the = following text (taken from Scott Rose's email: = http://www.ietf.org/mail-archive/web/dane/current/msg06180.html ) be = incorporated into the current version of the draft-ietf-dane-smime = document. We are sending text (below), but at a high-level, the text = outlines a few useful additions: 1 - Usage #4 (reject) is likely to be very important. This could either = emphasize the difference between saying, ``don't use this cert for this = operation,'' and ``this cert is universally revoked'' or be used to = selectively override an organization-wide TA for certain employees that = have left the organization. 2 - The certificate access field (Section 2.1.4) would enable alternate = discovery mechanisms that could help aid incremental deployment and = transition schemes. For example, while cutting over to a DANE solution, = some enterprises may want to transition users from (say) AD to DANE, and = this field would enable that. 3 - The ``_encr'' and ``_sign'' labels are excellent additions to the = management of zone sizes and lookup sizes. Rather than querying for all = keys and then locally selecting from them, I (as an RP) likely already = know which of these I want, and I should be able to look them up = separately in DANE (and owners should be able to manage them separately = in DANE). If anyone objects, please let us know. Thanks, Eric ------- ... 2.1. SMIMEA RDATA Fields The RDATA for the SMIMEA RR consists of a one-octet certificate usage field, a one-octet selector field, a one-octet matching type field, a one-octet certificate access field, and the certificate association data field. 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cert. Usage | Selector | Matching Type | Cert. Access | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / / / Certificate Association Data / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2.1.1. The Certificate Usage Field A one-octet value, called "certificate usage", specifies the provided association that will be used to validate the certificate. This value will be defined in a new IANA registry in order to make it easier to add additional certificate usages in the future. Four of the initial usages defined in this document are similar to the first four TLSA [RFC6698] certificate usages. The certificate usage values are: 0 or PKIX-CA -- PKIX-CA is used to specify a CA certificate, or the public key of such a certificate, that MUST be found in any of the PKIX certification paths for the user. This certificate usage is sometimes referred to as "CA constraint" because it limits which CA can be used to issue certificates for a given user. The presented certificate MUST pass PKIX certification path validation, and a CA certificate that matches the SMIMEA record MUST be included as part of a valid certification path. Because this certificate usage allows both trust anchors and CA certificates, the certificate might or might not have the basicConstraints extension present. 1 or PKIX-EE -- PKIX-EE is used to specify an end entity certificate, or the public key of such a certificate, that MUST be matched with the end entity certificate for the SMIME user. This certificate usage is sometimes referred to as "user certificate constraint" because it limits which end entity certificate can be used by a given user. The target user certificate MUST pass PKIX certification path validation and MUST match the SMIMEA record. 2 or DANE-TA -- DANE-TA is used to specify a certificate, or the public key of such a certificate, that MUST be used as the trust anchor when validating the SMIME user certificate. This certificate usage is sometimes referred to as "trust anchor assertion" and allows a domain name administrator to specify a new trust anchor -- for example, if the domain issues its own certificates under its own CA that is not expected to be in the end users' collection of trust anchors. The target user certificate MUST pass PKIX certification path validation, with any certificate matching the SMIMEA record considered to be a trust anchor for this certification path validation. 3 or DANE-EE -- DANE-EE is used to specify a certificate, or the public key of such a certificate, that MUST match the SMIME user's certificate. This certificate usage is sometimes referred to as "domain-issued certificate" because it allows for a domain name administrator to issue certificates for a domain without involving a third-party CA. The target user certificate MUST match the SMIMEA record. The difference between certificate usage 1 and certificate usage 3 is that certificate usage 1 requires that the certificate pass PKIX validation, but PKIX validation is not tested for certificate usage 3. 4 or REJECT -- REJECT is used by the domain owner to assert that this user's certificate MUST be considered invalid for the requested function (i.e. signature or encryption). This is a stronger assertion than a failed certificate validation check. Possible usage scenarios include unrecognized user names and revoked user certificates. Values in all other RDATA fields MAY be ignored but all fields MUST be populated to comply with SMIMEA RDATA parsing requirements. The certificate usages defined in this document explicitly only apply to PKIX-formatted certificates in DER encoding [ITU.X690.2002]. If SMIME allows other formats later, or if extensions to this RR type are made that accept other formats for certificates, those certificates will need their own certificate usage values. 2.1.2. The Selector Field A one-octet value, called "selector", specifies which part of the SMIME certificate presented by the server will be matched against the association data. This value will be defined in a new IANA registry. The selectors defined in this document are: 0 or CERT -- Full certificate: the Certificate binary structure as defined in [RFC5280]. 1 or SPKI -- SubjectPublicKeyInfo: DER-encoded binary structure as defined in [RFC5280]. (Note that the use of "selector" in this document is completely unrelated to the use of "selector" in DomainKeys Identified Mail (DKIM) [RFC6376].) 2.1.3. The Matching Type Field A one-octet value, called "matching type", specifies how the certificate association is presented. This value will be defined in a new IANA registry. The types defined in this document are: 0 or Full -- Exact match on selected content 1 or SHA2-256 -- SHA-256 hash of selected content [RFC6234] 2 or SHA2-512 -- SHA-512 hash of selected content [RFC6234] If the SMIMEA record's matching type is a hash, having the record use the same hash algorithm that was used in the signature in the certificate (if possible) will assist clients that support a small number of hash algorithms. 2.1.4. Certificate Access Field 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. 0 or NO: No alternative method advertised. 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. 2 or WF: X.509 certificates available in WebFinger [RFC7033]. 2.1.5. The Certificate Association Data Field This field specifies the "certificate association data" to be matched. These bytes are either raw data (that is, the full certificate or its SubjectPublicKeyInfo, depending on the selector) for matching type Full (0), or the hash of the raw data for matching types SHA2-256 (1) and SHA2-512 (2). The data refers to the certificate in the association, not to the ASN.1 Certificate object. For certificate usage type REJECT (4) at least one byte of data is REQUIRED but the value MUST be ignored. 2.2. SMIMEA RR Presentation Format The presentation format of the RDATA portion (as defined in [RFC1035]) is as follows: o The certificate usage field MUST be represented either as a certificate usage mnemonic or an 8-bit unsigned integer. o The selector field MUST be represented either as a selector field mnemonic or an 8-bit unsigned integer. o The matching type field MUST be represented either as a matching type mnemonic or an 8-bit unsigned integer. o The certificate access field MUST be represented either as a certificate access mnemonic or an 8-bit unsigned integer. o The certificate association data field MUST be represented as a string of hexadecimal characters. Whitespace is allowed within the string of hexadecimal characters, as described in [RFC1035]. Where practical, the mnemonic form SHOULD be used in order to provide clarity. 2.3. SMIMEA RR Examples In the following examples, the domain name is formed using the rules in Section 3. An example of a hashed (SHA2-256) association of a Full PKIX-CA certificate in the PKIX validation path of a certificate used to validate a signed S/MIME message. No alternative certificate access is advertised. = 1c190a039a9c355fba9eb653eb52cd64e2fbe76db2588fc5a2b5c5d4._sign._smimecert.= example.com. IN SMIMEA ( 0 0 1 0 d2abde240d7cd3ee6b4b28c54df034b9 7983a1d16e8a410e4561cb106618e971 ) Alternatively = 1c190a039a9c355fba9eb653eb52cd64e2fbe76db2588fc5a2b5c5d4._sign._smimecert.= example.com. IN SMIMEA ( PKIX-CA FULL SHA2-256 NO d2abde240d7cd3ee6b4b28c54df034b9 7983a1d16e8a410e4561cb106618e971 ) An example resource record providing Full self-signed encryption certificate: = 1c190a039a9c355fba9eb653eb52cd64e2fbe76db2588fc5a2b5c5d4._encr._smimecert.= example.com. IN SMIMEA ( DANE-EE Cert Full NO 30820307308201efa003020102020... ) An example of resource record invalidating all digital signatures by identified user: = 1c190a039a9c355fba9eb653eb52cd64e2fbe76db2588fc5a2b5c5d4._sign._smimecert.= example.com. IN SMIMEA ( REJECT Cert Full NO 00 ) ... 3. Domain Names for S/MIME Certificate Associations SMIMEA domain names include function and user labels. The purpose is to identify the function specific certificate if a user has multiple certificates. Alias MAY be used if a user has a common certificate for both functions ... 3.1. Domain Name Preparation Domain names are prepared for requests in the following manner. 1. The user name (the "left-hand side" of the email address, called the "local-part" in the mail message format definition [RFC5322] and the "local part" in the specification for internationalized email [RFC6530]), is encoded with Base32 [RFC4648], to become the left-most label in the prepared domain name. This does not include the "@" character that separates the left and right sides of the email address. 2. The second left-most label is the function specific label segment. It is selected based on the S/MIME function the MUA is performing. Values are: "_encr" for obtaining or validating a certificate or public key to be used to encrypt a message. "_sign" for certificate validation data to verify a digital signature. For certificate use cases XXXX-EE (1 and 3) the function specific label SHOULD be consistent with the Key Usage field (defined in section 4.2.1.3 of [RFC5280]) of the associated certificate. 3. The string "_smimecert" becomes the third left-most label in the prepared domain. The function specific label segment is separate to enable delegation of a single _smimecert zone cut. 4. The domain name (the "right-hand side" of the email address, called the "domain" in [RFC5322]) is appended to the result of step 3 to complete the prepared domain name. ... 3.2. Domain Name Examples Example 1. Signature certificate verification: to request an SMIMEA resource record to verify a signature certificate for a user whose address is "alice@example.com", you would use: = "df7f0c341e185f1073a2caef0d37a8b6a11fac62f46beaf459532bb0._sign._smimecert= .example.com" Example 2. Encryption key discovery: to request an SMIMEA resource record for encrypting an email to user "bob@example.com" you would use: = "550c233eeabd0f03bb42b99956efa56cdadaef7d346a04e351ac1b7a._encr._smimecert= .example.com" 4. Use of SMIMEA Records in SMIME SMIMEA records are used to publish user certificates or validate user certificates acquired by other means. Typically these use cases are associated with message encryption and signature validation processes respectively. Section 2.1 of this document defines the mandatory matching rules for the data. Where possible, consistency with [RFC6698] is maintained. 4.1. Usable Certificate Associations An implementation of this protocol makes a DNS query for SMIMEA records, validates these records using DNSSEC, and uses the resulting SMIMEA records and validation to modify S/MIME message processing behavior. Determining whether an SMIMEA RRSet can be used MUST be based on the DNSSEC validation state (as defined in [RFC4035]). o An SMIMEA RRSet whose DNSSEC validation state is secure MUST be used as a certificate association for S/MIME unless a local policy would prohibit the use of the specific certificate association in the secure SMIMEA RRSet. o If the DNSSEC validation state on the response to the request for the SMIMEA RRSet is bogus then the RRSet MUST be disregarded and considered unusable. Additional SMIMEA queries may be initiated. o If the DNSSEC validation state is indeterminate or insecure then the SMIMEA RRSet MUST be disregarded and considered unusable. MUAs that rely on another entity to perform the DNSSEC signature validation SHOULD use a secure mechanism between themselves and the validator. Examples of secure transports to other hosts include TSIG [RFC2845], SIG(0) [RFC2931], and IPsec [RFC6071]. Note that it is not sufficient to use secure transport to a DNS resolver that does not do DNSSEC signature validation. If a certificate association contains a certificate usage, selector, or matching type that is not understood by the MUA, that certificate association MUST be considered unusable. If the comparison data for a certificate is malformed, the certificate association MUST be considered unusable. If a certificate association contains a matching type or certificate association data that uses a cryptographic algorithm that is considered too weak for the MUA's local policy, the certificate association MUST be considered unusable. If a MUA receives zero usable certificate associations from a DNS request or from its cache, it processes S/MIME requests in the normal fashion without any input from the SMIMEA records. If a MUA performing certificate validation receives one or more usable certificate associations then it MUST attempt to match each certificate association with the user's certificate until a successful match is found. If no certificate associations match then the certificate MUST be considered invalid. If a MUA makes an SMIMEA request for an encryption certificate and the response includes more than one valid certificate, the certificate with the most recent "Not Before" data SHOULD be selected. [ Are there better criteria? ] ... 6. IANA Considerations 6.1. SMIMEA RRtype This document uses a new DNS RR type, SMIMEA, whose value will be allocated by IANA from the Resource Record (RR) TYPEs subregistry of the Domain Name System (DNS) Parameters registry. 6.2. SMIMEA Certificate Usage Registry This document creates a new registry, "SMIMEA Certificate Usages". The registry policy is "RFC Required". The initial entries in the registry are: +-------+----------+--------------------------------+-------------+ | Value | Mnemonic | Short Description | Reference | +-------+----------+--------------------------------+-------------+ | 0 | PKIX-CA | CA constraint | [this doc] | | 1 | PKIX-EE | Service certificate constraint | [this doc] | | 2 | DANE-TA | Trust anchor assertion | [this doc] | | 3 | DANE-EE | Domain-issued certificate | [this doc] | | 4 | REJECT | Invalid Certificate or User | [this doc] | | 5-254 | | Unassigned | | | 255 | PrivCert | Reserved for Private Use | [this doc] | +-------+----------+--------------------------------+-------------+ Applications to the registry can request specific values that have yet to be assigned. 6.3. SMIMEA Selectors This document creates a new registry, "TLSA Selectors". The registry policy is "Specification Required". The initial entries in the registry are: +-------+----------+--------------------------+-------------+ | Value | Mnemonic | Short Description | Reference | +-------+----------+--------------------------+-------------+ | 0 | Cert | Full certificate | [this doc] | | 1 | SPKI | SubjectPublicKeyInfo | [this doc] | | 2-254 | | Unassigned | | | 255 | PrivSel | Reserved for Private Use | [this doc] | +-------+----------+--------------------------+-------------+ Applications to the registry can request specific values that have yet to be assigned. 6.4. SMIMEA Matching Types This document creates a new registry, "SMIMEA Matching Types". The registry policy is "Specification Required". The initial entries in the registry are: +-------+-----------+--------------------------+-------------+ | Value | Mnemonic | Short Description | Reference | +-------+-----------+--------------------------+-------------+ | 0 | Full | No hash used | [this doc] | | 1 | SHA2-256 | 256 bit hash by SHA2 | [this doc] | | 2 | SHA2-512 | 512 bit hash by SHA2 | [this doc] | | 3-254 | | Unassigned | | | 255 | PrivMatch | Reserved for Private Use | [this doc] | +-------+-----------+--------------------------+-------------+ Applications to the registry can request specific values that have yet to be assigned. 6.5. Certificate Access Field This document creates a new registry, "SMIMEA Certificate Access". The registry policy is "Specification Required". The initial entries in the registry are: +-------+-----------+---------------------------+-------------+ | Value | Mnemonic | Short Description | Reference | +-------+-----------+---------------------------+-------------+ | 0 | NO | No Alternative Advertised | [this doc] | | 1 | NAPTR | NAPTR | [this doc] | | 2 | WF | WebFinger | [this doc] | | 3-254 | | Unassigned | | | 255 | PrivUse | Reserved for Private Use | [this doc] | +-------+-----------+---------------------------+-------------+ Applications to the registry can request specific values that have yet to be assigned. --Apple-Mail=_AB9CA192-AF13-43FB-B065-882640B2FB1C Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN7DCCBmAw ggVIoAMCAQICEHaFyweo4MwP0sVNjzk1sxIwDQYJKoZIhvcNAQEFBQAwgcoxCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ug b25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMiBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eSAtIEczMB4XDTExMDYwNzAwMDAwMFoXDTIxMDYwNjIzNTk1OVowgckxCzAJ BgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50 ZWMgVHJ1c3QgTmV0d29yazE1MDMGA1UECxMsQ2xhc3MgMiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0ExQzBBBgNVBAMTOlN5bWFudGVjIENsYXNzIDIgU2hhcmVkIEludGVybWVk aWF0ZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQC3+D8MK4MjIIWmTUkBUTra3VAzvuMEpDo+o2FmTDTC6HRwdUmlt0ns3bOSnN15DeK5+rg5PL6F 44zvbXmjprcIv5xMvj6YjqzbfJor7AUoMF8pGzNNRNVw6FYimaY+nUJb6yOnY50tLLAuPxjzKc0a NomEksdXcFtwheY4oXxQ4zc4iGVba8s5KgSxgqoZBP+gfz+j25FFdmaja/OFI15O2YVddaegFffB AHTg5cqUQmWawjd6i6hQrL+XdGd30TKnr43Lk6klQrQwGnQK4iUQEMt0Z1UPyxT8QVAKpHxNCwv5 Bak1+UWnMfGAu6LJPs52OeEq/3ZQ5+hRIt8tz7gzAgMBAAGjggI/MIICOzASBgNVHRMBAf8ECDAG AQH/AgEAMDQGA1UdHwQtMCswKaAnoCWGI2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTItZzMu Y3JsMA4GA1UdDwEB/wQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRVmVyaVNpZ25NUEtJ LTItNTYwHQYDVR0OBBYEFNhIKahfKheS4vqee+9vYIP4uLjcMIHwBgNVHSMEgegwgeWhgdCkgc0w gcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3Ig YXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMiBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczghBhcMtJjF+YRSnnsKbZUFt6MDQGCCsG AQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AudmVyaXNpZ24uY29tMGwGA1UdIARl MGMwYQYLYIZIAYb4RQEHFwIwUjAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9j cHMwKAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9ycGEwDQYJKoZIhvcNAQEF BQADggEBAKYqmwdAyez/s4joRdo00RcPKC23pYVnMc3B5tUphjis4vBZGwzhoUXOJHjvacGwTGGi SNloT7r+dVQ3ulhp6sF2pTZC6p5meJAg2ZVqJHlUzd5aGoo7rhiVctAl2NJGvjQwp4Ce8VbOIB5s Z8lNT3mHieIugNae7SZhZaID0MXi8yi5K0lpgmfs1ek0pC7cYiKkhU1I42oClPLN/eRnyEm8qtXH 5zzeh7EQa10HXBnka6D0T5nL3LVbDMwy+WrkdMAqWDd5s/vNwzRv4XbdEAcAY4sHTicXkkebDr7e DROFEfyiL2V9zDqsHlRrVmfE7qWHIiMXK3BWw/Gud1wnwTkwggeEMIIGbKADAgECAhBcCMgDVFpl hwRR0TZyMUgoMA0GCSqGSIb3DQEBBQUAMIHJMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50 ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxNTAzBgNVBAsT LENsYXNzIDIgTWFuYWdlZCBQS0kgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBMUMwQQYDVQQDEzpT eW1hbnRlYyBDbGFzcyAyIFNoYXJlZCBJbnRlcm1lZGlhdGUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5 MB4XDTE0MDQxMDAwMDAwMFoXDTE1MDQxMDIzNTk1OVowczEmMCQGCSqGSIb3DQEJARYXZW9zdGVy d2VpbEB2ZXJpc2lnbi5jb20xGDAWBgNVBAMMD09zdGVyd2VpbCwgRXJpYzEWMBQGA1UECwwNRU5U RVJQUklTRSBJVDEXMBUGA1UECgwOVmVyaVNpZ24sIEluYy4wggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQCmK2/yLaprGu39usXztz6N7uLYDoKN4MNaDFGGj1eYfMkIfb6LDoYBs9qcnINg 8in4NxGwVQGIJU5AE/1wHe/V1qavpHEO2mVxRq94cBF0P8ETPpM1yhwBhU4QKhjNEDj9wov8RXzO hjqPy/uknZvBxfobQx22vhnEKpf7QEN0zfLDJON3tyYwsnrFZkmop4ni4ANI7ev5uqcI05ED7vSh K9AHAVjzjr2QvtmvqHAkOnpHgqkWJWhuw4f9Gx+8LmbC3tl8oxF7+E7WEwKTQG56BV0uR6PN/o0S O7VSbDCZyNoxxrjzw+CesWsigi2NvC5DnhkKlxP+JSfJxMDu+7MDAgMBAAGjggO7MIIDtzAMBgNV HRMBAf8EAjAAMA4GA1UdDwEB/wQEAwIFoDAWBgNVHSUBAf8EDDAKBggrBgEFBQcDBDAdBgNVHQ4E FgQUVoVKaC1xEPB9EWKq3dWrwskIufkwUAYDVR0RBEkwR4EXZW9zdGVyd2VpbEB2ZXJpc2lnbi5j b22gLAYKKwYBBAGCNxQCA6AeDBxlb3N0ZXJ3ZWlsQHZjb3JwLmFkLnZyc24uY29tMB8GA1UdIwQY MBaAFNhIKahfKheS4vqee+9vYIP4uLjcMIIBcQYIKwYBBQUHAQEEggFjMIIBXzAnBggrBgEFBQcw AYYbaHR0cDovL3BraS1vY3NwLnN5bWF1dGguY29tMIIBMgYIKwYBBQUHMAKGggEkbGRhcDovL2Rp cmVjdG9yeS52ZXJpc2lnbi5jb20vQ04lMjAlM0QlMjBTeW1hbnRlYyUyMENsYXNzJTIwMiUyMFNo YXJlZCUyMEludGVybWVkaWF0ZSUyMENlcnRpZmljYXRlJTIwQXV0aG9yaXR5JTJDT1UlMjAlM0Ql MjBDbGFzcyUyMDIlMjBNYW5hZ2VkJTIwUEtJJTIwSW5kaXZpZHVhbCUyMFN1YnNjcmliZXIlMjBD QSUyQ09VJTIwJTNEJTIwU3ltYW50ZWMlMjBUcnVzdCUyME5ldHdvcmslMkNPJTIwJTNEJTIwU3lt YW50ZWMlMjBDb3Jwb3JhdGlvbiUyQ0MlMjAlM0QlMjBVUz9jQUNlcnRpZmljYXRlO2JpbmFyeTBd BgNVHR8EVjBUMFKgUKBOhkxodHRwOi8vcGtpLWNybC5zeW1hdXRoLmNvbS9jYV8wN2JiN2Q2NDc3 Y2Y0ZjZiZTk2YWYxYjM2Y2FiZDMxNi9MYXRlc3RDUkwuY3JsMGwGA1UdIARlMGMwYQYLYIZIAYb4 RQEHFwIwUjAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9jcHMwKAYIKwYBBQUH AgIwHBoaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9ycGEwQgYJKoZIhvcNAQkPBDUwMzAKBggqhkiG 9w0DBzALBglghkgBZQMEAQIwCwYJYIZIAWUDBAEWMAsGCWCGSAFlAwQBKjAsBgpghkgBhvhFARAD BB4wHAYSYIZIAYb4RQEQAQICAQGL8cYJFgYyNDc2NjQwOQYKYIZIAYb4RQEQBQQrMCkCAQAWJGFI UjBjSE02THk5d2Eya3RjbUV1YzNsdFlYVjBhQzVqYjIwPTANBgkqhkiG9w0BAQUFAAOCAQEAXFTS ZEP9la6QYPlo6ybMEEpxVOADx082WRGtrYoU9ZEaC2IlxmwI9JprNfBlIy8FtyJAuWKBbe9/XKJF cukb2HNS0httHUIcSTfMEsAyc99/ba/SoMlhtvko/nCvx5brzhpQwop6AgMv9v5V7F1GUFO7db8L LSs1gIZYI8IeudznJOQGUBFGe0aJhA4cD/3OIZyItWpNtn94i1GJUFPMjYhGcy/r0fUQY/KFLwOi M6bT/m1RwAJKJI/mON/OshdzylAYqKOPoFTJD4qrbrpij1r1+e1VHKklAxTd+nOg9J1L0yRwlEDS 1boeOxqNXGnEYAa54k0ZWPh+8dFemteaLjGCBE0wggRJAgEBMIHeMIHJMQswCQYDVQQGEwJVUzEd MBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5l dHdvcmsxNTAzBgNVBAsTLENsYXNzIDIgTWFuYWdlZCBQS0kgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBMUMwQQYDVQQDEzpTeW1hbnRlYyBDbGFzcyAyIFNoYXJlZCBJbnRlcm1lZGlhdGUgQ2VydGlm aWNhdGUgQXV0aG9yaXR5AhBcCMgDVFplhwRR0TZyMUgoMAkGBSsOAwIaBQCgggJDMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE0MDkyOTEyMjY0NVowIwYJKoZIhvcN AQkEMRYEFNrqCKCwSvvmqakde+Mx826Mrp3ZMIHvBgkrBgEEAYI3EAQxgeEwgd4wgckxCzAJBgNV BAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMg VHJ1c3QgTmV0d29yazE1MDMGA1UECxMsQ2xhc3MgMiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFsIFN1 YnNjcmliZXIgQ0ExQzBBBgNVBAMTOlN5bWFudGVjIENsYXNzIDIgU2hhcmVkIEludGVybWVkaWF0 ZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkCEFwIyANUWmWHBFHRNnIxSCgwgfEGCyqGSIb3DQEJEAIL MYHhoIHeMIHJMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAd BgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxNTAzBgNVBAsTLENsYXNzIDIgTWFuYWdlZCBQ S0kgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBMUMwQQYDVQQDEzpTeW1hbnRlYyBDbGFzcyAyIFNo YXJlZCBJbnRlcm1lZGlhdGUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5AhBcCMgDVFplhwRR0TZyMUgo MA0GCSqGSIb3DQEBAQUABIIBAB8TWixWKPlYbaEKzzLOpKh8gXOsIpHFPjVU/e8A+dEqCWWm2vIV RFmjMv6927mDr6ep8CGNqCpfwLpf/tHs34fnlK5bC7I4b8fNdy3HQQuNOanbHZF/bWh1bh3l6v7G +cdRJbhwIgqRYRuzPtFnR0eFIAXq2n4tBnyiQzZrza/3eNjVlb7wzz+7pkqzG60BOXKnb7MAm+d5 YQWMSZnqDq1vkCtJSluTxenvmIdC6MQ4Cyh9wbwgFvh9fHxeORHBJCBW6RXAqmSFINUS4VsyOH/7 +3oBSKuEToJD4oBCqs9El3k+B/ld1TOsgaFh7tbgwtdO98yaAb3JPeFLmvN3h28AAAAAAAA= --Apple-Mail=_AB9CA192-AF13-43FB-B065-882640B2FB1C-- From nobody Mon Sep 29 13:10:54 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 442B91ACC8A for ; Mon, 29 Sep 2014 13:10:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, RP_MATCHES_RCVD=-0.786, 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 LFccniHA0IM5 for ; Mon, 29 Sep 2014 13:10:49 -0700 (PDT) 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 6A5971ACC81 for ; Mon, 29 Sep 2014 13:10:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kirei.se; s=spg20100524; h=received:content-type:mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to:x-mailer; bh=6thLMwdZqL5hMncqIiphhkx8PQMOSGHmpvPe1dBXlNI=; b=YE4rIytebqluioncGtr39+EcyNLsCc6pyl7mkB3hLi+W6EFaG3FoaeuefFNikMPIG3/rTuZ+CIQjO MNyyY4nLcKKdJ8wofykjg7pTcm+fwYvJhhblHZE4hmX3B1kwrMv/hkT8jRi3b5aS0JU6/ejA6zxAmY nB4GGzYIHWpUbowU= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg-relay.kirei.se (Halon Mail Gateway) with ESMTPS; Mon, 29 Sep 2014 22:10:23 +0200 (CEST) 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: Date: Mon, 29 Sep 2014 22:10:27 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Warren Kumari X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/dleoofUTPR1fF0difb75IroTEtM Cc: "" Subject: Re: [dane] Meeting in Hawaii? 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, 29 Sep 2014 20:10:52 -0000 On 27 sep 2014, at 02:52, Warren Kumari wrote: > We have requested a 2 hour slot for Hawaii, however, we have not seen > much activity since Toronto, and so are thinking of handing the time > back. >=20 > Please let us know if you'd really like to meet, and open issues on > documents that need discussing. Also, if you have a doc, we'd like it > revised *soon*. All the authors of the various drafts on DANE for email (S/MIME and = OpenPGP) will be there, and we will have discussions on the list = beforehand. Given this, I for one, hope we can meet and flesh out any = details left on this topic. I'm not sure we need 2 hours though - 1,5 hours should be enough. jakob From nobody Mon Sep 29 14:11:36 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 143541A1BD9 for ; Mon, 29 Sep 2014 14:11:34 -0700 (PDT) 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 F8pcr5NVvDz5 for ; Mon, 29 Sep 2014 14:11:32 -0700 (PDT) Received: from mail-ie0-f175.google.com (mail-ie0-f175.google.com [209.85.223.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D75D1ACCE5 for ; Mon, 29 Sep 2014 14:11:29 -0700 (PDT) Received: by mail-ie0-f175.google.com with SMTP id y20so5924942ier.34 for ; Mon, 29 Sep 2014 14:11:28 -0700 (PDT) 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=g+dPbQskVL4e0zQoCaaLwvYTgWCTO3oelQvcOW30tV4=; b=bFySrNnBiOkN2g22Ln0ezSEGIpvsuCnezhfVB7OgdeZQNlkE2nLbRU79FH+0eiSAQ9 rHn5aeOGiZO3850VfZy1ZtHRfkbU3CNhrc1/7uYBedx4y04uXE61YB34OdhffuN8TnTT bTT5u1+q9mhAEI90sXlwmh8MATiQmsh7bEpCx4cj9N4ZAqnm9hPq6ealuKxGVJLG75rT 71Sv5e4/mxaOXR2dVrYgXDMPV1XR7dMMO7nk46YxMv7/AkXgpm9yyu+ZhGxdJiIqTVR8 ej7Q93rvcZfhE+pP0kfqN6e8VdeMWmKIRlB5GLPc5lukhKkDG9Lqc0mWPKDHICr+MxEd Qqdg== X-Gm-Message-State: ALoCoQnPB3fWrmC47dYdPZYtlYLbBiyJN0sAgmQmvl0lYSzsh6uMyV+nqEIycIvNN9oCTGzwGEPe X-Received: by 10.50.79.165 with SMTP id k5mr850403igx.16.1412025088572; Mon, 29 Sep 2014 14:11:28 -0700 (PDT) Received: from aither.local (68-113-20-60.dhcp.knwc.wa.charter.com. [68.113.20.60]) by mx.google.com with ESMTPSA id mg3sm2414091igb.22.2014.09.29.14.11.26 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 29 Sep 2014 14:11:27 -0700 (PDT) Message-ID: <5429CAFE.9010702@andyet.net> Date: Mon, 29 Sep 2014 14:11:26 -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: Jakob Schlyter , Warren Kumari References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dane/5Rju-4F3QIEQ5MQvZwmBZW4d_YY Cc: "" Subject: Re: [dane] Meeting in Hawaii? 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, 29 Sep 2014 21:11:34 -0000 On 9/29/14, 1:10 PM, Jakob Schlyter wrote: > On 27 sep 2014, at 02:52, Warren Kumari wrote: > >> We have requested a 2 hour slot for Hawaii, however, we have not seen >> much activity since Toronto, and so are thinking of handing the time >> back. >> >> Please let us know if you'd really like to meet, and open issues on >> documents that need discussing. Also, if you have a doc, we'd like it >> revised *soon*. > > All the authors of the various drafts on DANE for email (S/MIME and OpenPGP) will be there, and we will have discussions on the list beforehand. Given this, I for one, hope we can meet and flesh out any details left on this topic. Matt Miller and I plan to meet IRL soon to close a few remaining issues with the dane-srv spec. Hopefully that won't require further discussion in Hawaii, but if so it ought to be brief (IMHO). Peter From nobody Tue Sep 30 11:36: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 D59511A876F for ; Tue, 30 Sep 2014 11:36:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.687 X-Spam-Level: X-Spam-Status: No, score=-2.687 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, 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 HlswJV0YVwrW for ; Tue, 30 Sep 2014 11:36:17 -0700 (PDT) Received: from out.west.pexch112.icann.org (pfe112-ca-1.pexch112.icann.org [64.78.40.7]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89B181A8765 for ; Tue, 30 Sep 2014 11:36:17 -0700 (PDT) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) with Microsoft SMTP Server (TLS) id 15.0.847.32; Tue, 30 Sep 2014 11:36:15 -0700 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.0847.030; Tue, 30 Sep 2014 11:36:15 -0700 From: Richard Lamb To: "Osterweil, Eric" , dane WG list Thread-Topic: SMIMEA prototyping Thread-Index: AQHP29q7Y0Wg27e53U2QPZq9K7XNoJwaANlw Date: Tue, 30 Sep 2014 18:36:14 +0000 Message-ID: <3bd8ffc5c4ce4510ac3c1072c28e5c3a@PMBX112-W1-CA-1.PEXCH112.ICANN.ORG> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [76.103.0.6] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00A2_01CFDCA2.BF0B8690" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/4VraemPgQB32181-hInRvif2tfM Subject: Re: [dane] SMIMEA prototyping 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, 30 Sep 2014 18:36:20 -0000 ------=_NextPart_000_00A2_01CFDCA2.BF0B8690 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Very cool. Ive been waiting for the "killer app" and something better than Kaminsky's Outlook+DNSSEC/phreebird demo of 2008. I assume you mean DNSSEC Workshop @ ICANN 51 usually on Wed. Is a separate DANE workshop? Looking forward to seeing the demo... Rick -----Original Message----- From: dane [mailto:dane-bounces@ietf.org] On Behalf Of Osterweil, Eric Sent: Monday, September 29, 2014 4:45 AM To: dane WG list Subject: [dane] SMIMEA prototyping Hey everyone, A few of us at Verisign (actually, that would be Lynch Davis) have been working on a prototype for the SMIMEA draft. We have written a general library+API, we have integrated it into Thunderbird, and have begun integrating into Mail.app. Our plans are to publish this as open source at some point after the DANE workshop that will be taking place at ICANN 51 (where we will be demo'ing it). We ran into numerous interesting wrinkles and made some specific design choices, but at a high level the S/MIME prototype: - can sign - can encrypt - can decrypt (without writing clear text to disk) - can verify - and supports several features that are enabled through suggested additions. With the foresight that zones may need to be delegated to accommodate churn and scale, some certificates may need to be selectively authenticated or deauthenticated (perhaps on a per-user basis), and the locations of certificate information may need to be managed in different places (some in the DNS, some in external locations), etc. we have made some operational choices to modify elements of the draft in our prototype. We intend to detail these in a follow-on email. We're hoping to show this off at the upcoming IETF too. Eric ------=_NextPart_000_00A2_01CFDCA2.BF0B8690 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRhzCCA7cw ggKfoAMCAQICEAzn4OUX2Eb+j+Vg/BvwMDkwDQYJKoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UE AxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTA2MTExMDAwMDAwMFoXDTMxMTExMDAw MDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3 LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArQ4VzuRDgFyxh/O3YPlxEqWu3CaUiKr0zvUgOShY YAz4gNqpFZUyYTy1sSiEiorcnwoMgxd6j5Csiud5U1wxhCr2D5gyNnbM3t08qKLvavsh8lJh358g 1x/isdn+GGTSEltf+VgYNbxHzaE2+Wt/1LA4PsEbw4wz2dgvGP4oD7Ong9bDbkTAYTWWFv5ZnIt2 bdfxoksNK/8LctqeYNCOkDXGeFWHIKHP5W0KyEl8MZgzbCLph9AyWqK6E4IR7TkXnZk6cqHm+qTZ 1Rcxda6FfSKuPwFGhvYoecix2uRXF8R+HA6wtJKmVrO9spftqqfwt8WoP5UW0P+hlusIXxh3TwID AQABo2MwYTAOBgNVHQ8BAf8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUReuir/SS y4IxLVGLp6chnfNtyA8wHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQEFBQADggEBAKIOvN/i7fDjcnN6ZJS/93Jm2DLkQnVirofr8tXZ3lazn8zOFCi5DZdgXBJMWOTT PYNJRViXNWkaqEfqVsZ5qxLYZ4GE338JPJTmuCYsIL09syiJ91//IuKXhB/pZe+H4N/BZ0mzXeuy CSrrJu14vn0/K/O3JjVtX4kBtklbnwEFm6s9JcHMtn/C8W+GxvpkaOuBLZTrQrf6jB7dYvG+UGe3 bL3z8R9rDDYHFn83fKlbbXrxEkZgg9cnBL5Lzpe+w2cqaBHfgOcMM2a/Ew0UbvN/H2MQHvqNGyVt bI+lt2EBsdKjJqEQcZ2t4sP5w5lRtysHCM4u5lCyp/oKRS+i8PIwggbNMIIFtaADAgECAhAG/fkD lgOt6gAK6z8nu7obMA0GCSqGSIb3DQEBBQUAMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdp Q2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFz c3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAwMDAwMDBaFw0yMTExMTAwMDAwMDBaMGIxCzAJBgNV BAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20x ITAfBgNVBAMTGERpZ2lDZXJ0IEFzc3VyZWQgSUQgQ0EtMTCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBAOiCLZn5ysJClaWAc0Bw0p5WVFypxNJBBo/JM/xNRZFcgZ/tLJz4FlnfnrUkFcKY ubR3SdyJxArar8tea+2tsHEx6886QAxGTZPsi3o2CAOrDDT+GEmC/sfHMUiAfB6iD5IOUMnGh+s2 P9gww/+m9/uizW9zI/6sVgWQ8DIhFonGcIj5BZd9o8dD3QLoOz3tsUGj7T++25VIxO4es/K8DCuZ 0MZdEkKB4YNugnM/JksUkK5ZZgrEjb7SzgaurYRvSISbT0C58Uzyr5j79s5AXVz2qPEvr+yJIvJr GGWxwXOt1/HYzx4KdFxCuGh+t9V3CidWfA9ipD8yFGCV/QcEogkCAwEAAaOCA3owggN2MA4GA1Ud DwEB/wQEAwIBhjA7BgNVHSUENDAyBggrBgEFBQcDAQYIKwYBBQUHAwIGCCsGAQUFBwMDBggrBgEF BQcDBAYIKwYBBQUHAwgwggHSBgNVHSAEggHJMIIBxTCCAbQGCmCGSAGG/WwAAQQwggGkMDoGCCsG AQUFBwIBFi5odHRwOi8vd3d3LmRpZ2ljZXJ0LmNvbS9zc2wtY3BzLXJlcG9zaXRvcnkuaHRtMIIB ZAYIKwYBBQUHAgIwggFWHoIBUgBBAG4AeQAgAHUAcwBlACAAbwBmACAAdABoAGkAcwAgAEMAZQBy AHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMAdABpAHQAdQB0AGUAcwAgAGEAYwBjAGUAcAB0AGEA bgBjAGUAIABvAGYAIAB0AGgAZQAgAEQAaQBnAGkAQwBlAHIAdAAgAEMAUAAvAEMAUABTACAAYQBu AGQAIAB0AGgAZQAgAFIAZQBsAHkAaQBuAGcAIABQAGEAcgB0AHkAIABBAGcAcgBlAGUAbQBlAG4A dAAgAHcAaABpAGMAaAAgAGwAaQBtAGkAdAAgAGwAaQBhAGIAaQBsAGkAdAB5ACAAYQBuAGQAIABh AHIAZQAgAGkAbgBjAG8AcgBwAG8AcgBhAHQAZQBkACAAaABlAHIAZQBpAG4AIABiAHkAIAByAGUA ZgBlAHIAZQBuAGMAZQAuMAsGCWCGSAGG/WwDFTASBgNVHRMBAf8ECDAGAQH/AgEAMHkGCCsGAQUF BwEBBG0wazAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29tMEMGCCsGAQUFBzAC hjdodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURSb290Q0EuY3J0 MIGBBgNVHR8EejB4MDqgOKA2hjRodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1 cmVkSURSb290Q0EuY3JsMDqgOKA2hjRodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRB c3N1cmVkSURSb290Q0EuY3JsMB0GA1UdDgQWBBQVABIrE5iymQftHt+ivlcNK2cCzTAfBgNVHSME GDAWgBRF66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG9w0BAQUFAAOCAQEARlA+ybcoJKc4HbZb Ka9Sz1LpMUerVlx71Q0LQbPv7HUfdDjyslxhopyVw1Dkgrkj0bo6hnKtOHisdV0XFzRyR4WUVtHr uzaEd8wkpfMEGVWp5+Pnq2LN+4stkMLA0rWUvV5PsQXSDj0aqRRbpoYxYqioM+SbOafE9c4deHaU JXPkKqvPnHZL7V/CSxbkS3BMAIke/MV5vEwSV/5f4R68Al2o/vsHOE8Nxl2RuQ9nRc3Wg+3nkg2N sWmMT/tZ4CMP0qquAHzunEIOz5HXJ7cW7g/DvXwKoO4sCFWFIrjrGBpN/CohrUkxg0eVd3HcsRtL SxwQnHcUwZ1PL1qVCCkQJjCCBvcwggXfoAMCAQICEAG7T6cXg/+DLDQq2twfKyswDQYJKoZIhvcN AQEFBQAwYjELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3 LmRpZ2ljZXJ0LmNvbTEhMB8GA1UEAxMYRGlnaUNlcnQgQXNzdXJlZCBJRCBDQS0xMB4XDTEyMDMy MTAwMDAwMFoXDTE1MDMyMTEyMDAwMFowgaMxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9y bmlhMRcwFQYDVQQHEw5NYXJpbmEgZGVsIFJleTE8MDoGA1UEChMzSW50ZXJuZXQgQ29ycG9yYXRp b24gZm9yIEFzc2lnbmVkIE5hbWVzIGFuZCBOdW1iZXJzMREwDwYDVQQLEwhTZWN1cml0eTEVMBMG A1UEAxMMUmljaGFyZCBMYW1iMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAjhvDK7uG PB9Hd2ArMIGLHvd85eT4tEVK0AC1to1l1I+InHA+AXCQW1xjVYj5TbL3YRHKBlSr2HeJ2SCXSHtn /dXzPk340rUMAXAs5LPFSgvBjqSnrBVQJYU2PhGovKmlw2b29pucEp3F5YcWMBd3MaKTcehbhGUQ CTulKjKeWkPOQ8+JOVs14sT8K4sL0j6wicr9i44aptIX4OkhhjASqUJH6tA04Lx85Kof4743k9jP GWZJXzJwNCMMIjNZp62GM1baKOakR1/iTMaDf7vhcRTFMhugVe8BgvrGdQc0jqs5cBuvrFEXF+CB M7dUVVg8o7vvBo9UpFYrJfLZWQt+jQIDAQABo4IDZTCCA2EwHwYDVR0jBBgwFoAUFQASKxOYspkH 7R7for5XDStnAs0wHQYDVR0OBBYEFDekcwE8o+pYg/m8I4UVbYqWl4KZMCEGA1UdEQQaMBiBFnJp Y2hhcmQubGFtYkBpY2Fubi5vcmcwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwME BggrBgEFBQcDAjB9BgNVHR8EdjB0MDigNqA0hjJodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGln aUNlcnRBc3N1cmVkSURDQS0xLmNybDA4oDagNIYyaHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0Rp Z2lDZXJ0QXNzdXJlZElEQ0EtMS5jcmwwggHFBgNVHSAEggG8MIIBuDCCAbQGCmCGSAGG/WwEAQIw ggGkMDoGCCsGAQUFBwIBFi5odHRwOi8vd3d3LmRpZ2ljZXJ0LmNvbS9zc2wtY3BzLXJlcG9zaXRv cnkuaHRtMIIBZAYIKwYBBQUHAgIwggFWHoIBUgBBAG4AeQAgAHUAcwBlACAAbwBmACAAdABoAGkA cwAgAEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMAdABpAHQAdQB0AGUAcwAgAGEAYwBj AGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgAZQAgAEQAaQBnAGkAQwBlAHIAdAAgAEMAUAAvAEMA UABTACAAYQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkAaQBuAGcAIABQAGEAcgB0AHkAIABBAGcAcgBl AGUAbQBlAG4AdAAgAHcAaABpAGMAaAAgAGwAaQBtAGkAdAAgAGwAaQBhAGIAaQBsAGkAdAB5ACAA YQBuAGQAIABhAHIAZQAgAGkAbgBjAG8AcgBwAG8AcgBhAHQAZQBkACAAaABlAHIAZQBpAG4AIABi AHkAIAByAGUAZgBlAHIAZQBuAGMAZQAuMHcGCCsGAQUFBwEBBGswaTAkBggrBgEFBQcwAYYYaHR0 cDovL29jc3AuZGlnaWNlcnQuY29tMEEGCCsGAQUFBzAChjVodHRwOi8vY2FjZXJ0cy5kaWdpY2Vy dC5jb20vRGlnaUNlcnRBc3N1cmVkSURDQS0xLmNydDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEB BQUAA4IBAQBI+heX8qmdny0UTYTwZI5LuCZAKD7MfQhTynfOHDKsANsPK/w0jS38gQUy0zvNzAez rZXKpfUVwBBfRnsnsD3uj0RRZtyzSWHW3jffPvZ+S8x+v4ysDv7JDr75fBUrJuRyv8XtNmaOj42h enwFwsbiIJKesYowUmDNdTxEvYxRo24Bd79pgBXbLiaALUa/se5zU/oqZgNsl9bIH5FmwRUKVRNu klGzRgLuRXygENuSO7IvJtQ0X3pYK/c8Hn6+qhUctummPwcXvzFK84P8HMBLKJkpT1Bx4lj5bkAR UiEZU3pnel/dXAQO/+yfKCy26kpqy0VU0LAWRPkBHYqB2FHpMYIDizCCA4cCAQEwdjBiMQswCQYD VQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29t MSEwHwYDVQQDExhEaWdpQ2VydCBBc3N1cmVkIElEIENBLTECEAG7T6cXg/+DLDQq2twfKyswCQYF Kw4DAhoFAKCCAeowGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTQw OTMwMTgzNjE2WjAjBgkqhkiG9w0BCQQxFgQUHXgr0liyEveahLl7FDUlGKpBbvEweQYJKoZIhvcN AQkPMWwwajALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAoGCCqGSIb3DQMHMAsGCWCGSAFlAwQB AjAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAwDQYIKoZIhvcNAwICASgw gYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZ MBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEhMB8GA1UEAxMYRGlnaUNlcnQgQXNzdXJlZCBJRCBD QS0xAhABu0+nF4P/gyw0KtrcHysrMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEhMB8GA1UE AxMYRGlnaUNlcnQgQXNzdXJlZCBJRCBDQS0xAhABu0+nF4P/gyw0KtrcHysrMA0GCSqGSIb3DQEB AQUABIIBAHBcpstrDqRaoHa3o1auH2X5zvK43IdsMy8rEs2mQoFWSoPtu60MTltyOnKsuzUyktAx f+pQvDfFkcU+NsC+ESOARG8nnJ6OyOMgKgBsBWjjV2uRa4zuQzyVxKv2mCQXo4PcJNS1i/F+T6sC 85PK807bSrjCXKBb5WVFihW51x32ulw8Vv+3EI2ng+XVwv6EQXjoF5yeuvAxzUVxq8mOhY6p/EWE N2IVzpHZEAZGvITLw8LIzFYEncf/f0lQLHb1q9c86RbCmIBXSjvERG79AMkTjWhy0noMtR5a/+ji l923ZRuNA6My9D1R2qvqcMT8pmax6A3qeKzgXqQ33B4vcbwAAAAAAAA= ------=_NextPart_000_00A2_01CFDCA2.BF0B8690-- From nobody Tue Sep 30 11:50: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 16F741A8779 for ; Tue, 30 Sep 2014 11:50:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.688 X-Spam-Level: X-Spam-Status: No, score=-2.688 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, 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 5rrSJJEz-7KX for ; Tue, 30 Sep 2014 11:50:01 -0700 (PDT) Received: from trstech.net (afribone.trstech.net [196.200.57.137]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66C391A87A5 for ; Tue, 30 Sep 2014 11:49:28 -0700 (PDT) Received: from [80.248.74.18] (helo=[192.168.3.100]) by trstech.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1XZ2V5-0000Mm-Jp; Tue, 30 Sep 2014 18:50:19 +0000 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: ALAIN AINA In-Reply-To: Date: Tue, 30 Sep 2014 18:48:37 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <546440C2-C8FA-4B46-AA31-B89872F41AFE@trstech.net> References: To: "Osterweil, Eric" X-Mailer: Apple Mail (2.1085) X-SA-Exim-Connect-IP: 80.248.74.18 X-SA-Exim-Mail-From: aalain@trstech.net X-SA-Exim-Version: 4.2.1 (built Fri, 28 Sep 2012 15:58:25 +0000) X-SA-Exim-Scanned: Yes (on trstech.net) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/Y5pTFILLxrRp5KsSM0ZRSv1zKs4 Cc: dane WG list Subject: Re: [dane] SMIMEA prototyping 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, 30 Sep 2014 18:50:03 -0000 This sounds interesting... Thanks --Alain On Sep 29, 2014, at 11:44 AM, Osterweil, Eric wrote: > Hey everyone, >=20 > A few of us at Verisign (actually, that would be Lynch Davis) have = been working on a prototype for the SMIMEA draft. We have written a = general library+API, we have integrated it into Thunderbird, and have = begun integrating into Mail.app. Our plans are to publish this as open = source at some point after the DANE workshop that will be taking place = at ICANN 51 (where we will be demo'ing it). We ran into numerous = interesting wrinkles and made some specific design choices, but at a = high level the S/MIME prototype: > - can sign > - can encrypt > - can decrypt (without writing clear text to disk) > - can verify > - and supports several features that are enabled through suggested = additions. >=20 > With the foresight that zones may need to be delegated to accommodate = churn and scale, some certificates may need to be selectively = authenticated or deauthenticated (perhaps on a per-user basis), and the = locations of certificate information may need to be managed in different = places (some in the DNS, some in external locations), etc. we have made = some operational choices to modify elements of the draft in our = prototype. We intend to detail these in a follow-on email. >=20 > We're hoping to show this off at the upcoming IETF too. >=20 > Eric > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From nobody Tue Sep 30 12:41: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 028131A87EA for ; Tue, 30 Sep 2014 12:41:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aMfN0xWG9aVg for ; Tue, 30 Sep 2014 12:41:38 -0700 (PDT) Received: from exprod6og125.obsmtp.com (exprod6og125.obsmtp.com [64.18.1.218]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E3BF1A884A for ; Tue, 30 Sep 2014 12:41:17 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob125.postini.com ([64.18.5.12]) with SMTP ID DSNKVCsHXNr5HUMfg6xJQpvh2gWXdBC7GbyC@postini.com; Tue, 30 Sep 2014 12:41:37 PDT Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id s8UJfFmJ001201 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 30 Sep 2014 15:41:16 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Tue, 30 Sep 2014 15:41:15 -0400 From: "Osterweil, Eric" To: Richard Lamb Thread-Topic: SMIMEA prototyping Thread-Index: AQHP29q7Y0Wg27e53U2QPZq9K7XNoJwaANlwgABXfAA= Date: Tue, 30 Sep 2014 19:41:14 +0000 Message-ID: References: <3bd8ffc5c4ce4510ac3c1072c28e5c3a@PMBX112-W1-CA-1.PEXCH112.ICANN.ORG> In-Reply-To: <3bd8ffc5c4ce4510ac3c1072c28e5c3a@PMBX112-W1-CA-1.PEXCH112.ICANN.ORG> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: multipart/signed; boundary="Apple-Mail=_A608F195-4352-4B71-8918-BDAA770111FD"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/RXLHSI_IHRBGcW-vVsXR3_nF3nY Cc: dane WG list Subject: Re: [dane] SMIMEA prototyping 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, 30 Sep 2014 19:41:40 -0000 --Apple-Mail=_A608F195-4352-4B71-8918-BDAA770111FD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Sep 30, 2014, at 2:36 PM, Richard Lamb = wrote: > Very cool. Ive been waiting for the "killer app" and something = better than > Kaminsky's Outlook+DNSSEC/phreebird demo of 2008. I assume you mean = DNSSEC > Workshop @ ICANN 51 usually on Wed. Yup, that's the one! > Is a separate DANE workshop? >=20 > Looking forward to seeing the demo=85 Great! Eric --Apple-Mail=_A608F195-4352-4B71-8918-BDAA770111FD Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN7DCCBmAw ggVIoAMCAQICEHaFyweo4MwP0sVNjzk1sxIwDQYJKoZIhvcNAQEFBQAwgcoxCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ug b25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMiBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eSAtIEczMB4XDTExMDYwNzAwMDAwMFoXDTIxMDYwNjIzNTk1OVowgckxCzAJ BgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50 ZWMgVHJ1c3QgTmV0d29yazE1MDMGA1UECxMsQ2xhc3MgMiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0ExQzBBBgNVBAMTOlN5bWFudGVjIENsYXNzIDIgU2hhcmVkIEludGVybWVk aWF0ZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQC3+D8MK4MjIIWmTUkBUTra3VAzvuMEpDo+o2FmTDTC6HRwdUmlt0ns3bOSnN15DeK5+rg5PL6F 44zvbXmjprcIv5xMvj6YjqzbfJor7AUoMF8pGzNNRNVw6FYimaY+nUJb6yOnY50tLLAuPxjzKc0a NomEksdXcFtwheY4oXxQ4zc4iGVba8s5KgSxgqoZBP+gfz+j25FFdmaja/OFI15O2YVddaegFffB AHTg5cqUQmWawjd6i6hQrL+XdGd30TKnr43Lk6klQrQwGnQK4iUQEMt0Z1UPyxT8QVAKpHxNCwv5 Bak1+UWnMfGAu6LJPs52OeEq/3ZQ5+hRIt8tz7gzAgMBAAGjggI/MIICOzASBgNVHRMBAf8ECDAG AQH/AgEAMDQGA1UdHwQtMCswKaAnoCWGI2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTItZzMu Y3JsMA4GA1UdDwEB/wQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRVmVyaVNpZ25NUEtJ LTItNTYwHQYDVR0OBBYEFNhIKahfKheS4vqee+9vYIP4uLjcMIHwBgNVHSMEgegwgeWhgdCkgc0w gcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3Ig YXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMiBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczghBhcMtJjF+YRSnnsKbZUFt6MDQGCCsG AQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AudmVyaXNpZ24uY29tMGwGA1UdIARl MGMwYQYLYIZIAYb4RQEHFwIwUjAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9j cHMwKAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9ycGEwDQYJKoZIhvcNAQEF BQADggEBAKYqmwdAyez/s4joRdo00RcPKC23pYVnMc3B5tUphjis4vBZGwzhoUXOJHjvacGwTGGi SNloT7r+dVQ3ulhp6sF2pTZC6p5meJAg2ZVqJHlUzd5aGoo7rhiVctAl2NJGvjQwp4Ce8VbOIB5s Z8lNT3mHieIugNae7SZhZaID0MXi8yi5K0lpgmfs1ek0pC7cYiKkhU1I42oClPLN/eRnyEm8qtXH 5zzeh7EQa10HXBnka6D0T5nL3LVbDMwy+WrkdMAqWDd5s/vNwzRv4XbdEAcAY4sHTicXkkebDr7e DROFEfyiL2V9zDqsHlRrVmfE7qWHIiMXK3BWw/Gud1wnwTkwggeEMIIGbKADAgECAhBcCMgDVFpl hwRR0TZyMUgoMA0GCSqGSIb3DQEBBQUAMIHJMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50 ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxNTAzBgNVBAsT LENsYXNzIDIgTWFuYWdlZCBQS0kgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBMUMwQQYDVQQDEzpT eW1hbnRlYyBDbGFzcyAyIFNoYXJlZCBJbnRlcm1lZGlhdGUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5 MB4XDTE0MDQxMDAwMDAwMFoXDTE1MDQxMDIzNTk1OVowczEmMCQGCSqGSIb3DQEJARYXZW9zdGVy d2VpbEB2ZXJpc2lnbi5jb20xGDAWBgNVBAMMD09zdGVyd2VpbCwgRXJpYzEWMBQGA1UECwwNRU5U RVJQUklTRSBJVDEXMBUGA1UECgwOVmVyaVNpZ24sIEluYy4wggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQCmK2/yLaprGu39usXztz6N7uLYDoKN4MNaDFGGj1eYfMkIfb6LDoYBs9qcnINg 8in4NxGwVQGIJU5AE/1wHe/V1qavpHEO2mVxRq94cBF0P8ETPpM1yhwBhU4QKhjNEDj9wov8RXzO hjqPy/uknZvBxfobQx22vhnEKpf7QEN0zfLDJON3tyYwsnrFZkmop4ni4ANI7ev5uqcI05ED7vSh K9AHAVjzjr2QvtmvqHAkOnpHgqkWJWhuw4f9Gx+8LmbC3tl8oxF7+E7WEwKTQG56BV0uR6PN/o0S O7VSbDCZyNoxxrjzw+CesWsigi2NvC5DnhkKlxP+JSfJxMDu+7MDAgMBAAGjggO7MIIDtzAMBgNV HRMBAf8EAjAAMA4GA1UdDwEB/wQEAwIFoDAWBgNVHSUBAf8EDDAKBggrBgEFBQcDBDAdBgNVHQ4E FgQUVoVKaC1xEPB9EWKq3dWrwskIufkwUAYDVR0RBEkwR4EXZW9zdGVyd2VpbEB2ZXJpc2lnbi5j b22gLAYKKwYBBAGCNxQCA6AeDBxlb3N0ZXJ3ZWlsQHZjb3JwLmFkLnZyc24uY29tMB8GA1UdIwQY MBaAFNhIKahfKheS4vqee+9vYIP4uLjcMIIBcQYIKwYBBQUHAQEEggFjMIIBXzAnBggrBgEFBQcw AYYbaHR0cDovL3BraS1vY3NwLnN5bWF1dGguY29tMIIBMgYIKwYBBQUHMAKGggEkbGRhcDovL2Rp cmVjdG9yeS52ZXJpc2lnbi5jb20vQ04lMjAlM0QlMjBTeW1hbnRlYyUyMENsYXNzJTIwMiUyMFNo YXJlZCUyMEludGVybWVkaWF0ZSUyMENlcnRpZmljYXRlJTIwQXV0aG9yaXR5JTJDT1UlMjAlM0Ql MjBDbGFzcyUyMDIlMjBNYW5hZ2VkJTIwUEtJJTIwSW5kaXZpZHVhbCUyMFN1YnNjcmliZXIlMjBD QSUyQ09VJTIwJTNEJTIwU3ltYW50ZWMlMjBUcnVzdCUyME5ldHdvcmslMkNPJTIwJTNEJTIwU3lt YW50ZWMlMjBDb3Jwb3JhdGlvbiUyQ0MlMjAlM0QlMjBVUz9jQUNlcnRpZmljYXRlO2JpbmFyeTBd BgNVHR8EVjBUMFKgUKBOhkxodHRwOi8vcGtpLWNybC5zeW1hdXRoLmNvbS9jYV8wN2JiN2Q2NDc3 Y2Y0ZjZiZTk2YWYxYjM2Y2FiZDMxNi9MYXRlc3RDUkwuY3JsMGwGA1UdIARlMGMwYQYLYIZIAYb4 RQEHFwIwUjAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9jcHMwKAYIKwYBBQUH AgIwHBoaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9ycGEwQgYJKoZIhvcNAQkPBDUwMzAKBggqhkiG 9w0DBzALBglghkgBZQMEAQIwCwYJYIZIAWUDBAEWMAsGCWCGSAFlAwQBKjAsBgpghkgBhvhFARAD BB4wHAYSYIZIAYb4RQEQAQICAQGL8cYJFgYyNDc2NjQwOQYKYIZIAYb4RQEQBQQrMCkCAQAWJGFI UjBjSE02THk5d2Eya3RjbUV1YzNsdFlYVjBhQzVqYjIwPTANBgkqhkiG9w0BAQUFAAOCAQEAXFTS ZEP9la6QYPlo6ybMEEpxVOADx082WRGtrYoU9ZEaC2IlxmwI9JprNfBlIy8FtyJAuWKBbe9/XKJF cukb2HNS0httHUIcSTfMEsAyc99/ba/SoMlhtvko/nCvx5brzhpQwop6AgMv9v5V7F1GUFO7db8L LSs1gIZYI8IeudznJOQGUBFGe0aJhA4cD/3OIZyItWpNtn94i1GJUFPMjYhGcy/r0fUQY/KFLwOi M6bT/m1RwAJKJI/mON/OshdzylAYqKOPoFTJD4qrbrpij1r1+e1VHKklAxTd+nOg9J1L0yRwlEDS 1boeOxqNXGnEYAa54k0ZWPh+8dFemteaLjGCBE0wggRJAgEBMIHeMIHJMQswCQYDVQQGEwJVUzEd MBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5l dHdvcmsxNTAzBgNVBAsTLENsYXNzIDIgTWFuYWdlZCBQS0kgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBMUMwQQYDVQQDEzpTeW1hbnRlYyBDbGFzcyAyIFNoYXJlZCBJbnRlcm1lZGlhdGUgQ2VydGlm aWNhdGUgQXV0aG9yaXR5AhBcCMgDVFplhwRR0TZyMUgoMAkGBSsOAwIaBQCgggJDMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE0MDkzMDE5NDExNFowIwYJKoZIhvcN AQkEMRYEFLIbK5nw9o6tKzT2P4qSJGnEvk9IMIHvBgkrBgEEAYI3EAQxgeEwgd4wgckxCzAJBgNV BAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMg VHJ1c3QgTmV0d29yazE1MDMGA1UECxMsQ2xhc3MgMiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFsIFN1 YnNjcmliZXIgQ0ExQzBBBgNVBAMTOlN5bWFudGVjIENsYXNzIDIgU2hhcmVkIEludGVybWVkaWF0 ZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkCEFwIyANUWmWHBFHRNnIxSCgwgfEGCyqGSIb3DQEJEAIL MYHhoIHeMIHJMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAd BgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxNTAzBgNVBAsTLENsYXNzIDIgTWFuYWdlZCBQ S0kgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBMUMwQQYDVQQDEzpTeW1hbnRlYyBDbGFzcyAyIFNo YXJlZCBJbnRlcm1lZGlhdGUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5AhBcCMgDVFplhwRR0TZyMUgo MA0GCSqGSIb3DQEBAQUABIIBAGcY+0Iu9AoFzkC7TBcfF1z4PUd7mZAIIEC+xFtFlgqkZ3rjiJ5M FgIV/xjPxOgLhEUzRefRYAYn/Zf+zxV1ImxntgDUGp9G062wAYLjt8n5J4bBwDWe8+fsirwNMhyQ qoQKIFbCgiGGF92iC2PMDkTGWZmqujDMYbxr+/KK7E+nj9j+KpIaS67DH2gikuq/frGcOymEgWDm qqVCjh+TGmIMrQMl2vKBoLJh6sMHu7gRiItGT+jknaNOQNwjzYRTvIVMbc9yEDKG0wbdfN1o3coh PM9F5HMISNTXRChEC91gAi04f5T5NBYHRB/ECEl3fI5pbVJYewQlA55+B+Nz4SEAAAAAAAA= --Apple-Mail=_A608F195-4352-4B71-8918-BDAA770111FD-- From nobody Tue Sep 30 13:54:19 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 122671A89FB for ; Tue, 30 Sep 2014 13:54:18 -0700 (PDT) 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 BpUs6z4ar1Re for ; Tue, 30 Sep 2014 13:54:12 -0700 (PDT) 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 859AE1A897D for ; Tue, 30 Sep 2014 13:54:07 -0700 (PDT) Received: from [10.20.30.90] (142-254-17-87.dsl.dynamic.fusionbroadband.com [142.254.17.87]) (authenticated bits=0) by proper.com (8.14.9/8.14.7) with ESMTP id s8UKs4Qh002308 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 30 Sep 2014 13:54:06 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: proper.com: Host 142-254-17-87.dsl.dynamic.fusionbroadband.com [142.254.17.87] claimed to be [10.20.30.90] From: Paul Hoffman Content-Type: multipart/signed; boundary="Apple-Mail=_975D5B4A-EA8B-4AD8-BD62-E5A9838EE666"; protocol="application/pgp-signature"; micalg=pgp-sha1 Message-Id: Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Date: Tue, 30 Sep 2014 13:53:58 -0700 References: <273F9612-13AF-4CB8-B15C-912AAD04C738@verisign.com> To: dane WG list In-Reply-To: <273F9612-13AF-4CB8-B15C-912AAD04C738@verisign.com> X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/nmVzngD_i807zLB8HUuy_WdtDG8 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: Tue, 30 Sep 2014 20:54:18 -0000 --Apple-Mail=_975D5B4A-EA8B-4AD8-BD62-E5A9838EE666 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Sep 29, 2014, at 5:26 AM, Osterweil, Eric = wrote: > Based on our implementation experience we would like to suggest that = the following text (taken from Scott Rose's email: = http://www.ietf.org/mail-archive/web/dane/current/msg06180.html ) be = incorporated into the current version of the draft-ietf-dane-smime = document. We are sending text (below), but at a high-level, the text = outlines a few useful additions: >=20 > 1 - Usage #4 (reject) is likely to be very important. This could = either emphasize the difference between saying, ``don't use this cert = for this operation,'' and ``this cert is universally revoked'' or be = used to selectively override an organization-wide TA for certain = employees that have left the organization. >=20 > 2 - The certificate access field (Section 2.1.4) would enable = alternate discovery mechanisms that could help aid incremental = deployment and transition schemes. For example, while cutting over to a = DANE solution, some enterprises may want to transition users from (say) = AD to DANE, and this field would enable that. >=20 > 3 - The ``_encr'' and ``_sign'' labels are excellent additions to the = management of zone sizes and lookup sizes. Rather than querying for all = keys and then locally selecting from them, I (as an RP) likely already = know which of these I want, and I should be able to look them up = separately in DANE (and owners should be able to manage them separately = in DANE). >=20 > If anyone objects, please let us know. Jakob and I think that the three additions are unneeded here, and make = the draft diverge quite far from the TLSA format without significant = value. In specific: 1) This usage type is at least as applicable to TLS as it is to S/MIME. = We haven't seen anything indicating much use of certificate revocation = anywhere and, where we have seen it, it is much more common in TLS. If = the authors really want this feature, it should be an update to TLSA, = which SMIMEA could then adopt. 2) Making the record format for SMIMEA different than that of TLSA for = this feature seems like a bad idea. Alternate discovery mechanisms might = be important, but they will be just as important for TLS as they are for = S/MIME. The functionality that the authors want could be added to TLSA = by adding new Matching Type fields such as "Hash and NAPTR", "Hash and = URI", and so on. The latter is part of IKEv2 (although the feature is = generally considered not useful). If the authors really want this = feature, it should be an update to TLSA, which SMIMEA could then adopt. 3) There is absolutely no indication that zone size or response size is = important to SMIMEA, certainly not relative to the added complexity for = clients, servers, and operators. Currently, the RSA certs for SMIME from = common CAs are for both signing and encrypting, so this added complexity = won't buy current users anything. In the future when we are all = (hopefully) using elliptic curve keys, the zone size and response size = will be so much smaller than they are now that this change will appear = as an over-optimization that adds complexity. When these ideas were brought to the WG earlier this year, we didn't = hear any significant support. Given that both of us feel that the = proposed changes make the document harder to implement, we would want to = see much wider support before we adopt them. --Paul Hoffman and Jakob Schlyter --Apple-Mail=_975D5B4A-EA8B-4AD8-BD62-E5A9838EE666 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJUKxhrAAoJEJz/fXByZmLZvpQIAJT7mz8XkUHgf98ioiw+kBpy OvxPKQ+1CbGhGu7kmidWzUbasuSmT4/elhF/vsQsPKoNZrY7JGbG+BH32uNriniP I1oq5xpMYfBKn4NsDcTYJBXTmOoNInqF2xPbyV5lEGrQSL06+XqLdARfF7lSJ9ze TyEFzlWKLoOffjKYsnQD3E4HVjPv4gOJWMcPqc/NvNrhj4pJFuTC2Iq1cTx4sEAt hqchaLom1Id6ntjGveAroXTnUi68PFYewKjfJJhE2SC2znCzN7cPJXadShtk5DyR 8pCTnZDmKDWdDzs0bLmiVTDSxwRXDysV1xUhVC1j76+dwvVTTww26/UzeuyXpRs= =1lxB -----END PGP SIGNATURE----- --Apple-Mail=_975D5B4A-EA8B-4AD8-BD62-E5A9838EE666-- From nobody Tue Sep 30 14:12: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 DA70E1A9139; Tue, 30 Sep 2014 14:12:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZuXqaNXpVV12; Tue, 30 Sep 2014 14:12:28 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C9BD71A9132; Tue, 30 Sep 2014 14:12:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: paul.hoffman@vpnc.org,jakob@kirei.se X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140930211228.16611.43719.idtracker@ietfa.amsl.com> Date: Tue, 30 Sep 2014 14:12:28 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/nYAlE12NUPjISYXGGnE7J12DRMY Cc: dane@ietf.org, Kathleen.Moriarty.ietf@gmail.com, ipr-announce@ietf.org Subject: [dane] IPR Disclosure: Paul Hoffman's Statement about IPR related to draft-ietf-dane-smime-07 and Many other RFCs and drafts belonging to Verisign, Inc. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 21:12:30 -0000 Dear Paul E. Hoffman, Jakob Schlyter: An IPR disclosure that pertains to your Internet-Draft entitled "Using Secure DNS to Associate Certificates with Domain Names For S/MIME" (draft-ietf-dane- smime) was submitted to the IETF Secretariat on 2014-09-30 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/2446/). The title of the IPR disclosure is "Paul Hoffman's Statement about IPR related to draft-ietf-dane-smime-07 and Many other RFCs and drafts belonging to Verisign, Inc..""); The IETF Secretariat From nobody Tue Sep 30 14:27: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 8C2C81A9175; Tue, 30 Sep 2014 14:27:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gNmwXmZeRGed; Tue, 30 Sep 2014 14:27:06 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2298C1A9167; Tue, 30 Sep 2014 14:27:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: paul.hoffman@vpnc.org,jakob@kirei.se X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140930212706.31965.25882.idtracker@ietfa.amsl.com> Date: Tue, 30 Sep 2014 14:27:06 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/lLqo6ZBPIrP5Q-dJxMflGtJ35oM Cc: dane@ietf.org, Kathleen.Moriarty.ietf@gmail.com, ipr-announce@ietf.org Subject: [dane] IPR Disclosure: Paul Hoffman's Statement about IPR belonging to Verisign, Inc. related to draft-ietf-dane-smime-07 and many other RFCs and drafts X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 21:27:07 -0000 Dear Paul E. Hoffman, Jakob Schlyter: An IPR disclosure that pertains to your Internet-Draft entitled "Using Secure DNS to Associate Certificates with Domain Names For S/MIME" (draft-ietf-dane- smime) was submitted to the IETF Secretariat on 2014-09-30 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/2446/). The title of the IPR disclosure is "Paul Hoffman's Statement about IPR belonging to Verisign, Inc. related to draft-ietf-dane-smime-07 and many other RFCs and drafts.""); The IETF Secretariat