From nobody Wed Apr 1 02:26:26 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F7F41A8F36 for ; Wed, 1 Apr 2015 02:26:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O9y1d6EranfP for ; Wed, 1 Apr 2015 02:26:23 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD1861A8AED for ; Wed, 1 Apr 2015 02:26:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id A3B78BED9; Wed, 1 Apr 2015 10:26:21 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id flHukc1jswI2; Wed, 1 Apr 2015 10:26:20 +0100 (IST) Received: from [10.87.48.73] (unknown [86.46.29.244]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 04446BEAA; Wed, 1 Apr 2015 10:26:20 +0100 (IST) Message-ID: <551BB9B7.9060809@cs.tcd.ie> Date: Wed, 01 Apr 2015 10:26:15 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: John Levine , dane@ietf.org References: <20150401011715.96906.qmail@ary.lan> In-Reply-To: <20150401011715.96906.qmail@ary.lan> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dane] encoding mail addresses in the DNS 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, 01 Apr 2015 09:26:25 -0000 A nit on this topic (with no hats). I never liked the sha224 thing being used for this. If some form of hash is needed I'd much prefer if sha256 was used and then truncated. Morally, sha224 is also a truncated sha256, but it is not bitwise the same. So sha224 is generally treated as an entirely separate algorithm by APIs. Since sha256 is our current fav. hash function, there's code for that everywhere. And since sha224 is never or almost never used we normally don't need that, so sha224 might not be available on all platforms. (And could be deprecated in future even if it's present now - getting rid of unused code being a good thing.) But the real win here with a truncated sha256 is for people who have to have their code audited e.g. for CC purposes - having to have the sha224 code present for anything could cause them to incur pointless costs when doing such audits - e.g. if the auditor says: "Hey, please prove to me that you don't do any security sensitive things with sha224." This is the same logic that causes us to not want to use md5 even for non-security functions. So, if hashing anything here, please stick with sha256 and truncate the output if you need it shorter. Thanks, S. PS: Yes, I know John's draft doesn't do hashing, but since we're on the topic again, I thought I'd stick in my oar:-) On 01/04/15 02:17, John Levine wrote: >> An alternative is to go back to the original base32 encoding, which >> is lossless, and thus can allow the remote DNS server (a special-purpose >> DNS lookup engine serving a zone with per-user information) to >> decode the local-part and perform whatever fuzzy matching may be >> appropriate. >> >> The lossless encoding can support longer names by breaking them up >> into multiple labels. >> >> This allows static DNS to be published where desired, and custom >> code to produce dynamic results when appropriate. > > I wrote up a draft summarizing the ways one might do mailbox > name lookups in the DNS with something close to the local-part > rules that MTAs have: > > http://datatracker.ietf.org/doc/draft-levine-dns-mailbox/ > > There's two reversible encodings, including a worked out version of > base32 that handles full 64 character local-parts, preserves the > lexical order of local-parts, and makes signed dynamic zones at least > somewhat possible, an implementation of regular expression matching > that I think is cool, but probably doesn't scale adequately for large > mail systems, and a straightforward way to securely identify a web > lookup service. > > As far as I can tell, the base32 approach handles everything that > hashing does, is no harder to use if you want to publish a static set > of names, but still offers the possibility for large mail systems to > serve stuff on the fly. Take a look. I can send you a tiny python > script that turns local-parts into the base32 names if you want. > > R's, > John > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > > From nobody Wed Apr 1 06:19:36 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4C4F1A90C0 for ; Wed, 1 Apr 2015 06:19:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mqrVTDYHihgZ for ; Wed, 1 Apr 2015 06:19:33 -0700 (PDT) Received: from smtp108.ord1c.emailsrvr.com (smtp108.ord1c.emailsrvr.com [108.166.43.108]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55A291A908D for ; Wed, 1 Apr 2015 06:19:30 -0700 (PDT) Received: from smtp14.relay.ord1c.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp14.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id E93A7380351 for ; Wed, 1 Apr 2015 09:19:29 -0400 (EDT) Received: by smtp14.relay.ord1c.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id C8CD738032B for ; Wed, 1 Apr 2015 09:19:29 -0400 (EDT) X-Sender-Id: ogud@ogud.com Received: from [10.20.30.43] (pool-74-96-189-218.washdc.fios.verizon.net [74.96.189.218]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:465 (trex/5.4.2); Wed, 01 Apr 2015 13:19:29 GMT From: Olafur Gudmundsson Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: Date: Wed, 1 Apr 2015 09:19:29 -0400 To: "" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) Archived-At: Subject: [dane] Email box mapping: Who is responsible ? 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, 01 Apr 2015 13:19:35 -0000 Dear Colleagues=20 =20 I have been thinking about the issues in finding right email address = format for a user.=20 IMHO we need to take a step back and think about responsibilities, and = expectations as well as goals. =20 The goal is to create a simple way to find for a known = correspondent.=20 Can we assume that the email encryptor knows the address of recipients = in a format emitted by the recipients email system, and is that good = enough?=20 Can we expect a User mail agent to look up many different form of an = email address just to find an ?=20 Can we expect a Email provider to publish users email key for number of = variants of the users email address?=20 There have been mentions of EMAIL oracle, and other methods to find = =E2=80=9Ccanonical address=E2=80=9D for user.=20 Are there simple rules we can apply to email addresses that decrease the = number of combinations?=20 For example we can apply lower case rule to the left hand side before = hashing?=20 =20 =20 I think we can publish OPENPGPKEY draft as is tagging it as = Opportunistic key lookup, if it has to be labeled EXPERIMENTAL that is = fine.=20 We push the issues of canonical email discovery and techniques to = improve finding keys for random email addresses into the = OPENPGPKEY-usage document as there are things that email receivers can do as well as what senders can = do.=20 Comments.=20 Olafur=20 From nobody Wed Apr 1 06:25:43 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCADB1A90E1 for ; Wed, 1 Apr 2015 06:25:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2wK82SH1wCnq for ; Wed, 1 Apr 2015 06:25:40 -0700 (PDT) Received: from mx3.cira.ca (mx3.cira.ca [192.228.31.116]) by ietfa.amsl.com (Postfix) with ESMTP id 3116F1A90E2 for ; Wed, 1 Apr 2015 06:25:40 -0700 (PDT) X-Virus-Scanned: by SpamTitan at corp.cira.ca Received: from BAK-EXCH-03.CORP.CIRA.CA ([fe80::65f5:b482:dfd2:590d]) by BAK-EXCH-03.CORP.CIRA.CA ([fe80::65f5:b482:dfd2:590d%14]) with mapi id 14.01.0438.000; Wed, 1 Apr 2015 09:25:39 -0400 From: Jacques Latour To: Olafur Gudmundsson , "" Thread-Topic: [dane] Email box mapping: Who is responsible ? Thread-Index: AQHQbH6E6jCDLkqSOEO+5tYrUdJWSJ04JI2g Date: Wed, 1 Apr 2015 13:25:38 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.2.40.152] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [dane] Email box mapping: Who is responsible ? 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, 01 Apr 2015 13:25:42 -0000 KzENCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBkYW5lIFttYWlsdG86 ZGFuZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgT2xhZnVyDQo+IEd1ZG11bmRzc29u DQo+IFNlbnQ6IEFwcmlsLTAxLTE1IDk6MTkgQU0NCj4gVG86IDxkYW5lQGlldGYub3JnPg0KPiBT dWJqZWN0OiBbZGFuZV0gRW1haWwgYm94IG1hcHBpbmc6IFdobyBpcyByZXNwb25zaWJsZSA/DQo+ IA0KPiBEZWFyIENvbGxlYWd1ZXMNCj4gDQo+IDxjaGFpci1oYXQgb2ZmPg0KPiBJIGhhdmUgYmVl biB0aGlua2luZyBhYm91dCB0aGUgaXNzdWVzIGluIGZpbmRpbmcgcmlnaHQgZW1haWwgYWRkcmVz cyBmb3JtYXQgZm9yDQo+IGEgdXNlci4NCj4gSU1ITyB3ZSBuZWVkIHRvIHRha2UgYSBzdGVwIGJh Y2sgYW5kIHRoaW5rIGFib3V0IHJlc3BvbnNpYmlsaXRpZXMsIGFuZA0KPiBleHBlY3RhdGlvbnMg YXMgd2VsbCBhcyBnb2Fscy4NCj4gDQo+IFRoZSBnb2FsIGlzIHRvIGNyZWF0ZSBhIHNpbXBsZSB3 YXkgdG8gZmluZCA8ZW1haWwga2V5PiBmb3IgYSBrbm93bg0KPiBjb3JyZXNwb25kZW50Lg0KPiBD YW4gd2UgYXNzdW1lIHRoYXQgdGhlIGVtYWlsIGVuY3J5cHRvciBrbm93cyB0aGUgYWRkcmVzcyBv ZiByZWNpcGllbnRzIGluIGENCj4gZm9ybWF0IGVtaXR0ZWQgYnkgdGhlIHJlY2lwaWVudHMgZW1h aWwgc3lzdGVtLCBhbmQgaXMgdGhhdCBnb29kIGVub3VnaD8NCj4gDQo+IENhbiB3ZSBleHBlY3Qg YSBVc2VyIG1haWwgYWdlbnQgdG8gbG9vayB1cCBtYW55IGRpZmZlcmVudCBmb3JtIG9mIGFuIGVt YWlsDQo+IGFkZHJlc3MganVzdCB0byBmaW5kIGFuIDxlbWFpbCBrZXk+ID8NCj4gDQo+IENhbiB3 ZSBleHBlY3QgYSBFbWFpbCBwcm92aWRlciB0byBwdWJsaXNoIHVzZXJzIGVtYWlsIGtleSBmb3Ig bnVtYmVyIG9mDQo+IHZhcmlhbnRzIG9mIHRoZSB1c2VycyBlbWFpbCBhZGRyZXNzPw0KPiANCj4g VGhlcmUgaGF2ZSBiZWVuIG1lbnRpb25zIG9mIEVNQUlMIG9yYWNsZSwgYW5kIG90aGVyIG1ldGhv ZHMgdG8gZmluZA0KPiDigJxjYW5vbmljYWwgYWRkcmVzc+KAnSBmb3IgdXNlci4NCj4gDQo+IEFy ZSB0aGVyZSBzaW1wbGUgcnVsZXMgd2UgY2FuIGFwcGx5IHRvIGVtYWlsIGFkZHJlc3NlcyB0aGF0 IGRlY3JlYXNlIHRoZQ0KPiBudW1iZXIgb2YgY29tYmluYXRpb25zPw0KPiBGb3IgZXhhbXBsZSB3 ZSBjYW4gYXBwbHkgbG93ZXIgY2FzZSBydWxlIHRvIHRoZSBsZWZ0IGhhbmQgc2lkZSBiZWZvcmUN Cj4gaGFzaGluZz8NCj4gDQo+IDxjaGFpci1oYXQgb2ZmPg0KPiANCj4gPGNoYXItaGF0IG9uPg0K PiBJIHRoaW5rIHdlIGNhbiBwdWJsaXNoIE9QRU5QR1BLRVkgZHJhZnQgYXMgaXMgdGFnZ2luZyBp dCBhcyBPcHBvcnR1bmlzdGljIGtleQ0KPiBsb29rdXAsIGlmIGl0IGhhcyB0byBiZSBsYWJlbGVk IEVYUEVSSU1FTlRBTCB0aGF0IGlzIGZpbmUuDQo+IFdlICBwdXNoIHRoZSBpc3N1ZXMgb2YgY2Fu b25pY2FsIGVtYWlsIGRpc2NvdmVyeSBhbmQgdGVjaG5pcXVlcyB0byBpbXByb3ZlDQo+IGZpbmRp bmcga2V5cyBmb3IgcmFuZG9tIGVtYWlsIGFkZHJlc3NlcyBpbnRvIHRoZSBPUEVOUEdQS0VZLXVz YWdlDQo+IGRvY3VtZW50IGFzIHRoZXJlIGFyZSB0aGluZ3MgdGhhdCBlbWFpbCByZWNlaXZlcnMg Y2FuIGRvIGFzIHdlbGwgYXMgd2hhdA0KPiBzZW5kZXJzIGNhbiBkby4NCj4gDQo+IENvbW1lbnRz Lg0KPiANCj4gT2xhZnVyDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gZGFuZSBtYWlsaW5nIGxpc3QNCj4gZGFu ZUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RhbmUN Cg== From nobody Wed Apr 1 06:38:13 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 935721A9105 for ; Wed, 1 Apr 2015 06:38:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VrKD_AKerMTZ for ; Wed, 1 Apr 2015 06:38:10 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BB551A90F3 for ; Wed, 1 Apr 2015 06:38:10 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3lH7rb1MnbzCD0; Wed, 1 Apr 2015 15:38:07 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=CFHOvmQL X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id yLVbuOdY0ASL; Wed, 1 Apr 2015 15:38:04 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 1 Apr 2015 15:38:04 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id ED62D803E0; Wed, 1 Apr 2015 09:38:01 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1427895482; bh=g5z78/A0s3fZTniQoM5+dqvte8nDiRfMiSbD768E+bc=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=CFHOvmQLYHKkcEE8YEXZb3KYgekegChAVNgfqk99t7EuUDhySaHPMvafVqa/QChmp sbyXSzWnIxAJ64LYHTtTr5g3gDXHSUiFAa//dAquL5Rp0aoyZygr9ddJMKmWMNq0QT j/wyi3EXhCAAIN82hnpVAsBhExEH7tFf/0dMoMvE= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id t31Dc1ph018057; Wed, 1 Apr 2015 09:38:01 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Wed, 1 Apr 2015 09:38:01 -0400 (EDT) From: Paul Wouters To: Olafur Gudmundsson In-Reply-To: Message-ID: References: User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Cc: "" Subject: Re: [dane] Email box mapping: Who is responsible ? 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, 01 Apr 2015 13:38:12 -0000 On Wed, 1 Apr 2015, Olafur Gudmundsson wrote: > > I have been thinking about the issues in finding right email address format for a user. > IMHO we need to take a step back and think about responsibilities, and expectations as well as goals. > > The goal is to create a simple way to find for a known correspondent. > Can we assume that the email encryptor knows the address of recipients in a format emitted by the recipients email system, and is that good enough? I believe so. > Can we expect a User mail agent to look up many different form of an email address just to find an ? Whatever we say in the document, some User mail agents will probably perform multiple lookups, especially for the Firstcaps@example.com case. > Can we expect a Email provider to publish users email key for number of variants of the users email address? That is very unlikely. See the VRFY command in SMTP. > There have been mentions of EMAIL oracle, and other methods to find “canonical address” for user. > > Are there simple rules we can apply to email addresses that decrease the number of combinations? > For example we can apply lower case rule to the left hand side before hashing? I do think that lowercasing is a valid option that would reduce the number one case of requiring CNAME's for the hash("Firstcaps") use case. Even John wrote in his draft that: The most common variants are upper and lower case, which are now invariably treated as equivalent. > > I think we can publish OPENPGPKEY draft as is tagging it as Opportunistic key lookup, if it has to be labeled EXPERIMENTAL that is fine. I would prefer it not be labeled EXPERIMENTAL. This draft isn't rocket science. > We push the issues of canonical email discovery and techniques to improve finding keys for random email addresses into the OPENPGPKEY-usage document as > there are things that email receivers can do as well as what senders can do. As long as it is not decided to hold up this document over the -usage document, or else we are just moving and re-opening this same discussion again. As for Stephen's comment regarding sha224. I honestly don't care that much, but lean towards not manually cutting down hash lengths and let cryptographers make those calls. Hence the use of sha224. Paul From nobody Wed Apr 1 06:47:50 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E7991A9115 for ; Wed, 1 Apr 2015 06:47:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cyy3rjfQY4S4 for ; Wed, 1 Apr 2015 06:47:48 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EA351A9105 for ; Wed, 1 Apr 2015 06:47:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id E6D89BE8A; Wed, 1 Apr 2015 14:47:45 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7KLMK04IZg7D; Wed, 1 Apr 2015 14:47:45 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id C6A67BE88; Wed, 1 Apr 2015 14:47:45 +0100 (IST) Message-ID: <551BF702.3070106@cs.tcd.ie> Date: Wed, 01 Apr 2015 14:47:46 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Paul Wouters , Olafur Gudmundsson References: In-Reply-To: OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "" Subject: Re: [dane] Email box mapping: Who is responsible ? 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, 01 Apr 2015 13:47:49 -0000 On 01/04/15 14:38, Paul Wouters wrote: > > As for Stephen's comment regarding sha224. I honestly don't care that > much, but lean towards not manually cutting down hash lengths and let > cryptographers make those calls. Hence the use of sha224. We're not depending on either collision resistance or pre-image resistance here so truncating sha256 is way better compared to using a hash algorithm that is almost never used. S. From nobody Wed Apr 1 07:09:51 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42D031A9239 for ; Wed, 1 Apr 2015 07:09:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U0WWo2fVjlAl for ; Wed, 1 Apr 2015 07:09:48 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89CB61A9232 for ; Wed, 1 Apr 2015 07:09:43 -0700 (PDT) Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.3.224.2; Wed, 1 Apr 2015 10:09:34 -0400 Received: from postmark.nist.gov (129.6.16.94) by WSXGHUB1.xchange.nist.gov (129.6.18.96) with Microsoft SMTP Server (TLS) id 8.3.389.2; Wed, 1 Apr 2015 10:09:42 -0400 Received: from [132.163.222.28] ([132.163.222.28]) by postmark.nist.gov (8.13.8/8.13.1) with ESMTP id t31E9a6R032290 for ; Wed, 1 Apr 2015 10:09:37 -0400 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: "Rose, Scott W." In-Reply-To: Date: Wed, 1 Apr 2015 10:09:36 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <160728F8-CCC3-4C38-B795-9E98A1CCAEB0@nist.gov> References: To: "" X-Mailer: Apple Mail (2.1878.6) X-NIST-MailScanner-Information: Archived-At: Subject: Re: [dane] Email box mapping: Who is responsible ? 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, 01 Apr 2015 14:09:50 -0000 On Apr 1, 2015, at 9:38 AM, Paul Wouters wrote: > On Wed, 1 Apr 2015, Olafur Gudmundsson wrote: >=20 >> >> I have been thinking about the issues in finding right email address = format for a user. >> IMHO we need to take a step back and think about responsibilities, = and expectations as well as goals. >>=20 >> The goal is to create a simple way to find for a known = correspondent. >> Can we assume that the email encryptor knows the address of = recipients in a format emitted by the recipients email system, and is = that good enough? >=20 > I believe so. I don't but then the credentials aren't found. That is an answer - the = client/end user will need to account for that. >=20 >> Can we expect a User mail agent to look up many different form of an = email address just to find an ? >=20 > Whatever we say in the document, some User mail agents will probably > perform multiple lookups, especially for the Firstcaps@example.com = case. >=20 >> Can we expect a Email provider to publish users email key for number = of variants of the users email address? >=20 > That is very unlikely. See the VRFY command in SMTP. Some enterprises might if they feel it is important enough, but probably = only the "big ones" like FLast and flast, etc. >=20 >=20 >> >> I think we can publish OPENPGPKEY draft as is tagging it as = Opportunistic key lookup, if it has to be labeled EXPERIMENTAL that is = fine. >=20 > I would prefer it not be labeled EXPERIMENTAL. This draft isn't rocket = science. +1, Just having it opportunistic is enough. >=20 >>=20 >=20 > As for Stephen's comment regarding sha224. I honestly don't care that > much, but lean towards not manually cutting down hash lengths and let > cryptographers make those calls. Hence the use of sha224. >=20 I understand Stephen's reasoning and if it makes deployment easier for = folks who need to pass audits, then let's do that.=20 Scott > Paul >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Scott Rose NIST scott.rose@nist.gov +1 301-975-8439 Google Voice: +1 571-249-3671 http://www.dnsops.gov/ https://www.had-pilot.com/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D From nobody Wed Apr 1 07:45:33 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D025A1AC44B for ; Wed, 1 Apr 2015 07:45:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lGDK8AOdDU12 for ; Wed, 1 Apr 2015 07:45:30 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6D451ACCD9 for ; Wed, 1 Apr 2015 07:45:29 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3lH9LD61X9z4xr; Wed, 1 Apr 2015 16:45:24 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=Bj4Vm/yN X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id MU2odlfhCyUS; Wed, 1 Apr 2015 16:44:56 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 1 Apr 2015 16:44:56 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 2733E80416; Wed, 1 Apr 2015 10:44:55 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1427899495; bh=SIS8s3F/04zfEtramuUXTK3rsDLTGzeWCoy2osI2aWU=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=Bj4Vm/yNZwPb6R4x+OZPg3ivWgn2dAIhLQFhUA0rljMMqyIc7ROgX28+F8XRY67/Z Cl0KcnB39SkTtwTf/9VGBOPoPQwg6NO4FfE89j0t+mh/VTuAJKuzXaEfa2AW9qf0x/ gK5jniwe+6Vf8I29j39NCzRpxJuPmu03Vz1VIs6k= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id t31EisHs009762; Wed, 1 Apr 2015 10:44:54 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Wed, 1 Apr 2015 10:44:54 -0400 (EDT) From: Paul Wouters To: "Rose, Scott W." In-Reply-To: <160728F8-CCC3-4C38-B795-9E98A1CCAEB0@nist.gov> Message-ID: References: <160728F8-CCC3-4C38-B795-9E98A1CCAEB0@nist.gov> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: "" Subject: Re: [dane] Email box mapping: Who is responsible ? 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, 01 Apr 2015 14:45:32 -0000 On Wed, 1 Apr 2015, Rose, Scott W. wrote: >>> The goal is to create a simple way to find for a known correspondent. >>> Can we assume that the email encryptor knows the address of recipients in a format emitted by the recipients email system, and is that good enough? >> >> I believe so. > > I don't but then the credentials aren't found. That is an answer - the client/end user will need to account for that. If you do not know the email address of John Doe, your first task is to find out that email address. Once found, you can come back here and look for a key. (if you have a key, you might also have the email address, and you can verify the two are a set) Paul From nobody Wed Apr 1 07:57:27 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F20B71A8A82 for ; Wed, 1 Apr 2015 07:57:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CTNgiSXpnnoU for ; Wed, 1 Apr 2015 07:57:25 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 940191AC3DB for ; Wed, 1 Apr 2015 07:57:08 -0700 (PDT) Received: (qmail 52741 invoked from network); 1 Apr 2015 14:57:07 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=ce04.551c0743.k1504; bh=P/9vN2YjTpC9cE+UTpNq9I/Sqlho7o+6sKOLQVoLEbQ=; b=A66CzvfgmmlksSMMSRZpjAjW8jwCpIHrdq0Q8sp1sttotsWMdlt2kZyVRlCKXimHgK7UW6P/jA1b/KJ/OUhzSj2kEsde4d4t9mYW5DK+P5Zj2SBLkoH3jBng67dV6+yljUGPcNy5kcDjCAdck0nvlVxT7cx64ZU+vZVySGsXEsH9I4dtdbvyvDK8dTBioE7eUj4ApwIsKuY98kFIi62+64gNJEdWOrnzBTX1hYUi8QTv6o3qSA69vgpZSFE8EAVs DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=ce04.551c0743.k1504; bh=P/9vN2YjTpC9cE+UTpNq9I/Sqlho7o+6sKOLQVoLEbQ=; b=kw6c0ailGjKTFKdBcnSzi0hWUtlkfiqcNUN7MX3598jGBG+B5pYAUGQNeh50xWS1wHfDY2ctFM1EuEgCs5FG3e1QjStsFesNxRq2xwyQRiDmYwX8Mv/ju/U+fF2nU0Pt8DvpfH2PDroB2pp0JVzKydA+F81qfg7EfR0ShTANnBTz3cGa3KCi4CHGg3/3Q2OPA44ZzNuOFaEsMOZ3SUci5dhNG/1r5kL9N9kbVqWQyospnzVglFe7Bswat7CYNK0s Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 01 Apr 2015 14:57:07 -0000 Date: 1 Apr 2015 10:57:06 -0400 Message-ID: From: "John R Levine" To: "Stephen Farrell" In-Reply-To: <551BB9B7.9060809@cs.tcd.ie> References: <20150401011715.96906.qmail@ary.lan> <551BB9B7.9060809@cs.tcd.ie> User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: dane@ietf.org Subject: Re: [dane] encoding mail addresses in the DNS 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, 01 Apr 2015 14:57:26 -0000 > So, if hashing anything here, please stick with sha256 and truncate > the output if you need it shorter. For reasons discussed at great length, I don't think any sort of hash is a good idea here. Do you see any problems with the base32 encoding? Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Wed Apr 1 09:05:57 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 620021ACE9C for ; Wed, 1 Apr 2015 09:05:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hOW0VrysXUsn for ; Wed, 1 Apr 2015 09:05:51 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F10C01AC3EF for ; Wed, 1 Apr 2015 09:05:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id D11CDBEE2; Wed, 1 Apr 2015 17:05:48 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id boVxi0Ifn3dV; Wed, 1 Apr 2015 17:05:48 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id B0635BEDB; Wed, 1 Apr 2015 17:05:48 +0100 (IST) Message-ID: <551C175C.8070301@cs.tcd.ie> Date: Wed, 01 Apr 2015 17:05:48 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: John R Levine References: <20150401011715.96906.qmail@ary.lan> <551BB9B7.9060809@cs.tcd.ie> In-Reply-To: OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: dane@ietf.org Subject: Re: [dane] encoding mail addresses in the DNS 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, 01 Apr 2015 16:05:54 -0000 On 01/04/15 15:57, John R Levine wrote: >> So, if hashing anything here, please stick with sha256 and truncate >> the output if you need it shorter. > > For reasons discussed at great length, I don't think any sort of hash is > a good idea here. Do you see any problems with the base32 encoding? I'm neutral, but just took the opportunity to get back up on my own hobby horse:-) S > > Regards, > John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY > Please consider the environment before reading this e-mail. > From nobody Wed Apr 1 09:16:00 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E8C81ACE36 for ; Wed, 1 Apr 2015 09:15:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KQwQt_ujfsKB for ; Wed, 1 Apr 2015 09:15:55 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 624C21A1A64 for ; Wed, 1 Apr 2015 09:15:55 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3lHCLd2T5xzCL3; Wed, 1 Apr 2015 18:15:53 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=VGx2/zge X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id SlH5ec3DvfUY; Wed, 1 Apr 2015 18:15:47 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 1 Apr 2015 18:15:47 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id B1442803E0; Wed, 1 Apr 2015 12:15:46 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1427904946; bh=e4R00su01bEmQICsj89WThM4KsAoC3dDZjXjAn7UKYA=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=VGx2/zgeu5u5VHB5GYBHCLAvIGrXZQvf9PM74gnqwplIY+ad9hP45QJL64SCbGHiV Pargj52bpD3Q5zkMMFBbFb6MDkSeqmnuSJ50ZmwGpVstJdLSPoTlN33VLO17yh5vzy 8k9/rwdgaUDiu+5v85o+3g3UzdYgmGIncMPBs/Bs= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id t31GFjZ4022279; Wed, 1 Apr 2015 12:15:46 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Wed, 1 Apr 2015 12:15:45 -0400 (EDT) From: Paul Wouters To: John R Levine In-Reply-To: Message-ID: References: <20150401011715.96906.qmail@ary.lan> <551BB9B7.9060809@cs.tcd.ie> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: dane WG list Subject: Re: [dane] encoding mail addresses in the DNS 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, 01 Apr 2015 16:15:57 -0000 On Wed, 1 Apr 2015, John R Levine wrote: >> So, if hashing anything here, please stick with sha256 and truncate >> the output if you need it shorter. > > For reasons discussed at great length, I don't think any sort of hash is a > good idea here. Do you see any problems with the base32 encoding? The current mechanism for lookup can only return exact matches. The application creating the query already has access to the unhashed name. So whatever future protocol extension is used, the application can use the unhashed name with that future extension. Applications using base32 would still need to have an exact match to return anything in DNS - so I do not understand the use of base32 and another confusing empty non-terminal dot in DNS. I do not understand the advantage of base32 in the QNAME. Paul From nobody Wed Apr 1 09:16:23 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 053511A907B for ; Wed, 1 Apr 2015 09:16:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v__y2d_jKT-7 for ; Wed, 1 Apr 2015 09:16:21 -0700 (PDT) Received: from proper.com (Opus1.Proper.COM [207.182.41.91]) (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 2CB281A1A64 for ; Wed, 1 Apr 2015 09:16:21 -0700 (PDT) Received: from [10.20.30.101] (50-1-51-95.dsl.dynamic.fusionbroadband.com [50.1.51.95]) (authenticated bits=0) by proper.com (8.15.1/8.14.9) with ESMTPSA id t31GGITV043021 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Apr 2015 09:16:20 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: proper.com: Host 50-1-51-95.dsl.dynamic.fusionbroadband.com [50.1.51.95] claimed to be [10.20.30.101] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Paul Hoffman In-Reply-To: Date: Wed, 1 Apr 2015 09:16:18 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Olafur Gudmundsson X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "" Subject: Re: [dane] Email box mapping: Who is responsible ? 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, 01 Apr 2015 16:16:22 -0000 On Apr 1, 2015, at 6:19 AM, Olafur Gudmundsson wrote: > =20 > I think we can publish OPENPGPKEY draft as is tagging it as = Opportunistic key lookup, if it has to be labeled EXPERIMENTAL that is = fine.=20 > We push the issues of canonical email discovery and techniques to = improve finding keys for random email addresses into the = OPENPGPKEY-usage document as > there are things that email receivers can do as well as what senders = can do.=20 It does not have to be labeled "experimental". Saying that we know how = to do exact-name lookup is not experimental at all. --Paul Hoffman= From nobody Wed Apr 1 09:21:01 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 980971AD0A6 for ; Wed, 1 Apr 2015 09:21:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] 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 IvczDtQZIRjD for ; Wed, 1 Apr 2015 09:21:00 -0700 (PDT) Received: from homiemail-a64.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 25B831AD0AA for ; Wed, 1 Apr 2015 09:20:58 -0700 (PDT) Received: from homiemail-a64.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTP id 03FD4438080 for ; Wed, 1 Apr 2015 09:20:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=552Anxjiv1WSmdrEPYn4 zY3HRko=; b=ChDDRxR1aVBbKuARolzzQJztibHlFDOvRwqfHtJOuAdDxBRBqmFl axPcI86eSzljf4iRe9Zmzzqul/oD8bzUagtAeuzQpDXD1wg30ogYvJ7WQ7396b5T xjByxhAWcgbx98jBMCwGeAhB4fLt8U2K2AmVJQP5m18EzT6rD2ZvrDY= Received: from mail-ig0-f182.google.com (mail-ig0-f182.google.com [209.85.213.182]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTPSA id 525E243809F for ; Wed, 1 Apr 2015 09:20:57 -0700 (PDT) Received: by igbud6 with SMTP id ud6so52957470igb.1 for ; Wed, 01 Apr 2015 09:20:53 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.107.164.69 with SMTP id n66mr64883865ioe.82.1427905253630; Wed, 01 Apr 2015 09:20:53 -0700 (PDT) Received: by 10.64.130.66 with HTTP; Wed, 1 Apr 2015 09:20:53 -0700 (PDT) In-Reply-To: <20150401011715.96906.qmail@ary.lan> References: <20150330023734.GP17637@mournblade.imrryr.org> <20150401011715.96906.qmail@ary.lan> Date: Wed, 1 Apr 2015 11:20:53 -0500 Message-ID: From: Nico Williams To: John Levine Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: dane WG list Subject: Re: [dane] encoding mail addresses in the DNS 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, 01 Apr 2015 16:21:00 -0000 John, I'm OK with sections 4.1 and 6 from your I-D, provided that MUAs that implement either MUST implement both. This leaves the choice to mail domains, and it addresses the scalability issues discussed. I would add that the URI RRs for section 6 should be signed, that clients must validate them with DNSSEC, that the URIs must be HTTPS URIs, and that the authority of each such URI SHOULD (MUST?) have TLSA RRs. Nico -- From nobody Wed Apr 1 09:23:49 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C0041ACEB2 for ; Wed, 1 Apr 2015 09:23:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YyMwxvkmgpqN for ; Wed, 1 Apr 2015 09:23:47 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC0F11A8958 for ; Wed, 1 Apr 2015 09:23:46 -0700 (PDT) Received: (qmail 68469 invoked from network); 1 Apr 2015 16:23:45 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=10b74.551c1b91.k1504; bh=IMnW0t3wgcAFuw46deGWk8mlgpJBP2akS7EHtM4DKrg=; b=v3/xttFJYEA5/7g4d5yzVMmi8yVEP/kvHI35/7nZeaRLRyHGde0dQfJGvPYmmp37ugU77wyA5i9UWcCsI8+2TKfxiYHozNIZpixwGdnW0TXVoZqXcN8q2mSRVMsy2O4vwmIaIKS/u9CCLNp2LI0/PJz/VDlbbnKjBR+yX0CJFL0bIAIvVvTjK2r2aaeyRcNESRepVvYbdRzA0MK592ZwRTZqOaXLxZh9eW/k/5lI5nohb88kuLh9ZgsYkEmnH/Cy DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=10b74.551c1b91.k1504; bh=IMnW0t3wgcAFuw46deGWk8mlgpJBP2akS7EHtM4DKrg=; b=hUTBCgNc+O2yiOSWQfL4/7qSj8lB5nD9hJqTkjYPFttN6CNqKj3SjeXtY50KhYd01jLBGNjPG5Iqv1coGIpyLRKdNzjS0wywBHJ8PbXWwh3uFwz/MH3qedO8yDegnbKrnRXgRcP97x/ILVNwXl9fFsx2TxRbPNr0Pu6ZJ3amLHjuGUiXkZY9lfsFaFduF+3PNltclNN4VWL8ZuIY0u6XNmhBzkjpexmmEnQWLa0M9QkoXIIdxVHo/fyzXkWf0Ym0 Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 01 Apr 2015 16:23:45 -0000 Date: 1 Apr 2015 12:23:45 -0400 Message-ID: From: "John R Levine" To: "Paul Wouters" In-Reply-To: References: <20150401011715.96906.qmail@ary.lan> <551BB9B7.9060809@cs.tcd.ie> User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: dane WG list Subject: Re: [dane] encoding mail addresses in the DNS 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, 01 Apr 2015 16:23:48 -0000 > Applications using base32 would still need to have an exact match to > return anything in DNS - so I do not understand the use of base32 and > another confusing empty non-terminal dot in DNS. > > I do not understand the advantage of base32 in the QNAME. As Viktor pointed out, the advantage is that the server can easily recover the local-part from the query, which makes it possible for a specialized server to do whatever it does and generate a response dynamically. You can't do that with hashes. I've written DNS servers that generate responses on the fly from a database where it does application-specific lookups and transformations. It's surprisingly easy. They don't do DNSSEC yet but I'm planning to take a whack at that later this year. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Wed Apr 1 09:26:16 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5137E1ACEB7 for ; Wed, 1 Apr 2015 09:26:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Smtx_M5WI3sP for ; Wed, 1 Apr 2015 09:26:14 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AAA31A0AFE for ; Wed, 1 Apr 2015 09:26:14 -0700 (PDT) Received: (qmail 68816 invoked from network); 1 Apr 2015 16:26:13 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=10ccf.551c1c25.k1504; bh=2kMY/jegTX2aXWXNU4v/fX5CS+MS9qBJEtko004GzhY=; b=jDsSJ4eeZV6+kvw7jbZLYEgjxhtqexG1NGdPQo1TkWkBgUEJlDyN0071w7imrawOp3zIN5W9JRG6TvGSl6kAdsj2ksSoeWKoyM3IPpu6OPdJ1cKm0ayhzY5DGJZhHFoz0aMnviSFHX/EycUghoGzIcPM/3QLC2Do+rrUm96Y5BXq+tBRunyPQdYF6ouAltcskCoqLzZ3WevArbUOejuvCskeTUeoLh7BSq0NqKmyqZTups3OsJUOKZho9C9quYEx DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=10ccf.551c1c25.k1504; bh=2kMY/jegTX2aXWXNU4v/fX5CS+MS9qBJEtko004GzhY=; b=sl5NEwaY6250H74cp6rUZKe7jdm6B0WAGJKVgN+IEO+twRPwew6i8UFUW6lrJyXe//IQFDH8DtA4fqP6v/BryPbugNswWfEEpjKD75cZDjbhBogZRh8qTfuOX5yILZf72Wg9JL61/Lwb9bD3xfx2sFhUr3UFqYjSSjpJQJTEF2Gw/xzPghnaMM1qtYYaH6s10vRcWakB5cNnYwdvpdu2c90fxQfXM1uo53baVq/KGTQIGBm3QGzyhxbkDdy3ThhV Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 01 Apr 2015 16:26:13 -0000 Date: 1 Apr 2015 12:26:12 -0400 Message-ID: From: "John R Levine" To: "Nico Williams" In-Reply-To: References: <20150330023734.GP17637@mournblade.imrryr.org> <20150401011715.96906.qmail@ary.lan> User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: dane WG list Subject: Re: [dane] encoding mail addresses in the DNS 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, 01 Apr 2015 16:26:15 -0000 > I'm OK with sections 4.1 and 6 from your I-D, provided that MUAs that > implement either MUST implement both. This leaves the choice to mail > domains, and it addresses the scalability issues discussed. You'll notice that my draft says its intended status is experimental. We really need some experience with this stuff before we try to cast it in stone. I know of at least two projects to do SMIMEA support in an MUA, so with any luck we can find out how it works reasonably soon. > I would add that the URI RRs for section 6 should be signed, that > clients must validate them with DNSSEC, that the URIs must be HTTPS > URIs, and that the authority of each such URI SHOULD (MUST?) have TLSA > RRs. Well, sure. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Wed Apr 1 09:36:47 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CD1A1AD0C9 for ; Wed, 1 Apr 2015 09:36:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] 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 PCTosrieNsjy for ; Wed, 1 Apr 2015 09:36:42 -0700 (PDT) Received: from homiemail-a103.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 7FF351AD0BD for ; Wed, 1 Apr 2015 09:36:42 -0700 (PDT) Received: from homiemail-a103.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a103.g.dreamhost.com (Postfix) with ESMTP id 61A402005E625 for ; Wed, 1 Apr 2015 09:36:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=nYBtpGIvpsuRhIxfMHMM I6snK+o=; b=boK1gWzPPRdQiRx8ZWaueHwVx8liZ7dqzbZNicjECObhsujBi1HG rSapQdiRfCMq67eFRy+SM2MWIXOqcoTj6FzPtoVU8vYZdtY3g2b5xgabx8s66Zjy 40Phw9cuibLgsyXsD8NPhvVXlyqXuknXjXH9B1Fmm5VjdmT66tiyoQM= Received: from mail-ig0-f178.google.com (mail-ig0-f178.google.com [209.85.213.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a103.g.dreamhost.com (Postfix) with ESMTPSA id 2067F2005E601 for ; Wed, 1 Apr 2015 09:36:42 -0700 (PDT) Received: by igbqf9 with SMTP id qf9so51021472igb.1 for ; Wed, 01 Apr 2015 09:36:40 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.107.29.21 with SMTP id d21mr66258757iod.11.1427906200847; Wed, 01 Apr 2015 09:36:40 -0700 (PDT) Received: by 10.64.130.66 with HTTP; Wed, 1 Apr 2015 09:36:40 -0700 (PDT) In-Reply-To: References: <20150330023734.GP17637@mournblade.imrryr.org> <20150401011715.96906.qmail@ary.lan> Date: Wed, 1 Apr 2015 11:36:40 -0500 Message-ID: From: Nico Williams To: John R Levine Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: dane WG list Subject: Re: [dane] encoding mail addresses in the DNS 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, 01 Apr 2015 16:36:46 -0000 On Wed, Apr 1, 2015 at 11:26 AM, John R Levine wrote: >> I'm OK with sections 4.1 and 6 from your I-D, provided that MUAs that >> implement either MUST implement both. This leaves the choice to mail >> domains, and it addresses the scalability issues discussed. > > You'll notice that my draft says its intended status is experimental. We > really need some experience with this stuff before we try to cast it in > stone. I know of at least two projects to do SMIMEA support in an MUA, so > with any luck we can find out how it works reasonably soon. It can be experimental if you like, but if we don't require MUA support for both of these methods we'll be stuck later. We must at least recommend it. I don't think publishing as experimental absolves us of addressing that problem now, nor does it mean that we can't have normative or quasi-normaitve language in the document. >> I would add that the URI RRs for section 6 should be signed, that >> clients must validate them with DNSSEC, that the URIs must be HTTPS >> URIs, and that the authority of each such URI SHOULD (MUST?) have TLSA >> RRs. > > Well, sure. I know it's obvious, but it has to be stated. From nobody Wed Apr 1 09:44:14 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEF5E1AC3D3 for ; Wed, 1 Apr 2015 09:44:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B5NJ6Nbo3CJy for ; Wed, 1 Apr 2015 09:44:06 -0700 (PDT) Received: from proper.com (Opus1.Proper.COM [207.182.41.91]) (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 9F0CD1B29C8 for ; Wed, 1 Apr 2015 09:43:35 -0700 (PDT) Received: from [10.20.30.101] (50-1-51-95.dsl.dynamic.fusionbroadband.com [50.1.51.95]) (authenticated bits=0) by proper.com (8.15.1/8.14.9) with ESMTPSA id t31GhYLo044589 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Apr 2015 09:43:34 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: proper.com: Host 50-1-51-95.dsl.dynamic.fusionbroadband.com [50.1.51.95] claimed to be [10.20.30.101] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Paul Hoffman In-Reply-To: Date: Wed, 1 Apr 2015 09:43:33 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8165EA2A-8A2B-47CD-884A-7126AE21C5F7@vpnc.org> References: <20150401011715.96906.qmail@ary.lan> <551BB9B7.9060809@cs.tcd.ie> To: John R Levine X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: dane WG list Subject: Re: [dane] encoding mail addresses in the DNS 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, 01 Apr 2015 16:44:06 -0000 On Apr 1, 2015, at 9:23 AM, John R Levine wrote: >=20 >> Applications using base32 would still need to have an exact match to >> return anything in DNS - so I do not understand the use of base32 and >> another confusing empty non-terminal dot in DNS. >>=20 >> I do not understand the advantage of base32 in the QNAME. >=20 > As Viktor pointed out, the advantage is that the server can easily = recover the local-part from the query, which makes it possible for a = specialized server to do whatever it does and generate a response = dynamically. You can't do that with hashes. >=20 > I've written DNS servers that generate responses on the fly from a = database where it does application-specific lookups and transformations. = It's surprisingly easy. They don't do DNSSEC yet but I'm planning to = take a whack at that later this year. This sounds like a new protocol that changes the nature of the DNS. = That's fine, but it certainly does not belong in DANE, and probably not = in DNSOP. --Paul Hoffman= From nobody Wed Apr 1 09:47:00 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A18D1AC418 for ; Wed, 1 Apr 2015 09:46:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ASyqiDKUcXCZ for ; Wed, 1 Apr 2015 09:46:58 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A9051AC3D3 for ; Wed, 1 Apr 2015 09:46:58 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3lHD2S42fGz7vS for ; Wed, 1 Apr 2015 18:46:56 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=m/T9bwpj X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id T-vAy2el2FJ3 for ; Wed, 1 Apr 2015 18:46:51 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for ; Wed, 1 Apr 2015 18:46:51 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id E119A803E0 for ; Wed, 1 Apr 2015 12:46:49 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1427906809; bh=KJSe+R+uhTEStg6qeDVT3Cduk/I3lHF5ddY0r31kgiA=; h=Date:From:To:Subject:In-Reply-To:References; b=m/T9bwpj4mTrSWUA0Bo9TNQlDXhUXydM3Gg1X/sdD3AGV1ET3PRc7416GDhjmksgF +OFQ10I+73ohhvb7Dx5086Km+txZnim242r3mECjcWquAAyyTWra0kQSsXZxsd/PQm F8agGE/mNI+ZK+IB/VHTuixIkraJHT83Rn0xVi+Y= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id t31GknjL016339 for ; Wed, 1 Apr 2015 12:46:49 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Wed, 1 Apr 2015 12:46:49 -0400 (EDT) From: Paul Wouters To: dane WG list In-Reply-To: Message-ID: References: <20150401011715.96906.qmail@ary.lan> <551BB9B7.9060809@cs.tcd.ie> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dane] encoding mail addresses in the DNS 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, 01 Apr 2015 16:46:59 -0000 On Wed, 1 Apr 2015, John R Levine wrote: >> I do not understand the advantage of base32 in the QNAME. > > As Viktor pointed out, the advantage is that the server can easily recover > the local-part from the query, which makes it possible for a specialized > server to do whatever it does and generate a response dynamically. You can't > do that with hashes. Which might make sense for SMTP servers or whatever new protocol servers you come up with, but not for DNS QNAMEs. > I've written DNS servers that generate responses on the fly from a database > where it does application-specific lookups and transformations. It's > surprisingly easy. They don't do DNSSEC yet but I'm planning to take a whack > at that later this year. And you will be re-creating user/zone enumeration walking if you would. And you would violate the rule that only mail servers apparently may interpret mailbox names, and not secondary name servers. Unless you add a whole bunch of other requirements to this document, like DNS servers need to synchronise mailbox names and DNS servers must require online DNSSEC signing. Anything more complicated than a simple query-response, does not belong in the DNS. Once you are not in the DNS, your application can use the original LHS without any encoding and use whateve non-DNS protocol extension you come up with. Paul From nobody Wed Apr 1 09:49:32 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB30C1A905E for ; Wed, 1 Apr 2015 09:49:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] 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 6q3JpbubkcW2 for ; Wed, 1 Apr 2015 09:49:30 -0700 (PDT) Received: from homiemail-a31.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id E72BB1A8939 for ; Wed, 1 Apr 2015 09:49:30 -0700 (PDT) Received: from homiemail-a31.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTP id BFAEF20203C for ; Wed, 1 Apr 2015 09:49:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=pVv2DmtALMKhFiiEDW3A gcL5Nc0=; b=kSON1YL41/2hA4Ci/019/ePwVhTJDC4Ti0oX30LH/xwU4bQy5MEh EJi3gBwXG4tdhttSvAOIIQLrfQ7AU+Drlu8OJ8kCclcgbjQRjn8pAK7OG3Casldx PHhB1W7DwJaUjqw0GvC/Iyi2aF6Tl7udbUSfSKY40LOWvdT+hWa06Uw= Received: from mail-ie0-f175.google.com (mail-ie0-f175.google.com [209.85.223.175]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTPSA id 77F25202022 for ; Wed, 1 Apr 2015 09:49:30 -0700 (PDT) Received: by iebmp1 with SMTP id mp1so41160615ieb.0 for ; Wed, 01 Apr 2015 09:49:29 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.107.29.21 with SMTP id d21mr66340463iod.11.1427906969129; Wed, 01 Apr 2015 09:49:29 -0700 (PDT) Received: by 10.64.130.66 with HTTP; Wed, 1 Apr 2015 09:49:29 -0700 (PDT) In-Reply-To: <8165EA2A-8A2B-47CD-884A-7126AE21C5F7@vpnc.org> References: <20150401011715.96906.qmail@ary.lan> <551BB9B7.9060809@cs.tcd.ie> <8165EA2A-8A2B-47CD-884A-7126AE21C5F7@vpnc.org> Date: Wed, 1 Apr 2015 11:49:29 -0500 Message-ID: From: Nico Williams To: Paul Hoffman Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: John R Levine , dane WG list Subject: Re: [dane] encoding mail addresses in the DNS 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, 01 Apr 2015 16:49:31 -0000 On Wed, Apr 1, 2015 at 11:43 AM, Paul Hoffman wrote: > On Apr 1, 2015, at 9:23 AM, John R Levine wrote: >> >>> Applications using base32 would still need to have an exact match to >>> return anything in DNS - so I do not understand the use of base32 and >>> another confusing empty non-terminal dot in DNS. >>> >>> I do not understand the advantage of base32 in the QNAME. >> >> As Viktor pointed out, the advantage is that the server can easily recover the local-part from the query, which makes it possible for a specialized server to do whatever it does and generate a response dynamically. You can't do that with hashes. >> >> I've written DNS servers that generate responses on the fly from a database where it does application-specific lookups and transformations. It's surprisingly easy. They don't do DNSSEC yet but I'm planning to take a whack at that later this year. > > This sounds like a new protocol that changes the nature of the DNS. That's fine, but it certainly does not belong in DANE, and probably not in DNSOP. DNS servers exist which serve dynamically-generated data, and DNS servers exist which serve signed (on the fly) dynamically-generated RRsets with non-existence proofs. IIUC PowerDNS is one example. Nico -- From nobody Wed Apr 1 09:51:53 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C76651A905E for ; Wed, 1 Apr 2015 09:51:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p-RVKlPhp70x for ; Wed, 1 Apr 2015 09:51:47 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C20AF1ACEC2 for ; Wed, 1 Apr 2015 09:51:46 -0700 (PDT) Received: (qmail 73651 invoked from network); 1 Apr 2015 16:51:45 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=11fb2.551c2221.k1504; bh=j0qH3BSZ03P6ELLLDKX/8B24Ohrp64e10hu9io3C2PY=; b=fPveGlwFGc13jitvgge9erhtbwZN0DLlqPqkuj5mz+oWGeGP7uA9fs9QHetGB8DY4kV0F5bnlettQmzEHZipUlq9kQsEDCecbck+ehqxGmYmZmYvkEYCufYn3PosSQfChGSknJPSnlKsfMMBeTW5cr5XBop63TsItSmmyH/RkAkrO/uZmss9vh/yROgUxW3AkxeXcZWfxmPbFN3rtuWKoTj65iI+rdM00hhpn6f8ykRElqC6MF0jSnRN9a7gftJE DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=11fb2.551c2221.k1504; bh=j0qH3BSZ03P6ELLLDKX/8B24Ohrp64e10hu9io3C2PY=; b=J3bMWQrSFhMy/gFsTKjCQJcuMLw02i9G623uyKmV8ZqE+gxtp3XUdbBhjjnSQSe33spOgsJWFTxUbOuit0buy/YHnF18V/DR42ZnKuhhZ3l9sqVhxTw5N8cPE0/WL6+cAkYRuSZNegIMUhYzNsH+PDmtlYOTIpUPj1X3RIOqy56nvZ/BDi+QXDom6rL/X/OdL3Skf+MmWPftGAZLlneCb4XYPHbKNkpLFq8VYI63GezE5n/F67QpLoAGdndI9W4T Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 01 Apr 2015 16:51:45 -0000 Date: 1 Apr 2015 12:51:44 -0400 Message-ID: From: "John R Levine" To: "Paul Hoffman" In-Reply-To: <8165EA2A-8A2B-47CD-884A-7126AE21C5F7@vpnc.org> References: <20150401011715.96906.qmail@ary.lan> <551BB9B7.9060809@cs.tcd.ie> <8165EA2A-8A2B-47CD-884A-7126AE21C5F7@vpnc.org> User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: dane WG list Subject: Re: [dane] encoding mail addresses in the DNS 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, 01 Apr 2015 16:51:47 -0000 >> I've written DNS servers that generate responses on the fly from a database where it does application-specific lookups and transformations. It's surprisingly easy. They don't do DNSSEC yet but I'm planning to take a whack at that later this year. > > This sounds like a new protocol that changes the nature of the DNS. > That's fine, but it certainly does not belong in DANE, and probably not > in DNSOP. Not at all. The queries and reponses are exactly the same as with any other DNS operations. Only the internal implementation of the DNS server is different. I've been sending dynamically generated responses to queries to contacts.abuse.net for the better part of a decade with no interop problems I'm aware of, so it can't be that new or exotic. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Wed Apr 1 09:54:05 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C61EF1ACE0A for ; Wed, 1 Apr 2015 09:54:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zM8goKAV_Au5 for ; Wed, 1 Apr 2015 09:54:02 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A85531ACD36 for ; Wed, 1 Apr 2015 09:54:02 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3lHDBb6Mfhz7vS for ; Wed, 1 Apr 2015 18:53:59 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=Sawwz9xq X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id KWjdJmPywbUd for ; Wed, 1 Apr 2015 18:53:59 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for ; Wed, 1 Apr 2015 18:53:59 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 24602803E0 for ; Wed, 1 Apr 2015 12:53:58 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1427907238; bh=mjTknwYpjyTM7fQ24pzesawqmC8260gYhp4JTI2aqOA=; h=Date:From:To:Subject:In-Reply-To:References; b=Sawwz9xq4q8UYwpohKd3siusYm5IHmes+hElAEftewgz5VWn79BH0GogeFYGkvU17 71CvjIXoDwOPBxN6pYHVX2BeLH2QoVrMk2ehjrJtwaXF4wabTFARR5aTYQaLig+yq6 aYgMeM7eux6dqEy43uQBnIAE5rpOsG0TIaEuUVgQ= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id t31GrvKn022239 for ; Wed, 1 Apr 2015 12:53:57 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Wed, 1 Apr 2015 12:53:57 -0400 (EDT) From: Paul Wouters To: dane WG list In-Reply-To: Message-ID: References: <20150401011715.96906.qmail@ary.lan> <551BB9B7.9060809@cs.tcd.ie> <8165EA2A-8A2B-47CD-884A-7126AE21C5F7@vpnc.org> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dane] encoding mail addresses in the DNS 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, 01 Apr 2015 16:54:03 -0000 On Wed, 1 Apr 2015, Nico Williams wrote: > DNS servers exist which serve dynamically-generated data, and DNS > servers exist which serve signed (on the fly) dynamically-generated > RRsets with non-existence proofs. IIUC PowerDNS is one example. And requiring the private DNS key is available on all name servers for online signing really adds a huge amount of risk to the server in case of compromise - an attacker could make up OPENPGPKEY records. Paul From nobody Wed Apr 1 10:24:46 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DFF41A0113 for ; Wed, 1 Apr 2015 10:24:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.138 X-Spam-Level: X-Spam-Status: No, score=-1.138 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, 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 mdBJ0-8GyN8z for ; Wed, 1 Apr 2015 10:24:42 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 793BC1A00DF for ; Wed, 1 Apr 2015 10:24:42 -0700 (PDT) Received: (qmail 77843 invoked from network); 1 Apr 2015 17:24:41 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 1 Apr 2015 17:24:41 -0000 Date: 1 Apr 2015 17:24:19 -0000 Message-ID: <20150401172419.770.qmail@ary.lan> From: "John Levine" To: dane@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dane] Email box mapping: Who is responsible ? 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, 01 Apr 2015 17:24:44 -0000 >The goal is to create a simple way to find for a known correspondent. >Can we assume that the email encryptor knows the address of recipients in a format emitted by the recipients email >system, and is that good enough? I have a stack of business cards on my desk about 10cm high. Every one has at least one e-mail address that I am presumably expected to type in by hand. (Two have QR codes, but they have text addresses, too, which is good since my laptop doesn't have a QR scanner.) With internationalized addresses, the fuzz problem gets a lot worse. Domain names have normalization rules so there's no ambiguity about whether to use the separate or precomposed accented letters and the like. But internationalized local-parts remain totally opaque to the sender. I expect that inbound MTAs will do lots of normalization on incoming addresses, but there is no way to predict from the outside what they'll do, or what their internal normalized format will be. This means that hand-typed internationalized addresses are unlikely to match the internal form the recipient MTA uses without some intermediate massaging, and nobody but the MTA knows what massaging to do. >I think we can publish OPENPGPKEY draft as is tagging it as Opportunistic key lookup, > if it has to be labeled EXPERIMENTAL that is fine. That seems appropriate. The design is well-defined, but we have no experience to tell us whether it'll be workable in practice. This reminds me of the early EAI drafts which were also experimental. The address protocol was well defined, but it turned out to be unworkable in practice, so for the standards track we did something different. R's, John PS: I still don't understand the opposition to base32. From nobody Wed Apr 1 10:54:06 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D8A11A1A6F for ; Wed, 1 Apr 2015 10:54:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] 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 t_dMaEuCPMII for ; Wed, 1 Apr 2015 10:54:02 -0700 (PDT) Received: from homiemail-a49.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id BA5CB1A0270 for ; Wed, 1 Apr 2015 10:54:02 -0700 (PDT) Received: from homiemail-a49.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a49.g.dreamhost.com (Postfix) with ESMTP id 7E271200D5787; Wed, 1 Apr 2015 10:54:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=Gtmiw7Gw8QEn30 lMSnH6QowG9BQ=; b=cJP5CDoTkuuzxtFqoo7hdX3VHjkcLL/TqZF4ViAOf8E/wx m6E8siPOksz7lXbTxcILAZiwxVFIxceJN9mcAGImRZ8zlgKGA3QWfWsRecD1xaQ0 5ZNx262I5Uk3zQH7idFY8L3QZGCDFcetROuQc9mNEjlUAuBqT04uZGFruzfaw= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a49.g.dreamhost.com (Postfix) with ESMTPA id E10A5200D5786; Wed, 1 Apr 2015 10:54:00 -0700 (PDT) Date: Wed, 1 Apr 2015 12:53:59 -0500 From: Nico Williams To: Paul Wouters Message-ID: <20150401175357.GY10960@localhost> References: <20150401011715.96906.qmail@ary.lan> <551BB9B7.9060809@cs.tcd.ie> <8165EA2A-8A2B-47CD-884A-7126AE21C5F7@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: dane WG list Subject: Re: [dane] encoding mail addresses in the DNS 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, 01 Apr 2015 17:54:05 -0000 On Wed, Apr 01, 2015 at 12:53:57PM -0400, Paul Wouters wrote: > On Wed, 1 Apr 2015, Nico Williams wrote: > >DNS servers exist which serve dynamically-generated data, and DNS > >servers exist which serve signed (on the fly) dynamically-generated > >RRsets with non-existence proofs. IIUC PowerDNS is one example. > > And requiring the private DNS key is available on all name servers > for online signing really adds a huge amount of risk to the server > in case of compromise - an attacker could make up OPENPGPKEY records. Any dynamic lookup will have this problem. The pointer-to-server approach has the same problem, only at an HTTPS server instead of at a DNS server. The scope of compromise can be limited in both cases (since the online keys in the DNS case could be for just the SMIME/OPENPGP sub-zones). John L.'s regexp DFA concept doesn't have any such problems, but I think it'd be rather slow for MUAs... Any mail domain that chooses simply not to implement any dynamic mailbox name canonicalization can fob off all normalization problems onto users. Nico -- From nobody Wed Apr 1 11:13:46 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5FE41A1B7C for ; Wed, 1 Apr 2015 11:13:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] 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 m_JNsI10Cwll for ; Wed, 1 Apr 2015 11:13:43 -0700 (PDT) Received: from homiemail-a55.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id D87EF1A1A69 for ; Wed, 1 Apr 2015 11:13:43 -0700 (PDT) Received: from homiemail-a55.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a55.g.dreamhost.com (Postfix) with ESMTP id 9C62B2A07; Wed, 1 Apr 2015 11:13:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=AjPV9KmLAGOZfb 6jxOQtKvtmeBo=; b=pKlLVZRr95fFkHVgoQ0Lecbur6eW0jt2YxX4T4j2vznwN+ OKeMAeeMZm1g9vQbIlkkEey9nvLjgnKp3BdE+iHRX3GSFYwX/K7HZIq/QyUVXZNa feRc+U3BHnmWHg5tbuChXyXQ9u3eWG3NXC4BTfpNuATlJ45aUuYUzRYe+5CSI= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a55.g.dreamhost.com (Postfix) with ESMTPA id D4D072A06; Wed, 1 Apr 2015 11:13:42 -0700 (PDT) Date: Wed, 1 Apr 2015 13:13:41 -0500 From: Nico Williams To: John Levine Message-ID: <20150401181339.GZ10960@localhost> References: <20150330023734.GP17637@mournblade.imrryr.org> <20150401011715.96906.qmail@ary.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150401011715.96906.qmail@ary.lan> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: dane@ietf.org Subject: Re: [dane] encoding mail addresses in the DNS 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, 01 Apr 2015 18:13:45 -0000 On Wed, Apr 01, 2015 at 01:17:15AM -0000, John Levine wrote: > >An alternative is to go back to the original base32 encoding, which > >is lossless, and thus can allow the remote DNS server (a special-purpose > >DNS lookup engine serving a zone with per-user information) to > >decode the local-part and perform whatever fuzzy matching may be > >appropriate. > > > >The lossless encoding can support longer names by breaking them up > >into multiple labels. > > > >This allows static DNS to be published where desired, and custom > >code to produce dynamic results when appropriate. > > I wrote up a draft summarizing the ways one might do mailbox > name lookups in the DNS with something close to the local-part > rules that MTAs have: > > http://datatracker.ietf.org/doc/draft-levine-dns-mailbox/ The All Names Valid approach has a problem: we're looking for S/MIME or OPENPGP public keys, so that's what needs to be found. For any public key algorithms where not every possible bit string is a possible public key, and where clients can figure that out, the server would have to generate distinct plausible public keys, otherwise clients could still enumerate the set of plausible mailboxes. I would still prefer to require MUAs to implement the DNS (base32-encoded) LHS lookup and the pointer-to-HTTPS-server lookup. Whether mail domains choose to implement static or dynamic DNS lookups, or the pointer-to-HTTPS-server, should be up to them. That said, I really don't mind living with users having to type in peers' e-mail addresses correctly. Forcing users to either have easy-to-enter email addresses on their business cards (and/or QR codes) or publish all reasonable variants of their e-mail addresses, seems perfectly reasonable -if annoying, for the +list use case- to me. The choice should be the mail domain admins'. Nico -- From nobody Wed Apr 1 11:35:42 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE0811A70E1 for ; Wed, 1 Apr 2015 11:35:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id njV6tVcpW3Ai for ; Wed, 1 Apr 2015 11:35:38 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36C0B1A7003 for ; Wed, 1 Apr 2015 11:35:38 -0700 (PDT) Received: (qmail 89047 invoked from network); 1 Apr 2015 18:35:36 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=15bd6.551c3a78.k1504; bh=Kn70o/YbnkdFgYFF5lwmk8bEN4ZL96bxTdmdL79rTzY=; b=rvLAejFfudf9+da//qx2Vij+eg16uPcWX1kjwsePeXd1dnmNOUpv1kYJ0HCzzqT3KMnXBaJ7C45jS71/OwtN3Qe/x8K+Qpob3Azaoapk5czTjixh6PilUZB/iKqPV7vCSjPrB4WVSBj/bVTvEKnfVEIQvsrHU85FhbWX3vWJCzhnckd6678cWwkmhoU+K7sAcayRdQV4wrSGAxEhw3VxZFR6N1ZwJD5/5g/pb4pFbmUh5RVDBj5Ng0cSleMTLdGK DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=15bd6.551c3a78.k1504; bh=Kn70o/YbnkdFgYFF5lwmk8bEN4ZL96bxTdmdL79rTzY=; b=f+J9KAAuR5wjBWFDqX8uAajB7OA4JT+h5bMIa3f82VD8TgaQaCgou9yWyPUVcwmmIKHIMPmbLH9H8HJ81G/OMWOfQVBWzdNJLkDRc7dBqjqcKVOMAXB3mLmGUKSlaupta6Wsamyts5rOq1nlNJ/7rrIkauHpoVYOZECoO0LzbiZLmlv3SE+KSlXJTGuMpGMUBKsFj974kTQj5EEldwr9uNLTZ3iK0hPEvWh1mSCBiaIrRBSxPS2DxXvRHiu+5ShB Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 01 Apr 2015 18:35:36 -0000 Date: 1 Apr 2015 14:35:36 -0400 Message-ID: From: "John R Levine" To: "Nico Williams" In-Reply-To: <20150401181339.GZ10960@localhost> References: <20150330023734.GP17637@mournblade.imrryr.org> <20150401011715.96906.qmail@ary.lan> <20150401181339.GZ10960@localhost> User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: dane@ietf.org Subject: Re: [dane] encoding mail addresses in the DNS 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, 01 Apr 2015 18:35:40 -0000 >> http://datatracker.ietf.org/doc/draft-levine-dns-mailbox/ > > The All Names Valid approach has a problem: we're looking for S/MIME or > OPENPGP public keys, so that's what needs to be found. For any public > key algorithms where not every possible bit string is a possible public > key, and where clients can figure that out, the server would have to > generate distinct plausible public keys, otherwise clients could still > enumerate the set of plausible mailboxes. That would require 2^512 lookups, which I hope we agree is too slow. Every possible name returns an answer, the vast majority of which have a null key. Since there's no NXDOMAINs, there's no pointers to tell you where the next non-null key is. If you're worried about people guessing addresses through dictionary attacks, they do that now, there's no way to prevent that without also preventing legitimate lookups, although you can greatly mitigate the damage by rate limiting when you see a lot of failures. > I would still prefer to require MUAs to implement the DNS > (base32-encoded) LHS lookup and the pointer-to-HTTPS-server lookup. > Whether mail domains choose to implement static or dynamic DNS lookups, > or the pointer-to-HTTPS-server, should be up to them. I don't feel strongly about whether base32 or pointer-to-https is better, but history tells us that if you have two services that are supposed to be the same, they never are. That's why we need to do experiments to see what's workable in practice so we can pick one that we know servers can implmenent and users can use. > That said, I really don't mind living with users having to type in > peers' e-mail addresses correctly. I just don't see that agreeing with reality. Particularly with non-ASCII names, there's way too many ways to type what looks like the same thing. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Wed Apr 1 13:44:58 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1384C1A90B5 for ; Wed, 1 Apr 2015 13:44:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tJgF0aVhmx_8 for ; Wed, 1 Apr 2015 13:44:48 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 465DC1A913E for ; Wed, 1 Apr 2015 13:44:48 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3lHKJn3lffz4xr; Wed, 1 Apr 2015 22:44:40 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=nwv0Zv1I X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id YgqL4lOWlP_K; Wed, 1 Apr 2015 22:44:32 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 1 Apr 2015 22:44:31 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 5603C8078B; Wed, 1 Apr 2015 16:44:25 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1427921065; bh=TpiD2r6fhR6E/kWPl1A7fFr4hVlOLj2ebYif5nd9Z3A=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=nwv0Zv1IlbDXw1Bn9jT/Meizb2ZrdfHKcUlGDiAn2ruNmejc7MVOzdGmpZMx5+iq4 kHfcUB1GYaoOKi53ZD+Bb/kAQEgOOLYuUiPRyhmbLRjurRUcxOHKQYzCPDkY4vSdwA GNusK0l5juxLWYpj8+KVR8clwF/pV2z5V4I/GYY4= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id t31KiOOp022083; Wed, 1 Apr 2015 16:44:24 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Wed, 1 Apr 2015 16:44:24 -0400 (EDT) From: Paul Wouters To: Nico Williams In-Reply-To: <20150401175357.GY10960@localhost> Message-ID: References: <20150401011715.96906.qmail@ary.lan> <551BB9B7.9060809@cs.tcd.ie> <8165EA2A-8A2B-47CD-884A-7126AE21C5F7@vpnc.org> <20150401175357.GY10960@localhost> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: dane WG list Subject: Re: [dane] encoding mail addresses in the DNS 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, 01 Apr 2015 20:44:56 -0000 On Wed, 1 Apr 2015, Nico Williams wrote: >> And requiring the private DNS key is available on all name servers >> for online signing really adds a huge amount of risk to the server >> in case of compromise - an attacker could make up OPENPGPKEY records. > > Any dynamic lookup will have this problem. Not a non-dns based lookup that has no private DNSKEY ? > The pointer-to-server > approach has the same problem, only at an HTTPS server instead of at a > DNS server. Yes, in addition to not being able to tell an outage from an attack like DNS with "indeterminate" or "bogus". > The scope of compromise can be limited in both cases (since > the online keys in the DNS case could be for just the SMIME/OPENPGP > sub-zones). Those zones are the only ones that matter if you want to replace a PGP key? I don't understand your point. > John L.'s regexp DFA concept doesn't have any such problems, I guess I still don't understand where this matching engine that returns variable answers actually lives..... > but I think it'd be rather slow for MUAs... Slow for MUA's and MTA's don't really matter that much. Some people greylist for an hour. > Any mail domain that chooses simply not to implement any dynamic mailbox > name canonicalization can fob off all normalization problems onto users. Agreed, but I still don't understand how using base32 in DNS helps that draft at all. The QNAME either matches or not. You cannot return a DNS record that does not match the QNAME/QTYPE. Paul From nobody Wed Apr 1 13:53:37 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72CE91A92E3 for ; Wed, 1 Apr 2015 13:53:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.01 X-Spam-Level: X-Spam-Status: No, score=-4.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_LETTER=-2, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7xyqGSltp7ap for ; Wed, 1 Apr 2015 13:53:35 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B3641A9251 for ; Wed, 1 Apr 2015 13:53:30 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3lHKVw3Znhz4xr for ; Wed, 1 Apr 2015 22:53:28 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=m6CpudCc X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id BMe4RxHGCBgJ for ; Wed, 1 Apr 2015 22:53:27 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for ; Wed, 1 Apr 2015 22:53:27 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 71EE28078B for ; Wed, 1 Apr 2015 16:53:26 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1427921606; bh=deNl4tV3KqwK7YQ7L0l35wqERhhPSdX0a2sJ8CRWdpI=; h=Date:From:To:Subject:In-Reply-To:References; b=m6CpudCccXwGtfhucxm7ClF83IyZRsl406e6qEPEeBv8U/kM1b0tkyB8YlTtQAnW0 pdsOM0f1FfSoaP9Hjn9yEH09+z0AR4VBcLeoc+FCPTEtCas7RRGQt5K6D0rrVoYZUm epxNg3gay7Oi/xL1/htwLQGaNVBLHIQKZHrQDFw8= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id t31KrQZj029571 for ; Wed, 1 Apr 2015 16:53:26 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Wed, 1 Apr 2015 16:53:26 -0400 (EDT) From: Paul Wouters To: dane WG list In-Reply-To: Message-ID: References: <20150330023734.GP17637@mournblade.imrryr.org> <20150401011715.96906.qmail@ary.lan> <20150401181339.GZ10960@localhost> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dane] encoding mail addresses in the DNS 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, 01 Apr 2015 20:53:36 -0000 On Wed, 1 Apr 2015, John R Levine wrote: >> That said, I really don't mind living with users having to type in >> peers' e-mail addresses correctly. > > I just don't see that agreeing with reality. Particularly with non-ASCII > names, there's way too many ways to type what looks like the same thing. This is not a problem that is fixable in any way. I do not know how to type in any letter in any script that is not on my keyboard. My keyboard has no Arabic, Chinese, French, Korean or German characters on it. I have no chance whatsoever to ever be able to type any of that in. I'm sure people with an Arabic keyboard can't enter Traditional Chinese either, so this is a problem for 100% of internet users. If that's the only thing on your business card, the world cannot email you. At best, they will type as best they can into google, and hope it will find a page with the correct email address on it for cut and paste and hope it works. This has absoutely nothing to do with encryption. I can't solve this problem and I'm not going to try and solve that problem. Paul From nobody Wed Apr 1 14:16:44 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75E051A03AA for ; Wed, 1 Apr 2015 14:16:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] 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 G9Zh4RhYZ_-x for ; Wed, 1 Apr 2015 14:16:42 -0700 (PDT) Received: from homiemail-a29.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 83D131A01E2 for ; Wed, 1 Apr 2015 14:16:42 -0700 (PDT) Received: from homiemail-a29.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTP id 1313D67409D; Wed, 1 Apr 2015 14:16:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=7chPh4zZ0CITlU WL2QzTZW9fEDs=; b=xNTDQFzyvxnKIUDV6EAFoPDZfZvZ+WgJoDBG7WgFz/sRvn U1jeLXm6j0bfFYRqCH8hpTDNeH67ZqfwEOwThjk0ZkvlzrcO4wpP6Xs4bBUjL2jy LhZLluehvU9U5P8m/6/O3ZryDb8O49R6nHnkaPWfdn5zaoX0ECOaN5ccQkJsE= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTPA id A003A67406A; Wed, 1 Apr 2015 14:16:39 -0700 (PDT) Date: Wed, 1 Apr 2015 16:16:37 -0500 From: Nico Williams To: Paul Wouters Message-ID: <20150401211636.GB10960@localhost> References: <20150401011715.96906.qmail@ary.lan> <551BB9B7.9060809@cs.tcd.ie> <8165EA2A-8A2B-47CD-884A-7126AE21C5F7@vpnc.org> <20150401175357.GY10960@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: dane WG list Subject: Re: [dane] encoding mail addresses in the DNS 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, 01 Apr 2015 21:16:43 -0000 On Wed, Apr 01, 2015 at 04:44:24PM -0400, Paul Wouters wrote: > On Wed, 1 Apr 2015, Nico Williams wrote: > >>And requiring the private DNS key is available on all name servers > >>for online signing really adds a huge amount of risk to the server > >>in case of compromise - an attacker could make up OPENPGPKEY records. > > > >Any dynamic lookup will have this problem. > > Not a non-dns based lookup that has no private DNSKEY ? (Recall that we have a label suitable for doing a zone cut such that the SMIME and OPENPGP mappings are in their own zone, with its own signing keys. I expect operators to make that zone cut, and the I-D should recommend it, when the mappings are dynamic and require on-line private keys.) In both cases there are private keys which are used to protect just the mailbox->public key mappings and nothing else. The scope of compromise is the same in both cases. > > The pointer-to-server > >approach has the same problem, only at an HTTPS server instead of at a > >DNS server. > > Yes, in addition to not being able to tell an outage from an attack like > DNS with "indeterminate" or "bogus". DNS has that too (timeouts, SERVFAIL). > >The scope of compromise can be limited in both cases (since > >the online keys in the DNS case could be for just the SMIME/OPENPGP > >sub-zones). > > Those zones are the only ones that matter if you want to replace a PGP > key? I don't understand your point. You can't use compromise of a live-signed dynamic zone to compromise a parent or sibling zone that is not signed with the same keys. > >John L.'s regexp DFA concept doesn't have any such problems, > > I guess I still don't understand where this matching engine that returns > variable answers actually lives..... In the MUA. > >but I think it'd be rather slow for MUAs... > > Slow for MUA's and MTA's don't really matter that much. Some people > greylist for an hour. MUA UI latency matters a great deal. As for MTAs: they wouldn't be doing these lookups (unless you want your MTA to auto-encrypt to your correspondents when it can). > >Any mail domain that chooses simply not to implement any dynamic mailbox > >name canonicalization can fob off all normalization problems onto users. > > Agreed, but I still don't understand how using base32 in DNS helps that > draft at all. The QNAME either matches or not. You cannot return a DNS > record that does not match the QNAME/QTYPE. If we don't care to do anything other than exact matching then hashing works, but so does base32 encoding. A loss-less encoding makes it easier to deal with on the operator/ publisher side. Nico -- From nobody Wed Apr 1 14:45:42 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B2C81A86F7 for ; Wed, 1 Apr 2015 14:45:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.611 X-Spam-Level: X-Spam-Status: No, score=-0.611 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZeMZa_PGROlX for ; Wed, 1 Apr 2015 14:45:39 -0700 (PDT) Received: from ore.jhcloos.com (ore.jhcloos.com [198.147.23.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 601291A6F11 for ; Wed, 1 Apr 2015 14:45:39 -0700 (PDT) Received: by ore.jhcloos.com (Postfix, from userid 10) id 89EEE1EF73; Wed, 1 Apr 2015 21:45:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore14; t=1427924738; bh=iyKwPrBHYQMXniZH1rkHuqjwDU0ta2WsKtxas36FkOg=; h=From:To:Subject:In-Reply-To:References:Date:From; b=nIeVhJ+PeWx/bEiu6P8APUB2LGAmX5hDXCFDC103iEcqYaQLLperDlC1lDFz9JXNI N05HvOedOPcVZbw57+4Tb7IpLDG1d3sR9JThKRqQQZfD9vQ5W6WJGTxQ+szxcsWNBZ G62yF29owuvtO3rhHPoBK7ABfh7G1/wa/J5WMjWs= Received: by carbon.jhcloos.org (Postfix, from userid 500) id D5332106FD880; Wed, 1 Apr 2015 21:45:16 +0000 (UTC) From: James Cloos To: In-Reply-To: (Paul Wouters's message of "Wed, 1 Apr 2015 16:53:26 -0400 (EDT)") References: <20150330023734.GP17637@mournblade.imrryr.org> <20150401011715.96906.qmail@ary.lan> <20150401181339.GZ10960@localhost> User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/25.0.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2015 James Cloos OpenPGP: 0x997A9F17ED7DAEA6; url=https://jhcloos.com/public_key/0x997A9F17ED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Wed, 01 Apr 2015 17:45:16 -0400 Message-ID: Lines: 24 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:28:150401:dane@ietf.org::Sxoc9z/LpWBr3gMJ:0005qo45 Archived-At: Subject: Re: [dane] encoding mail addresses in the DNS 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, 01 Apr 2015 21:45:41 -0000 [replying to semi-random post in the thread] I think the real problem is the idea of using OPENPGPCERT as a discovery mechanism. It doesn't need to be. It works much better as just an additional trust path. For openpgp, an hkps query followed by a dane lookup on each uid in the returned keyset will work much better. Or webfinger followed by dane. With TLSA offering a trust path for the https. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 From nobody Wed Apr 1 14:55:52 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3122F1A884B for ; Wed, 1 Apr 2015 14:55:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.41 X-Spam-Level: X-Spam-Status: No, score=-1.41 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_42=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4zDSOhu3uj3R for ; Wed, 1 Apr 2015 14:55:49 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD19D1A8857 for ; Wed, 1 Apr 2015 14:55:48 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3lHLtp2Rphz6f; Wed, 1 Apr 2015 23:55:46 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=f9f0ABtc X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id U25o5TDW5HFS; Wed, 1 Apr 2015 23:55:44 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 1 Apr 2015 23:55:44 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id C3637803E0; Wed, 1 Apr 2015 17:55:43 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1427925343; bh=R2j4TeZrU/jMDdBecAlwEZbvfxLT2l0ERSx0D1IAr1g=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=f9f0ABtcZ9DSv0h/IYJjFw8tQkdQPMOXKQPrwGDa34g1C+4wMxz7+sRpcn71tcnwH /NZlNPvMYTe8rbI7vptLTYjAYCw4d/GNYiuDvAI4uw/nW0/F+rqNdAr0RbfTZdX+59 HGixV5EehKV0C12eQpCLmfoFrEzsi89DiCDQsLX8= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id t31Lthn9016752; Wed, 1 Apr 2015 17:55:43 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Wed, 1 Apr 2015 17:55:43 -0400 (EDT) From: Paul Wouters To: Nico Williams In-Reply-To: <20150401211636.GB10960@localhost> Message-ID: References: <20150401011715.96906.qmail@ary.lan> <551BB9B7.9060809@cs.tcd.ie> <8165EA2A-8A2B-47CD-884A-7126AE21C5F7@vpnc.org> <20150401175357.GY10960@localhost> <20150401211636.GB10960@localhost> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: dane WG list Subject: Re: [dane] encoding mail addresses in the DNS 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, 01 Apr 2015 21:55:51 -0000 On Wed, 1 Apr 2015, Nico Williams wrote: > (Recall that we have a label suitable for doing a zone cut such that the > SMIME and OPENPGP mappings are in their own zone, with its own signing > keys. I expect operators to make that zone cut, and the I-D should > recommend it, when the mappings are dynamic and require on-line private > keys.) Yes, but if anything, the document should recommend not to use online DNSSEC signing for _openpgpkey zones. It would be a prime attack vector. By using offline signing, no one can ever forge an OPENPGPKEY even if they own the DNS server or the Mail server. >> Yes, in addition to not being able to tell an outage from an attack like >> DNS with "indeterminate" or "bogus". > > DNS has that too (timeouts, SERVFAIL). Yes, but those lead clearly to "indeterminate" and are handled as "verification failure". And DNS is much harder to block than a mapping server on port 12345. And does not have corner cases on what to do when the TLSA record matches the web server but the certificate is expired, or uses a blacklisted CA or has the wrong EKU bits or many other things that TLS libraries will check for you even if you don't care about it. (I know, I do X.509 in IKE and deal with crypto libraries that only have TLS as use case) >>> The scope of compromise can be limited in both cases (since >>> the online keys in the DNS case could be for just the SMIME/OPENPGP >>> sub-zones). >> >> Those zones are the only ones that matter if you want to replace a PGP >> key? I don't understand your point. > > You can't use compromise of a live-signed dynamic zone to compromise a > parent or sibling zone that is not signed with the same keys. huh? I don't need to compromise the parent of _openpgpkey.nohats.ca if I compromise _openpgpkey.nohats.ca, although if I could clearly I can redelegate _openpgpkey.nohats.ca. Although not all zones will use a zone cut for _openpgpkey. >>> John L.'s regexp DFA concept doesn't have any such problems, >> >> I guess I still don't understand where this matching engine that returns >> variable answers actually lives..... > > In the MUA. The way John explains it to me, the matching engine lives in the dynamic DNS server code - You send base32-cat("paul") as QNAME and you actually get the answer to the QNAME of base32("wouters"). It gets even more complicated because now to ensure you're not being lied to, you need the NSEC(3) proof that the entry with QNAME "paul" does in fact, not exist. So now you are looking at a DNS protocol change. Unless you do online signing... Furthermore this ties user accounts, SMTP and DNS servers all together in a dynamic way and need to ensure those are all servers are sync'ed up. I know of many people who gave up on even just running secondary MX because of the user lookup problem and double bounces via their secondary MX. The mail system does not have a good track record here for small and simple redundant deployments. And all for a use case that has not even be solved for unecrypted email, where I attempt to type in some french, german or traditional chinese LHS from a business card into my email client and somehow magically I end up mailing the right email address that my keyboard does not even support inputting. >>> but I think it'd be rather slow for MUAs... >> >> Slow for MUA's and MTA's don't really matter that much. Some people >> greylist for an hour. > > MUA UI latency matters a great deal. Ok, in the corner case of you first typing the content of the email, and only then the From: line, yes you are right, it matters :P > As for MTAs: they wouldn't be doing these lookups (unless you want your > MTA to auto-encrypt to your correspondents when it can). Exactly why I wrote: https://github.com/letoams/openpgpkey-milter >>> Any mail domain that chooses simply not to implement any dynamic mailbox >>> name canonicalization can fob off all normalization problems onto users. >> >> Agreed, but I still don't understand how using base32 in DNS helps that >> draft at all. The QNAME either matches or not. You cannot return a DNS >> record that does not match the QNAME/QTYPE. > > If we don't care to do anything other than exact matching then hashing > works, but so does base32 encoding. > > A loss-less encoding makes it easier to deal with on the operator/ > publisher side. And using a "." in there will increase the change of dns wire or dns presentation format mistakes in running code. Which is one of the reasons we opted for a hash that fits within 63 characters. Implementation simplicity. Paul From nobody Wed Apr 1 15:21:13 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A8E61A87BF for ; Wed, 1 Apr 2015 15:21:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.554 X-Spam-Level: X-Spam-Status: No, score=-1.554 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, URIBL_GREY=0.424] 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 PCnsb9luXwna for ; Wed, 1 Apr 2015 15:21:10 -0700 (PDT) Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03DE11A87C6 for ; Wed, 1 Apr 2015 15:21:10 -0700 (PDT) Received: by wibgn9 with SMTP id gn9so83751867wib.1 for ; Wed, 01 Apr 2015 15:21:08 -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=4APVHEsalcsJfed0PTERosI3pmsbbXVbYryndSboWqc=; b=BhuHcLOOoLxZ9zvSF0dtmmLJtUBJM+bPjX6LQNPz7vsDfsOjlSdrspQjw35bxyZx8n fFi+agQACvlmXfhrjVdUTutVpkG40DbUANoyKbKV9dzC+EWAGf6N1kA3u4jjYoYNE1en lbvbP1VD4vuDw618m0Fs0Gde6zyzrm6uA/jtaXeKAMyRJ47Pvhjy3F/17qv4AmSGWZqp QCqr05pEUDC8WgGbzspfC8fK2Jct4ASB74GHL055oAD6lkuqqTv1jQlWM0kjTf+XGB1p MEtCqm0tPdyYBLMYTwCWWGEEWgnZkBzuOgqJM9a+r8h5UMkaVTFuTQr5YNGnPdT9tK4h MY7g== X-Gm-Message-State: ALoCoQn+lq7FEaWOrRNzYZOM1+GhY5V/gbCkzOM+Gvyo4fuRowt6cKPXf6kq66UQlPtApYW1JK4m MIME-Version: 1.0 X-Received: by 10.180.93.166 with SMTP id cv6mr18636219wib.89.1427926868758; Wed, 01 Apr 2015 15:21:08 -0700 (PDT) Received: by 10.194.110.97 with HTTP; Wed, 1 Apr 2015 15:21:08 -0700 (PDT) Date: Wed, 1 Apr 2015 18:21:08 -0400 Message-ID: From: Warren Kumari To: "" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [dane] Virtual Queue Experiment for DANE X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 22:21:11 -0000 Hi all, The secretariat / remote participation folk would like you to complete a survey on how the Virtual Queue Experiment went (the thing that looked like PacMan and have a queue that folk could join). Survey is here: https://www.surveymonkey.com/s/92dane Thanks, 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 Wed Apr 1 16:14:01 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B59BE1A88F5 for ; Wed, 1 Apr 2015 16:13:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.037 X-Spam-Level: X-Spam-Status: No, score=-1.037 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K_56yT52AhGb for ; Wed, 1 Apr 2015 16:13:58 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 709A91A1A3C for ; Wed, 1 Apr 2015 16:13:58 -0700 (PDT) Received: (qmail 29390 invoked from network); 1 Apr 2015 23:13:57 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 1 Apr 2015 23:13:57 -0000 Date: 1 Apr 2015 23:13:35 -0000 Message-ID: <20150401231335.1770.qmail@ary.lan> From: "John Levine" To: dane@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: paul@nohats.ca Subject: Re: [dane] encoding mail addresses in the DNS 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, 01 Apr 2015 23:13:59 -0000 >> I just don't see that agreeing with reality. Particularly with non-ASCII >> names, there's way too many ways to type what looks like the same thing. > >This is not a problem that is fixable in any way. One of the major reasons that mail servers do fuzzy matching of local-parts is so they can deal with the multiple ways people might type something. It's a problem the mail world has been dealing with for decades. The challenge is figuring out how to port the solutions into the DNS if we're going to publish mail addresses in the DNS. >This has absoutely nothing to do with encryption. Quite true, but this discussion is about mail addresses at least as much as it's about encryption. Recall that last week we saw a proposal to publish payment info using the same naming scheme. I still don't see what the objection is to base32. If you want to publish a static set of names on a regular DNS server, you can do that, the same way you'd do hashed local-parts. Or if you're up for a more challenging programming task, you can write a DNS server that takes the queried local-parts and uses your MTA's mailbox rules when it responsds to DNS queries. R's, John From nobody Wed Apr 1 17:12:47 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 218C11A90C8 for ; Wed, 1 Apr 2015 17:12:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6EODVVZd6cqH for ; Wed, 1 Apr 2015 17:12:41 -0700 (PDT) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C9EA1A1BFA for ; Wed, 1 Apr 2015 17:12:41 -0700 (PDT) Received: by iebmp1 with SMTP id mp1so49945218ieb.0 for ; Wed, 01 Apr 2015 17:12:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1qCHKL2OjlBcZJtl2yPA2vADMXIHekYWMDyZ6i/Jg+4=; b=ncN5CqNhT/zSL7OldRJbmGwRifj0O3zLqN+swivVpgB6s+TWg5Epol/klKiwivckUA MJRKpU5i2ckHet+VOiB39z9qL5BN8KLK/rdlr4LhYZkMFVCt14PtRhiU2VYiK9Rd73eQ ldy1wbw+Zm2qyKAy4u9r+30vQ6AqAlrxcYlYxh3bpNaGJkagUDKzUxLMIG7kXk3uoyfW V1D69vx3uER6Pjn2PBYSQrXrmAfz+uhW/JWVKXXKWsZ5REwJ28ypnwdhmGpC7KFaS3TS UYIOa9mGPywHdn5j+WPas9SAK6RqeIC2ZUa3RtUsCcZr3E6bsNvkSZFvBRTaEZMPBgvD UEMg== MIME-Version: 1.0 X-Received: by 10.107.13.136 with SMTP id 130mr30109004ion.70.1427933560912; Wed, 01 Apr 2015 17:12:40 -0700 (PDT) Received: by 10.64.57.201 with HTTP; Wed, 1 Apr 2015 17:12:40 -0700 (PDT) In-Reply-To: <20150401011715.96906.qmail@ary.lan> References: <20150330023734.GP17637@mournblade.imrryr.org> <20150401011715.96906.qmail@ary.lan> Date: Wed, 1 Apr 2015 17:12:40 -0700 Message-ID: From: Brian Dickson To: John Levine Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "dane@ietf.org" Subject: Re: [dane] encoding mail addresses in the DNS 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, 02 Apr 2015 00:12:45 -0000 On Tue, Mar 31, 2015 at 6:17 PM, John Levine wrote: >>An alternative is to go back to the original base32 encoding, which >>is lossless, > As far as I can tell, the base32 approach handles everything that > hashing does The draf, has a "characters/octets" conflation problem, as do the sequence of successors to RFC-822. This likely dates back to the before-UTF and before-IDNA era, and how the docs were updated. What is not clear to me, reviewing the updates over time, are the following: - when and why was the 64-length local-part introduced? (It appeared magically in RFC 2821 4.5.3.1) - when it changed from "64 characters" to "64 octets" in RFC 5321, this implicitly affected UTF-2/3/4 languages - was this impact considered? (In UTF, #characters is not automatically #octets.) - is the 64 octet limit sufficiently universally enforced to be considered an actual de-facto standard? - is it really the case that UTF-2 mailboxes are <= 32 characters, UTF-3 mailboxes <= 21 characters, and UTF-4 mailboxes <= 16 characters? Hashing, by definition, does not care about the length of local-part, and thus is less restrictive. In effect, it ignores that 64 character limit. (I'm not entirely sure if that is a pro, con, or irrelevant.) However, the _other_ issue is that the length of local-part _encoding_ implicitly limits the parent domain name length. Using 2 x 52-octet long labels, reduces the maximum domain name length to 255-106=149 octets, minus whatever the "_mailbox" label's length is, and is applicable to IDNA and non-IDNA domain names alike. Each A-label encoding of a multi-level name, eats 5 octets (xn-- plus the dot). At 3 labels , this becomes 125 octets of punycode. Dividing that by 2, 3, or 4 (for various UTF flavors) and then splitting that into 3 parts (one per label), runs the risk of running the host name out of characters. So, simply from an IDNA perspective, hashing is less restrictive (105 vs e.g. 56). Brian From nobody Wed Apr 1 17:16:14 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6757F1ACEA5 for ; Wed, 1 Apr 2015 17:16:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zZ5iwdOyc98R for ; Wed, 1 Apr 2015 17:16:11 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09AA91ACEA4 for ; Wed, 1 Apr 2015 17:16:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id ED024BF02 for ; Thu, 2 Apr 2015 01:16:07 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fdhIs852g-Uk for ; Thu, 2 Apr 2015 01:16:06 +0100 (IST) Received: from [10.87.48.73] (unknown [86.46.29.244]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id D0F0BBEFF for ; Thu, 2 Apr 2015 01:16:06 +0100 (IST) Message-ID: <551C8A46.9030904@cs.tcd.ie> Date: Thu, 02 Apr 2015 01:16:06 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: dane OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [dane] AD review of draft-ietf-dane-srv-12 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, 02 Apr 2015 00:16:13 -0000 Hiya, I have just one question I'd like to ask before starting IETF LC. Appendix B: I'm not sure there's really going to be IETF consensus that it's better to have a TLS server cert for the hostname and not the service name. If you can point at where it's recorded that the WG reached that consensus that may save us time later. But we'll see I guess - I think there's a reasonable case for both sides of that argument. While this comment is about an appendix I suspect that if the wg change it's mind here, it'd also change other bits of the draft. Note that as soon as I get a reasonable answer I'll move on here - though I think having an easily accessible recent answer may be quite useful. Thanks, Stephen. PS: some more nits below, feel free to treat these as IETF LC comments. nits: - intro: 2nd bullet: I think including an explicit definition of "target domain" in section 2 would be good even if it's defined elsewhere too. - intro: last bullet: I don't get that sorry. - section 7: The first sentence doesn't fill one with confidence. It reads as if speculation. Maybe s/often would like/ought/ would help. From nobody Wed Apr 1 18:19:54 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2018D1AD06E for ; Wed, 1 Apr 2015 18:19:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.037 X-Spam-Level: X-Spam-Status: No, score=-1.037 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 62zCyd_Lwtlt for ; Wed, 1 Apr 2015 18:19:50 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D3781ACCF3 for ; Wed, 1 Apr 2015 18:19:50 -0700 (PDT) Received: (qmail 42786 invoked from network); 2 Apr 2015 01:19:49 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 2 Apr 2015 01:19:49 -0000 Date: 2 Apr 2015 01:19:27 -0000 Message-ID: <20150402011927.2056.qmail@ary.lan> From: "John Levine" To: dane@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dane] encoding internationalized mail addresses in the DNS 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, 02 Apr 2015 01:19:52 -0000 >> As far as I can tell, the base32 approach handles everything that >> hashing does > >The draft, has a "characters/octets" conflation problem, as do the >sequence of successors to RFC-822. > >This likely dates back to the before-UTF and before-IDNA era, and how >the docs were updated. Until RFC 6530-6532, SMTP commands were (and mostly still are) ASCII only, and mail message headers were and are ASCII only. When 5321 says octets, those octets hold ASCII characters. With internationalised mail as described in RFCs 6530-6532, there is a new SMTP extsnsion SMTPUTF8 which allows the client and server to agree that they allow UTF-8 in the commands and message headers as well as ASCII, but the octet limits don't change. In particular, local-part is limited to 64 octets whether it contains only ASCII or UTF-8. >- when and why was the 64-length local-part introduced? (It appeared >magically in RFC 2821 4.5.3.1) It was documenting existing practice. See below. >- when it changed from "64 characters" to "64 octets" in RFC 5321, >this implicitly affected UTF-2/3/4 languages - was this impact >considered? There was nothing to consider -- non-ASCII wasn't valid in any SMTP transaction so the 64 characters was 64 octets. >- is the 64 octet limit sufficiently universally enforced to be >considered an actual de-facto standard? As I learned the hard way when I was experimenting with BATV (a hack that put signatures in bounce addresses), if your local-parts are longer than 64 octets, things break. I think MS Exchange was one of the strictest, and it's all over the place. >- is it really the case that UTF-2 mailboxes are <= 32 characters, >UTF-3 mailboxes <= 21 characters, and UTF-4 mailboxes <= 16 >characters? If you are referring to multibyte UTF-8 characters, a UTF-8 string typically has a mixture of characters whose encodings are of different numbers of bytes. The SMTP and mail header limit is on the UTF-8 octets, not the decoded Unicode characters. >Hashing, by definition, does not care about the length of local-part, >and thus is less restrictive. In effect, it ignores that 64 character >limit. (I'm not entirely sure if that is a pro, con, or irrelevant.) I think it's irrelevant -- I don't think I've ever seen a local part longer than 64. Most are much shorter. >However, the _other_ issue is that the length of local-part _encoding_ >implicitly limits the parent domain name length. Using 2 x 52-octet >long labels, reduces the maximum domain name length to 255-106=149 >octets, minus whatever the "_mailbox" label's length is, and is >applicable to IDNA and non-IDNA domain names alike. I suppose that could be a problem, but it's one we might run into at some point whatever we do. Here's a data point: I run abuse.net, a place where people register abuse contact addresses primarily for their mail domains. People have registered info for over 500,000 domains during the last decade. I just checked, and the longest names for which anyone has ever registered a contact are 67 characters, and they look pretty bogus: mp3-mp3-mp3-mp3-mp3-mp3-mp3-mp3-mp3-mp3-mp3-mp3-mp3-mp3-mp3-mp3.net realestateagentnewhomeforsalerealtysjoselistingsjoserestaurants.com sanjoserestaurantitalianchinesejapaneseindianmexicanpizzafrench.com People can and do register names with three or four name components, but these are the longest overall. Everything else is shorter, mostly much shorter. So it looks to me that the chances of a non-contrived mail address having a domain approaching 140 octets is vanishingly small. R's, John From nobody Wed Apr 1 18:21:37 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B89E1AD09E for ; Wed, 1 Apr 2015 18:21:36 -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 gNa_osVcHh24 for ; Wed, 1 Apr 2015 18:21:34 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 110541AD0A4 for ; Wed, 1 Apr 2015 18:21:34 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 2BC29283031; Thu, 2 Apr 2015 01:21:33 +0000 (UTC) Date: Thu, 2 Apr 2015 01:21:33 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150402012132.GW17637@mournblade.imrryr.org> References: <551C8A46.9030904@cs.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <551C8A46.9030904@cs.tcd.ie> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dane] AD review of draft-ietf-dane-srv-12 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, 02 Apr 2015 01:21:36 -0000 On Thu, Apr 02, 2015 at 01:16:06AM +0100, Stephen Farrell wrote: > Appendix B: I'm not sure there's really going to be IETF > consensus that it's better to have a TLS server cert for the > hostname and not the service name. The rationale in appendix B of SRV leaves what I think is the most important reason for preferring the server hostname: * That's what clients MUST send in the SNI extension! DNSSEC/DANE authenticate the "redirect" from the service domain to the target host (which may well in a hosting provider domain) and the TLSA record promising TLS support and providing the authentication material is associated with *that* name and not the service domain. ; hosted domain zone _imap._tcp.example.com IN SRV 0 0 143 mail.example.net. ; hosting provider zone _143._tcp.mail.example.net. IN TLSA 2 0 1 The party promising TLS support is the provider, not the hosted domain. And that's whose certificate the TLSA record is expected to match. Support for the service domain in the certificate is a concession to interoperability with legacy or mixed deployments, where some clients are still doing non-DANE PKIX. Though per Alexey's most recent UTA draft, they should some day primarily be looking for srvNAME altnames, rather than domain names in the certificate. > If you can point at where > it's recorded that the WG reached that consensus that may save > us time later. It is fundamental to the DANE TLSA model, that the certificate is associated with the TLSA base domain. There really is no other way to do it, without breaking the indirection, and forcing hosted clients to publish TLSA RRs for the provider's servers, which totally stinks because the coordination is unworkable. > While this > comment is about an appendix I suspect that if the wg change > it's mind here, it'd also change other bits of the draft. No change of mind is likely here, I for one, would oppose this rather strongly. -- Viktor. From nobody Wed Apr 1 20:26:02 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08D651A1BC8; Wed, 1 Apr 2015 20:26:01 -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 xljhQjXHx2_z; Wed, 1 Apr 2015 20:25:59 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A89491A86F6; Wed, 1 Apr 2015 20:25:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150402032557.13835.65368.idtracker@ietfa.amsl.com> Date: Wed, 01 Apr 2015 20:25:57 -0700 Archived-At: Cc: dane@ietf.org Subject: [dane] I-D Action: draft-ietf-dane-openpgpkey-03.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2015 03:26:01 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS-based Authentication of Named Entities Working Group of the IETF. Title : Using DANE to Associate OpenPGP public keys with email addresses Author : Paul Wouters Filename : draft-ietf-dane-openpgpkey-03.txt Pages : 11 Date : 2015-04-01 Abstract: OpenPGP is a message format for email (and file) encryption that lacks a standardized lookup mechanism to securely obtain OpenPGP public keys. This document specifies a method for publishing, locating and verifying OpenPGP public keys in DNS for a specific email address using a new OPENPGPKEY DNS Resource Record. Security is provided via DNSSEC. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dane-openpgpkey/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dane-openpgpkey-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-dane-openpgpkey-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Apr 1 20:29:00 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FDB71B29E8 for ; Wed, 1 Apr 2015 20:28:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.01 X-Spam-Level: X-Spam-Status: No, score=-4.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_LETTER=-2, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XaO88LtP1TpM for ; Wed, 1 Apr 2015 20:28:57 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F01C1AD355 for ; Wed, 1 Apr 2015 20:28:57 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3lHVHC1stqz3nF for ; Thu, 2 Apr 2015 05:28:55 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=DadN7Bi/ X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id Xrj9Zqa2hOPx for ; Thu, 2 Apr 2015 05:28:53 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for ; Thu, 2 Apr 2015 05:28:52 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 80EBC80416 for ; Wed, 1 Apr 2015 23:28:51 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1427945331; bh=0VCUclo8DJZuTDYCHQkZ/AseosCMkQ5Icwgi1OVHSIc=; h=Date:From:To:Subject; b=DadN7Bi/jZ0rSY7/JQ0xipFnsZhKE8COGxTIA7olXd2h3luZYEFDoLow7Q4fMqzXn 7fzep8utkHdG93/fnUJbEXpys4NaBnBQT0IjCqNGF1aC986HVHot0hvAUfG/MWvY3x Z7cMuCyeOLLMxLSc2mJHtPC7uP4zYzCAVpC4WdlY= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id t323SpuY032720 for ; Wed, 1 Apr 2015 23:28:51 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Wed, 1 Apr 2015 23:28:50 -0400 (EDT) From: Paul Wouters To: dane WG list Message-ID: User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Archived-At: Subject: [dane] Updated draft-ietf-dane-openpgpkey 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, 02 Apr 2015 03:28:59 -0000 I have updated draft-ietf-dane-openpgpkey Latest version: http://tools.ietf.org/html/draft-ietf-dane-openpgpkey-03 Diff: http://www.ietf.org/rfcdiff?url1=draft-ietf-dane-openpgpkey-02&url2=draft-ietf-dane-openpgpkey-03 Items changed: - SHA-224 changed to SHA-256 truncated at 28 octets. It was indicated that SHA224 is the black sheep of the SHA2 (FIPS) family and is also not part of the Microsoft CryptoAPI. [various people including Stephen Farrell and Sean Leonard] - Clarify the local part should be in UTF-8/ASCII encoding [Wil Tan] - Lowercase before hash - as there seems to be consensus that all email servers in real life deployments do not have different mailboxes for different case (Paul@nohats.ca vs paul@nohats.ca). This avoids the most common problem of webforms and phone virtual keyboards automatically capitalizing the first letter of a recognised name. [based on John Levine's input] - Forbid any other kind of attempt at guessing or rewriting the local-part [based on the many people present at the Dallas DANE meeting] - Added a section more clearly documenting the usage of OPENPGPKEY and updating the Introduction section [result of discussion with Paul Hoffman] - Do not allow replacing/adding local key stores without user confirmation [Pieter Lexis] - Do not cache the record beyond its TTL [Pieter Lexis] - Point to the OpenPGP key ring section within the RFC, instead of just the RFC [based on feedback from Petr Spacek] From nobody Wed Apr 1 21:09:23 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7ABB1B2A80 for ; Wed, 1 Apr 2015 21:09:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.862 X-Spam-Level: X-Spam-Status: No, score=0.862 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6rhVUdHHeOey for ; Wed, 1 Apr 2015 21:09:20 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 762951B2A64 for ; Wed, 1 Apr 2015 21:09:20 -0700 (PDT) Received: (qmail 67544 invoked from network); 2 Apr 2015 04:09:18 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 2 Apr 2015 04:09:18 -0000 Date: 2 Apr 2015 04:08:56 -0000 Message-ID: <20150402040856.2610.qmail@ary.lan> From: "John Levine" To: dane@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: paul@nohats.ca Subject: Re: [dane] online vs. offline signing, was encoding mail addresses in the DNS 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, 02 Apr 2015 04:09:22 -0000 >Yes, but if anything, the document should recommend not to use online >DNSSEC signing for _openpgpkey zones. It would be a prime attack vector. >By using offline signing, no one can ever forge an OPENPGPKEY even if >they own the DNS server or the Mail server. There's some assumptions here I'd like to unpack. One is the assumption that keys are all very valuable. Sure, some of them are, but some aren't. As an extreme example, consider something like abcd@mailinator.com, addresses intended to be used a few times and then discarded, where every address has little value and the associated keys would't be worth much either. Also, a rule like this doesn't help interoperation -- nobody talking to a DNS server can tell whether it's doing online or offline signing. DNSSEC allows online signing, it's going to continue to happen, and it's up to the server managers to assess their security issues, of which potential theft of DNSSEC keys is only one of many. I'd be more worried about users getting phished and bad guys using their credentials to upload PGP keys, replacing the users' own in the zone to be signed. Most important, there's the scale issue. Reports say that Yahoo has over 300,000,000 active mailboxes and Gmail has over 500,000,000. I gather the goal here is to make publishing your key cheap and easy, so let's posit modest success and say that 20% of Gmail users have keys. It looks to me like a typical PGP key is about 1.5K, so that's 100M keys at 1.5K or a zone file of about 150 gigabytes. The largest signed zone I'm aware of is .COM which as of yesterday is a little under 10GB before signing. Is it really plausible that anyone is going to generate and sign and serve static zones more than an order of magnitude bigger than .COM? That seems like a stretch. On the other hand, with base32 coding and the option of online signing, it should scale OK since the records in the zone are generated from the user database and signed as needed. R's, John From nobody Wed Apr 1 21:45:17 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 441081B2AAE for ; Wed, 1 Apr 2015 21:45:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15R7p8AF1K7c for ; Wed, 1 Apr 2015 21:45:12 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67E571B2AAD for ; Wed, 1 Apr 2015 21:45:12 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3lHWz66yt6z45s; Thu, 2 Apr 2015 06:45:06 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=lGJ/4hMR X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id Ho9A6PVOttYT; Thu, 2 Apr 2015 06:45:04 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Thu, 2 Apr 2015 06:45:04 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id B571F8078B; Thu, 2 Apr 2015 00:45:02 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1427949902; bh=OLnApHp1Q2D7x/AZVsugJA9kCd0dnlYmMAeG2kwMX00=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=lGJ/4hMRtRMxLgxJmOCWHs0+4YGs9ZqeWSc7qrLw9jJkCiC0DHnTiF6hcEfXLmZwu xfAmhX5yyqLpTbVTTZrhOzMNIdKNlX7UHS1jZyyehpqnG6seaA79Loz6LhzC0GCWyl SOookKHIOp3R6+IlPydXF7vjJWbRv+dTpVOp+BzY= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id t324j1U2030972; Thu, 2 Apr 2015 00:45:02 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Thu, 2 Apr 2015 00:45:01 -0400 (EDT) From: Paul Wouters To: John Levine In-Reply-To: <20150402040856.2610.qmail@ary.lan> Message-ID: References: <20150402040856.2610.qmail@ary.lan> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: dane@ietf.org Subject: Re: [dane] online vs. offline signing, was encoding mail addresses in the DNS 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, 02 Apr 2015 04:45:15 -0000 On Thu, 2 Apr 2015, John Levine wrote: > Most important, there's the scale issue. Reports say that Yahoo has > over 300,000,000 active mailboxes and Gmail has over 500,000,000. I > gather the goal here is to make publishing your key cheap and easy, so > let's posit modest success and say that 20% of Gmail users have keys. > It looks to me like a typical PGP key is about 1.5K, That is not my experience from adding 1000+ keys from the fedoraproject.org into the _openpgpkey zone. The keys are bigger. > Is it really plausible that anyone is going to generate and sign and > serve static zones more than an order of magnitude bigger than .COM? > That seems like a stretch. You do not need static zones. You just need to pull the right signed data from further inside your network on demand. I do not know of any DNS provider doing online signing for 1 zone on dozens or hundreds of DNS servers. The chance of losing your private key, and worse, not even knowing someone else has a copy of your private key, would be too high. In your example 499,000,000 records will never be asked for and do not need to be available on the DNS servers. The signed records do not need to reside in "zone files". The nameservers can fetch data on demand, without having the private key to sign their own data. I'm sure Yahoo and Google are smart and rich enough to implement the most insane and complicated scheme we throw at them. But there are many other players with a lot less time and money to throw at these problems. My problem is not with base32, it is with your suggested split and using a "." (or was it "\." and who knows what the difference is?) I fear will cause interop issues. If we can do lossless encoding using gzip then base32 or something, I would be okay with that. As long as we stick to < 63 characters. If that means some theoretical long high entropy email address cannot be mapped, I'm fine with that. I'm solving a practical matter, not a philosophical one. Paul From nobody Wed Apr 1 22:29:19 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A1341B2A97 for ; Wed, 1 Apr 2015 22:29:18 -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 Plm1fxNJDNaJ for ; Wed, 1 Apr 2015 22:29:16 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6AE31B2A80 for ; Wed, 1 Apr 2015 22:29:15 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id B3997283032; Thu, 2 Apr 2015 05:29:14 +0000 (UTC) Date: Thu, 2 Apr 2015 05:29:14 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150402052914.GZ17637@mournblade.imrryr.org> References: <20150402040856.2610.qmail@ary.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dane] online vs. offline signing, was encoding mail addresses in the DNS 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, 02 Apr 2015 05:29:18 -0000 On Thu, Apr 02, 2015 at 12:45:01AM -0400, Paul Wouters wrote: > My problem is not with base32, it is with your suggested split and using > a "." (or was it "\." and who knows what the difference is?) Naturally the former, as the idea would be to create two labels, not a label with a ".". > I fear will cause interop issues. If we can do lossless encoding using > gzip then base32 or something. Gzip is not very good with short strings, you'd need enough data to warrant the overhead. Mostly you lose: $ echo viktor.dukhovni | wc -c 16 $ echo viktor.dukhovni | gzip -c | wc -c 36 $ echo Gabriel.Jose.de.la.Concordia.Garcia.Marquez | wc -c 44 $ echo Gabriel.Jose.de.la.Concordia.Garcia.Marquez | gzip -c | wc -c 62 If the goal is primarily not to supporting key "discovery" (security for first contact when one is not even sure of the address), but rather primarily key lookup for addresses known to be canonical (thus iPhone capitalization e.g. is moot, since it will find an address-book match I expect), then DNS not being able to find keys for variant names is fine, and we don't need lossless encodings. As for how people will publish their zones, we simply cant't predict what any particular domain will do, but we can be sure everything that can be done will be done by someone. Cloudflare's hosting of www.ietf.org uses online signing with P-256. Note that for non-existent names they return NODATA rather than NXDOMAIN (and the NSEC RRs claim to have all the standard RR types other than the one you ask for): $ dig +noall +comment +ans +auth +nocl +nottl +nosplit +dnssec -t tlsa vvv.ietf.org.cdn.cloudflare-dnssec.net. ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27653 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1 cloudflare-dnssec.net. SOA ns1.cloudflare-dnssec.net. dns.cloudflare.com. 2017357885 10000 2400 604800 3600 vvv.ietf.org.cdn.cloudflare-dnssec.net. NSEC \003.vvv.ietf.org.cdn.cloudflare-dnssec.net. A WKS HINFO MX TXT AAAA LOC SRV CERT SSHFP IPSECKEY RRSIG NSEC HIP TYPE61 SPF $ dig +noall +comment +ans +auth +nocl +nosplit +dnssec -t a vvv.ietf.org.cdn.cloudflare-dnssec.net. ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59135 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1 cloudflare-dnssec.net. SOA ns1.cloudflare-dnssec.net. dns.cloudflare.com. 2017357885 10000 2400 604800 3600 vvv.ietf.org.cdn.cloudflare-dnssec.net. NSEC \003.vvv.ietf.org.cdn.cloudflare-dnssec.net. WKS HINFO MX TXT AAAA LOC SRV CERT SSHFP IPSECKEY RRSIG NSEC TLSA HIP TYPE61 SPF Power-DNS is often configured to to online signing and to return less radically creative "narrow-mode" NSEC3 RRs, (signature of [hash-1, hash+1] interval). -- Viktor. From nobody Thu Apr 2 04:53:12 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A11401B2C7D for ; Thu, 2 Apr 2015 04:53:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s0zBJIPgkIU5 for ; Thu, 2 Apr 2015 04:53:08 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C7F21B2C7C for ; Thu, 2 Apr 2015 04:53:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id F14D7BF0B for ; Thu, 2 Apr 2015 12:53:06 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YHeEgedMdFEq for ; Thu, 2 Apr 2015 12:53:05 +0100 (IST) Received: from [10.87.48.73] (unknown [86.46.18.59]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 88329BF0A for ; Thu, 2 Apr 2015 12:53:05 +0100 (IST) Message-ID: <551D2DA1.10809@cs.tcd.ie> Date: Thu, 02 Apr 2015 12:53:05 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: dane@ietf.org References: <551C8A46.9030904@cs.tcd.ie> <20150402012132.GW17637@mournblade.imrryr.org> In-Reply-To: <20150402012132.GW17637@mournblade.imrryr.org> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dane] AD review of draft-ietf-dane-srv-12 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, 02 Apr 2015 11:53:11 -0000 Hi Viktor, Meta-question: was this something the wg discussed or did they just follow your lead? If the former, that's grand and I'll stop when shown the archive URL for the thread (I do think I recall similar discussion, but not sure). If not, then let's use this thread to check - so if someone disagrees with Viktor and hasn't sent mail on this previously (if it was discussed already please don't re-raise stuff) it'd be good to hear about it now. The reason I'm asking is the obvious one - this could be a surprise - if the user agent for some protocol shows foo.example.com (or has that in a configuration) but via DNSSEC/DANE/SRV we end up with a TLS session with bar.example.com and if we say that that is ok, then we're causing potential developer/deployer/user surprise, and also setting an upper bound for the level of TLS security that is only as good as domain-validated. That is a defensible position (esp for the DANE wg!) but might surprise some application developers etc. One other question: you mentioned SNI below. Is that very relevant here, given we're not talking about the web (that won't use SRV) and afaik most use of SNI is for the web. So, for which non-web applications is SNI sufficiently important to justify this (potential) level of developer surprise? Thanks, S. On 02/04/15 02:21, Viktor Dukhovni wrote: > On Thu, Apr 02, 2015 at 01:16:06AM +0100, Stephen Farrell wrote: > >> Appendix B: I'm not sure there's really going to be IETF >> consensus that it's better to have a TLS server cert for the >> hostname and not the service name. > > The rationale in appendix B of SRV leaves what I think is the most > important reason for preferring the server hostname: > > * That's what clients MUST send in the SNI extension! > > DNSSEC/DANE authenticate the "redirect" from the service domain to > the target host (which may well in a hosting provider domain) and > the TLSA record promising TLS support and providing the authentication > material is associated with *that* name and not the service domain. > > ; hosted domain zone > _imap._tcp.example.com IN SRV 0 0 143 mail.example.net. > > ; hosting provider zone > _143._tcp.mail.example.net. IN TLSA 2 0 1 > > The party promising TLS support is the provider, not the hosted > domain. And that's whose certificate the TLSA record is expected > to match. > > Support for the service domain in the certificate is a concession > to interoperability with legacy or mixed deployments, where some > clients are still doing non-DANE PKIX. Though per Alexey's most > recent UTA draft, they should some day primarily be looking for > srvNAME altnames, rather than domain names in the certificate. > >> If you can point at where >> it's recorded that the WG reached that consensus that may save >> us time later. > > It is fundamental to the DANE TLSA model, that the certificate is > associated with the TLSA base domain. There really is no other > way to do it, without breaking the indirection, and forcing hosted > clients to publish TLSA RRs for the provider's servers, which > totally stinks because the coordination is unworkable. > >> While this >> comment is about an appendix I suspect that if the wg change >> it's mind here, it'd also change other bits of the draft. > > No change of mind is likely here, I for one, would oppose this > rather strongly. > From nobody Thu Apr 2 06:40:27 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ABF31A9089 for ; Thu, 2 Apr 2015 06:40:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.351 X-Spam-Level: X-Spam-Status: No, score=-3.351 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_LETTER=-2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.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 1e11ZpnxiAOV for ; Thu, 2 Apr 2015 06:40:23 -0700 (PDT) Received: from mx.roessner-net.de (mail.roessner-net.de [193.239.107.42]) (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 495171A8AEA for ; Thu, 2 Apr 2015 06:40:23 -0700 (PDT) Received: from mail.roessner-net.de (mail.roessner-net.de [193.239.107.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.roessner-net.de", Issuer "thawte DV SSL CA - G2" (verified OK)) by mx.roessner-net.de (Postfix) with ESMTPS id 3lHlrg5VJrzGpNf; Thu, 2 Apr 2015 15:40:19 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=roessner-network-solutions.com; s=swioBi3opho; t=1427982020; i=@roessner-network-solutions.com; bh=gPAbuMt/q2wJQ5ndo6S+oUp4lnWkz28xMVXd4HMM4q0=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=faAdb9F64vSaGWK78jDpHgDiGcAUxX1Pkc4F22E5VfAcGmbSF9YKnmDeSby+8eW2L 8w9HkIWTyy9qgQG2HsqRSKSAZX/3BtO0ILMMbYXXgE1rUi/Be8K3EXwdY5G5KM15EN 10NtvXU7pgMjOz+a+zYaVrdfpmTyllPOde+k1/jDZ7cCqNPkVsL/pX9gZKLyWwVU2X huLvnf0iRkAMoZLIebGL23E+zDotlocHlWVDaiycc2fOIMV3n6ZJ0y/Oytw0O17yLv ggfxDwFW+kvGORxfFZWr5k1k4bzV+yUCtsfGCqmzVIAIs+7jB8yDRBJAtqi1DfEjM8 KvMCp/7lLtZcQ== Received: from [172.16.2.200] (static-201-106.deltasurf.de [193.239.106.201]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Christian Roessner", Issuer "RootCA (c) 2014" (verified OK)) (Authenticated sender: c@roessner.co) by mail.roessner-net.de (Postfix) with ESMTPSA id 3lHlrg0smGzMkrT; Thu, 2 Apr 2015 15:40:19 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_32716BB0-BCE0-45ED-8EA8-648CC7BE5372"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2096\)) From: =?utf-8?Q?Christian_R=C3=B6=C3=9Fner?= In-Reply-To: Date: Thu, 2 Apr 2015 15:40:18 +0200 Message-Id: <2E2E6A49-3ED5-49A7-A263-54D8F1B8EE95@roessner-network-solutions.com> References: To: Paul Wouters X-Mailer: Apple Mail (2.2096) Outgoingd: 0.3.0_m1 Archived-At: Cc: dane WG list Subject: Re: [dane] Updated draft-ietf-dane-openpgpkey 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, 02 Apr 2015 13:40:26 -0000 --Apple-Mail=_32716BB0-BCE0-45ED-8EA8-648CC7BE5372 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, > Latest version: = http://tools.ietf.org/html/draft-ietf-dane-openpgpkey-03 > Diff: = http://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-dane-openpgpkey-02&url2=3Ddr= aft-ietf-dane-openpgpkey-03 >=20 > Items changed: >=20 > - SHA-224 changed to SHA-256 truncated at 28 octets. It was indicated > that SHA224 is the black sheep of the SHA2 (FIPS) family and is > also not part of the Microsoft CryptoAPI. [various people including > Stephen Farrell and Sean Leonard] Is this also an option for SMIMEA draft? > - Clarify the local part should be in UTF-8/ASCII encoding [Wil Tan] >=20 > - Lowercase before hash - as there seems to be consensus that all = email > servers in real life deployments do not have different mailboxes for > different case (Paul@nohats.ca vs paul@nohats.ca). This avoids the > most common problem of webforms and phone virtual keyboards = automatically > capitalizing the first letter of a recognised name. [based on John > Levine's input] And is this also an option for the SMIMEA draft? Christian -- Bachelor of Science Informatik Erlenwiese 14, 36304 Alsfeld T: +49 6631 78823400, F: +49 6631 78823409, M: +49 171 9905345 USt-IdNr.: DE225643613, http://www.roessner-network-solutions.com --Apple-Mail=_32716BB0-BCE0-45ED-8EA8-648CC7BE5372 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIE8TCCBO0w ggPVoAMCAQICAhAFMA0GCSqGSIb3DQEBCwUAMIHeMQswCQYDVQQGEwJERTESMBAGCgmSJomT8ixk ARkWAmRlMRwwGgYKCZImiZPyLGQBGRYMcm9lc3NuZXItbmV0MQ8wDQYDVQQIDAZIZXNzZW4xEDAO BgNVBAcMB0Fsc2ZlbGQxDzANBgNVBAoMBlIuTi5TLjEeMBwGA1UECwwVQ2VydGlmaWNhdGUgQXV0 aG9yaXR5MRgwFgYDVQQDDA9Sb290Q0EgKGMpIDIwMTQxLzAtBgkqhkiG9w0BCQEWIGNAcm9lc3Nu ZXItbmV0d29yay1zb2x1dGlvbnMuY29tMB4XDTE0MDkwNzE0MDI0NloXDTI0MDkwNDE0MDI0Nlow gdAxCzAJBgNVBAYTAkRFMRIwEAYKCZImiZPyLGQBGRYCZGUxHDAaBgoJkiaJk/IsZAEZFgxyb2Vz c25lci1uZXQxDzANBgNVBAgMBkhlc3NlbjEQMA4GA1UEBwwHQWxzZmVsZDEPMA0GA1UECgwGUi5O LlMuMQ0wCwYDVQQLDARNYWlsMRswGQYDVQQDDBJDaHJpc3RpYW4gUm9lc3NuZXIxLzAtBgkqhkiG 9w0BCQEWIGNAcm9lc3NuZXItbmV0d29yay1zb2x1dGlvbnMuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAvRa6QBgHt56hf1RuKHsNkXPXTFzG0RLualxlyfsJS0nWNWFaBD7ceZ8F WhnP7ypHSyWE4aCy7BYM4n2iVDm9m8bKV5cXuSdLY3kefqSOk9+YvCLu1MqQk70BY7UReS7OUJ1r ml1v09igaYA1+4FT8Um5oXB69BMm/JxFlkJ/TEu7KQzZ++oWavezChU+tc3neP4TJ9B+e4Q3BiTW RPMzmWf1HDR9RfhU4YPT0AQpvMusYUN/QKqKgh7cCCx8fcMO7noZDCNJchKLuil8/jKznJtj8+/B mwbvHJjshv/txNxKr8Id1K7+cQMweMA6uuOiJIt9oOAcPM8UEMzFwrShvwIDAQABo4HAMIG9MAkG A1UdEwQCMAAwLAYJYIZIAYb4QgENBB8WHU9wZW5TU0wgR2VuZXJhdGVkIENlcnRpZmljYXRlMB0G A1UdDgQWBBQkzf3k5Z/BAcTvlAu53yCIqJXMUzAfBgNVHSMEGDAWgBTgcUa1UKCapZJ6/qUWTH2C bOT9nDBCBgNVHR8EOzA5MDegNaAzhjFodHRwOi8vd3d3LnJvZXNzbmVyLW5ldHdvcmstc29sdXRp b25zLmNvbS9jcmwucGVtMA0GCSqGSIb3DQEBCwUAA4IBAQBGVbjnbP3RkXd5BStfKfyGWwNAAzrS dR1fy+tje5Zoq8t9nvxtaNnPCehyztTgUFfNaARFI5yY+z2ZaJ58NnQhSKYuZDkx/mwZkGcVbvp5 r7uDqFo42OfHej6SMIMzwKuXEgF26bKmcm4uZOouw8Ec68raEfnRY22loL8usx2yrH1qURgjSTJP PZ2Rs+2WVTWxylhLADAf7aAXTUPCx4zW6cGPYA2GR8w9ZYk74fIpPus4hs/LbBUVYtOMX6daVwkC 8xmQmcRihGo8wB5N2dH2T0fPV70HSn5GTUQ8O69ObDT8zo33dvg2w4swbWaKdn11Ywhd+HhvM+Ru bOSB+EBuMYIEYjCCBF4CAQEwgeUwgd4xCzAJBgNVBAYTAkRFMRIwEAYKCZImiZPyLGQBGRYCZGUx HDAaBgoJkiaJk/IsZAEZFgxyb2Vzc25lci1uZXQxDzANBgNVBAgMBkhlc3NlbjEQMA4GA1UEBwwH QWxzZmVsZDEPMA0GA1UECgwGUi5OLlMuMR4wHAYDVQQLDBVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkx GDAWBgNVBAMMD1Jvb3RDQSAoYykgMjAxNDEvMC0GCSqGSIb3DQEJARYgY0Byb2Vzc25lci1uZXR3 b3JrLXNvbHV0aW9ucy5jb20CAhAFMAkGBSsOAwIaBQCgggJRMBgGCSqGSIb3DQEJAzELBgkqhkiG 9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDQwMjEzNDAxOVowIwYJKoZIhvcNAQkEMRYEFBSJV5vG IELEMgLr5BfxYL/CTycUMIH2BgkrBgEEAYI3EAQxgegwgeUwgd4xCzAJBgNVBAYTAkRFMRIwEAYK CZImiZPyLGQBGRYCZGUxHDAaBgoJkiaJk/IsZAEZFgxyb2Vzc25lci1uZXQxDzANBgNVBAgMBkhl c3NlbjEQMA4GA1UEBwwHQWxzZmVsZDEPMA0GA1UECgwGUi5OLlMuMR4wHAYDVQQLDBVDZXJ0aWZp Y2F0ZSBBdXRob3JpdHkxGDAWBgNVBAMMD1Jvb3RDQSAoYykgMjAxNDEvMC0GCSqGSIb3DQEJARYg Y0Byb2Vzc25lci1uZXR3b3JrLXNvbHV0aW9ucy5jb20CAhAFMIH4BgsqhkiG9w0BCRACCzGB6KCB 5TCB3jELMAkGA1UEBhMCREUxEjAQBgoJkiaJk/IsZAEZFgJkZTEcMBoGCgmSJomT8ixkARkWDHJv ZXNzbmVyLW5ldDEPMA0GA1UECAwGSGVzc2VuMRAwDgYDVQQHDAdBbHNmZWxkMQ8wDQYDVQQKDAZS Lk4uUy4xHjAcBgNVBAsMFUNlcnRpZmljYXRlIEF1dGhvcml0eTEYMBYGA1UEAwwPUm9vdENBIChj KSAyMDE0MS8wLQYJKoZIhvcNAQkBFiBjQHJvZXNzbmVyLW5ldHdvcmstc29sdXRpb25zLmNvbQIC EAUwDQYJKoZIhvcNAQEBBQAEggEAAIGXtJiD0vJoyH4qg0sC2TSOS/trTBV9h9V+UI0Gr3Rru5Vu nzwwmBmjM5eSsa5Rmj5CnEWUODPIqwj83T8kd3pDOuvJYKmZ6tRg/vL8+eXxfOGj2uDDC3TpICho ElrP3k5Jo+2opMjtlAjUj5ULlC9cxIJPd4UoiwKgCpSZH3d1sCLsWUogz5LmFYr6gcgfmub3Adh3 BskLjFagC4CSvAMjWxEz+W/L5nzO3Gl1IrtcMcgryV6LV9ZKKkPQlHU1GphLhHF/4gJJI5n03pFr u5myb1rA7gqap4jhDwTaGwItwxFPx1SaOYjgViyxGqn0jo+lvjP3hCEeaPuqXy6qlAAAAAAAAA== --Apple-Mail=_32716BB0-BCE0-45ED-8EA8-648CC7BE5372-- From nobody Thu Apr 2 06:48:29 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ABE31ACEA4; Wed, 1 Apr 2015 17:16:27 -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 SG74Kwd0HHrK; Wed, 1 Apr 2015 17:16:26 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 19A171ACEAC; Wed, 1 Apr 2015 17:16:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150402001625.8653.77876.idtracker@ietfa.amsl.com> Date: Wed, 01 Apr 2015 17:16:25 -0700 From: IETF Secretariat Archived-At: X-Mailman-Approved-At: Thu, 02 Apr 2015 06:48:29 -0700 Subject: [dane] ID Tracker State Update Notice: X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2015 00:16:27 -0000 IESG state changed to AD Evaluation from Publication Requested ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-dane-srv/ From nobody Thu Apr 2 07:03:12 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C7A11A90C0 for ; Thu, 2 Apr 2015 07:03:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.71 X-Spam-Level: X-Spam-Status: No, score=-1.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PIzjLvIh_-zX for ; Thu, 2 Apr 2015 07:03:10 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F24E01A90BE for ; Thu, 2 Apr 2015 07:03:09 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3lHmLz6FnmzC2d; Thu, 2 Apr 2015 16:03:07 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=ry3Wr3aK X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id KbJ2qC0MPxTA; Thu, 2 Apr 2015 16:03:05 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Thu, 2 Apr 2015 16:03:05 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 6D806803E0; Thu, 2 Apr 2015 10:03:03 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1427983383; bh=62sK1NmLU2LswBMpPoctona2FAr9Y3TBd/lg1hm8WoQ=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=ry3Wr3aKRi49jYmHcEIilIkFYsvAlQT0aB2BxOhb46uETidVoeUKfG7WfWETWFAEF EiHnUn69ovTshQKqQe7KD9b9UR0IvTFy0M4qA/0Fc+TaGDgoq57eVoXadqZfxKu3tI 1rgD31S7cdjxXU8AGo8EaVDQdnRsnOgR2wAgTPsw= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id t32E32WW007794; Thu, 2 Apr 2015 10:03:02 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Thu, 2 Apr 2015 10:03:02 -0400 (EDT) From: Paul Wouters To: =?ISO-8859-15?Q?Christian_R=F6=DFner?= In-Reply-To: <2E2E6A49-3ED5-49A7-A263-54D8F1B8EE95@roessner-network-solutions.com> Message-ID: References: <2E2E6A49-3ED5-49A7-A263-54D8F1B8EE95@roessner-network-solutions.com> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Cc: dane WG list Subject: Re: [dane] Updated draft-ietf-dane-openpgpkey 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, 02 Apr 2015 14:03:11 -0000 On Thu, 2 Apr 2015, Christian Rner wrote: >> Latest version: http://tools.ietf.org/html/draft-ietf-dane-openpgpkey-03 >> Diff: http://www.ietf.org/rfcdiff?url1=draft-ietf-dane-openpgpkey-02&url2=draft-ietf-dane-openpgpkey-03 >> Items changed: > Is this also an option for SMIMEA draft? > And is this also an option for the SMIMEA draft? We're trying to keep the location the same with the two drafts, so if people are okay with it for openpgpkey, I assume the smime draft will follow. Paul From nobody Thu Apr 2 07:23:48 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 174551A90E0 for ; Thu, 2 Apr 2015 07:23:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.601 X-Spam-Level: X-Spam-Status: No, score=-3.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p_Otb5A-LbQi for ; Thu, 2 Apr 2015 07:23:45 -0700 (PDT) Received: from smtp92.ord1c.emailsrvr.com (smtp92.ord1c.emailsrvr.com [108.166.43.92]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F7C21B2B70 for ; Thu, 2 Apr 2015 07:23:42 -0700 (PDT) Received: from smtp20.relay.ord1c.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp20.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 7E80D8045A; Thu, 2 Apr 2015 10:23:40 -0400 (EDT) Received: by smtp20.relay.ord1c.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id 4023180370; Thu, 2 Apr 2015 10:23:40 -0400 (EDT) X-Sender-Id: ogud@ogud.com Received: from [10.20.30.43] (pool-74-96-189-218.washdc.fios.verizon.net [74.96.189.218]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:465 (trex/5.4.2); Thu, 02 Apr 2015 14:23:40 GMT Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Olafur Gudmundsson In-Reply-To: <2E2E6A49-3ED5-49A7-A263-54D8F1B8EE95@roessner-network-solutions.com> Date: Thu, 2 Apr 2015 10:23:39 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2E2E6A49-3ED5-49A7-A263-54D8F1B8EE95@roessner-network-solutions.com> To: =?utf-8?Q?Christian_R=C3=B6=C3=9Fner?= X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: Paul Wouters , dane WG list Subject: Re: [dane] Updated draft-ietf-dane-openpgpkey 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, 02 Apr 2015 14:23:47 -0000 =20 The drafts will be advanced with the same lookup mechanism.=20 The process is defined in OPENPGP draft, the SMIME draft will follow = OPENPGP lead in email address =E2=80=9Ctransformation=E2=80=9D.=20 Olafur > On Apr 2, 2015, at 9:40 AM, Christian R=C3=B6=C3=9Fner = wrote: >=20 > Hi, >=20 >> Latest version: = http://tools.ietf.org/html/draft-ietf-dane-openpgpkey-03 >> Diff: = http://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-dane-openpgpkey-02&url2=3Ddr= aft-ietf-dane-openpgpkey-03 >>=20 >> Items changed: >>=20 >> - SHA-224 changed to SHA-256 truncated at 28 octets. It was indicated >> that SHA224 is the black sheep of the SHA2 (FIPS) family and is >> also not part of the Microsoft CryptoAPI. [various people including >> Stephen Farrell and Sean Leonard] >=20 > Is this also an option for SMIMEA draft? >=20 >> - Clarify the local part should be in UTF-8/ASCII encoding [Wil Tan] >>=20 >> - Lowercase before hash - as there seems to be consensus that all = email >> servers in real life deployments do not have different mailboxes for >> different case (Paul@nohats.ca vs paul@nohats.ca). This avoids the >> most common problem of webforms and phone virtual keyboards = automatically >> capitalizing the first letter of a recognised name. [based on John >> Levine's input] >=20 > And is this also an option for the SMIMEA draft? >=20 > Christian > -- > Bachelor of Science Informatik > Erlenwiese 14, 36304 Alsfeld > T: +49 6631 78823400, F: +49 6631 78823409, M: +49 171 9905345 > USt-IdNr.: DE225643613, http://www.roessner-network-solutions.com >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From nobody Thu Apr 2 07:40:55 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32A391B2CF1 for ; Thu, 2 Apr 2015 07:40:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kWZu0CehOPzF for ; Thu, 2 Apr 2015 07:40:52 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5BF61B2CE7 for ; Thu, 2 Apr 2015 07:40:51 -0700 (PDT) Received: (qmail 51295 invoked from network); 2 Apr 2015 14:40:50 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=c85e.551d54f2.k1504; bh=QgR4CdPAMXoQlbjdGZKxs+vfnDFALeli4/jU+66JSdw=; b=jrIcVTgjfKGz5QNQQboJWDYl49yVJOZoJJg1fcch4DbnVSkmSnbHoH9kWeHV03o0O8nHpIr2QOvjfX/dp0agbvNlfHEJJ0PYghtptMwWkFpFa1KrDO91HL9WD96d4STNOXE3FvTLE2bg8dVd/PtyU/iZHYY2dEooXyknh8uyKQOXIuiJvcHJK2fA75jwIjR22ol33HRhvpKR0jXcom888heODXJS8+miJpoUO1eS0kA0OWEsk3XeK+z0TnB1PZnq DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=c85e.551d54f2.k1504; bh=QgR4CdPAMXoQlbjdGZKxs+vfnDFALeli4/jU+66JSdw=; b=exwCWwlkrqfb0/gzTtcH82wktZfTr/kDoRhBfq1BikCiFMp8PQa1T1S6vGo5H5pf/bi11kiYmOVcW8AjjiEr/QPCJkmiB/kp0aWvyblFBdpvnyXhYRM2/5lk9fR6ZyVxELaewPo2zaRc7opEcLkA7e5OG4V7F1AomrNpYYAMdKNWEJ3ia53YP5hi+CMpEu+Za6kRSoQtlEuEXV3m+/YyKznaS/CCaDfzAi2KafkGywL2bgCXprryLjdbK30q5CJg Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 02 Apr 2015 14:40:50 -0000 Date: 2 Apr 2015 10:40:49 -0400 Message-ID: From: "John R Levine" To: "Paul Wouters" In-Reply-To: References: <20150402040856.2610.qmail@ary.lan> User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: dane@ietf.org Subject: Re: [dane] online vs. offline signing, was encoding mail addresses in the DNS 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, 02 Apr 2015 14:40:53 -0000 > That is not my experience from adding 1000+ keys from the > fedoraproject.org into the _openpgpkey zone. The keys are bigger. I wouldn't argue -- that just makes the scaling issue worse. > My problem is not with base32, it is with your suggested split and using > a "." (or was it "\." and who knows what the difference is?) Oh, for heaven's sake. It's the same dot that's between nohats and ca or that's between the hash and _openpgpkey in your draft. Domain names can only have 63 octets per components so you write the base32 string as two components rather than one. The base32 is all LDH so there's no quoting needed. It's hard to imagine a DNS server that would have problems with that. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Thu Apr 2 08:08:52 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A08AB1B2B14 for ; Thu, 2 Apr 2015 08:08:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hl9WzL1M_UKr for ; Thu, 2 Apr 2015 08:08:46 -0700 (PDT) Received: from mail-qg0-f100.google.com (mail-qg0-f100.google.com [209.85.192.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B6631B2CC8 for ; Thu, 2 Apr 2015 08:08:45 -0700 (PDT) Received: by qgdz60 with SMTP id z60so4710894qgd.3 for ; Thu, 02 Apr 2015 08:08:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:content-type:content-id:content-transfer-encoding :mime-version; bh=/6iBDDNoumJu9jhswtEPM+xXo87hdeinObsW1K1uco0=; b=RSdn1qgzRkzLNFu0QnzFLlVzQto81oFeTU0gkLgFieTZoe7nzzNa5D2d8zxwS9olE4 sUsL+tYpH6HMJ51yW1dPkNgPqNMUL8noqr7LKdhGC05/PjtlutAKqpHCV7JPGPR2DTEj w2Y5QUUdXrWQGuFHG/HGfVp4T55TJvqGtPTY6dcaMlYjSKKghTWrFjct8vNDcfGgZ2F2 y563yJr/PRgQvWYbsE16uWnjyzv213Z/XeJ++6Zy0ur2caWCtbowLcQwZjax80/ArFNP fjipLsn1KU+Yfr/XNrxHUrzw9FQRi+QmM+ANYKem9B1xtiyxXeEE1i+8ffS3F4y9D4w+ KH6w== X-Gm-Message-State: ALoCoQmbWtmbccnYKvoSQi57WswufcOjJyCYK0qQ+zi1sCW2mlSW6SURlZuLNsLV2WT0ohDfIZ16CPTfweAPV6ersjuJCBtSsg== X-Received: by 10.55.16.87 with SMTP id a84mr53094919qkh.86.1427987324052; Thu, 02 Apr 2015 08:08:44 -0700 (PDT) Received: from brn1lxmailout01.verisign.com (brn1lxmailout01.verisign.com. [72.13.63.41]) by mx.google.com with ESMTPS id hx9sm1241717qcb.3.2015.04.02.08.08.43 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 02 Apr 2015 08:08:44 -0700 (PDT) X-Relaying-Domain: verisign.com Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01 [10.173.152.255]) by brn1lxmailout01.verisign.com (8.13.8/8.13.8) with ESMTP id t32F8gfX023223 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 2 Apr 2015 11:08:43 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Thu, 2 Apr 2015 11:08:42 -0400 From: "Osterweil, Eric" To: Olafur Gudmundsson Thread-Topic: [dane] Updated draft-ietf-dane-openpgpkey Thread-Index: AQHQbPU1G3T2yEx5KUGnKcWYMYe3j505/kAAgAAMHYCAAAyagA== Date: Thu, 2 Apr 2015 15:08:41 +0000 Message-ID: <4B7FCFB2-F91C-4C43-B121-F53ADA63E328@verisign.com> References: <2E2E6A49-3ED5-49A7-A263-54D8F1B8EE95@roessner-network-solutions.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="Windows-1252" Content-ID: <963E5067D91D194FA2B2A6C1CA3A641D@verisign.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Paul Wouters , dane WG list Subject: Re: [dane] Updated draft-ietf-dane-openpgpkey 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, 02 Apr 2015 15:08:50 -0000 On Apr 2, 2015, at 10:23 AM, Olafur Gudmundsson wrote: > =20 > The drafts will be advanced with the same lookup mechanism.=20 > The process is defined in OPENPGP draft, the SMIME draft will follow OPEN= PGP lead in email address =93transformation=94.=20 Hey all, As a clarifying side comment (to the hashing algo): there is still some int= erest in having _encr and _sign labels in the SMIMEA RR=92s lookup name. i= mho, this can offer a lot of benefits in managing user preference when look= ing up the association between a mailbox and crypto material. I only menti= on that because I think this could be seen as part of the ``lookup mechanis= m.=92=92 libsmaug uses these labels (as well as our soon-to-be available provisionin= g portal). Eric= From nobody Thu Apr 2 08:25:47 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6618A1ACC82 for ; Thu, 2 Apr 2015 08:25:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Q_zc4A4PL8I for ; Thu, 2 Apr 2015 08:25:40 -0700 (PDT) Received: from mail-qg0-f98.google.com (mail-qg0-f98.google.com [209.85.192.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09E761B2D1A for ; Thu, 2 Apr 2015 08:25:38 -0700 (PDT) Received: by qgaj5 with SMTP id j5so1003145qga.1 for ; Thu, 02 Apr 2015 08:25:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:content-type:content-id:content-transfer-encoding :mime-version; bh=95vPTxTuW/HNQLUTOiHsO6EAmOVXeun6ZGLOLx0162E=; b=d74flIMlMRAiAspeEcairjXpgaolcBf4O2+yd5jtD4uvCeN+5OnqqqVOXmUtY+H0m+ iNYRndR9hkb0FfJhUrl2YzmPt1hMHIqZekaMsWFoQr4UXUCR587nxVOjcT1Minb3g2dV CLHBlVZcXkfNMnA+z5MxR8W12rokR1jp5WdnunLh4/wvk0ENrRS69GKrWfL+RUA+ks7Y hPq4HQdDb+fnXC1hSp9UXrKHY7/jU0t2V7f87HCfTeH+lc1aF+DsbgWjgd/YGDgM6Wuf yn8dIwRQoVVDB3dasM31iVNHWBL108IntzB1afw72xGfCiAn0ej43xOVzgH/SwdVxe0S WpYQ== X-Gm-Message-State: ALoCoQlmKWweBsTj4oJjF/nCV99T3HRTdU+qK5WxG9e30HGyun/QU3fb+RF3CfvbIkep6Nb6ke5lIrQpTugN5+EUVQnbrjeaSA== X-Received: by 10.55.31.83 with SMTP id f80mr101035114qkf.57.1427988337979; Thu, 02 Apr 2015 08:25:37 -0700 (PDT) Received: from brn1lxmailout02.verisign.com (brn1lxmailout02.verisign.com. [72.13.63.42]) by mx.google.com with ESMTPS id jy4sm1269091qcb.0.2015.04.02.08.25.37 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 02 Apr 2015 08:25:37 -0700 (PDT) X-Relaying-Domain: verisign.com Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01 [10.173.152.255]) by brn1lxmailout02.verisign.com (8.13.8/8.13.8) with ESMTP id t32FPbNQ013168 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 2 Apr 2015 11:25:37 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Thu, 2 Apr 2015 11:25:37 -0400 From: "Osterweil, Eric" To: Nico Williams Thread-Topic: [dane] encoding mail addresses in the DNS Thread-Index: AQHQbBm1UFRg1SY6sUKop0rwezu6+J04ugSAgAFjZAA= Date: Thu, 2 Apr 2015 15:25:37 +0000 Message-ID: References: <20150330023734.GP17637@mournblade.imrryr.org> <20150401011715.96906.qmail@ary.lan> <20150401181339.GZ10960@localhost> In-Reply-To: <20150401181339.GZ10960@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-ID: <31863B050A865F428BAA4B3FEBE48C38@verisign.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: John Levine , "dane@ietf.org" Subject: Re: [dane] encoding mail addresses in the DNS 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, 02 Apr 2015 15:25:44 -0000 On Apr 1, 2015, at 2:13 PM, Nico Williams wrote: > On Wed, Apr 01, 2015 at 01:17:15AM -0000, John Levine wrote: >>> An alternative is to go back to the original base32 encoding, which >>> is lossless, and thus can allow the remote DNS server (a special-purpos= e >>> DNS lookup engine serving a zone with per-user information) to >>> decode the local-part and perform whatever fuzzy matching may be >>> appropriate. >>>=20 >>> The lossless encoding can support longer names by breaking them up >>> into multiple labels. >>>=20 >>> This allows static DNS to be published where desired, and custom >>> code to produce dynamic results when appropriate. >>=20 >> I wrote up a draft summarizing the ways one might do mailbox >> name lookups in the DNS with something close to the local-part >> rules that MTAs have: >>=20 >> http://datatracker.ietf.org/doc/draft-levine-dns-mailbox/ >=20 > The All Names Valid approach has a problem: we're looking for S/MIME or > OPENPGP public keys, so that's what needs to be found. For any public > key algorithms where not every possible bit string is a possible public > key, and where clients can figure that out, the server would have to > generate distinct plausible public keys, otherwise clients could still > enumerate the set of plausible mailboxes. >=20 > I would still prefer to require MUAs to implement the DNS > (base32-encoded) LHS lookup and the pointer-to-HTTPS-server lookup. > Whether mail domains choose to implement static or dynamic DNS lookups, > or the pointer-to-HTTPS-server, should be up to them. Following up on an earlier comment: by adding a URI field to the SMIMEA RR = (and keeping the CAD for verification on the other end), zone admin/operato= rs can add an RR at the apex of their zone, that points to another service,= secure the delegation with the CAD material, and then (optionally) add per= -inbox RRs (also possibly using URI pointers) in their zone. This would al= so let domains experiment with oracle-like-services in a compatible way wit= h direct key learning from mailboxes, me thinks. :) Eric= From nobody Thu Apr 2 09:49:38 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B24581A9131 for ; Thu, 2 Apr 2015 09:49:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_24=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 rFy8ljgD8kQZ for ; Thu, 2 Apr 2015 09:49:35 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A42E01A870C for ; Thu, 2 Apr 2015 09:49:35 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 9B53E283032; Thu, 2 Apr 2015 16:49:34 +0000 (UTC) Date: Thu, 2 Apr 2015 16:49:34 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150402164934.GC17637@mournblade.imrryr.org> References: <551C8A46.9030904@cs.tcd.ie> <20150402012132.GW17637@mournblade.imrryr.org> <551D2DA1.10809@cs.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <551D2DA1.10809@cs.tcd.ie> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dane] AD review of draft-ietf-dane-srv-12 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, 02 Apr 2015 16:49:37 -0000 On Thu, Apr 02, 2015 at 12:53:05PM +0100, Stephen Farrell wrote: > Meta-question: was this something the wg discussed or did > they just follow your lead? When I joined the WG in ~Mar 15, text along these lines was already in the Tony Finch drafts srv and smtp drafts. So I was not a party to any WG discussion of that decision, but it is obviously the *only* way to deal with DNSSEC redirection (be it SRV or MX). What I was a party to was subsequent discussion of CNAME indirection that is captured in the "ops" draft (WGLC soon, right!). I believe we got consensus for that. And again, if the TLSA base domain is the expanded CNAME, then that's the primary reference identifier (used in SNI, ...) but for mixed/legacy environments the original name is to be also be supported. > The reason I'm asking is the obvious one - this could be > a surprise - if the user agent for some protocol shows > foo.example.com (or has that in a configuration) but via > DNSSEC/DANE/SRV You can add CNAME to the list. :-) > we end up with a TLS session with > bar.example.com and if we say that that is ok, then we're > causing potential developer/deployer/user surprise, and also > setting an upper bound for the level of TLS security that is > only as good as domain-validated. DANE is stronger than DV, but makes no pretense to be EV. > That is a defensible > position (esp for the DANE wg!) but might surprise some > application developers etc. I don't think there'll be many surprises, the application will often be the one passing the reference identifiers to the TLS library. At least in OpenSSL (where I'm involved in designing the DANE support) the TLS library is not going to be doing the TLSA lookups. Rather the application will call use some DNSSEC library to obtain the service specification records (see DANE vocabulary) and find the associated TLSA RRs. It will then hand these (TLSA base domain, RRs, and additional names to accept) off the the TLS library as verification input parameters. > One other question: you mentioned SNI below. Is that very > relevant here, given we're not talking about the web (that > won't use SRV) and afaik most use of SNI is for the web. SNI is a TLS mechanism. It is not a web mechanism. Any time a server handles multiple domains, SNI is potentially useful. We've worked hard (in the ops draft) to make it less necessary to use SNI, precisely by specifying that the primary reference identifier must be the expanded name (except when CNAME expansion is not secure). > So, for which non-web applications is SNI sufficiently > important to justify this (potential) level of developer > surprise? No surprise, on the contrary, as an SMTP developer (e.g.) I *expect* that the reference identifer is the MX hostname, we've been waiting for DNSSEC to make this possible for many years now. Lots of domains have shared backup MX hosts, which can't possibly have certificates for all the domains, but can field a certificate for their own name. Better yet, with DANE-EE(3) the name and expiration of the certificate are entirely irrelevant, making multi-tenancy even easier. [ With DANE-EE(3) Postfix will happily accept certificates in which the Subject DN and Issuer DN are empty RDN sequences, there are no subject alternative names (it's just a fancy key container), and the expiration time precedes the inception time, but I've been asked to not speak of such PKIX-violating apostasy, and I've been good about that. :-) I'll just make a retroactive exception for April 1 below. ] -- Viktor. Certificate: Data: Version: 3 (0x2) Serial Number: 12795556661879960995 (0xb192f2fd7ebcf5a3) Signature Algorithm: sha1WithRSAEncryption Issuer: Validity Not Before: Apr 2 16:46:41 2015 GMT Not After : Apr 1 16:46:41 2015 GMT Subject: Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) Modulus: 00:c6:7c:a9:d1:67:e8:16:9e:c8:94:04:a8:8c:ca: 4f:d1:5c:d0:cf:1f:a8:6d:46:84:29:72:5d:26:fc: e3:0d:14:08:2a:cc:27:8b:ad:ef:68:80:68:8a:b2: be:10:df:c1:1e:26:b4:3d:94:1b:d2:2b:d8:41:05: 46:93:26:d5:f4:10:a5:48:e4:d3:ae:e1:78:34:43: 2b:13:33:3f:1a:7c:72:7f:e6:a9:24:e6:5e:c0:e6: 42:ad:d5:4e:e4:95:6c:91:b8:83:66:7e:76:6f:64: e6:bd:c9:f1:ff:34:89:08:bc:7b:10:bf:63:a2:8c: 62:0a:0a:14:69:71:e1:24:de:e1:ce:22:2f:fe:14: dd:cf:0d:99:b7:9e:8a:62:2d:5c:29:06:d6:7e:95: ef:d0:8c:0f:e7:23:e8:34:2d:af:37:d6:05:bc:83: 72:00:d5:18:64:38:44:f4:61:39:9c:8b:2d:b9:b7: 04:57:16:cb:79:5a:8e:61:94:fa:2e:82:9e:0d:23: bc:23:d8:42:01:ee:3c:53:6f:c7:13:0c:46:03:7c: 93:97:9d:50:af:af:8a:e9:e5:42:b4:46:fa:89:9c: e9:b8:24:b9:6a:44:e9:31:50:87:1d:9f:b8:07:9a: 98:a8:0d:ca:ca:41:d3:d2:f1:d0:a5:d6:7f:76:b8: 54:7f Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Subject Key Identifier: B5:76:28:80:32:B8:9D:82:75:94:AE:20:9E:DF:A0:B7:BA:53:D9:55 X509v3 Authority Key Identifier: keyid:B5:76:28:80:32:B8:9D:82:75:94:AE:20:9E:DF:A0:B7:BA:53:D9:55 X509v3 Basic Constraints: CA:TRUE Signature Algorithm: sha1WithRSAEncryption c0:1d:17:0d:74:c0:bd:38:a1:dc:ed:b1:86:0d:81:ad:74:58: 20:c3:31:9f:80:94:4d:47:28:10:14:bf:04:30:4b:bf:dc:91: af:d7:73:05:f4:3f:af:0f:fe:87:12:88:17:07:68:2a:51:31: f6:b9:c6:10:3b:84:87:bd:f6:b1:dc:8d:02:e9:87:c8:cf:54: b4:8d:bf:17:8c:e1:e1:95:4a:a8:b0:1e:75:36:e8:b5:c0:e9: 7e:52:c9:7b:62:69:55:0a:b0:0e:d6:e9:b5:a1:ea:c5:22:e1: bc:c4:73:ec:7d:cd:26:ab:12:7a:1f:4f:7d:1d:52:25:6f:69: f4:ea:79:91:10:68:73:a5:67:15:87:a4:e9:85:e4:1a:bd:12: 17:70:cc:83:d7:23:d8:19:79:94:38:c9:44:92:61:16:3f:e5: 07:a7:8c:6d:4e:b7:8b:d1:7f:d4:14:de:02:94:7e:2f:6f:66: 2a:04:eb:dd:2a:58:c2:bd:c7:10:e9:e7:2d:f7:18:78:4a:54: f5:8a:75:6f:56:71:3b:be:28:07:f6:31:78:91:1c:40:0b:f8: 64:2c:ca:99:e7:da:70:25:15:be:af:77:1d:d7:2b:67:f8:01: 7c:ab:08:e8:4c:60:7c:92:d1:d1:80:14:57:bc:14:a8:10:a1: a3:70:44:0f -----BEGIN CERTIFICATE----- MIIC0zCCAbugAwIBAgIJALGS8v1+vPWjMA0GCSqGSIb3DQEBBQUAMAAwHhcNMTUw NDAyMTY0NjQxWhcNMTUwNDAxMTY0NjQxWjAAMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEAxnyp0WfoFp7IlASojMpP0VzQzx+obUaEKXJdJvzjDRQIKswn i63vaIBoirK+EN/BHia0PZQb0ivYQQVGkybV9BClSOTTruF4NEMrEzM/Gnxyf+ap JOZewOZCrdVO5JVskbiDZn52b2Tmvcnx/zSJCLx7EL9jooxiCgoUaXHhJN7hziIv /hTdzw2Zt56KYi1cKQbWfpXv0IwP5yPoNC2vN9YFvINyANUYZDhE9GE5nIstubcE VxbLeVqOYZT6LoKeDSO8I9hCAe48U2/HEwxGA3yTl51Qr6+K6eVCtEb6iZzpuCS5 akTpMVCHHZ+4B5qYqA3KykHT0vHQpdZ/drhUfwIDAQABo1AwTjAdBgNVHQ4EFgQU tXYogDK4nYJ1lK4gnt+gt7pT2VUwHwYDVR0jBBgwFoAUtXYogDK4nYJ1lK4gnt+g t7pT2VUwDAYDVR0TBAUwAwEB/zANBgkqhkiG9w0BAQUFAAOCAQEAwB0XDXTAvTih 3O2xhg2BrXRYIMMxn4CUTUcoEBS/BDBLv9yRr9dzBfQ/rw/+hxKIFwdoKlEx9rnG EDuEh732sdyNAumHyM9UtI2/F4zh4ZVKqLAedTbotcDpflLJe2JpVQqwDtbptaHq xSLhvMRz7H3NJqsSeh9PfR1SJW9p9Op5kRBoc6VnFYek6YXkGr0SF3DMg9cj2Bl5 lDjJRJJhFj/lB6eMbU63i9F/1BTeApR+L29mKgTr3SpYwr3HEOnnLfcYeEpU9Yp1 b1ZxO74oB/YxeJEcQAv4ZCzKmefacCUVvq93HdcrZ/gBfKsI6ExgfJLR0YAUV7wU qBCho3BEDw== -----END CERTIFICATE----- From nobody Thu Apr 2 09:52:43 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E25751A890F for ; Thu, 2 Apr 2015 09:52:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.351 X-Spam-Level: X-Spam-Status: No, score=-1.351 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, 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 RtBLWhUCKB5I for ; Thu, 2 Apr 2015 09:52:36 -0700 (PDT) Received: from mx.roessner-net.de (mail.roessner-net.de [193.239.107.42]) (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 75B7D1A1A4A for ; Thu, 2 Apr 2015 09:52:36 -0700 (PDT) Received: from mail.roessner-net.de (mail.roessner-net.de [193.239.107.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.roessner-net.de", Issuer "thawte DV SSL CA - G2" (verified OK)) by mx.roessner-net.de (Postfix) with ESMTPS id 3lHr6V4H2MzGp56; Thu, 2 Apr 2015 18:52:34 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=roessner-network-solutions.com; s=swioBi3opho; t=1427993554; i=@roessner-network-solutions.com; bh=OlNH3AkpbUysW2v/lyGUFuSroIBd7MDLFLBJ4qy42HE=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=DyYlWdlnT4jm9B6FEIU34EopBF5rOWWvOK/bkFhRXXyGvIR4RSi+dDrUl5QJ7TE27 FuB9HBAEF2WV/HMSK2ttV5DmD8Ecx8QJ4y2d8CPoJxaNOXEoM6MzUNJ82jZhxrG2W7 S9Nyv488DE/RxHufrCV8MoBsUbvZ4LkNSpztTwow54Qtz9VOzPc+5noqmZWCdJDRN2 ouSVH8TN0QEPG7XRwFJdKyiijCcmc6qRODjQkZ2P5ctU3+QgCD4+F3miX2cHhOqifr L6aw5EvqUPWa69q/78FTACbBvHmEv1xAzBvgp0IDYpVDTDZn/KfVMQLHU9/L8vAB+X 8iqU+IMyN3c0g== Received: from [172.16.2.200] (static-201-106.deltasurf.de [193.239.106.201]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Christian Roessner", Issuer "RootCA (c) 2014" (verified OK)) (Authenticated sender: c@roessner.co) by mail.roessner-net.de (Postfix) with ESMTPSA id 3lHr6V0GMPzMkrT; Thu, 2 Apr 2015 18:52:33 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_82B9B305-035C-43B0-BBDE-81E5C4E9C20F"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2096\)) From: =?utf-8?Q?Christian_R=C3=B6=C3=9Fner?= In-Reply-To: <4B7FCFB2-F91C-4C43-B121-F53ADA63E328@verisign.com> Date: Thu, 2 Apr 2015 18:52:33 +0200 Message-Id: References: <2E2E6A49-3ED5-49A7-A263-54D8F1B8EE95@roessner-network-solutions.com> <4B7FCFB2-F91C-4C43-B121-F53ADA63E328@verisign.com> To: "Osterweil, Eric" X-Mailer: Apple Mail (2.2096) Outgoingd: 0.3.0_m1 Archived-At: Cc: Paul Wouters , dane WG list Subject: Re: [dane] Updated draft-ietf-dane-openpgpkey 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, 02 Apr 2015 16:52:39 -0000 --Apple-Mail=_82B9B305-035C-43B0-BBDE-81E5C4E9C20F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 > Am 02.04.2015 um 17:08 schrieb Osterweil, Eric = : >=20 >=20 > On Apr 2, 2015, at 10:23 AM, Olafur Gudmundsson wrote: >=20 >> =20 >> The drafts will be advanced with the same lookup mechanism.=20 >> The process is defined in OPENPGP draft, the SMIME draft will follow = OPENPGP lead in email address =93transformation=94.=20 >=20 > Hey all, >=20 > As a clarifying side comment (to the hashing algo): there is still = some interest in having _encr and _sign labels in the SMIMEA RR=92s = lookup name. imho, this can offer a lot of benefits in managing user = preference when looking up the association between a mailbox and crypto = material. I only mention that because I think this could be seen as = part of the ``lookup mechanism.=92=92 >=20 > libsmaug uses these labels (as well as our soon-to-be available = provisioning portal). Just a question for ._encr and ._sign: Do you really plan to store private keys in public DNS? Is it, what = ._sign will be used for? Isn=92t this really a security issue? I am not a DNS expert, but isn=92t it possible to walk through a DNS = zone using NSEC and get all records of a zone and therefor you also = would get all private keys in the subdomain ._sign? I personally only would store public keys in DNS for opportunistic = encryption. Therefor I would not see a need for an extra subdomain = ._encr (and of course not ._sign) Christian -- Bachelor of Science Informatik Erlenwiese 14, 36304 Alsfeld T: +49 6631 78823400, F: +49 6631 78823409, M: +49 171 9905345 USt-IdNr.: DE225643613, http://www.roessner-network-solutions.com --Apple-Mail=_82B9B305-035C-43B0-BBDE-81E5C4E9C20F Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIE8TCCBO0w ggPVoAMCAQICAhAFMA0GCSqGSIb3DQEBCwUAMIHeMQswCQYDVQQGEwJERTESMBAGCgmSJomT8ixk ARkWAmRlMRwwGgYKCZImiZPyLGQBGRYMcm9lc3NuZXItbmV0MQ8wDQYDVQQIDAZIZXNzZW4xEDAO BgNVBAcMB0Fsc2ZlbGQxDzANBgNVBAoMBlIuTi5TLjEeMBwGA1UECwwVQ2VydGlmaWNhdGUgQXV0 aG9yaXR5MRgwFgYDVQQDDA9Sb290Q0EgKGMpIDIwMTQxLzAtBgkqhkiG9w0BCQEWIGNAcm9lc3Nu ZXItbmV0d29yay1zb2x1dGlvbnMuY29tMB4XDTE0MDkwNzE0MDI0NloXDTI0MDkwNDE0MDI0Nlow gdAxCzAJBgNVBAYTAkRFMRIwEAYKCZImiZPyLGQBGRYCZGUxHDAaBgoJkiaJk/IsZAEZFgxyb2Vz c25lci1uZXQxDzANBgNVBAgMBkhlc3NlbjEQMA4GA1UEBwwHQWxzZmVsZDEPMA0GA1UECgwGUi5O LlMuMQ0wCwYDVQQLDARNYWlsMRswGQYDVQQDDBJDaHJpc3RpYW4gUm9lc3NuZXIxLzAtBgkqhkiG 9w0BCQEWIGNAcm9lc3NuZXItbmV0d29yay1zb2x1dGlvbnMuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAvRa6QBgHt56hf1RuKHsNkXPXTFzG0RLualxlyfsJS0nWNWFaBD7ceZ8F WhnP7ypHSyWE4aCy7BYM4n2iVDm9m8bKV5cXuSdLY3kefqSOk9+YvCLu1MqQk70BY7UReS7OUJ1r ml1v09igaYA1+4FT8Um5oXB69BMm/JxFlkJ/TEu7KQzZ++oWavezChU+tc3neP4TJ9B+e4Q3BiTW RPMzmWf1HDR9RfhU4YPT0AQpvMusYUN/QKqKgh7cCCx8fcMO7noZDCNJchKLuil8/jKznJtj8+/B mwbvHJjshv/txNxKr8Id1K7+cQMweMA6uuOiJIt9oOAcPM8UEMzFwrShvwIDAQABo4HAMIG9MAkG A1UdEwQCMAAwLAYJYIZIAYb4QgENBB8WHU9wZW5TU0wgR2VuZXJhdGVkIENlcnRpZmljYXRlMB0G A1UdDgQWBBQkzf3k5Z/BAcTvlAu53yCIqJXMUzAfBgNVHSMEGDAWgBTgcUa1UKCapZJ6/qUWTH2C bOT9nDBCBgNVHR8EOzA5MDegNaAzhjFodHRwOi8vd3d3LnJvZXNzbmVyLW5ldHdvcmstc29sdXRp b25zLmNvbS9jcmwucGVtMA0GCSqGSIb3DQEBCwUAA4IBAQBGVbjnbP3RkXd5BStfKfyGWwNAAzrS dR1fy+tje5Zoq8t9nvxtaNnPCehyztTgUFfNaARFI5yY+z2ZaJ58NnQhSKYuZDkx/mwZkGcVbvp5 r7uDqFo42OfHej6SMIMzwKuXEgF26bKmcm4uZOouw8Ec68raEfnRY22loL8usx2yrH1qURgjSTJP PZ2Rs+2WVTWxylhLADAf7aAXTUPCx4zW6cGPYA2GR8w9ZYk74fIpPus4hs/LbBUVYtOMX6daVwkC 8xmQmcRihGo8wB5N2dH2T0fPV70HSn5GTUQ8O69ObDT8zo33dvg2w4swbWaKdn11Ywhd+HhvM+Ru bOSB+EBuMYIEYjCCBF4CAQEwgeUwgd4xCzAJBgNVBAYTAkRFMRIwEAYKCZImiZPyLGQBGRYCZGUx HDAaBgoJkiaJk/IsZAEZFgxyb2Vzc25lci1uZXQxDzANBgNVBAgMBkhlc3NlbjEQMA4GA1UEBwwH QWxzZmVsZDEPMA0GA1UECgwGUi5OLlMuMR4wHAYDVQQLDBVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkx GDAWBgNVBAMMD1Jvb3RDQSAoYykgMjAxNDEvMC0GCSqGSIb3DQEJARYgY0Byb2Vzc25lci1uZXR3 b3JrLXNvbHV0aW9ucy5jb20CAhAFMAkGBSsOAwIaBQCgggJRMBgGCSqGSIb3DQEJAzELBgkqhkiG 9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDQwMjE2NTIzNFowIwYJKoZIhvcNAQkEMRYEFP+vIqb5 5Gbvn+LoXVqNijZ+1X/wMIH2BgkrBgEEAYI3EAQxgegwgeUwgd4xCzAJBgNVBAYTAkRFMRIwEAYK CZImiZPyLGQBGRYCZGUxHDAaBgoJkiaJk/IsZAEZFgxyb2Vzc25lci1uZXQxDzANBgNVBAgMBkhl c3NlbjEQMA4GA1UEBwwHQWxzZmVsZDEPMA0GA1UECgwGUi5OLlMuMR4wHAYDVQQLDBVDZXJ0aWZp Y2F0ZSBBdXRob3JpdHkxGDAWBgNVBAMMD1Jvb3RDQSAoYykgMjAxNDEvMC0GCSqGSIb3DQEJARYg Y0Byb2Vzc25lci1uZXR3b3JrLXNvbHV0aW9ucy5jb20CAhAFMIH4BgsqhkiG9w0BCRACCzGB6KCB 5TCB3jELMAkGA1UEBhMCREUxEjAQBgoJkiaJk/IsZAEZFgJkZTEcMBoGCgmSJomT8ixkARkWDHJv ZXNzbmVyLW5ldDEPMA0GA1UECAwGSGVzc2VuMRAwDgYDVQQHDAdBbHNmZWxkMQ8wDQYDVQQKDAZS Lk4uUy4xHjAcBgNVBAsMFUNlcnRpZmljYXRlIEF1dGhvcml0eTEYMBYGA1UEAwwPUm9vdENBIChj KSAyMDE0MS8wLQYJKoZIhvcNAQkBFiBjQHJvZXNzbmVyLW5ldHdvcmstc29sdXRpb25zLmNvbQIC EAUwDQYJKoZIhvcNAQEBBQAEggEAq46VTLFMCdxtsUNW/yx1OZD++TO82zW0wBxolS1LyQTO2If6 JQCGLUTvbD0bN5gLpFx4JthBQBbuvGB4yIs8709BIth3ff72OAax7kENhZcIp2tcrOWph3aFDCuc nQuzIXPMp3OgrvahwrMgCX4ALncg6ftazqL6kLd1kGiIlJtsjcQa3rQqm7hzMRCpV2YuaVilDwsS upT76KcLJFmmYNwiyzoHU1fJPswD7LxKSKikbE55p7XBTiqdPuuZI9F87ngrp+FLsOjFoBrMh1jW rUyICgZV21fgZ7Ds4Qn/jdifDC8F3E5fUOEBVQbPz2iyPVIDRkpYLvTLwdK0Qgko8gAAAAAAAA== --Apple-Mail=_82B9B305-035C-43B0-BBDE-81E5C4E9C20F-- From nobody Thu Apr 2 10:12:45 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12EE71AC422 for ; Thu, 2 Apr 2015 10:12:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_31=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FNYLq89nNDoC for ; Thu, 2 Apr 2015 10:12:43 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC1C31AC40F for ; Thu, 2 Apr 2015 10:12:42 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id AA289283032; Thu, 2 Apr 2015 17:12:41 +0000 (UTC) Date: Thu, 2 Apr 2015 17:12:41 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150402171241.GD17637@mournblade.imrryr.org> References: <2E2E6A49-3ED5-49A7-A263-54D8F1B8EE95@roessner-network-solutions.com> <4B7FCFB2-F91C-4C43-B121-F53ADA63E328@verisign.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dane] Updated draft-ietf-dane-openpgpkey 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, 02 Apr 2015 17:12:44 -0000 On Thu, Apr 02, 2015 at 06:52:33PM +0200, Christian R??ner wrote: > > libsmaug uses these labels (as well as our soon-to-be available provisioning portal). > > Just a question for ._encr and ._sign: > > Do you really plan to store private keys in public DNS? Is it, what ._sign will be used for? Isn?t this really a security issue? No they are public keys in both cases. Some public keys are for signing only, others are for encryption (which means that they can receive encrypted content). The idea that these need separate locations in DNS has not seen much support on this list. In consumer deployments, I don't see such separation as likely to take place. In enterprise deployments, I expect implementations will publish gateway keys that decrypt the email, apply various content policies, and then sometimes deliver re-encrypted content to the end-user, but using keys that the outside world does not see. -- Viktor. To be honest, I don't expect encrypted messages in the mailbox to ever be very popular, encrypted storage is just too inconvenient for most users. End-to-end is good for live conversations, but not so well suited to archived communication. We can try to make it more usable for those willing to put up with the inconvenience, but I would not really expect large-scale adoption. That's a personal best guess of course, I am willing to be proved wrong. From nobody Thu Apr 2 10:24:36 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C8581A1B48 for ; Thu, 2 Apr 2015 10:24:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.41 X-Spam-Level: X-Spam-Status: No, score=-1.41 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_31=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bOjWXYBhCI5u for ; Thu, 2 Apr 2015 10:24:34 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E52D1AD364 for ; Thu, 2 Apr 2015 10:24:34 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3lHrqN4f5XzlH for ; Thu, 2 Apr 2015 19:24:32 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=hJb93UK+ X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id Pk9CZ0Lafmf0 for ; Thu, 2 Apr 2015 19:24:31 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for ; Thu, 2 Apr 2015 19:24:31 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 0C09D8078B for ; Thu, 2 Apr 2015 13:24:30 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1427995470; bh=NhAeFVWsEnb4EsTguq/fzB23VZblHByg7qzn2GssbQI=; h=Date:From:To:Subject:In-Reply-To:References; b=hJb93UK+S18/P9msSYgPuMWbM99KiuBQ03U/2sDC9Wy8f9zanpgH9objRJ5xakDPk R6+4amA3nesPUtYDx3QaZp2Vs2//lwFOolKYuJ+U72XaIegLshAFHWjF4lEMrOGX9C mDYlOcY69JpBUQvU+mO8A/iDyoAO8U1DbKLCeY1s= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id t32HOTBK013564 for ; Thu, 2 Apr 2015 13:24:29 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Thu, 2 Apr 2015 13:24:29 -0400 (EDT) From: Paul Wouters To: dane@ietf.org In-Reply-To: <20150402171241.GD17637@mournblade.imrryr.org> Message-ID: References: <2E2E6A49-3ED5-49A7-A263-54D8F1B8EE95@roessner-network-solutions.com> <4B7FCFB2-F91C-4C43-B121-F53ADA63E328@verisign.com> <20150402171241.GD17637@mournblade.imrryr.org> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dane] Updated draft-ietf-dane-openpgpkey 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, 02 Apr 2015 17:24:36 -0000 On Thu, 2 Apr 2015, Viktor Dukhovni wrote: >> Just a question for ._encr and ._sign: >> >> Do you really plan to store private keys in public DNS? Is it, what ._sign will be used for? Isn?t this really a security issue? > > No they are public keys in both cases. Some public keys are for > signing only, others are for encryption (which means that they can > receive encrypted content). > > The idea that these need separate locations in DNS has not seen > much support on this list. In consumer deployments, I don't see > such separation as likely to take place. > > In enterprise deployments, I expect implementations will publish > gateway keys that decrypt the email, apply various content policies, > and then sometimes deliver re-encrypted content to the end-user, > but using keys that the outside world does not see. Also, the smime key attributes will tell if if they are usable for signing and/or encrypting. So my preference is to not have another place to indicate this so we avoid needing to deal with mismatches. > To be honest, I don't expect encrypted messages in the mailbox to > ever be very popular, encrypted storage is just too inconvenient > for most users. Having run openpgpkey-milter and gotten all of my email encrypted due to my own forwarder, I strongly agree with that it is completely inconvenient right now. But it is a problem that we need to solve to make it convenient. I'm hoping that encrypting more email will mean more people will work on better MUA integration of it. We really need to fix this problem. > End-to-end is good for live conversations, but > not so well suited to archived communication. I personally would like my MUA to store email decrypted, replace the encrypted email headers inside the body back into real email headers and rely on full disk encryption. That way, I get the best of both worlds. Paul From nobody Thu Apr 2 10:29:27 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28CF21A006B for ; Thu, 2 Apr 2015 10:29:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.751 X-Spam-Level: X-Spam-Status: No, score=-0.751 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_DE=0.35, J_CHICKENPOX_31=0.6, MIME_8BIT_HEADER=0.3, 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 PTOpZpZzhAts for ; Thu, 2 Apr 2015 10:29:24 -0700 (PDT) Received: from mx.roessner-net.de (mail.roessner-net.de [193.239.107.42]) (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 D7AB01A8939 for ; Thu, 2 Apr 2015 10:29:23 -0700 (PDT) Received: from mail.roessner-net.de (mail.roessner-net.de [193.239.107.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.roessner-net.de", Issuer "thawte DV SSL CA - G2" (verified OK)) by mx.roessner-net.de (Postfix) with ESMTPS id 3lHrwx6bw7zGpN9 for ; Thu, 2 Apr 2015 19:29:21 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=roessner-network-solutions.com; s=swioBi3opho; t=1427995761; i=@roessner-network-solutions.com; bh=HfqwIqaLKhTJSHe6LtLRdu/oV7de4Zcc+O4/lC9HtSE=; h=From:Subject:Date:References:To:In-Reply-To; b=CR/A2Q1H6PHXf9lNS+Z7SjH+NUXhcr1vN0AwW1WYTXwPoZ50YCw7EQ5zYaMNnVWxp x3kSpWk03DLYZ5ZcAbYb3InXSPUTrJ+b/RJ8TaMPT+rVfPQxtUoP/RgF67+m9dDttB U4h+K10gMYKQIaSJFPcX2x/QWr/C43X+tht+f7HeXgAYey6S9FtrOMbilimxIevkiZ NuZuiVLx86ALY2Fh4hTZ53OO3cfBfVpk/O26srbCQU/LTw6oX8f1LppzqybPXx6uxf HZWhbOt9jfOj8zdev2wd30/V+jjmwNWjRsaNOHbpAoFgSO4rGpyebwhDw4ykV3CvFT SVuks0R7z6G4g== Received: from [172.16.2.200] (static-201-106.deltasurf.de [193.239.106.201]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Christian Roessner", Issuer "RootCA (c) 2014" (verified OK)) (Authenticated sender: c@roessner.co) by mail.roessner-net.de (Postfix) with ESMTPSA id 3lHrwx46dszMkrT for ; Thu, 2 Apr 2015 19:29:21 +0200 (CEST) From: =?utf-8?Q?Christian_R=C3=B6=C3=9Fner?= Content-Type: multipart/signed; boundary="Apple-Mail=_96B973A2-AE4C-4CEA-9F44-C3054C8610DE"; protocol="application/pkcs7-signature"; micalg=sha1 Message-Id: <8955C3CA-6C5A-4FF9-AF65-BF56C0BC4FB8@roessner-network-solutions.com> Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2096\)) Date: Thu, 2 Apr 2015 19:29:21 +0200 References: <2E2E6A49-3ED5-49A7-A263-54D8F1B8EE95@roessner-network-solutions.com> <4B7FCFB2-F91C-4C43-B121-F53ADA63E328@verisign.com> <20150402171241.GD17637@mournblade.imrryr.org> To: dane@ietf.org In-Reply-To: <20150402171241.GD17637@mournblade.imrryr.org> X-Mailer: Apple Mail (2.2096) Outgoingd: 0.3.0_m1 Archived-At: Subject: Re: [dane] Updated draft-ietf-dane-openpgpkey 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, 02 Apr 2015 17:29:25 -0000 --Apple-Mail=_96B973A2-AE4C-4CEA-9F44-C3054C8610DE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > Am 02.04.2015 um 19:12 schrieb Viktor Dukhovni = : >=20 > On Thu, Apr 02, 2015 at 06:52:33PM +0200, Christian R??ner wrote: >=20 >>> libsmaug uses these labels (as well as our soon-to-be available = provisioning portal). >>=20 >> Just a question for ._encr and ._sign: >>=20 >> Do you really plan to store private keys in public DNS? Is it, what = ._sign will be used for? Isn?t this really a security issue? >=20 > No they are public keys in both cases. Some public keys are for > signing only, others are for encryption (which means that they can > receive encrypted content). Ok, seems I have to learn a lot more about security. I always thought = that a pair of keys consist of one public key and one private key and = that the public key is distributed for those who want to encrypt mail = and that the private key is used for decryption. At the other hand using = that private key for signing mails and giving others the chance to = verify with the published public key. Is that wrong thinking? I never knew that you can use a public key for signing. Or at least I = never tried. Sorry, if I ask :-) Christian --Apple-Mail=_96B973A2-AE4C-4CEA-9F44-C3054C8610DE Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIE8TCCBO0w ggPVoAMCAQICAhAFMA0GCSqGSIb3DQEBCwUAMIHeMQswCQYDVQQGEwJERTESMBAGCgmSJomT8ixk ARkWAmRlMRwwGgYKCZImiZPyLGQBGRYMcm9lc3NuZXItbmV0MQ8wDQYDVQQIDAZIZXNzZW4xEDAO BgNVBAcMB0Fsc2ZlbGQxDzANBgNVBAoMBlIuTi5TLjEeMBwGA1UECwwVQ2VydGlmaWNhdGUgQXV0 aG9yaXR5MRgwFgYDVQQDDA9Sb290Q0EgKGMpIDIwMTQxLzAtBgkqhkiG9w0BCQEWIGNAcm9lc3Nu ZXItbmV0d29yay1zb2x1dGlvbnMuY29tMB4XDTE0MDkwNzE0MDI0NloXDTI0MDkwNDE0MDI0Nlow gdAxCzAJBgNVBAYTAkRFMRIwEAYKCZImiZPyLGQBGRYCZGUxHDAaBgoJkiaJk/IsZAEZFgxyb2Vz c25lci1uZXQxDzANBgNVBAgMBkhlc3NlbjEQMA4GA1UEBwwHQWxzZmVsZDEPMA0GA1UECgwGUi5O LlMuMQ0wCwYDVQQLDARNYWlsMRswGQYDVQQDDBJDaHJpc3RpYW4gUm9lc3NuZXIxLzAtBgkqhkiG 9w0BCQEWIGNAcm9lc3NuZXItbmV0d29yay1zb2x1dGlvbnMuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAvRa6QBgHt56hf1RuKHsNkXPXTFzG0RLualxlyfsJS0nWNWFaBD7ceZ8F WhnP7ypHSyWE4aCy7BYM4n2iVDm9m8bKV5cXuSdLY3kefqSOk9+YvCLu1MqQk70BY7UReS7OUJ1r ml1v09igaYA1+4FT8Um5oXB69BMm/JxFlkJ/TEu7KQzZ++oWavezChU+tc3neP4TJ9B+e4Q3BiTW RPMzmWf1HDR9RfhU4YPT0AQpvMusYUN/QKqKgh7cCCx8fcMO7noZDCNJchKLuil8/jKznJtj8+/B mwbvHJjshv/txNxKr8Id1K7+cQMweMA6uuOiJIt9oOAcPM8UEMzFwrShvwIDAQABo4HAMIG9MAkG A1UdEwQCMAAwLAYJYIZIAYb4QgENBB8WHU9wZW5TU0wgR2VuZXJhdGVkIENlcnRpZmljYXRlMB0G A1UdDgQWBBQkzf3k5Z/BAcTvlAu53yCIqJXMUzAfBgNVHSMEGDAWgBTgcUa1UKCapZJ6/qUWTH2C bOT9nDBCBgNVHR8EOzA5MDegNaAzhjFodHRwOi8vd3d3LnJvZXNzbmVyLW5ldHdvcmstc29sdXRp b25zLmNvbS9jcmwucGVtMA0GCSqGSIb3DQEBCwUAA4IBAQBGVbjnbP3RkXd5BStfKfyGWwNAAzrS dR1fy+tje5Zoq8t9nvxtaNnPCehyztTgUFfNaARFI5yY+z2ZaJ58NnQhSKYuZDkx/mwZkGcVbvp5 r7uDqFo42OfHej6SMIMzwKuXEgF26bKmcm4uZOouw8Ec68raEfnRY22loL8usx2yrH1qURgjSTJP PZ2Rs+2WVTWxylhLADAf7aAXTUPCx4zW6cGPYA2GR8w9ZYk74fIpPus4hs/LbBUVYtOMX6daVwkC 8xmQmcRihGo8wB5N2dH2T0fPV70HSn5GTUQ8O69ObDT8zo33dvg2w4swbWaKdn11Ywhd+HhvM+Ru bOSB+EBuMYIEYjCCBF4CAQEwgeUwgd4xCzAJBgNVBAYTAkRFMRIwEAYKCZImiZPyLGQBGRYCZGUx HDAaBgoJkiaJk/IsZAEZFgxyb2Vzc25lci1uZXQxDzANBgNVBAgMBkhlc3NlbjEQMA4GA1UEBwwH QWxzZmVsZDEPMA0GA1UECgwGUi5OLlMuMR4wHAYDVQQLDBVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkx GDAWBgNVBAMMD1Jvb3RDQSAoYykgMjAxNDEvMC0GCSqGSIb3DQEJARYgY0Byb2Vzc25lci1uZXR3 b3JrLXNvbHV0aW9ucy5jb20CAhAFMAkGBSsOAwIaBQCgggJRMBgGCSqGSIb3DQEJAzELBgkqhkiG 9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDQwMjE3MjkyMlowIwYJKoZIhvcNAQkEMRYEFCWHRCW+ vCFPiBg12WoAvbISrTgGMIH2BgkrBgEEAYI3EAQxgegwgeUwgd4xCzAJBgNVBAYTAkRFMRIwEAYK CZImiZPyLGQBGRYCZGUxHDAaBgoJkiaJk/IsZAEZFgxyb2Vzc25lci1uZXQxDzANBgNVBAgMBkhl c3NlbjEQMA4GA1UEBwwHQWxzZmVsZDEPMA0GA1UECgwGUi5OLlMuMR4wHAYDVQQLDBVDZXJ0aWZp Y2F0ZSBBdXRob3JpdHkxGDAWBgNVBAMMD1Jvb3RDQSAoYykgMjAxNDEvMC0GCSqGSIb3DQEJARYg Y0Byb2Vzc25lci1uZXR3b3JrLXNvbHV0aW9ucy5jb20CAhAFMIH4BgsqhkiG9w0BCRACCzGB6KCB 5TCB3jELMAkGA1UEBhMCREUxEjAQBgoJkiaJk/IsZAEZFgJkZTEcMBoGCgmSJomT8ixkARkWDHJv ZXNzbmVyLW5ldDEPMA0GA1UECAwGSGVzc2VuMRAwDgYDVQQHDAdBbHNmZWxkMQ8wDQYDVQQKDAZS Lk4uUy4xHjAcBgNVBAsMFUNlcnRpZmljYXRlIEF1dGhvcml0eTEYMBYGA1UEAwwPUm9vdENBIChj KSAyMDE0MS8wLQYJKoZIhvcNAQkBFiBjQHJvZXNzbmVyLW5ldHdvcmstc29sdXRpb25zLmNvbQIC EAUwDQYJKoZIhvcNAQEBBQAEggEAlyE2fMpxsswvrTz5fHqZimNsjMa8ZUMPSWstm8tQMudIl5Xf Q7ZuRudlkmhJoUCDmIObUVyyzSW1JLQqjQ50Tmpoy/dIa3OJD4NQhKT7DpctxG4Yg7196Xm2jnL5 QPhtr7RDy4t9L2ZK+ovyfnfv30Krp5mBz4m6pKlFDJoD2UUJj7aocDmIg03zIl8OpNKM0nT8hb/Q ytwQDaH58Mymr00NBMQfzOaUAFw+tRgVqi18QN4Ipglml7rw+5iq6Nr4L/qkCWzuuVkoP6qk0Q1S iG8jkL27MuMbws1xnmWJ/MBdROx3+cxAJ1oAi++lpDaI6I6IKhHxN/b9+vZGZXcbZQAAAAAAAA== --Apple-Mail=_96B973A2-AE4C-4CEA-9F44-C3054C8610DE-- From nobody Thu Apr 2 10:33:45 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EE4C1B2D5B for ; Thu, 2 Apr 2015 10:33:44 -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 9VGAT9__NRLd for ; Thu, 2 Apr 2015 10:33:43 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BF5D1B2D58 for ; Thu, 2 Apr 2015 10:33:43 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 43819283032; Thu, 2 Apr 2015 17:33:42 +0000 (UTC) Date: Thu, 2 Apr 2015 17:33:42 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150402173342.GG17637@mournblade.imrryr.org> References: <2E2E6A49-3ED5-49A7-A263-54D8F1B8EE95@roessner-network-solutions.com> <4B7FCFB2-F91C-4C43-B121-F53ADA63E328@verisign.com> <20150402171241.GD17637@mournblade.imrryr.org> <8955C3CA-6C5A-4FF9-AF65-BF56C0BC4FB8@roessner-network-solutions.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8955C3CA-6C5A-4FF9-AF65-BF56C0BC4FB8@roessner-network-solutions.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dane] Updated draft-ietf-dane-openpgpkey 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, 02 Apr 2015 17:33:44 -0000 On Thu, Apr 02, 2015 at 07:29:21PM +0200, Christian R??ner wrote: > I never knew that you can use a public key for signing. Or at least I never tried. Your initial thinking was right, the private key is used for signing, but the public key is published so that verifiers can validate the signature. The proposal is to publish verification (public) keys (that validate received mail) separately from encryption (public) keys that enable encryption of outgoing mail. -- Viktor. From nobody Thu Apr 2 10:43:27 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36E2B1B2D6C for ; Thu, 2 Apr 2015 10:43:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CjKmVOGgJBzc for ; Thu, 2 Apr 2015 10:43:25 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 063D41B2D34 for ; Thu, 2 Apr 2015 10:43:25 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3lHsF713ZFzlH for ; Thu, 2 Apr 2015 19:43:23 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=gn+36Buc X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id i62omuKkdL9e for ; Thu, 2 Apr 2015 19:43:22 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for ; Thu, 2 Apr 2015 19:43:22 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 617F4803E0 for ; Thu, 2 Apr 2015 13:43:21 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1427996601; bh=JCVePzVLA8K9cx2rY1Fn/Hjo6QJ+sULOESDECk2Jq9k=; h=Date:From:To:Subject:In-Reply-To:References; b=gn+36BucDINAP5ObTfjUPcQaiSjcnW2PrhEy6i0L1JUwX0Vkk8LhSR9WSUsiWOVyO BtfsNFpFCBofRenCweWyz0jVbbrKJ/G4YcS4IOa2bPFBjiVZYSUDZk1BMXvX5ZXSF3 gwlDEUu6roeIrJqTpEuf6DVCDxPNpEwlp8Ew+81k= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id t32HhL3m029159 for ; Thu, 2 Apr 2015 13:43:21 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Thu, 2 Apr 2015 13:43:21 -0400 (EDT) From: Paul Wouters To: dane@ietf.org In-Reply-To: <20150402173342.GG17637@mournblade.imrryr.org> Message-ID: References: <2E2E6A49-3ED5-49A7-A263-54D8F1B8EE95@roessner-network-solutions.com> <4B7FCFB2-F91C-4C43-B121-F53ADA63E328@verisign.com> <20150402171241.GD17637@mournblade.imrryr.org> <8955C3CA-6C5A-4FF9-AF65-BF56C0BC4FB8@roessner-network-solutions.com> <20150402173342.GG17637@mournblade.imrryr.org> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-7; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Subject: Re: [dane] Updated draft-ietf-dane-openpgpkey 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, 02 Apr 2015 17:43:26 -0000 On Thu, 2 Apr 2015, Viktor Dukhovni wrote: > Your initial thinking was right, the private key is used for signing, > but the public key is published so that verifiers can validate the > signature. The proposal is to publish verification (public) keys > (that validate received mail) separately from encryption (public) > keys that enable encryption of outgoing mail. Right, and: for email signing): - must have the Digital Signature or Non-Repudiation OIDs as a Key Usage. (for email encryption): - must have the Key Agreement or Data Encipherment OIDs as a Key Usage. So why add the dns complexity for _sign and _encrypt. While it is nice that you can skip fetching an smime cert if you need to sign but the you cannot find it at the _sign prefix, once you have the cert and then you need to encrypt, you either need to repeat a DNS lookup for a cert you already have or you need to store the "sign" or "encrypt" flags, meaning you will want to do two lookups always even if you only want to sign or encrypt now. And then you still need to check for conflicts within the smime certificate's OID. When you drink the X.509 kool-aid, you have to play by its rules, which means full PKIX validation of the EKU. Paul From nobody Thu Apr 2 10:50:29 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65A471B2DB4 for ; Thu, 2 Apr 2015 10:50:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.351 X-Spam-Level: X-Spam-Status: No, score=-1.351 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, 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 dnwGuzR9iBjE for ; Thu, 2 Apr 2015 10:50:22 -0700 (PDT) Received: from mx.roessner-net.de (mail.roessner-net.de [193.239.107.42]) (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 66ABE1B2DB3 for ; Thu, 2 Apr 2015 10:50:22 -0700 (PDT) Received: from mail.roessner-net.de (mail.roessner-net.de [193.239.107.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.roessner-net.de", Issuer "thawte DV SSL CA - G2" (verified OK)) by mx.roessner-net.de (Postfix) with ESMTPS id 3lHsP83GnnzGpHZ for ; Thu, 2 Apr 2015 19:50:20 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=roessner-network-solutions.com; s=swioBi3opho; t=1427997020; i=@roessner-network-solutions.com; bh=uCNnpLr0czOqdAInNqeEoBRyV6PUSDJI8O6ppeGGlJ4=; h=Subject:From:In-Reply-To:Date:References:To; b=li5am0Ay+zyPNsmNIS8bTRs/U4N/tdrlLeEJaFSUj3nb64bM9EX2E4knVuuNMLUo5 tMn2ZA45vxsHePrTbDLO6VVcBpxOX+EZNQVfG6Os5sKQS0jUV6TDAjMvEE++zuv3Vp FHE20kNCPm42IAJUzaszkBZl1+jaMiUZhvguMlpnld7NFxo3wz1A1fDFOlKQ6TRuzx a5NeqVszClb0h4jk/60IBdg3z4sMUQaKDTqJkaL+zsWoFqq5nShuB2Y/Dvyd7oTnVF f3YdtdP0hGrlzoRQ1jVqbbrlCXIdJh0jk4itqS4MMJ4LkMkIzAE8rO+9d7BH7cwiXc ozhWjvcssHsng== Received: from [172.16.2.200] (static-201-106.deltasurf.de [193.239.106.201]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Christian Roessner", Issuer "RootCA (c) 2014" (verified OK)) (Authenticated sender: c@roessner.co) by mail.roessner-net.de (Postfix) with ESMTPSA id 3lHsP81cKvzMkrT for ; Thu, 2 Apr 2015 19:50:20 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2096\)) From: =?utf-8?Q?Christian_R=C3=B6=C3=9Fner?= In-Reply-To: <20150402173342.GG17637@mournblade.imrryr.org> Date: Thu, 2 Apr 2015 19:50:20 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7636CBD7-FEA8-4A2B-BED6-F4EBC467640D@roessner-network-solutions.com> References: <2E2E6A49-3ED5-49A7-A263-54D8F1B8EE95@roessner-network-solutions.com> <4B7FCFB2-F91C-4C43-B121-F53ADA63E328@verisign.com> <20150402171241.GD17637@mournblade.imrryr.org> <8955C3CA-6C5A-4FF9-AF65-BF56C0BC4FB8@roessner-network-solutions.com> <20150402173342.GG17637@mournblade.imrryr.org> To: dane@ietf.org X-Mailer: Apple Mail (2.2096) Outgoingd: 0.3.0_m1 Archived-At: Subject: Re: [dane] Updated draft-ietf-dane-openpgpkey 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, 02 Apr 2015 17:50:23 -0000 > Am 02.04.2015 um 19:33 schrieb Viktor Dukhovni = : >=20 > On Thu, Apr 02, 2015 at 07:29:21PM +0200, Christian R??ner wrote: >=20 >> I never knew that you can use a public key for signing. Or at least I = never tried. >=20 > Your initial thinking was right, the private key is used for signing, > but the public key is published so that verifiers can validate the > signature. The proposal is to publish verification (public) keys > (that validate received mail) separately from encryption (public) > keys that enable encryption of outgoing mail. Thanks. But in that case I don=E2=80=99t really get the use case of = ._encr and ._sign, as I can not believe that people would distribute = different keys for signing and encrypting mails (in the sense you = described) If I have a pair of public/private keys, I would expect that a sender = does not use a second private key just for signing and that you would = require a second public the public key for verification. Das that = scenario really exist? Or is it more of a theoretical nature with these two subdomains? Just my = personal opinion, if I may say it: I would vote against two different = subdomains. Christian= From nobody Thu Apr 2 10:55:43 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C01BB1B2DAE for ; Thu, 2 Apr 2015 10:55:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_31=0.6, 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 a7I7ibUoXdAM for ; Thu, 2 Apr 2015 10:55:40 -0700 (PDT) Received: from mail-qg0-f100.google.com (mail-qg0-f100.google.com [209.85.192.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F4021B2DA4 for ; Thu, 2 Apr 2015 10:55:40 -0700 (PDT) Received: by qgaj5 with SMTP id j5so1262965qga.1 for ; Thu, 02 Apr 2015 10:55:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:thread-topic:thread-index:date :message-id:references:in-reply-to:accept-language:content-language :content-type:content-id:content-transfer-encoding:mime-version; bh=cdd/ap0yppKuY0FeZB1bO+AHe+dHZUSb6gaEi/Bl5ho=; b=bDFwAd4yOF8s28i4lc/PfeACQUwKHFg2MmRQmKaj/WZuDZJ1Yd5OltkRhKyUE9eqMz h+hMlr+rB17xO2ZY+ehaqFVHkHUPRRXN+VAniPHVWC0K1h/H8Z0TL9uG6BEV/kPWvr2z PjOvEViyQzdkQ6b3wQYrWOfvdHNlCIey9rp4ad4O3H4KApgBD7hTXf9uW9kIgrCbh9dJ E4MJW5jBYDVN527zf4APzEQyxUPr1QpYSAAi9hnnf+bSqPBkwVVxl6ODsvaibx+0tB1f sPq38gg8sgFDS3pgUwuSllBmMtK0K501hj+A9Aj5X32Fky0wTDKZYqY/9Pk2ygMcxNt/ 8ZiA== X-Gm-Message-State: ALoCoQlhr6l1ntN0IHMhDNH2s5dl+g82ZvcSFvHvEOZh7rVh6Teel7KzIoX7oiHa/GUrWldvT50Yk11tn9Q/fyaIiHGRIKZ6RA== X-Received: by 10.55.16.139 with SMTP id 11mr3007463qkq.79.1427997339592; Thu, 02 Apr 2015 10:55:39 -0700 (PDT) Received: from brn1lxmailout02.verisign.com (brn1lxmailout02.verisign.com. [72.13.63.42]) by mx.google.com with ESMTPS id cd6sm1351213qcb.2.2015.04.02.10.55.39 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 02 Apr 2015 10:55:39 -0700 (PDT) X-Relaying-Domain: verisign.com Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01 [10.173.152.205]) by brn1lxmailout02.verisign.com (8.13.8/8.13.8) with ESMTP id t32HtcPe030796 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 2 Apr 2015 13:55:38 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Thu, 2 Apr 2015 13:55:39 -0400 From: "Osterweil, Eric" To: "dane@ietf.org" Thread-Topic: [dane] Updated draft-ietf-dane-openpgpkey Thread-Index: AQHQbPU1G3T2yEx5KUGnKcWYMYe3j505/kAAgAAMHYCAAAyagIAAHQCAgAAFoICAAAwEgA== Date: Thu, 2 Apr 2015 17:55:37 +0000 Message-ID: <90D54E3A-C7D2-4D0E-9C67-92DF6F8CFA18@verisign.com> References: <2E2E6A49-3ED5-49A7-A263-54D8F1B8EE95@roessner-network-solutions.com> <4B7FCFB2-F91C-4C43-B121-F53ADA63E328@verisign.com> <20150402171241.GD17637@mournblade.imrryr.org> In-Reply-To: <20150402171241.GD17637@mournblade.imrryr.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [dane] Updated draft-ietf-dane-openpgpkey 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, 02 Apr 2015 17:55:41 -0000 On Apr 2, 2015, at 1:12 PM, Viktor Dukhovni wrote: > On Thu, Apr 02, 2015 at 06:52:33PM +0200, Christian R??ner wrote: >=20 >>> libsmaug uses these labels (as well as our soon-to-be available provisi= oning portal). >>=20 >> Just a question for ._encr and ._sign: >>=20 >> Do you really plan to store private keys in public DNS? Is it, what ._si= gn will be used for? Isn?t this really a security issue? > To be honest, I don't expect encrypted messages in the mailbox to > ever be very popular, encrypted storage is just too inconvenient > for most users. End-to-end is good for live conversations, but > not so well suited to archived communication. We can try to make > it more usable for those willing to put up with the inconvenience, > but I would not really expect large-scale adoption. Actually, we=92re seeing a lot of renewed interest in this. Issues ranging= from the Sony incident, to APT threats in networks have seemed to be very = motivating to a number of people in the security space. I think we all oug= ht to be very worried about our data when it's at rest (i.e. controlling wh= ere and when our data/email/etc is encrypted, by whom, etc.). > That's a personal best guess of course, I am willing to be proved > wrong. We=92ve been trying to validate with industry and are seeing the opposite, = but I=92m certain ymmv. Eric= From nobody Thu Apr 2 11:00:59 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4023E1B2D79 for ; Thu, 2 Apr 2015 11:00:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_31=0.6, 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 M2EyFYWgzmBv for ; Thu, 2 Apr 2015 11:00:56 -0700 (PDT) Received: from mail-qg0-f100.google.com (mail-qg0-f100.google.com [209.85.192.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 990931A005B for ; Thu, 2 Apr 2015 11:00:56 -0700 (PDT) Received: by qgdq107 with SMTP id q107so1258031qgd.2 for ; Thu, 02 Apr 2015 11:00:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:content-type:content-id:content-transfer-encoding :mime-version; bh=+2jy9JK4kF2jHvtKtvJEmiCqJ6sdRzyrk4CeKOiesp0=; b=RjKCCu7gRYtYE3v9h84NcX6LFtr5G5a8kCL3q/x+6k/xRsoLZ2dCMIfxBSeWGbOTgb rJ8h+bC/LPv0pfPM5xx+uyTuDqxKGpI+6S+s5S3vz2PiVQ5Qt2cHUzOR8XdCiah6Lpkj QjIqkU/8sIvcLG2RqPRV5EKlvSLes8eHvXdr0jjp+jVdy4Ch+iKOyTZZJfHbl/46J81b yqFrb6zdGDV1DMSsM7YTwV3Na3ZKTm+WprfemKqabnlUN/2yKZiZNXsxb5RV0BS4fQqX U0pkG+pa9Ri2XiWfW9j1VWauUXQGII+VhkExvF8BaBabDxHbMtQ1KGlSKU3Qz+zGkujm M+5g== X-Gm-Message-State: ALoCoQnf/w0cf87Mpau1p7qSGY7Mjtm0GF2rcWYYrSkqJo7bHLviHYbJBCtEQEtJ7jLzHNcVSl5QoAVUjfVidz02xRS62crJ3g== X-Received: by 10.229.71.72 with SMTP id g8mr65001413qcj.25.1427997655917; Thu, 02 Apr 2015 11:00:55 -0700 (PDT) Received: from brn1lxmailout02.verisign.com (brn1lxmailout02.verisign.com. [72.13.63.42]) by mx.google.com with ESMTPS id cd6sm1354623qcb.2.2015.04.02.11.00.55 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 02 Apr 2015 11:00:55 -0700 (PDT) X-Relaying-Domain: verisign.com Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02 [10.173.152.206]) by brn1lxmailout02.verisign.com (8.13.8/8.13.8) with ESMTP id t32I0ttI031393 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 2 Apr 2015 14:00:55 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Thu, 2 Apr 2015 14:00:55 -0400 From: "Osterweil, Eric" To: Paul Wouters Thread-Topic: [dane] Updated draft-ietf-dane-openpgpkey Thread-Index: AQHQbPU1G3T2yEx5KUGnKcWYMYe3j505/kAAgAAMHYCAAAyagIAAHQCAgAAFoICAAANMgIAACjIA Date: Thu, 2 Apr 2015 18:00:54 +0000 Message-ID: <24051EA3-88B5-4D29-9900-7B49A672000D@verisign.com> References: <2E2E6A49-3ED5-49A7-A263-54D8F1B8EE95@roessner-network-solutions.com> <4B7FCFB2-F91C-4C43-B121-F53ADA63E328@verisign.com> <20150402171241.GD17637@mournblade.imrryr.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="Windows-1252" Content-ID: <2E210185D6334E48B434176886B754F5@verisign.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "dane@ietf.org" Subject: Re: [dane] Updated draft-ietf-dane-openpgpkey 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, 02 Apr 2015 18:00:58 -0000 On Apr 2, 2015, at 1:24 PM, Paul Wouters wrote: > On Thu, 2 Apr 2015, Viktor Dukhovni wrote: >=20 >>> Just a question for ._encr and ._sign: >>>=20 >>> Do you really plan to store private keys in public DNS? Is it, what ._s= ign will be used for? Isn?t this really a security issue? >>=20 >> No they are public keys in both cases. Some public keys are for >> signing only, others are for encryption (which means that they can >> receive encrypted content). >>=20 >> The idea that these need separate locations in DNS has not seen >> much support on this list. In consumer deployments, I don't see >> such separation as likely to take place. >>=20 >> In enterprise deployments, I expect implementations will publish >> gateway keys that decrypt the email, apply various content policies, >> and then sometimes deliver re-encrypted content to the end-user, >> but using keys that the outside world does not see. >=20 > Also, the smime key attributes will tell if if they are usable for > signing and/or encrypting. So my preference is to not have another > place to indicate this so we avoid needing to deal with mismatches. I think this was better described by Doug M before, and you and I spoke abo= ut this at the interim meeting, but to rehash: my certs may be used for any= number of actions (like the USG PIV cards), but I may not want them to be = used arbitrarily for different services (like all manner of email). I may = also have a cert that I want to no longer use for email, but I do _not_ wan= t to revoke it. I may want to use a cert (whose attributes are very permis= sive) for just email signing. I can codify my wishes by not listing it as = an encryption key in DNS. >=20 >> To be honest, I don't expect encrypted messages in the mailbox to >> ever be very popular, encrypted storage is just too inconvenient >> for most users. >=20 > Having run openpgpkey-milter and gotten all of my email encrypted > due to my own forwarder, I strongly agree with that it is completely > inconvenient right now. But it is a problem that we need to solve to > make it convenient. I'm hoping that encrypting more email will mean > more people will work on better MUA integration of it. We really > need to fix this problem. I=92m aware of a lot of enterprise interest in encrypted email at rest. >> End-to-end is good for live conversations, but >> not so well suited to archived communication. >=20 > I personally would like my MUA to store email decrypted, replace the > encrypted email headers inside the body back into real email headers > and rely on full disk encryption. That way, I get the best of both > worlds. I actually favor the encrypted email for the afore mentioned reasons. At t= he very least, it seems fair to consider giving the user the option. Eric= From nobody Thu Apr 2 11:15:45 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 918D81A0397 for ; Thu, 2 Apr 2015 11:15:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.41 X-Spam-Level: X-Spam-Status: No, score=-1.41 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_31=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1mH3RRjPH2Vw for ; Thu, 2 Apr 2015 11:15:43 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D841E1A0389 for ; Thu, 2 Apr 2015 11:15:42 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3lHsyM66sdzlH for ; Thu, 2 Apr 2015 20:15:39 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=Scoy1qR4 X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id 4JzD_Ufr2-hw for ; Thu, 2 Apr 2015 20:15:36 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for ; Thu, 2 Apr 2015 20:15:36 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 6570C803E0 for ; Thu, 2 Apr 2015 14:15:35 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1427998535; bh=4T0LWL7KADmk+aaGVFeAKLgOW3PIM2+GmYetcvvzjMM=; h=Date:From:To:Subject:In-Reply-To:References; b=Scoy1qR4D4I1GPNG8vkiJ0lOIK+/lKFDW76TLrpAADND0QolH6UvLcDw+8m2/rq8/ jEdvySnKtN74NCdKCJITaThPjs1BXdeNcWGxi6miBOoJg+ZI/gbfoWETKcZx0sE7gn spuchPhg7S7/aghB/HetfVBSU6Se+Nf2/HX/8R9I= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id t32IFYoU032692 for ; Thu, 2 Apr 2015 14:15:35 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Thu, 2 Apr 2015 14:15:34 -0400 (EDT) From: Paul Wouters To: dane@ietf.org In-Reply-To: Message-ID: References: <2E2E6A49-3ED5-49A7-A263-54D8F1B8EE95@roessner-network-solutions.com> <4B7FCFB2-F91C-4C43-B121-F53ADA63E328@verisign.com> <20150402171241.GD17637@mournblade.imrryr.org> <8955C3CA-6C5A-4FF9-AF65-BF56C0BC4FB8@roessner-network-solutions.com> <20150402173342.GG17637@mournblade.imrryr.org> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed Archived-At: Subject: Re: [dane] Updated draft-ietf-dane-openpgpkey 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, 02 Apr 2015 18:15:43 -0000 On Thu, 2 Apr 2015, Paul Wouters wrote: > Right, and: > > for email signing): > - must have the Digital Signature or Non-Repudiation OID?s as a Key Usage. > > (for email encryption): > - must have the Key Agreement or Data Encipherment OID?s as a Key Usage. > > So why add the dns complexity for _sign and _encrypt. Additionally, using the DNS prefix leaks the intent of the user. The DNS servers should not know whether or not a user is going to sign or encrypt. Paul From nobody Thu Apr 2 11:27:52 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B3951A0271 for ; Thu, 2 Apr 2015 11:27:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_31=0.6, 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 xqLBxsWIW9TG for ; Thu, 2 Apr 2015 11:27:48 -0700 (PDT) Received: from mail-qg0-f97.google.com (mail-qg0-f97.google.com [209.85.192.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E2121A0195 for ; Thu, 2 Apr 2015 11:27:40 -0700 (PDT) Received: by qgdz60 with SMTP id z60so3287819qgd.0 for ; Thu, 02 Apr 2015 11:27:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:content-type:content-id:content-transfer-encoding :mime-version; bh=7bgrDVj1QqIXJCJjd+MlOTtR8J2l+Z9xO62bimAIbrI=; b=ZgyJkci6+yvC+QD8VOX3Ov/DOW6XtRVutQtnbTxp/d7HUIObXQxI5YKv1g47vo49xk 5eyv0zPadtyMQaGAKplt2nGyZCYmbakMnGQF5H1exAYoTS0HliSBODMkwrL3vW/FqV5m lKf4cppYYxUwu7bl3H3jJVfruCw+R2yQLUGPpzeH5Ir9pDIPHV30WhnmPNJLza4Mqwfe yERnQHU3CJne5xqRtRBpG1MBml/R4XHoZE/ibiuerIZmbVAO25PbID5iIRjRLBbZsWpR dnLerXVeoUv1Nv0jA93SohkBiLNJr8ao073Y4WqHx+7Iap3UBIRlG+qe92jRJIy2Ko5y ieww== X-Gm-Message-State: ALoCoQkgH1wtizQHAcs+gJoOZz29/cJ9q8VAaCFVSjKRb0xwDCNAHAkUCKyuEvJT/+/Kx7SHS3BmuLEFNnc8DxX38BgSC9hCDw== X-Received: by 10.55.52.13 with SMTP id b13mr34863745qka.7.1427999259351; Thu, 02 Apr 2015 11:27:39 -0700 (PDT) Received: from brn1lxmailout01.verisign.com (brn1lxmailout01.verisign.com. [72.13.63.41]) by mx.google.com with ESMTPS id 6sm1378140qcf.1.2015.04.02.11.27.38 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 02 Apr 2015 11:27:39 -0700 (PDT) X-Relaying-Domain: verisign.com Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01 [10.173.152.255]) by brn1lxmailout01.verisign.com (8.13.8/8.13.8) with ESMTP id t32IRcK0014655 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 2 Apr 2015 14:27:38 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Thu, 2 Apr 2015 14:27:38 -0400 From: "Osterweil, Eric" To: Paul Wouters Thread-Topic: [dane] Updated draft-ietf-dane-openpgpkey Thread-Index: AQHQbPU1G3T2yEx5KUGnKcWYMYe3j505/kAAgAAMHYCAAAyagIAAHQCAgAAFoICAAASogIAAATcAgAACs4CAAAkAAIAAA2OA Date: Thu, 2 Apr 2015 18:27:37 +0000 Message-ID: References: <2E2E6A49-3ED5-49A7-A263-54D8F1B8EE95@roessner-network-solutions.com> <4B7FCFB2-F91C-4C43-B121-F53ADA63E328@verisign.com> <20150402171241.GD17637@mournblade.imrryr.org> <8955C3CA-6C5A-4FF9-AF65-BF56C0BC4FB8@roessner-network-solutions.com> <20150402173342.GG17637@mournblade.imrryr.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "dane@ietf.org" Subject: Re: [dane] Updated draft-ietf-dane-openpgpkey 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, 02 Apr 2015 18:27:50 -0000 On Apr 2, 2015, at 2:15 PM, Paul Wouters wrote: > On Thu, 2 Apr 2015, Paul Wouters wrote: >=20 >> Right, and: >>=20 >> for email signing): >> - must have the Digital Signature or Non-Repudiation OID?s as a Key Usag= e. >>=20 >> (for email encryption): >> - must have the Key Agreement or Data Encipherment OID?s as a Key Usage= . >>=20 >> So why add the dns complexity for _sign and _encrypt. >=20 > Additionally, using the DNS prefix leaks the intent of the user. The DNS > servers should not know whether or not a user is going to sign or > encrypt. I think that=92s a red hearing. Either the user is worried about this, and= we have the whole learning intent through DNS lookups (in which case I ref= er to an email I sent earlier today, which proposes to use URIs in SMIMEA c= erts at the apex of a zone), or not. In any event, I really can=92t unders= tand where there is clear gain to an adversary in knowing encr/sign over ju= st the transmission of email, when the real protection in the crypto being = used _after_ keys are learned? By contrast, we get a lot of management an= d configurability gains by giving users these hooks. Eric= From nobody Thu Apr 2 11:40:56 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BB811A19F7 for ; Thu, 2 Apr 2015 11:40:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NwKlXkalPIDU for ; Thu, 2 Apr 2015 11:40:53 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEF271A079D for ; Thu, 2 Apr 2015 11:40:52 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3lHtWP72DFz7VT; Thu, 2 Apr 2015 20:40:49 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=YvW26qlP X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id Pc0J-TKA4U_C; Thu, 2 Apr 2015 20:40:49 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Thu, 2 Apr 2015 20:40:48 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 04AC8803E0; Thu, 2 Apr 2015 14:40:48 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1428000048; bh=mHNQl3akarAVGvKFf27ohQHZK7SWZAAGam7hZm+b5RY=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=YvW26qlPscQmfwOQJSeqDRYXKaRcLnLi+6F6QwpWQKVCuG1Y/WXVZTcCByNRNdE+K Js1b8vvlzrJ7fotRxPLhPOc84zqJsZzxQmFu3uNDyhriDVO7iHkr1Z4F7nOii31aRG kjnTGhk5BJp5T239zhieQLcLIb1Qk2p15jWOYTmY= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id t32IeliX021402; Thu, 2 Apr 2015 14:40:47 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Thu, 2 Apr 2015 14:40:47 -0400 (EDT) From: Paul Wouters To: "Osterweil, Eric" In-Reply-To: <24051EA3-88B5-4D29-9900-7B49A672000D@verisign.com> Message-ID: References: <2E2E6A49-3ED5-49A7-A263-54D8F1B8EE95@roessner-network-solutions.com> <4B7FCFB2-F91C-4C43-B121-F53ADA63E328@verisign.com> <20150402171241.GD17637@mournblade.imrryr.org> <24051EA3-88B5-4D29-9900-7B49A672000D@verisign.com> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=Windows-1252; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Cc: "dane@ietf.org" Subject: Re: [dane] Updated draft-ietf-dane-openpgpkey 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, 02 Apr 2015 18:40:55 -0000 On Thu, 2 Apr 2015, Osterweil, Eric wrote: >> Also, the smime key attributes will tell if if they are usable for >> signing and/or encrypting. So my preference is to not have another >> place to indicate this so we avoid needing to deal with mismatches. > > I think this was better described by Doug M before, and you and I spoke about this at the interim meeting, but to rehash: my certs may be used for any number of actions (like the USG PIV cards), but I may not want them to be used arbitrarily for different services (like all manner of email). I may also have a cert that I want to no longer use for email, but I do _not_ want to revoke it. I may want to use a cert (whose attributes are very permissive) for just email signing. I can codify my wishes by not listing it as an encryption key in DNS. Well, this is SMIME and it uses PKIX, so the proper way to express any kind of attributes is via EKU OIDs. >> >>> To be honest, I don't expect encrypted messages in the mailbox to >>> ever be very popular, encrypted storage is just too inconvenient >>> for most users. >> >> Having run openpgpkey-milter and gotten all of my email encrypted >> due to my own forwarder, I strongly agree with that it is completely >> inconvenient right now. But it is a problem that we need to solve to >> make it convenient. I'm hoping that encrypting more email will mean >> more people will work on better MUA integration of it. We really >> need to fix this problem. > > Im aware of a lot of enterprise interest in encrypted email at rest. > >>> End-to-end is good for live conversations, but >>> not so well suited to archived communication. >> >> I personally would like my MUA to store email decrypted, replace the >> encrypted email headers inside the body back into real email headers >> and rely on full disk encryption. That way, I get the best of both >> worlds. > > I actually favor the encrypted email for the afore mentioned reasons. At the very least, it seems fair to consider giving the user the option. The MUA can implement either. But I can tell you that it is next to impossible to search through old encrypted emails. I often search through old email, so I have a clear preference for storing it in decrypted form accessable to my MUA, all of it protected by whole disk encryption. But that's all a MUA based local/user policy decision and we don't have to indicate any of this in DNS. Paul From nobody Thu Apr 2 13:54:43 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCDF01A1AFB for ; Thu, 2 Apr 2015 13:54:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.211 X-Spam-Level: X-Spam-Status: No, score=-14.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9K9OzDgROeUA for ; Thu, 2 Apr 2015 13:54:39 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F9661A1ADD for ; Thu, 2 Apr 2015 13:54:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5671; q=dns/txt; s=iport; t=1428008079; x=1429217679; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=5HQlSnayzNDxeRgqUkBfO1jlmY7nwr07QXkdSeB4As0=; b=kcS+7EHodmMBXE2iwbZBHDR+FTX04KWGdOcLnKTtVYcvdljrur0DViX1 x+ogrtjTvgXrcYUEerzCu6F8aE+sXiFLK9ZaPz532g/gQlzZtC6FUHVqt TlWDFriDCP31CDb3PRwuEAsm92Y70D36ZqB/+nmODV5dXgBb4Y74m1GmZ w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AxBQCGqx1V/5FdJa1cgwhSXAWDEMJUhX0CgUxMAQEBAQEBfoQfAQEEIw8BOwoRCxgCAgUWCwICCQMCAQIBRQYNBgIBARCIGw21V5gXAQEBAQEBBAEBAQEBAQEbgSGJCX+EDSEYOoJogUUFiyKJPYYLgR2FcYlyg0giggIBHIFvUIEEJBx/AQEB X-IronPort-AV: E=Sophos;i="5.11,512,1422921600"; d="scan'208";a="405692655" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-9.cisco.com with ESMTP; 02 Apr 2015 20:54:38 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t32Ksce2003154 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 2 Apr 2015 20:54:38 GMT Received: from [10.129.24.55] (10.129.24.55) by xhc-aln-x08.cisco.com (173.36.12.82) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 2 Apr 2015 15:54:38 -0500 Message-ID: <551DAC8D.1050704@cisco.com> Date: Thu, 2 Apr 2015 14:54:37 -0600 From: =?UTF-8?B?4oyYIE1hdHQgTWlsbGVy?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: References: <551C8A46.9030904@cs.tcd.ie> <20150402012132.GW17637@mournblade.imrryr.org> <551D2DA1.10809@cs.tcd.ie> <20150402164934.GC17637@mournblade.imrryr.org> In-Reply-To: <20150402164934.GC17637@mournblade.imrryr.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Originating-IP: [10.129.24.55] Archived-At: Subject: Re: [dane] AD review of draft-ietf-dane-srv-12 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, 02 Apr 2015 20:54:42 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 At least for XMPP, using the target server host name was discussed in several forums over the course of many (> 5) years; I'm having trouble finding specific threads because the discussion started so long ago. The best I can do without a lot of archeology is point you at Section 1 of [POSH] and Section 6 of [XMPP-DNA] for the rationale. Both sections resulted from much discussion on mailing lists, in physical meetings, and XMPP community gatherings. I believe Olle Johansson can point you to nearly identical discussions around SIP. TLDR -- multi-tenant hosting providers (outside of HTTPS providers) can't get a "good" cert for the service name, but can for their target server host name. Instead of forcing users to understand an "accept anyway" box that their brains are being wired to ignore anyway, we try to prove the delegation and let the hosting provider use a cert they can actually get. - -- - - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. [POSH] "PKIX Obtained over Secure HTTP" < https://tools.ietf.org/html/draft-ietf-xmpp-posh > [XMPP-DNA] "Domain Name Associations (DNA) in the Extensible Messaging and Presence Protocol (XMPP)" < https://tools.ietf.org/html/draft-ietf-xmpp-dna > On 4/2/15 10:49 AM, Viktor Dukhovni wrote: > On Thu, Apr 02, 2015 at 12:53:05PM +0100, Stephen Farrell wrote: > >> Meta-question: was this something the wg discussed or did they >> just follow your lead? > > When I joined the WG in ~Mar 15, text along these lines was > already in the Tony Finch drafts srv and smtp drafts. So I was not > a party to any WG discussion of that decision, but it is obviously > the *only* way to deal with DNSSEC redirection (be it SRV or MX). > > What I was a party to was subsequent discussion of CNAME > indirection that is captured in the "ops" draft (WGLC soon, > right!). I believe we got consensus for that. And again, if the > TLSA base domain is the expanded CNAME, then that's the primary > reference identifier (used in SNI, ...) but for mixed/legacy > environments the original name is to be also be supported. > >> The reason I'm asking is the obvious one - this could be a >> surprise - if the user agent for some protocol shows >> foo.example.com (or has that in a configuration) but via >> DNSSEC/DANE/SRV > > You can add CNAME to the list. :-) > >> we end up with a TLS session with bar.example.com and if we say >> that that is ok, then we're causing potential >> developer/deployer/user surprise, and also setting an upper bound >> for the level of TLS security that is only as good as >> domain-validated. > > DANE is stronger than DV, but makes no pretense to be EV. > >> That is a defensible position (esp for the DANE wg!) but might >> surprise some application developers etc. > > I don't think there'll be many surprises, the application will > often be the one passing the reference identifiers to the TLS > library. > > At least in OpenSSL (where I'm involved in designing the DANE > support) the TLS library is not going to be doing the TLSA > lookups. Rather the application will call use some DNSSEC library > to obtain the service specification records (see DANE vocabulary) > and find the associated TLSA RRs. It will then hand these (TLSA > base domain, RRs, and additional names to accept) off the the TLS > library as verification input parameters. > >> One other question: you mentioned SNI below. Is that very >> relevant here, given we're not talking about the web (that won't >> use SRV) and afaik most use of SNI is for the web. > > SNI is a TLS mechanism. It is not a web mechanism. Any time a > server handles multiple domains, SNI is potentially useful. We've > worked hard (in the ops draft) to make it less necessary to use > SNI, precisely by specifying that the primary reference identifier > must be the expanded name (except when CNAME expansion is not > secure). > >> So, for which non-web applications is SNI sufficiently important >> to justify this (potential) level of developer surprise? > > No surprise, on the contrary, as an SMTP developer (e.g.) I > *expect* that the reference identifer is the MX hostname, we've > been waiting for DNSSEC to make this possible for many years now. > Lots of domains have shared backup MX hosts, which can't possibly > have certificates for all the domains, but can field a certificate > for their own name. > > Better yet, with DANE-EE(3) the name and expiration of the > certificate are entirely irrelevant, making multi-tenancy even > easier. > > [ With DANE-EE(3) Postfix will happily accept certificates in which > the Subject DN and Issuer DN are empty RDN sequences, there are no > subject alternative names (it's just a fancy key container), and > the expiration time precedes the inception time, but I've been > asked to not speak of such PKIX-violating apostasy, and I've been > good about that. :-) I'll just make a retroactive exception for > April 1 below. ] > -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJVHayNAAoJEDWi+S0W7cO1ASwH/jIvcfffPWVgA55/rfv4fI5H 7AC7M3gwGiRD2nejgz6pB+SgD9NAC4oCGmnmf3Bm9/9gqHEY0Jy50rnsGokzUc3q srGV7KcE80yuQLTJ6Azv1bilosyfK1w8gWDNpoxhfv2JtaVtslhOcfv8aLFosTfj T5Ag5JvDtoN47cPFQ6v8LxHYnGZRG4P9cDgnrbHqEDkS/O4F+kV8z+n3Xq3c2JQc cj6ZwSgw/vad92JxscZ6tHpGJnzW8fDyZH9rpclx9gGYnUIb3BzKsYEfnPZPORR7 aHedgTZNW3wHv6tQyTcze9e85PTArCLY+rZWMTIF17dew+kHZEsAG9MYgjLSlZI= =lv5P -----END PGP SIGNATURE----- From nobody Thu Apr 2 14:06:57 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3BDB1A1BEF for ; Thu, 2 Apr 2015 14:06:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, 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 nZpBwuT6fPkE for ; Thu, 2 Apr 2015 14:06:54 -0700 (PDT) Received: from mail-pd0-f170.google.com (mail-pd0-f170.google.com [209.85.192.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 378961A1BEC for ; Thu, 2 Apr 2015 14:06:54 -0700 (PDT) Received: by pdea3 with SMTP id a3so49465127pde.3 for ; Thu, 02 Apr 2015 14:06:54 -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 :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=CKxCl4wqvoVXPSBPg5GsyHty0ePKKvEENRgbegZRztA=; b=bJBHZ1ZG9ve6rlvELOYRw7waoqjLuSjLi0LPedQ1dkeElzh/zxwJ0PHhrknrF7GHsv L3zF3OBAEz7MBOyarv54F/b7D0KxiLXRA4wdrxpkkFoLuVyMl7F7Thv3/TmGde0n868l wAiycBH5i/5R5fjcdtJy3kjfxLQARlcUAjg9IO6bauFTppfogrWUBBLpPr1XIyNZXeCU XE2DzJD0NZBBIguxDxGpU7ktNgTFE+keXJJagEp0Z1Zk2QhQX/z0OUHkIYVgAwxJyhfT 9ulNXGCqC0Klya0Nv5JzsCTjh5Mo/B6EgRNcHvTIXoJKOgQ1DDj7Yi8kXqYf8DeQHCoG 1OCQ== X-Gm-Message-State: ALoCoQngvz+B6CUdJgJ58y99YadMOoGoTOdDEc6BY+sACBQoYK7U0CWbJIs7DbOci+b5nE3DLYTL X-Received: by 10.70.137.72 with SMTP id qg8mr90775343pdb.8.1428008813877; Thu, 02 Apr 2015 14:06:53 -0700 (PDT) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id gx1sm6112146pbd.3.2015.04.02.14.06.51 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 Apr 2015 14:06:52 -0700 (PDT) Message-ID: <551DAF6B.2020002@andyet.net> Date: Thu, 02 Apr 2015 15:06:51 -0600 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: =?UTF-8?B?4oyYIE1hdHQgTWlsbGVy?= , dane@ietf.org References: <551C8A46.9030904@cs.tcd.ie> <20150402012132.GW17637@mournblade.imrryr.org> <551D2DA1.10809@cs.tcd.ie> <20150402164934.GC17637@mournblade.imrryr.org> <551DAC8D.1050704@cisco.com> In-Reply-To: <551DAC8D.1050704@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dane] AD review of draft-ietf-dane-srv-12 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, 02 Apr 2015 21:06:55 -0000 On 4/2/15 2:54 PM, ⌘ Matt Miller wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > At least for XMPP, using the target server host name was discussed in > several forums over the course of many (> 5) years; I'm having trouble > finding specific threads because the discussion started so long ago. > The best I can do without a lot of archeology is point you at Section > 1 of [POSH] and Section 6 of [XMPP-DNA] for the rationale. Both > sections resulted from much discussion on mailing lists, in physical > meetings, and XMPP community gatherings. I believe Olle Johansson can > point you to nearly identical discussions around SIP. I did a bit of archeology. In the XMPP community these assumptions go back to at least 2009: http://www.ietf.org/archive/id/draft-hildebrand-dna-00.txt See for instance Section 6.2 there. I have not been able to trace it farther than that. Peter -- Peter Saint-Andre https://andyet.com/ From nobody Fri Apr 3 04:20:51 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE71F1A886A for ; Fri, 3 Apr 2015 04:20:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.91 X-Spam-Level: X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0kthMuI2jCbl for ; Fri, 3 Apr 2015 04:20:49 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DF441A8866 for ; Fri, 3 Apr 2015 04:20:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 20D58BEDB; Fri, 3 Apr 2015 12:20:48 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yeQpfcvX5JQd; Fri, 3 Apr 2015 12:20:46 +0100 (IST) Received: from [10.87.48.73] (unknown [86.46.18.59]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id DC5D3BECA; Fri, 3 Apr 2015 12:20:45 +0100 (IST) Message-ID: <551E778D.7080208@cs.tcd.ie> Date: Fri, 03 Apr 2015 12:20:45 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Peter Saint-Andre - &yet , =?UTF-8?B?4oyYIE1hdHQgTWk=?= =?UTF-8?B?bGxlcg==?= , dane@ietf.org References: <551C8A46.9030904@cs.tcd.ie> <20150402012132.GW17637@mournblade.imrryr.org> <551D2DA1.10809@cs.tcd.ie> <20150402164934.GC17637@mournblade.imrryr.org> <551DAC8D.1050704@cisco.com> <551DAF6B.2020002@andyet.net> In-Reply-To: <551DAF6B.2020002@andyet.net> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dane] AD review of draft-ietf-dane-srv-12 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, 03 Apr 2015 11:20:50 -0000 Thanks Peter and Matt. Those (and Viktor's arugments) are good enough for me. I'll kick off the IETF LC later today. Cheers, S. On 02/04/15 22:06, Peter Saint-Andre - &yet wrote: > On 4/2/15 2:54 PM, ⌘ Matt Miller wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA512 >> >> At least for XMPP, using the target server host name was discussed in >> several forums over the course of many (> 5) years; I'm having trouble >> finding specific threads because the discussion started so long ago. >> The best I can do without a lot of archeology is point you at Section >> 1 of [POSH] and Section 6 of [XMPP-DNA] for the rationale. Both >> sections resulted from much discussion on mailing lists, in physical >> meetings, and XMPP community gatherings. I believe Olle Johansson can >> point you to nearly identical discussions around SIP. > > I did a bit of archeology. In the XMPP community these assumptions go > back to at least 2009: > > http://www.ietf.org/archive/id/draft-hildebrand-dna-00.txt > > See for instance Section 6.2 there. > > I have not been able to trace it farther than that. > > Peter > From nobody Fri Apr 3 05:16:55 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A70311A9045; Fri, 3 Apr 2015 05:16:53 -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 N2C1EUrhAVdY; Fri, 3 Apr 2015 05:16:52 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 32FD91A9055; Fri, 3 Apr 2015 05:16:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150403121651.30293.58663.idtracker@ietfa.amsl.com> Date: Fri, 03 Apr 2015 05:16:51 -0700 From: IETF Secretariat Archived-At: Subject: [dane] ID Tracker State Update Notice: X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2015 12:16:53 -0000 IESG state changed to Last Call Requested from AD Evaluation ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-dane-srv/ From nobody Fri Apr 3 19:07:54 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFC7F1A87E1; Fri, 3 Apr 2015 19:07:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CUq-hQvsRjGC; Fri, 3 Apr 2015 19:07:52 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E7871A87B3; Fri, 3 Apr 2015 19:07:52 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 5.13.0 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20150404020752.21750.57199.idtracker@ietfa.amsl.com> Date: Fri, 03 Apr 2015 19:07:52 -0700 Archived-At: Cc: dane@ietf.org Subject: [dane] Last Call: (Using DNS-Based Authentication of Named Entities (DANE) TLSA Records with SRV Records) to Internet Standard X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Apr 2015 02:07:54 -0000 The IESG has received a request from the DNS-based Authentication of Named Entities WG (dane) to consider the following document: - 'Using DNS-Based Authentication of Named Entities (DANE) TLSA Records with SRV Records' as Internet Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2015-04-17. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The DANE specification (RFC 6698) describes how to use TLSA resource records secured by DNSSEC (RFC 4033) to associate a server's connection endpoint with its TLS certificate. However, application protocols that use SRV records (RFC 2782) to indirectly name the target server connection endpoints for a service domain cannot apply the rules from RFC 6698. Therefore this document provides guidelines that enable such protocols to locate and use TLSA records. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-dane-srv/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-dane-srv/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Fri Apr 3 19:08:10 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57A5B1A882E; Fri, 3 Apr 2015 19:08:03 -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 Cf-M3ZAMVVMQ; Fri, 3 Apr 2015 19:08:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CD35C1A886C; Fri, 3 Apr 2015 19:07:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150404020754.21750.9594.idtracker@ietfa.amsl.com> Date: Fri, 03 Apr 2015 19:07:54 -0700 From: IETF Secretariat Archived-At: Subject: [dane] ID Tracker State Update Notice: 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: Sat, 04 Apr 2015 02:08:03 -0000 Last call has been made for draft-ietf-dane-srv and state has been changed to In Last Call ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-dane-srv/ From nobody Sun Apr 5 18:23:02 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AFAC1ACED0 for ; Sun, 5 Apr 2015 18:23:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.353 X-Spam-Level: * X-Spam-Status: No, score=1.353 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ocq5JE3qpyLA for ; Sun, 5 Apr 2015 18:23:00 -0700 (PDT) Received: from proper.com (Opus1.Proper.COM [207.182.41.91]) (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 2D0441A1AB4 for ; Sun, 5 Apr 2015 18:23:00 -0700 (PDT) Received: from [10.20.30.101] (50-1-51-95.dsl.dynamic.fusionbroadband.com [50.1.51.95]) (authenticated bits=0) by proper.com (8.15.1/8.14.9) with ESMTPSA id t361Mw6Q060334 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 5 Apr 2015 18:22:59 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: proper.com: Host 50-1-51-95.dsl.dynamic.fusionbroadband.com [50.1.51.95] claimed to be [10.20.30.101] From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <744A4EA3-F138-4D5D-AE98-AA56A75E18B3@vpnc.org> Date: Sun, 5 Apr 2015 18:22:57 -0700 To: dane@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) Archived-At: Subject: [dane] Proposed design for draft-ietf-dane-openpgpkey (and then for draft-ietf-dane-smime) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2015 01:23:01 -0000 Greetings again. The discussion about exact-match and discovery in = draft-ietf-dane-openpgpkey has been useful for finding out what the use = cases are, and it's time to settle on a design that works for most = people (we're never going to make everyone happy). My motivation for = this message is that Jakob and I will match whatever the WG comes up = with for draft-ietf-dane-openpgpkey in our draft-ietf-dane-smime draft. Proposal: - Lookup of OpenPGP and S/MIME keys and certs in the DNS are = exact-match, following the DNS's database model. This is known to = possibly fail when the party looking up the address has a copy of the = email address different than what might be entered in the zone, such as = with different casing. There is no expectation in this design that all = variants that might be delivered to for a particular address will have = key records. This design keeps the security model understandable: it's = all authenticated just by DNSSEC. - Discovery of delivery variants is better handled by a more flexible = protocol, such as WebFinger. In fact, instead of just looking for = variants and then coming back to the DNS to get the key, that protocol = can instead hand back the keys and certs directly in a single response. = The security model for that protocol would also be simple: it's all = authenticated by the TLS cert of the server. This new protocol should = probably be designed somewhere in the Applications Area, not here, even = though some of what is being delivered are objects similar to what we = are delivering here. If folks agree with this proposal, we can move forwards with = draft-ietf-dane-openpgpkey pretty much as it is. (PaulW: you threw in = downcasing before hashing, which is definitely not what people agreed to = at the meeting.) For draft-ietf-dane-smime, we can then use the same = format and semantics, and add in the LDAP access model proposed by Eric = and Scott, which historically has never applied to OpenPGP. Thoughts? --Paul Hoffman= From nobody Sun Apr 5 18:57:04 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 807F81AD074 for ; Sun, 5 Apr 2015 18:57:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Oelmgm_L5nf for ; Sun, 5 Apr 2015 18:57:01 -0700 (PDT) Received: from orthanc.ca (orthanc.ca [IPv6:2607:f2f8:abf8::2]) (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 4EFF61AD072 for ; Sun, 5 Apr 2015 18:57:01 -0700 (PDT) Received: from [192.168.42.6] (d66-183-211-183.bchsia.telus.net [66.183.211.183]) (authenticated bits=0) by orthanc.ca (8.14.7/8.14.7) with ESMTP id t361utMu095518 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 5 Apr 2015 18:56:58 -0700 (PDT) (envelope-from lyndon@orthanc.ca) Content-Type: multipart/signed; boundary="Apple-Mail=_4295984F-FC8F-4F2A-B4AA-451CD6BDA223"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Lyndon Nerenberg In-Reply-To: <744A4EA3-F138-4D5D-AE98-AA56A75E18B3@vpnc.org> Date: Sun, 5 Apr 2015 18:56:54 -0700 Message-Id: <5FD8ADD1-E741-48B4-B0A4-364FE6909D44@orthanc.ca> References: <744A4EA3-F138-4D5D-AE98-AA56A75E18B3@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: dane@ietf.org Subject: Re: [dane] Proposed design for draft-ietf-dane-openpgpkey (and then for draft-ietf-dane-smime) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2015 01:57:02 -0000 --Apple-Mail=_4295984F-FC8F-4F2A-B4AA-451CD6BDA223 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Apr 5, 2015, at 6:22 PM, Paul Hoffman wrote: > Greetings again. The discussion about exact-match and discovery in = draft-ietf-dane-openpgpkey has been useful for finding out what the use = cases are, and it's time to settle on a design that works for most = people (we're never going to make everyone happy). How can we possibly do that without real experience in the field? I know for a fact the case insensitive hashing rules will break Cyrus, = where foo+Bar@mumble will deliver to mailbox 'inbox.Bar', which is = distinct from foo+bar@mumble, delivering to 'inbox.bar'. Folder names = are case sensitive, so the two addresses are not equivalencies. Ultimately, I don't see a way out of this other than to make a standard = for sub-addressing, with a well defined cut-point delimiter. But that still doesn't change how the LHS has been defined as = case-sensitive since the dawn of time. If we are to change this, = RFC5322 3.4.1 needs a change in its last paragraph. As things stand, we = cannot treat as case-insensitive in any interpretation of = the grammar. --lyndon --Apple-Mail=_4295984F-FC8F-4F2A-B4AA-451CD6BDA223 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----- iQIcBAEBAgAGBQJVIefmAAoJEG8PnXiV/JnUWBwP/00ZaAp81+HooTELdFPfNWv+ yP9QtoWnTF+rOQDXOgAFE/pLZ/WAhoQM4NTMrbONSSpRBcbqw6DxKyyY0OphdIa4 e7QdGOL64BwUcHs83ST8nrc3OggiOm5HUG2hj2htHUjyzP8BGXKGQL/LSRvNrG6w kGTtF7iWiBfAK/7HXtcqSM/dVq0JcuPKGZZWq1wZCMXl2m08HCYZNfysaOpWmRUJ Az1h8f0zjiispnJpj7rh1ZJ509Nl1oZr2kjkFs2+F/3Bkd5O//2/E1sgBlyiKnvc FUkyzyslm1i+T+GTxPKF5U4yPA8BzVQwQ2lnpsr3zaOgU+4lp+pLjPolBvuQIhi8 wEIgBr3nwSZf/wIdEQkUM5UmLNexPloNk29oLD2i+UWB6wZPpNcsfWsoOmnecIvi Q4RgWRt4uCOdW0JjQvyRN1LOjIw/aVit0/ezmDndwMWOrB4IeSiPdJNk2Nb2imwx h+7A8rQMtgrdKrlS+Rv4uBKZGg9KIYrlOO7bv+eJc7w5kO9/PazuRDL6wGdmB4f0 FSRLbp/UYAU57NyA1EmrCaSF99juxMoL6bDvZHbvMC9O1IA3veQdgYItZLVZUDxg 4Mryx7eynxi6wujCxtFjFU+EXlODCLcdwItqFSiEU3uLeZV3SGqURT8cwZcLsuun zTmChcwMkOGEa/Cz8jc4 =/xex -----END PGP SIGNATURE----- --Apple-Mail=_4295984F-FC8F-4F2A-B4AA-451CD6BDA223-- From nobody Sun Apr 5 19:19:18 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9EDA1AD0D7 for ; Sun, 5 Apr 2015 19:19:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tyijYNo3RPwS for ; Sun, 5 Apr 2015 19:19:15 -0700 (PDT) Received: from proper.com (Opus1.Proper.COM [207.182.41.91]) (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 D20811AD16B for ; Sun, 5 Apr 2015 19:19:15 -0700 (PDT) Received: from [10.20.30.101] (50-1-51-95.dsl.dynamic.fusionbroadband.com [50.1.51.95]) (authenticated bits=0) by proper.com (8.15.1/8.14.9) with ESMTPSA id t362JDQJ061937 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 5 Apr 2015 19:19:14 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: proper.com: Host 50-1-51-95.dsl.dynamic.fusionbroadband.com [50.1.51.95] claimed to be [10.20.30.101] Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_EF3E59D5-8806-42E2-9A4D-08E837D57341"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Pgp-Agent: GPGMail 2.5b6 From: Paul Hoffman In-Reply-To: <5FD8ADD1-E741-48B4-B0A4-364FE6909D44@orthanc.ca> Date: Sun, 5 Apr 2015 19:19:09 -0700 Message-Id: References: <744A4EA3-F138-4D5D-AE98-AA56A75E18B3@vpnc.org> <5FD8ADD1-E741-48B4-B0A4-364FE6909D44@orthanc.ca> To: Lyndon Nerenberg X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: dane@ietf.org Subject: Re: [dane] Proposed design for draft-ietf-dane-openpgpkey (and then for draft-ietf-dane-smime) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2015 02:19:16 -0000 --Apple-Mail=_EF3E59D5-8806-42E2-9A4D-08E837D57341 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Apr 5, 2015, at 6:56 PM, Lyndon Nerenberg wrote: >=20 >=20 > On Apr 5, 2015, at 6:22 PM, Paul Hoffman = wrote: >=20 >> Greetings again. The discussion about exact-match and discovery in = draft-ietf-dane-openpgpkey has been useful for finding out what the use = cases are, and it's time to settle on a design that works for most = people (we're never going to make everyone happy). >=20 > How can we possibly do that without real experience in the field? How can we possibly get real experience in the field unless we get = at-least-rough consensus on a direction and publish a document? > I know for a fact the case insensitive hashing rules will break Cyrus, = where foo+Bar@mumble will deliver to mailbox 'inbox.Bar', which is = distinct from foo+bar@mumble, delivering to 'inbox.bar'. Folder names = are case sensitive, so the two addresses are not equivalencies. I'm not sure what "break" means in this context. It means, as I = proposed, that Cyrus will not be able to do exact-match lookup of = key/cert records, but that doesn't "break" Cyrus any more than the = current situation where no lookup is possible. > Ultimately, I don't see a way out of this other than to make a = standard for sub-addressing, with a well defined cut-point delimiter. That's an alternative for the second point I proposed, one that I think = would be much harder to get agreement on than "Webfinger to find = keys/certs". > But that still doesn't change how the LHS has been defined as = case-sensitive since the dawn of time. If we are to change this, = RFC5322 3.4.1 needs a change in its last paragraph. As things stand, we = cannot treat as case-insensitive in any interpretation of = the grammar. Nothing in what I proposed (or what has been proposed before now) = changes anything about how LHSs are treated. The address in mail = messages don't change at all. --Paul Hoffman --Apple-Mail=_EF3E59D5-8806-42E2-9A4D-08E837D57341 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----- iQEcBAEBCAAGBQJVIe0hAAoJEJz/fXByZmLZK8YH/2faJ5SIxCKMd7WwDesGJ/mM z6mmSij3lQeXMVJPe38aSpGIYTLiE8hs6Bpbd/rQE2fmT36WtiiI+dTHhsFG8c4z ooHVQN0S0So3Tmkmvg4wWEergjJWYvos+AwgwP5L1cCi0sW+zS6UUZ9zHnN32ZbJ NmsHg0mdPPcAUfXhDpoRFzIUNwypZFCtRpn2wn5VYMtargbHpMATpx8+rNY9zhtI 2Wmg00Yt0/abXgZQMnR2f6JPXHZC4jNHR4Cs57ajJrr6wKEtDYnx1YBJoN75pozq 3f9ysCaEiumZOLmcW39YTA/CL+BS3yZUigVqA9yEQ6/gRVhWIe3sq5ylVxphgMM= =35QE -----END PGP SIGNATURE----- --Apple-Mail=_EF3E59D5-8806-42E2-9A4D-08E837D57341-- From nobody Sun Apr 5 19:50:50 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25D2E1A8032 for ; Sun, 5 Apr 2015 19:50:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CFitt6xffYEk for ; Sun, 5 Apr 2015 19:50:48 -0700 (PDT) Received: from orthanc.ca (orthanc.ca [IPv6:2607:f2f8:abf8::2]) (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 26BC91A70FE for ; Sun, 5 Apr 2015 19:50:48 -0700 (PDT) Received: from [192.168.42.6] (d66-183-211-183.bchsia.telus.net [66.183.211.183]) (authenticated bits=0) by orthanc.ca (8.14.7/8.14.7) with ESMTP id t362ohiW096429 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 5 Apr 2015 19:50:46 -0700 (PDT) (envelope-from lyndon@orthanc.ca) Content-Type: multipart/signed; boundary="Apple-Mail=_2AB0D2E8-5792-495C-B228-22DEA08787DC"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Lyndon Nerenberg In-Reply-To: Date: Sun, 5 Apr 2015 19:50:41 -0700 Message-Id: <095420EB-0413-41A1-9C6A-CB1CF866E3C6@orthanc.ca> References: <744A4EA3-F138-4D5D-AE98-AA56A75E18B3@vpnc.org> <5FD8ADD1-E741-48B4-B0A4-364FE6909D44@orthanc.ca> To: Paul Hoffman X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: dane@ietf.org Subject: Re: [dane] Proposed design for draft-ietf-dane-openpgpkey (and then for draft-ietf-dane-smime) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2015 02:50:49 -0000 --Apple-Mail=_2AB0D2E8-5792-495C-B228-22DEA08787DC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Apr 5, 2015, at 7:19 PM, Paul Hoffman wrote: >>> Greetings again. The discussion about exact-match and discovery in = draft-ietf-dane-openpgpkey has been useful for finding out what the use = cases are, and it's time to settle on a design that works for most = people (we're never going to make everyone happy). >>=20 >> How can we possibly do that without real experience in the field? >=20 > How can we possibly get real experience in the field unless we get = at-least-rough consensus on a direction and publish a document? Then at the very least, the security section needs to call out = explicitly the potential for hash collisions caused by the case-folding = behaviour mandated by the draft. And that should include a specific = reference to RFC 5322 section 3.4.1. (And an informative reference to = 5322.) --Apple-Mail=_2AB0D2E8-5792-495C-B228-22DEA08787DC 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----- iQIcBAEBAgAGBQJVIfSBAAoJEG8PnXiV/JnU6ZYP/0ufSYYh1BLg2Pd1ewUPlUUm d7ETCQ+U3UsTRv/UBZsuPtZs0LvihNPchiEayCT/plMTYT1hDjS1XgxoZE7EgDVQ LZ+GmOejQfbeT38fkDS1EQcPGZopMvg4EwIbhzKvA4kyGXYrddGEoUR2cEcz4/Gv 04Hu+sorXLHZNwg+ioJIJEqZpxqVq1VrQ4dDlCI+SimjnLjr7jWMma9e4KTb03e/ sWWhyu5Ed/r6j8aTHS5VbqiJomvRSe5myXNVD9DbYpltyAcQ7dULFIHB3rha4Grj x84ycpl5l3J3HTF/wezcIZKJ6VcO58bsuVQEEQtAyTGp0C/vu+mRWPe934hONqKE P99K/k9FE6D21/rdNCK+1dsanZX1Osv839tYuOQW35g+pmbpG/5DNXpxyOgt9ps8 +7HNg+rPqOorTynoPsD9MIo++5ukeF95ixPQznhkeMJfR8HPHhOAkK/wKDe51TO+ yeKRzFbBWVK6JwFnxcnBUOSgO9D/zFLu/ZNhuiUixlR2CxuF6gmL+TuztLB+qSn2 FDo1sBMaY2cwdXpO9W5gZ54bs+YblRRZVvWySlvbnyA7g+3tWQuHxMuv35Rg9J2B m6b8iF1+lPaZDAXl8gIsYonbrbdWkY2PKlHlCeNMvGTFfsJCEcWQ4HOwI+AT1Vfq zy/BzO47wOn3KAnvsXC1 =Br0s -----END PGP SIGNATURE----- --Apple-Mail=_2AB0D2E8-5792-495C-B228-22DEA08787DC-- From nobody Sun Apr 5 19:57:14 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3FFE1A6EED for ; Sun, 5 Apr 2015 19:57:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hTFWlECM7ioY for ; Sun, 5 Apr 2015 19:57:11 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0DAC1A854D for ; Sun, 5 Apr 2015 19:57:10 -0700 (PDT) Received: from Philemon (unknown [50.109.252.111]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id 8AD982CA07; Sun, 5 Apr 2015 19:57:09 -0700 (PDT) From: "Jim Schaad" To: "'Lyndon Nerenberg'" , "'Paul Hoffman'" References: <744A4EA3-F138-4D5D-AE98-AA56A75E18B3@vpnc.org> <5FD8ADD1-E741-48B4-B0A4-364FE6909D44@orthanc.ca> In-Reply-To: <5FD8ADD1-E741-48B4-B0A4-364FE6909D44@orthanc.ca> Date: Sun, 5 Apr 2015 19:56:00 -0700 Message-ID: <007601d07015$37f2d670$a7d88350$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH4MwuYIHH80O0fRsbDeqy65qZN1gJmscs4nNyLgNA= Content-Language: en-us Archived-At: Cc: dane@ietf.org Subject: Re: [dane] Proposed design for draft-ietf-dane-openpgpkey (and then for draft-ietf-dane-smime) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2015 02:57:13 -0000 > -----Original Message----- > From: dane [mailto:dane-bounces@ietf.org] On Behalf Of Lyndon Nerenberg > Sent: Sunday, April 05, 2015 6:57 PM > To: Paul Hoffman > Cc: dane@ietf.org > Subject: Re: [dane] Proposed design for draft-ietf-dane-openpgpkey (and > then for draft-ietf-dane-smime) > > > On Apr 5, 2015, at 6:22 PM, Paul Hoffman wrote: > > > Greetings again. The discussion about exact-match and discovery in draft- > ietf-dane-openpgpkey has been useful for finding out what the use cases are, > and it's time to settle on a design that works for most people (we're never > going to make everyone happy). > > How can we possibly do that without real experience in the field? > > I know for a fact the case insensitive hashing rules will break Cyrus, where > foo+Bar@mumble will deliver to mailbox 'inbox.Bar', which is distinct from > foo+bar@mumble, delivering to 'inbox.bar'. Folder names are case sensitive, > so the two addresses are not equivalencies. What I read of Paul's message was that the hashing would be on case sensitive strings. This means that the two strings above will produce different results. > > Ultimately, I don't see a way out of this other than to make a standard for sub- > addressing, with a well defined cut-point delimiter. If this is going to be done, then it will need to be back ported into the S/MIME and PGP specifications as well. The S/MIME specification says that names SHOULD be matched case insensitive, I was unable to find any rules in the OpenPGP spec for how user IDs and email address are matched. However, neither of these documents dealt with sub-addressing in any way and would ignore the fact that one is trying to do this. Thus foo+Bar and foo+bar are going to be matched, but foo@example.com and foo+Bar@example.com are not going to be matched by S/MIME implementations. In S/MIME this decision was made to make most people happy. However, I do know that there are implementations where the names are matched case sensitive rather than case insensitive. Jim > > But that still doesn't change how the LHS has been defined as case-sensitive > since the dawn of time. If we are to change this, RFC5322 3.4.1 needs a > change in its last paragraph. As things stand, we cannot treat as > case-insensitive in any interpretation of the grammar. > > --lyndon From nobody Sun Apr 5 19:58:02 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F7921A854B for ; Sun, 5 Apr 2015 19:58:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w58Cr1ida036 for ; Sun, 5 Apr 2015 19:57:59 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E0211A6EED for ; Sun, 5 Apr 2015 19:57:59 -0700 (PDT) Received: from Philemon (unknown [50.109.252.111]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 4E1AA2C9FB for ; Sun, 5 Apr 2015 19:57:58 -0700 (PDT) From: "Jim Schaad" To: References: <744A4EA3-F138-4D5D-AE98-AA56A75E18B3@vpnc.org> In-Reply-To: <744A4EA3-F138-4D5D-AE98-AA56A75E18B3@vpnc.org> Date: Sun, 5 Apr 2015 19:56:49 -0700 Message-ID: <007701d07015$54d4a2f0$fe7de8d0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH4MwuYIHH80O0fRsbDeqy65qZN1pzvxG/g Content-Language: en-us Archived-At: Subject: Re: [dane] Proposed design for draft-ietf-dane-openpgpkey (and then for draft-ietf-dane-smime) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2015 02:58:00 -0000 +1 Until somebody else solves the matching problem it should be acknowledged and ignored. Jim > -----Original Message----- > From: dane [mailto:dane-bounces@ietf.org] On Behalf Of Paul Hoffman > Sent: Sunday, April 05, 2015 6:23 PM > To: dane@ietf.org > Subject: [dane] Proposed design for draft-ietf-dane-openpgpkey (and then for > draft-ietf-dane-smime) > > Greetings again. The discussion about exact-match and discovery in draft-ietf- > dane-openpgpkey has been useful for finding out what the use cases are, and > it's time to settle on a design that works for most people (we're never going to > make everyone happy). My motivation for this message is that Jakob and I will > match whatever the WG comes up with for draft-ietf-dane-openpgpkey in our > draft-ietf-dane-smime draft. > > Proposal: > > - Lookup of OpenPGP and S/MIME keys and certs in the DNS are exact-match, > following the DNS's database model. This is known to possibly fail when the > party looking up the address has a copy of the email address different than > what might be entered in the zone, such as with different casing. There is no > expectation in this design that all variants that might be delivered to for a > particular address will have key records. This design keeps the security model > understandable: it's all authenticated just by DNSSEC. > > - Discovery of delivery variants is better handled by a more flexible protocol, > such as WebFinger. In fact, instead of just looking for variants and then coming > back to the DNS to get the key, that protocol can instead hand back the keys > and certs directly in a single response. The security model for that protocol > would also be simple: it's all authenticated by the TLS cert of the server. This > new protocol should probably be designed somewhere in the Applications > Area, not here, even though some of what is being delivered are objects > similar to what we are delivering here. > > If folks agree with this proposal, we can move forwards with draft-ietf-dane- > openpgpkey pretty much as it is. (PaulW: you threw in downcasing before > hashing, which is definitely not what people agreed to at the meeting.) For > draft-ietf-dane-smime, we can then use the same format and semantics, and > add in the LDAP access model proposed by Eric and Scott, which historically > has never applied to OpenPGP. > > Thoughts? > > --Paul Hoffman > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From nobody Sun Apr 5 20:00:36 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F6D61A86EA for ; Sun, 5 Apr 2015 20:00:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ok7alObKNJjw for ; Sun, 5 Apr 2015 20:00:34 -0700 (PDT) Received: from orthanc.ca (orthanc.ca [IPv6:2607:f2f8:abf8::2]) (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 1C66D1A8033 for ; Sun, 5 Apr 2015 20:00:34 -0700 (PDT) Received: from [192.168.42.6] (d66-183-211-183.bchsia.telus.net [66.183.211.183]) (authenticated bits=0) by orthanc.ca (8.14.7/8.14.7) with ESMTP id t3630HRu096632 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 5 Apr 2015 20:00:20 -0700 (PDT) (envelope-from lyndon@orthanc.ca) Content-Type: multipart/signed; boundary="Apple-Mail=_7FBBEAA7-9B9A-4DDB-AF29-D65081ADC16D"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Lyndon Nerenberg In-Reply-To: <007601d07015$37f2d670$a7d88350$@augustcellars.com> Date: Sun, 5 Apr 2015 20:00:16 -0700 Message-Id: <7DEC3ED0-6DF3-48E5-8952-FB1034C96B78@orthanc.ca> References: <744A4EA3-F138-4D5D-AE98-AA56A75E18B3@vpnc.org> <5FD8ADD1-E741-48B4-B0A4-364FE6909D44@orthanc.ca> <007601d07015$37f2d670$a7d88350$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: dane@ietf.org Subject: Re: [dane] Proposed design for draft-ietf-dane-openpgpkey (and then for draft-ietf-dane-smime) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2015 03:00:35 -0000 --Apple-Mail=_7FBBEAA7-9B9A-4DDB-AF29-D65081ADC16D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Apr 5, 2015, at 7:56 PM, Jim Schaad wrote: > What I read of Paul's message was that the hashing would be on case > sensitive strings. This means that the two strings above will produce > different results. =20 That's not what I'm reading out of the draft, which seems to me to call = out for explicit case folding before generating the hash. --Apple-Mail=_7FBBEAA7-9B9A-4DDB-AF29-D65081ADC16D 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----- iQIcBAEBAgAGBQJVIfbAAAoJEG8PnXiV/JnU14QQAKNpGo0HqFXEIs7MagWw8VwV 4g14z4aWPNVrjcGiOW2VvU7RnH5KLjHaFJOyJnPd7w8xx3mDwBOInbL2qTXAnhz2 l1gbY6FYdFTCfVUWMIw1LLJvvyZImZd/vOdN+DO9HjgQnNJJtXz60TYmzxK5eGdL q1gDHBrwBZ5xaKukf9TWasv8mc6RF0fyrX9MwvxXLOqKkRy7P6LtmUFthlihl6PX Ejfb1GSm18XhPlO7tljnhUn05kGXna0VGuVuC2TgXQnYvVQd2Rzy1zDiL7245Vc1 qpMxr42tfWhu65RPwLg4Y1G9aVCrugyThRACrPwb4f8N4xohLpAAd4QZ4Or10G6y pGMtuL97U2H7PDokd+RNtw9AgaSAlyahh0HRX79darXa4Cyeo5gRsdZMJTMe+QC/ /PXpyjWsXYASj+/01hGSmb1w4ycPVLg/zOeF0Bq+YN9CHKIbW4lpg6EoNbPrHiSV xLyUZxJHFOvMMvKrTbzTxVIX8k9sehMpYv8mfWKprHDr7z6wDYxd/3dwN+78WeCU i9RyfdMNjfZ7hsR7R+qhPsFOtTLSbyFDvMCpqtC5KIOyG9dKMGB3MH3ezWkLG/ZF zvBqWbaA5NtmQVN/OeqAzi0OG18IvTUHu1dlKzQBSctki4YJcptAlm4cddM1Yal7 OORaOa9S+Bz2/DY3YIxs =GFQJ -----END PGP SIGNATURE----- --Apple-Mail=_7FBBEAA7-9B9A-4DDB-AF29-D65081ADC16D-- From nobody Sun Apr 5 20:24:31 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6017E1B29D3 for ; Sun, 5 Apr 2015 20:24:28 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N1N1EbhQpZmO for ; Sun, 5 Apr 2015 20:24:27 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A8B51A8749 for ; Sun, 5 Apr 2015 20:24:27 -0700 (PDT) Received: from Philemon (unknown [50.109.252.111]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 46E5C38F01; Sun, 5 Apr 2015 20:24:26 -0700 (PDT) From: "Jim Schaad" To: "'Lyndon Nerenberg'" References: <744A4EA3-F138-4D5D-AE98-AA56A75E18B3@vpnc.org> <5FD8ADD1-E741-48B4-B0A4-364FE6909D44@orthanc.ca> <007601d07015$37f2d670$a7d88350$@augustcellars.com> <7DEC3ED0-6DF3-48E5-8952-FB1034C96B78@orthanc.ca> In-Reply-To: <7DEC3ED0-6DF3-48E5-8952-FB1034C96B78@orthanc.ca> Date: Sun, 5 Apr 2015 20:23:17 -0700 Message-ID: <009001d07019$07688cd0$1639a670$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH4MwuYIHH80O0fRsbDeqy65qZN1gJmscs4AsLBVQ4CAOXTiZy2eRew Content-Language: en-us Archived-At: Cc: dane@ietf.org Subject: Re: [dane] Proposed design for draft-ietf-dane-openpgpkey (and then for draft-ietf-dane-smime) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2015 03:24:28 -0000 > -----Original Message----- > From: Lyndon Nerenberg [mailto:lyndon@orthanc.ca] > Sent: Sunday, April 05, 2015 8:00 PM > To: Jim Schaad > Cc: dane@ietf.org > Subject: Re: [dane] Proposed design for draft-ietf-dane-openpgpkey (and > then for draft-ietf-dane-smime) > > > On Apr 5, 2015, at 7:56 PM, Jim Schaad wrote: > > > What I read of Paul's message was that the hashing would be on case > > sensitive strings. This means that the two strings above will produce > > different results. > > That's not what I'm reading out of the draft, which seems to me to call out for > explicit case folding before generating the hash. Yes - that is what the note at the bottom of Paul's message was about (PaulW: you threw in downcasing before hashing, which is definitely not what people agreed to at the meeting.) Jim From nobody Sun Apr 5 20:52:03 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FA441A00CD for ; Sun, 5 Apr 2015 20:52:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ycz6O3hMR8bW for ; Sun, 5 Apr 2015 20:51:59 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5526A1A00C3 for ; Sun, 5 Apr 2015 20:51:59 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3lKybs3Gyqz7mC; Mon, 6 Apr 2015 05:51:53 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=kyyjYJ9B X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id b55h6kvGMMbs; Mon, 6 Apr 2015 05:51:50 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Mon, 6 Apr 2015 05:51:49 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 0B8B080416; Sun, 5 Apr 2015 23:51:47 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1428292307; bh=m8WPhZ1fXdgh6ZxEUfV+Gmo0RieQKom+K3yvdv99JUE=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=kyyjYJ9BhKVz5X4yaWKeS6C1Akk2YOpWKUrvp645aDIkFLO68otA1CE0Jr3hG9IY/ Isx7EA390OkJJrRIaNEInAEIRmQIBIFV9oYrQN9+vuAaP7psdmA+mQWoZUUaQD7r6C mmUThQTSCue03qa64szozWpwfFgba5DKRK+ku7Cw= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id t363phjn032276; Sun, 5 Apr 2015 23:51:44 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Sun, 5 Apr 2015 23:51:43 -0400 (EDT) From: Paul Wouters To: Jim Schaad In-Reply-To: <009001d07019$07688cd0$1639a670$@augustcellars.com> Message-ID: References: <744A4EA3-F138-4D5D-AE98-AA56A75E18B3@vpnc.org> <5FD8ADD1-E741-48B4-B0A4-364FE6909D44@orthanc.ca> <007601d07015$37f2d670$a7d88350$@augustcellars.com> <7DEC3ED0-6DF3-48E5-8952-FB1034C96B78@orthanc.ca> <009001d07019$07688cd0$1639a670$@augustcellars.com> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: dane@ietf.org Subject: Re: [dane] Proposed design for draft-ietf-dane-openpgpkey (and then for draft-ietf-dane-smime) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2015 03:52:01 -0000 On Sun, 5 Apr 2015, Jim Schaad wrote: >> That's not what I'm reading out of the draft, which seems to me to call > out for >> explicit case folding before generating the hash. > > > Yes - that is what the note at the bottom of Paul's message was about > > (PaulW: you threw in downcasing before hashing, which is definitely not what > people agreed to at the meeting.) Which I did, based on the following related text in a draft by John Levine that I thought was something shared amongst the app/email people: https://tools.ietf.org/html/draft-levine-dns-mailbox-00#section-1 Mail systems usually handle variant forms of local-parts. The most common variants are upper and lower case, which are now invariably treated as equivalent. This would greatly enhance the lookup mechanism to help in case of "auto uppercasing" that is very common in webforms and mobile phone input methods via virtual keyboards. That is, if I start composing an email to myself, after I type "paul@" it will help me and correct it to "Paul@". I believe this use case is MANY times more common than case sensitive LHS. And as PaulH already said, we are not changing the case of the actual email delivery. Otherwise, everyone generating OPENPGPKEY records basically has to add a CNAME for hash(Paul) pointing to the hash(paul) OPENPGPKEY record. So it is the lesser of two evils, Paul From nobody Mon Apr 6 05:46:44 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 144F21A8863 for ; Mon, 6 Apr 2015 05:46:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uWzl8lhhkC4U for ; Mon, 6 Apr 2015 05:46:40 -0700 (PDT) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40B1B1A8862 for ; Mon, 6 Apr 2015 05:46:40 -0700 (PDT) Received: by laat2 with SMTP id t2so11868053laa.1 for ; Mon, 06 Apr 2015 05:46:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=7Eef2wYw3InAGWdHvYy8pBdAJXLNiylngcupIJZ/mYE=; b=TKiftwXxH4+3p7nVbb5FJBTPuaJVflmYS4YCSOGEtKBKHatkfDI087LRap57KaQZim IL2+ljnE35csGTTjUaUm5tl/aqCVIUBsQJZIwkIHJax7cHK4KQksQkqk9FIDWyIJnkV2 KUYXc84ofUV3DKNCik7hqbJ62mTRy17bwmYp68Psu+yHaQrjUQtt97pNECsCrY9ogFhB uQYocSrK/G7WyJFKNQ+43HEFoHUKCfItsOgVgNs6udLUWqs604I7GPKYqKRuwuskCM/q tbYIBIs98NUACGmX/jljKJqL6hZk2xM9U6bn18RT52Fnsi39xhpvdbDCn0Ko6d02pBXc 8b4w== X-Received: by 10.152.19.162 with SMTP id g2mr1718095lae.46.1428324398809; Mon, 06 Apr 2015 05:46:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.62.193 with HTTP; Mon, 6 Apr 2015 05:46:18 -0700 (PDT) In-Reply-To: References: <2E2E6A49-3ED5-49A7-A263-54D8F1B8EE95@roessner-network-solutions.com> <4B7FCFB2-F91C-4C43-B121-F53ADA63E328@verisign.com> <20150402171241.GD17637@mournblade.imrryr.org> <24051EA3-88B5-4D29-9900-7B49A672000D@verisign.com> From: Doug Montgomery Date: Mon, 6 Apr 2015 08:46:18 -0400 Message-ID: To: Paul Wouters Content-Type: multipart/alternative; boundary=089e013d186c6a46f505130db058 Archived-At: Cc: "dane@ietf.org" Subject: Re: [dane] Updated draft-ietf-dane-openpgpkey 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, 06 Apr 2015 12:46:43 -0000 --089e013d186c6a46f505130db058 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Apr 2, 2015 at 2:40 PM, Paul Wouters wrote: > On Thu, 2 Apr 2015, Osterweil, Eric wrote: > > Also, the smime key attributes will tell if if they are usable for >>> signing and/or encrypting. So my preference is to not have another >>> place to indicate this so we avoid needing to deal with mismatches. >>> >> >> I think this was better described by Doug M before, and you and I spoke >> about this at the interim meeting, but to rehash: my certs may be used f= or >> any number of actions (like the USG PIV cards), but I may not want them = to >> be used arbitrarily for different services (like all manner of email). = I >> may also have a cert that I want to no longer use for email, but I do _n= ot_ >> want to revoke it. I may want to use a cert (whose attributes are very >> permissive) for just email signing. I can codify my wishes by not listi= ng >> it as an encryption key in DNS. >> > > Well, this is SMIME and it uses PKIX, so the proper way to express any > kind of attributes is via EKU OIDs. Part of the issue here is that we have large enterprise identity management systems that issue credentials for security functions, but independent of application. So while the EKU bits say that a CERT is useful for encryption, it does not say if that is for file encryption, disk encryption, or email encryption. Thus the EKU bits may not be enough to understand if the domain in question supports/allows encrypted email or not. DANE/SMIMEA offers the potential to clearly express / control key usage per service and at the domain level. Both of which are not controllable, and/or, are out of scope of the business processes and regulations that control the creation of the actual certificates. Enterprise identity management systems, business process, and the laws and policies that govern them are the long pole in the tent here. At least on the enterprise side, we are not talking about an individual getting a $5 CERT or running ssh-keygen. > > >>> To be honest, I don't expect encrypted messages in the mailbox to >>>> ever be very popular, encrypted storage is just too inconvenient >>>> for most users. >>>> >>> >>> Having run openpgpkey-milter and gotten all of my email encrypted >>> due to my own forwarder, I strongly agree with that it is completely >>> inconvenient right now. But it is a problem that we need to solve to >>> make it convenient. I'm hoping that encrypting more email will mean >>> more people will work on better MUA integration of it. We really >>> need to fix this problem. >>> >> >> I=E2=80=99m aware of a lot of enterprise interest in encrypted email at = rest. >> >> End-to-end is good for live conversations, but >>>> not so well suited to archived communication. >>>> >>> >>> I personally would like my MUA to store email decrypted, replace the >>> encrypted email headers inside the body back into real email headers >>> and rely on full disk encryption. That way, I get the best of both >>> worlds. >>> >> >> I actually favor the encrypted email for the afore mentioned reasons. A= t >> the very least, it seems fair to consider giving the user the option. >> > > The MUA can implement either. But I can tell you that it is next to > impossible to search through old encrypted emails. I often search > through old email, so I have a clear preference for storing it in > decrypted form accessable to my MUA, all of it protected by whole > disk encryption. But that's all a MUA based local/user policy > decision and we don't have to indicate any of this in DNS. +1 Having seen the awkward and complex machinery that exists to allow users to recover their decade old encryption keys so as to read an old email in their inbox, I personally think the idea of storing encrypted email encrypted by the original key both useless and misguided / misleading. After delivery to the end user it offers no security service to the original sender as I could have done anything with the decrypted message. The only sane way to do this is to store in local encrypted file store that presumably is actively managed in terms of keying material. > > Paul dougm --=20 DougM at Work --089e013d186c6a46f505130db058 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Apr 2, 2015 at 2:40 PM, Paul Wouters <paul@nohats.ca> wrote:
On Thu, 2 Apr = 2015, Osterweil, Eric wrote:

Also, the smime key attributes will tell if if they are usable for
signing and/or encrypting. So my preference is to not have another
place to indicate this so we avoid needing to deal with mismatches.

I think this was better described by Doug M before, and you and I spoke abo= ut this at the interim meeting, but to rehash: my certs may be used for any= number of actions (like the USG PIV cards), but I may not want them to be = used arbitrarily for different services (like all manner of email).=C2=A0 I= may also have a cert that I want to no longer use for email, but I do _not= _ want to revoke it.=C2=A0 I may want to use a cert (whose attributes are v= ery permissive) for just email signing.=C2=A0 I can codify my wishes by not= listing it as an encryption key in DNS.

 Well, this is SMIME and it uses PKIX, so the proper way to express any
kind of attributes is via EKU OIDs.

Part of= the issue here is that we have large enterprise identity management system= s that issue credentials for security functions, but independent of applica= tion.=C2=A0 So while the EKU bits say that a CERT is useful for encryption,= it does not say if that is for file encryption, disk encryption, or email = encryption. =C2=A0

Thus the EKU bits may not be en= ough to understand if the domain in question supports/allows encrypted emai= l or not. =C2=A0 DANE/SMIMEA offers the potential to clearly express / cont= rol key usage per service and at the domain level. =C2=A0 Both of which are= not controllable, and/or, are out of scope of the business processes and r= egulations that control the creation of the actual certificates.
=
Enterprise identity management systems, business process, an= d the laws and policies that govern them are the long pole in the tent here= .=C2=A0 At least on the enterprise side, we are not talking about an indivi= dual getting a $5 CERT or running ssh-keygen. =C2=A0=C2=A0




To be honest, I don't expect encrypted messages in the mailbox to
ever be very popular, encrypted storage is just too inconvenient
for most users.

Having run openpgpkey-milter and gotten all of my email encrypted
due to my own forwarder, I strongly agree with that it is completely
inconvenient right now. But it is a problem that we need to solve to
make it convenient. I'm hoping that encrypting more email will mean
more people will work on better MUA integration of it. We really
need to fix this problem.

I=E2=80=99m aware of a lot of enterprise interest in encrypted email at res= t.

End-to-end is good for live conversations, but
not so well suited to archived communication.

I personally would like my MUA to store email decrypted, replace the
encrypted email headers inside the body back into real email headers
and rely on full disk encryption. That way, I get the best of both
worlds.

I actually favor the encrypted email for the afore mentioned reasons.=C2=A0= At the very least, it seems fair to consider giving the user the option.

The MUA can implement either. But I can tell you that it is next to
impossible to search through old encrypted emails. I often search
through old email, so I have a clear preference for storing it in
decrypted form accessable to my MUA, all of it protected by whole
disk encryption. But that's all a MUA based local/user policy
decision and we don't have to indicate any of this in DNS.
=

+1

Having seen the awkward and= complex machinery that exists to allow users to recover their decade old e= ncryption keys so as to read an old email in their inbox, I personally thin= k the idea of storing encrypted email encrypted by the original key both us= eless and misguided / misleading. =C2=A0 After delivery to the end user it = offers no security service to the original sender as I could have done anyt= hing with the decrypted message.

The only sane way= to do this is to store in local encrypted file store that presumably is ac= tively managed in terms of keying material.




Paul

dougm
=C2=A0

--
DougM at Wor= k
--089e013d186c6a46f505130db058-- From nobody Mon Apr 6 07:38:23 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92F6E1A1A1B for ; Mon, 6 Apr 2015 07:38:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.363 X-Spam-Level: X-Spam-Status: No, score=0.363 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gl_2MEATihQQ for ; Mon, 6 Apr 2015 07:38:20 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F26D1A88CB for ; Mon, 6 Apr 2015 07:38:20 -0700 (PDT) Received: (qmail 56955 invoked from network); 6 Apr 2015 14:38:18 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 6 Apr 2015 14:38:18 -0000 Date: 6 Apr 2015 14:37:56 -0000 Message-ID: <20150406143756.23164.qmail@ary.lan> From: "John Levine" To: dane@ietf.org In-Reply-To: <5FD8ADD1-E741-48B4-B0A4-364FE6909D44@orthanc.ca> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: lyndon@orthanc.ca Subject: Re: [dane] Proposed design for draft-ietf-dane-openpgpkey (and then for draft-ietf-dane-smime) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2015 14:38:21 -0000 In article <5FD8ADD1-E741-48B4-B0A4-364FE6909D44@orthanc.ca> you write: >-=-=-=-=-=- >-=-=-=-=-=- > > >On Apr 5, 2015, at 6:22 PM, Paul Hoffman wrote: > >> Greetings again. The discussion about exact-match and discovery in draft-ietf-dane-openpgpkey >has been useful for finding out what the use cases are, and it's time to settle on a design that >works for most people (we're never going to make everyone happy). > >How can we possibly do that without real experience in the field? Publish the thing as experimental and be done with it. It's not an accident that SMTP and DNS have both been around for 30 years and nobody has ever published mailbox info in the DNS. It's a really hard problem with no good solution. Every approach has security problems (address guessing), doesn't scale (static zones particularly if they include address variants), and/or works in ways the DNS crowd doesn't like (dynamic replies to base32 requests.) Throughout this argument, there's been nothing new. It's evident that a few people want to try retrieving keys for mail messages from the DNS. This allows a way to experiment with it. R's, John From nobody Mon Apr 6 07:50:05 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9528D1A8930 for ; Mon, 6 Apr 2015 07:50:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q-hYDOgxLJaq for ; Mon, 6 Apr 2015 07:50:02 -0700 (PDT) Received: from proper.com (Opus1.Proper.COM [207.182.41.91]) (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 7E6181A8935 for ; Mon, 6 Apr 2015 07:49:59 -0700 (PDT) Received: from [10.20.30.101] (50-1-51-95.dsl.dynamic.fusionbroadband.com [50.1.51.95]) (authenticated bits=0) by proper.com (8.15.1/8.14.9) with ESMTPSA id t36Envdm067012 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Apr 2015 07:49:58 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: proper.com: Host 50-1-51-95.dsl.dynamic.fusionbroadband.com [50.1.51.95] claimed to be [10.20.30.101] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Paul Hoffman In-Reply-To: <20150406143756.23164.qmail@ary.lan> Date: Mon, 6 Apr 2015 07:49:57 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150406143756.23164.qmail@ary.lan> To: John Levine X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: dane@ietf.org Subject: Re: [dane] Proposed design for draft-ietf-dane-openpgpkey (and then for draft-ietf-dane-smime) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2015 14:50:03 -0000 On Apr 6, 2015, at 7:37 AM, John Levine wrote: > Publish the thing as experimental and be done with it. The proposals are no more "experimental" than TLSA is. Further, they = don't follow the guidelines from the IETF process for what is called = "experimental" (RFC 2026, section 4.2.1) any more than over half of the = RFCs produced by WGs these days. These are standards-track proposals = that, like a large percentage of standards-track RFCs, might or might = not garner much deployment. --Paul Hoffman P.S. And, no, let's not turn this into an argument about IETF process = and what "should" be "experimental".= From nobody Mon Apr 6 09:08:30 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E5511A8AC2 for ; Mon, 6 Apr 2015 09:08:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ShqwV6QpnWhB for ; Mon, 6 Apr 2015 09:08:26 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 382CA1A8ABF for ; Mon, 6 Apr 2015 09:08:26 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3lLGxh290HzJtk; Mon, 6 Apr 2015 18:08:24 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=EEki+syV X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id oqrc4IB7CbkE; Mon, 6 Apr 2015 18:08:23 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Mon, 6 Apr 2015 18:08:23 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 6787980416; Mon, 6 Apr 2015 12:08:22 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1428336502; bh=NZxog0MS944Gy1fwa8P7a0/sQ455m1zz5+PIL7NR5Zk=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=EEki+syVIjtOcrw9QdkjNehI3SsUX6KaeL1VIB6EaLsbpQU/86hFFPZAWxHCC1QT5 xEZeSCekC6NRvayhv2QQ+26t9+pqDn0lvnRq3913MdvZNjZwz+JAjWRykM06uviWBO Kg02PtaEpRTQ8f+MpcO2Y+oRHUYWgcR3S4gZ4FJI= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id t36G8Lx8027805; Mon, 6 Apr 2015 12:08:21 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Mon, 6 Apr 2015 12:08:21 -0400 (EDT) From: Paul Wouters To: Doug Montgomery In-Reply-To: Message-ID: References: <2E2E6A49-3ED5-49A7-A263-54D8F1B8EE95@roessner-network-solutions.com> <4B7FCFB2-F91C-4C43-B121-F53ADA63E328@verisign.com> <20150402171241.GD17637@mournblade.imrryr.org> <24051EA3-88B5-4D29-9900-7B49A672000D@verisign.com> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Cc: "dane@ietf.org" Subject: Re: [dane] Updated draft-ietf-dane-openpgpkey 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, 06 Apr 2015 16:08:28 -0000 On Mon, 6 Apr 2015, Doug Montgomery wrote: > Well, this is SMIME and it uses PKIX, so the proper way to express any > kind of attributes is via EKU OIDs. > > Part of the issue here is that we have large enterprise identity management systems that issue > credentials for security functions, but independent of application.  So while the EKU bits say > that a CERT is useful for encryption, it does not say if that is for file encryption, disk > encryption, or email encryption.   > > Thus the EKU bits may not be enough to understand if the domain in question supports/allows > encrypted email or not. Do we need the PKIX/SMIME people to write a document to express these? This really seems to be in their domain, and using the DNS to work around not having the right EKUs seems wrong to me. >  DANE/SMIMEA offers the potential to clearly express / control key > usage per service and at the domain level. The DANE working group sees regular invasions of other IETF areas whenever that area feels the DNS is trespassing on their domain. I'd prefer not to see another wave. And additionally, I do think it matters that we leak key usage intent into the DNS - especially in the current architecture of a few big resolvers like google dns and opendns seeing many of the queries. > Enterprise identity management systems, business process, and the laws and policies that govern > them are the long pole in the tent here.  At least on the enterprise side, we are not talking > about an individual getting a $5 CERT or running ssh-keygen.    i would expect the enterprise to have a lot more control on the EKU's in the certificates they hand out to their employees than I would have ordering my $5 certificate online from an SMIME CA. Paul From nobody Mon Apr 6 10:19:47 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 370FF1A9008 for ; Mon, 6 Apr 2015 10:19:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZGf9wfFjp7ht for ; Mon, 6 Apr 2015 10:19:44 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 476741A8F37 for ; Mon, 6 Apr 2015 10:19:44 -0700 (PDT) Received: from Philemon (winery.augustcellars.com [206.212.239.129]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id AE9B22C9F4; Mon, 6 Apr 2015 10:19:43 -0700 (PDT) From: "Jim Schaad" To: "'Paul Wouters'" , "'Doug Montgomery'" References: <2E2E6A49-3ED5-49A7-A263-54D8F1B8EE95@roessner-network-solutions.com> <4B7FCFB2-F91C-4C43-B121-F53ADA63E328@verisign.com> <20150402171241.GD17637@mournblade.imrryr.org> <24051EA3-88B5-4D29-9900-7B49A672000D@verisign.com> In-Reply-To: Date: Mon, 6 Apr 2015 10:18:35 -0700 Message-ID: <00fd01d0708d$b75decb0$2619c610$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGim1cnncPRMnktg9tyOc8UVtMsbAInZ2jnArtlKhkBuGkh7wEn7lENAnDwJMABydoheQGowhqTAnXeS4YBDBGpdAHeTScNnQOrZBA= Content-Language: en-us Archived-At: Cc: dane@ietf.org Subject: Re: [dane] Updated draft-ietf-dane-openpgpkey 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, 06 Apr 2015 17:19:46 -0000 > -----Original Message----- > From: dane [mailto:dane-bounces@ietf.org] On Behalf Of Paul Wouters > Sent: Monday, April 06, 2015 9:08 AM > To: Doug Montgomery > Cc: dane@ietf.org > Subject: Re: [dane] Updated draft-ietf-dane-openpgpkey >=20 > On Mon, 6 Apr 2015, Doug Montgomery wrote: >=20 > > Well, this is SMIME and it uses PKIX, so the proper way to = express any > > kind of attributes is via EKU OIDs. > > > > Part of the issue here is that we have large enterprise identity > > management systems that issue credentials for security functions, = but > > independent of application. So while the EKU bits say that a CERT = is > > useful for encryption, it does not say if that is for file = encryption, > > disk encryption, or email encryption. > > > > Thus the EKU bits may not be enough to understand if the domain in > > question supports/allows encrypted email or not. >=20 > Do we need the PKIX/SMIME people to write a document to express these? > This really seems to be in their domain, and using the DNS to work = around not > having the right EKUs seems wrong to me. I have been doing my best to ignore this thread, but I guess I cannot = any more. Firstly. EKU is not the correct way to deal with what type of key is in = a certificate. EKU is used to say this is an SMIME only certificate = (and I don't believe without looking that this was ever done). Key = Usage (KU) is used to say this is a signing key or this is an encryption = key (by restricting the usages). Yes EKU could say that a certificate = is used for a specific type of encryption, however that should not be an = issue here as only those targeted for S/MIME should be published in the = directory. =20 NONE OF THESE VALUES CAN BE CHANGED by the user after the certificate = has been issued. This means that there is nothing that can be done to = say - Oh, I have this encryption certificate that is being published but = I don't want you to use it. I want you to use a different one. In this = case you just stop publishing the first certificate - no problems as = long as the second is published at the same time. One can continue to publish signing certificates long after one has = stopped using the matching key to perform signature operations. There = is more of a problem with a validator that cannot deal with the fact = that you have the same public key in two certificates, however good = practice says that an EE should not do this. There is nothing that the PKIX/SMIME people should need to write to deal = with any of these issues. >=20 > > DANE/SMIMEA offers the potential to clearly express / control key > >usage per service and at the domain level. >=20 > The DANE working group sees regular invasions of other IETF areas = whenever > that area feels the DNS is trespassing on their domain. I'd prefer not = to see > another wave. >=20 > And additionally, I do think it matters that we leak key usage intent = into the > DNS - especially in the current architecture of a few big resolvers = like google > dns and opendns seeing many of the queries. This I completely agree with. If one is using certificates, that = information is totally public. Jim >=20 > > Enterprise identity management systems, business process, and the = laws > > and policies that govern them are the long pole in the tent here. = At > > least on the enterprise side, we are not talking about an individual > > getting a $5 CERT or running ssh-keygen. >=20 > i would expect the enterprise to have a lot more control on the EKU's = in the > certificates they hand out to their employees than I would have = ordering my > $5 certificate online from an SMIME CA. >=20 > Paul >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From nobody Mon Apr 6 12:46:31 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AFBF1A90ED for ; Mon, 6 Apr 2015 12:46:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.351 X-Spam-Level: X-Spam-Status: No, score=-1.351 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, 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 FNWsxNvEJv5o for ; Mon, 6 Apr 2015 12:46:28 -0700 (PDT) Received: from mx.roessner-net.de (mail.roessner-net.de [193.239.107.42]) (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 E6A0D1A90EA for ; Mon, 6 Apr 2015 12:46:27 -0700 (PDT) Received: from mail.roessner-net.de (mail.roessner-net.de [193.239.107.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.roessner-net.de", Issuer "thawte DV SSL CA - G2" (verified OK)) by mx.roessner-net.de (Postfix) with ESMTPS id 3lLMnD362lzGp9c; Mon, 6 Apr 2015 21:46:24 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=roessner-network-solutions.com; s=swioBi3opho; t=1428349584; i=@roessner-network-solutions.com; bh=U4SwTOMLt4OzlnTiVpNVN3Z0h+RTAS6cTb0EaMatDkA=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=JmliHzjrglI7iZBwR44KV1FFAZNYN1wd4dTgiDXs1yZ6vbk5YPT3LUsY+FyzApa1b XI2hNU0voS6fH4Pj57hfj7ComBrzw7U8MPqsSgqb33FLAld7eGcT9fT4dDET1PXasj SNOK81AbI2s5jwU+TxNLq5HtU/zMKajMMz1yUpDbcR+rKjWSWphwz/jFPYfGYAmhoA EBykTDsYvLU/jmAGdWPNsp/UuwG8JKZx/6UyTvlsS2kr6Db7OZV9WW59zlYtwiXZR4 EOfrrSfqGGcM0B83MbE1LhcITw9wh3cMOXxUGtPLXyVKM705TphKDSFUZLqPVZPzCy LXtfApLRZojfQ== Received: from [172.20.10.2] (tmo-106-205.customers.d1-online.com [80.187.106.205]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Christian Roessner", Issuer "RootCA (c) 2014" (verified OK)) (Authenticated sender: c@roessner.co) by mail.roessner-net.de (Postfix) with ESMTPSA id 3lLMnB57pYzMkrT; Mon, 6 Apr 2015 21:46:22 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2097\)) Content-Type: multipart/signed; boundary="Apple-Mail=_23F4EA3C-006B-4AD5-86F4-B6FCFE1D8CC4"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Pgp-Agent: GPGMail 2.5b6 From: =?utf-8?Q?Christian_R=C3=B6=C3=9Fner?= In-Reply-To: <00fd01d0708d$b75decb0$2619c610$@augustcellars.com> Date: Mon, 6 Apr 2015 21:46:20 +0200 Message-Id: References: <2E2E6A49-3ED5-49A7-A263-54D8F1B8EE95@roessner-network-solutions.com> <4B7FCFB2-F91C-4C43-B121-F53ADA63E328@verisign.com> <20150402171241.GD17637@mournblade.imrryr.org> <24051EA3-88B5-4D29-9900-7B49A672000D@verisign.com> <00fd01d0708d$b75decb0$2619c610$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.2097) Outgoingd: 0.3.0_m1 Archived-At: Cc: Paul Wouters , dane@ietf.org Subject: Re: [dane] Updated draft-ietf-dane-openpgpkey 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, 06 Apr 2015 19:46:30 -0000 --Apple-Mail=_23F4EA3C-006B-4AD5-86F4-B6FCFE1D8CC4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > Am 06.04.2015 um 19:18 schrieb Jim Schaad : >=20 >=20 >=20 >> -----Original Message----- >> From: dane [mailto:dane-bounces@ietf.org] On Behalf Of Paul Wouters >> Sent: Monday, April 06, 2015 9:08 AM >> To: Doug Montgomery >> Cc: dane@ietf.org >> Subject: Re: [dane] Updated draft-ietf-dane-openpgpkey >>=20 >> On Mon, 6 Apr 2015, Doug Montgomery wrote: >>=20 >>> Well, this is SMIME and it uses PKIX, so the proper way to = express any >>> kind of attributes is via EKU OIDs. >>>=20 >>> Part of the issue here is that we have large enterprise identity >>> management systems that issue credentials for security functions, = but >>> independent of application. So while the EKU bits say that a CERT = is >>> useful for encryption, it does not say if that is for file = encryption, >>> disk encryption, or email encryption. >>>=20 >>> Thus the EKU bits may not be enough to understand if the domain in >>> question supports/allows encrypted email or not. >>=20 >> Do we need the PKIX/SMIME people to write a document to express = these? >> This really seems to be in their domain, and using the DNS to work = around not >> having the right EKUs seems wrong to me. >=20 > I have been doing my best to ignore this thread, but I guess I cannot = any more. >=20 > Firstly. EKU is not the correct way to deal with what type of key is = in a certificate. EKU is used to say this is an SMIME only certificate = (and I don't believe without looking that this was ever done). Key = Usage (KU) is used to say this is a signing key or this is an encryption = key (by restricting the usages). Yes EKU could say that a certificate = is used for a specific type of encryption, however that should not be an = issue here as only those targeted for S/MIME should be published in the = directory. >=20 > NONE OF THESE VALUES CAN BE CHANGED by the user after the certificate = has been issued. This means that there is nothing that can be done to = say - Oh, I have this encryption certificate that is being published but = I don't want you to use it. I want you to use a different one. In this = case you just stop publishing the first certificate - no problems as = long as the second is published at the same time. >=20 > One can continue to publish signing certificates long after one has = stopped using the matching key to perform signature operations. There = is more of a problem with a validator that cannot deal with the fact = that you have the same public key in two certificates, however good = practice says that an EE should not do this. >=20 > There is nothing that the PKIX/SMIME people should need to write to = deal with any of these issues. For S/MIME (SMIMEA), if you publish your S/MIME DER cert in DNS (1 0 0 = or 3 0 0), I think you must check for keyUsage to make sure that the = certificate was issued for this use case. You will have to check this on = encryption software (not sure for signing software). It doesn=E2=80=99t = matter, if the certificate was already issued and the user can not = change things anymore, but the software that retrieves a certificate = from DNS still can validate (and in my opinion MUST validate) certain = things. Not only keyUsage, also not before and not after date validity). = So every software MUST do sanity checks. Sorry, if I should have misunderstood you :-) Christian --Apple-Mail=_23F4EA3C-006B-4AD5-86F4-B6FCFE1D8CC4 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVIuKNAAoJEDilQ0bXJ5TlYCEQAJPs0MXSLOdmTOiNiWqPPpy1 hMQYcogVuhko2Z8qjF3dQHNe6i0Iq7WvYhKYqcBrKlq2qFzBIqge6r7F7MmcnoaL BAP6bAGLw7pcD+STRauFIcIym8R5BP5l8Sv/gW1s8s48bxcen0TN6NFi0bbKlO9v HME4+pEv57Ept+0gRaq40RbSGNYBt7rvLUMN8qTz85FhmbSHHeSqj27976YoIWeV MscAvDhkw43eDp2qkxrdm0I8Pshd8DFvsCG9m6S1Uuk6UuTTEVQxbN2wHydEDC+B Fl1kobRrVtzmrUraXj3aNxpcAyTyNg8ysqzLT095ei69j45fYsNmTeGqPgikmMOC iq/aDY0pu5k4CFCM3/VOs3xzM49Ntx68QFlgaLGBdnSpOkfoRaOLWRAUcn4cOc+s ECu+9pqHV5e+7Sh+55Aq82TH8UaqsehuB2Kcqyl7I2o9kOQi4WPduQCFBSZBeRWE 5ytxi8Z2mTQo0r8tvyMYGjosJqOtFeznT7cz5ajGsvIvhYY2IeAgtMXmIdld9uQM we1AhLcUAeEYuN6C21epnxwvYfT8cd7m5uyPp/3UDoIdzBQiGcwgK1PEk0f3SahT CIB3Cz2CKXbNojYxB1j2pWp7W/1/X6SXEbOcYcmnCWu3GtfvK8OLn6lZVLZC6L4E v6VWndzuFPaEHNHAgQNI =Q+FG -----END PGP SIGNATURE----- --Apple-Mail=_23F4EA3C-006B-4AD5-86F4-B6FCFE1D8CC4-- From nobody Mon Apr 6 13:10:01 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 829501A9124 for ; Mon, 6 Apr 2015 13:09:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001] 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 4WjeK3DQ_8ZC for ; Mon, 6 Apr 2015 13:09:58 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 379071A9115 for ; Mon, 6 Apr 2015 13:09:58 -0700 (PDT) Received: from Philemon (c-24-20-125-230.hsd1.or.comcast.net [24.20.125.230]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 6E56538F14; Mon, 6 Apr 2015 13:09:57 -0700 (PDT) From: "Jim Schaad" To: =?utf-8?Q?'Christian_R=C3=B6=C3=9Fner'?= References: <2E2E6A49-3ED5-49A7-A263-54D8F1B8EE95@roessner-network-solutions.com> <4B7FCFB2-F91C-4C43-B121-F53ADA63E328@verisign.com> <20150402171241.GD17637@mournblade.imrryr.org> <24051EA3-88B5-4D29-9900-7B49A672000D@verisign.com> <00fd01d0708d$b75decb0$2619c610$@augustcellars.com> In-Reply-To: Date: Mon, 6 Apr 2015 13:08:48 -0700 Message-ID: <012c01d070a5$7f023430$7d069c90$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGim1cnncPRMnktg9tyOc8UVtMsbAInZ2jnArtlKhkBuGkh7wEn7lENAnDwJMABydoheQGowhqTAnXeS4YBDBGpdAHeTScNAeWS0mECaZjsYZzhYzbw Content-Language: en-us Archived-At: Cc: dane@ietf.org Subject: Re: [dane] Updated draft-ietf-dane-openpgpkey 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, 06 Apr 2015 20:09:59 -0000 > -----Original Message----- > From: Christian R=C3=B6=C3=9Fner = [mailto:c@roessner-network-solutions.com] > Sent: Monday, April 06, 2015 12:46 PM > To: Jim Schaad > Cc: Paul Wouters; Doug Montgomery; dane@ietf.org > Subject: Re: [dane] Updated draft-ietf-dane-openpgpkey >=20 >=20 > > Am 06.04.2015 um 19:18 schrieb Jim Schaad : > > > > > > > >> -----Original Message----- > >> From: dane [mailto:dane-bounces@ietf.org] On Behalf Of Paul Wouters > >> Sent: Monday, April 06, 2015 9:08 AM > >> To: Doug Montgomery > >> Cc: dane@ietf.org > >> Subject: Re: [dane] Updated draft-ietf-dane-openpgpkey > >> > >> On Mon, 6 Apr 2015, Doug Montgomery wrote: > >> > >>> Well, this is SMIME and it uses PKIX, so the proper way to = express any > >>> kind of attributes is via EKU OIDs. > >>> > >>> Part of the issue here is that we have large enterprise identity > >>> management systems that issue credentials for security functions, > >>> but independent of application. So while the EKU bits say that a > >>> CERT is useful for encryption, it does not say if that is for file > >>> encryption, disk encryption, or email encryption. > >>> > >>> Thus the EKU bits may not be enough to understand if the domain in > >>> question supports/allows encrypted email or not. > >> > >> Do we need the PKIX/SMIME people to write a document to express > these? > >> This really seems to be in their domain, and using the DNS to work > >> around not having the right EKUs seems wrong to me. > > > > I have been doing my best to ignore this thread, but I guess I = cannot any > more. > > > > Firstly. EKU is not the correct way to deal with what type of key = is in a > certificate. EKU is used to say this is an SMIME only certificate = (and I don't > believe without looking that this was ever done). Key Usage (KU) is = used to > say this is a signing key or this is an encryption key (by restricting = the usages). > Yes EKU could say that a certificate is used for a specific type of = encryption, > however that should not be an issue here as only those targeted for = S/MIME > should be published in the directory. > > > > NONE OF THESE VALUES CAN BE CHANGED by the user after the = certificate > has been issued. This means that there is nothing that can be done to = say - > Oh, I have this encryption certificate that is being published but I = don't want > you to use it. I want you to use a different one. In this case you = just stop > publishing the first certificate - no problems as long as the second = is published > at the same time. > > > > One can continue to publish signing certificates long after one has = stopped > using the matching key to perform signature operations. There is more = of a > problem with a validator that cannot deal with the fact that you have = the same > public key in two certificates, however good practice says that an EE = should > not do this. > > > > There is nothing that the PKIX/SMIME people should need to write to = deal > with any of these issues. >=20 > For S/MIME (SMIMEA), if you publish your S/MIME DER cert in DNS (1 0 0 = or 3 > 0 0), I think you must check for keyUsage to make sure that the = certificate was > issued for this use case. You will have to check this on encryption = software > (not sure for signing software). It doesn=E2=80=99t matter, if the = certificate was already > issued and the user can not change things anymore, but the software = that > retrieves a certificate from DNS still can validate (and in my opinion = MUST > validate) certain things. Not only keyUsage, also not before and not = after date > validity). So every software MUST do sanity checks. Complete and total agreement on this. I was responding to the fact that = people seemed to be wanting to change this information to control things = when publishing this information in the SMIMEA records. Jim >=20 > Sorry, if I should have misunderstood you :-) >=20 > Christian From nobody Mon Apr 6 14:49:24 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EEB41ACD53 for ; Mon, 6 Apr 2015 14:49:22 -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 qKE6u-YF9pUd for ; Mon, 6 Apr 2015 14:49:20 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4DEC1ACD4F for ; Mon, 6 Apr 2015 14:49:20 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 8CD23283032; Mon, 6 Apr 2015 21:49:13 +0000 (UTC) Date: Mon, 6 Apr 2015 21:49:13 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150406214913.GZ17637@mournblade.imrryr.org> References: <2E2E6A49-3ED5-49A7-A263-54D8F1B8EE95@roessner-network-solutions.com> <4B7FCFB2-F91C-4C43-B121-F53ADA63E328@verisign.com> <20150402171241.GD17637@mournblade.imrryr.org> <24051EA3-88B5-4D29-9900-7B49A672000D@verisign.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dane] Updated draft-ietf-dane-openpgpkey 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, 06 Apr 2015 21:49:22 -0000 On Mon, Apr 06, 2015 at 08:46:18AM -0400, Doug Montgomery wrote: > Part of the issue here is that we have large enterprise identity management > systems that issue credentials for security functions, but independent of > application. So while the EKU bits say that a CERT is useful for > encryption, it does not say if that is for file encryption, disk > encryption, or email encryption. Public keys in the form of certificates can be obtained by MUAs from a variety of sources. For example, they may be obtained and cached from a signed email. If the key usa supports encryption, the MUA may attempt to encrypt email replies to the sender. It seems odd to communicate the requisite key usage information via DANE records but fail to communicate it via other channels. So I would suggest that the usage bits be in the certificate, regardless of transport. -- Viktor. From nobody Tue Apr 7 03:53:23 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 393C11B3423 for ; Tue, 7 Apr 2015 03:53:22 -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 d0C8HEMHiqKj for ; Tue, 7 Apr 2015 03:53:19 -0700 (PDT) Received: from mango.plexis.eu (mango.plexis.eu [77.72.150.82]) by ietfa.amsl.com (Postfix) with ESMTP id 846951B3421 for ; Tue, 7 Apr 2015 03:53:18 -0700 (PDT) Received: from [192.168.1.39] (82-170-91-193.ip.telfort.nl [82.170.91.193]) by mango.plexis.eu (Postfix) with ESMTPSA id BBA601F3 for ; Tue, 7 Apr 2015 12:53:16 +0200 (CEST) Message-ID: <5523B71C.6030100@powerdns.com> Date: Tue, 07 Apr 2015 12:53:16 +0200 From: Pieter Lexis User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.5.0 MIME-Version: 1.0 To: dane@ietf.org References: <744A4EA3-F138-4D5D-AE98-AA56A75E18B3@vpnc.org> In-Reply-To: <744A4EA3-F138-4D5D-AE98-AA56A75E18B3@vpnc.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dane] Proposed design for draft-ietf-dane-openpgpkey (and then for draft-ietf-dane-smime) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2015 10:53:22 -0000 Hi, On 04/06/2015 03:22 AM, Paul Hoffman wrote: > - Lookup of OpenPGP and S/MIME keys and certs in the DNS are > exact-match, following the DNS's database model. This is known to > possibly fail when the party looking up the address has a copy of the > email address different than what might be entered in the zone, such > as with different casing. There is no expectation in this design that > all variants that might be delivered to for a particular address will > have key records. This design keeps the security model > understandable: it's all authenticated just by DNSSEC. Yes, if that is made explicit in the draft, it won't lead to false assumptions by implementors. The draft does need some information on UIDs on the keys and whether or not to match the recipients address against them. > - Discovery of delivery variants is better handled by a more flexible > protocol, such as WebFinger. In fact, instead of just looking for > variants and then coming back to the DNS to get the key, that > protocol can instead hand back the keys and certs directly in a > single response. The security model for that protocol would also be > simple: it's all authenticated by the TLS cert of the server. This > new protocol should probably be designed somewhere in the > Applications Area, not here, even though some of what is being > delivered are objects similar to what we are delivering here. Agreed, I started a write-up for a somewhat generic 'email metadata' lookup mechanism with the intention of grabbing OpenPGP and S/MIME data via webfinger. I hope to have an initial version done this week. > If folks agree with this proposal, we can move forwards with > draft-ietf-dane-openpgpkey pretty much as it is. (PaulW: you threw in > downcasing before hashing, which is definitely not what people agreed > to at the meeting.) For draft-ietf-dane-smime, we can then use the > same format and semantics, and add in the LDAP access model proposed > by Eric and Scott, which historically has never applied to OpenPGP. Yes, with the remarks above :). Regards, Pieter From nobody Fri Apr 10 06:43:06 2015 Return-Path: X-Original-To: expand-draft-ietf-dane-srv.all@virtual.ietf.org Delivered-To: dane@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 0C8781B3620; Thu, 9 Apr 2015 16:08:40 -0700 (PDT) X-Original-To: xfilter-draft-ietf-dane-srv.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-dane-srv.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD9701B35F1; Thu, 9 Apr 2015 16:08:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 V4IJxMZkIssp; Thu, 9 Apr 2015 16:08:33 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7AC01B35F6; Thu, 9 Apr 2015 16:08:29 -0700 (PDT) X-AuditID: c6180641-f790b6d000004359-63-5526a3b15f14 Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 79.D4.17241.1B3A6255; Thu, 9 Apr 2015 18:07:14 +0200 (CEST) Received: from eusjgala119.dyn.sj.us.am.ericsson.se (147.117.188.8) by smtp-am.internal.ericsson.com (147.117.188.77) with Microsoft SMTP Server id 14.3.210.2; Thu, 9 Apr 2015 19:08:28 -0400 From: Wassim Haddad Content-Type: multipart/alternative; boundary="Apple-Mail=_F6A35F91-2320-4CB2-B6CD-18CB5FB695B3" Date: Thu, 9 Apr 2015 16:09:24 -0700 Message-ID: To: General Area Review MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprCLMWRmVeSWpSXmKPExsUyuXSPt+6mxWqhBn9nsFl8mPeN3eLqq88s DkweS5b8ZApgjOKySUnNySxLLdK3S+DKeLH6LlvBHeGK0/+msTQwrhXsYuTkkBAwkXjyfR47 hC0mceHeerYuRi4OIYGjjBIn905hhnAOMUrcOP2FCaSKTcBA4uvys6wgNrNAksTaz8sYQWxh AWuJ7x8ngU1iEVCRONZ0jgXE5hWwl/g+sZUNoj5E4taz18wgtoiAlkTz6o9sEDUGEse//2SB uEJe4sOH42BzhATUJabcmsAygZFvFpJ1s5C0QMS1JZYtfM0MYetILNj9iQ1TXFvizIHHTAsY 2VYxcpQWp5blphsZbmIEBuMxCTbHHYwLPlkeYhTgYFTi4X2wRDVUiDWxrLgy9xCjNAeLkjhv 2ZWDIUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoYzXd5ab71+cqUq8L4cO3xpscrm8NYCqw5 zWewuX+vVxL6xXhqo5Ceo+J3vvN714op+t3jaV+VIrdQk1ks4GhcUFya+CqurT18p37877t1 d5LJp7QKhbl2P+8+FLOznmJYs+O9z6HTV/3kfife+Xz54K0nv4zKsieaWpQdn//vRerCbeXi exrNlViKMxINtZiLihMBb+4p0icCAAA= Archived-At: X-Mailman-Approved-At: Fri, 10 Apr 2015 06:43:04 -0700 Cc: draft-ietf-dane-srv.all@ietf.org Subject: [dane] [Gen-art] Gen-ART Review of draft-ietf-dane-srv-12 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, 09 Apr 2015 23:08:40 -0000 --Apple-Mail=_F6A35F91-2320-4CB2-B6CD-18CB5FB695B3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" I am the assigned Gen-ART reviewer for this draft. For background on = Gen-ART,=20 please see the FAQ at = Document: draft-ietf-dane-srv-12 Reviewer: Wassim Haddad Review Date: 09 April 2015 IETF LC End Date: 17 April 2015 IETF Telechat Date: unknown Summary: This draft is ready for publication as proposed RFC - Major Issues: None - Minor Issues: None Regards, Wassim H. --Apple-Mail=_F6A35F91-2320-4CB2-B6CD-18CB5FB695B3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="us-ascii" 
I am the assigned =
Gen-ART reviewer for this draft. For background on =
Gen-ART, 
please see the FAQ at <http://wi=
ki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>

Document:&nb=
sp;draft-ietf-dane-srv-12
Reviewer:  Wassim =
Haddad
Review Date: 09 April 2015
IETF LC End Date: 17 April =
2015
IETF Telechat Date: unknown

Summary:  This draft is =
ready for publication as proposed RFC

- Major Issues: None

- Minor =
Issues: None


Regards,

Wassim =
H.



= --Apple-Mail=_F6A35F91-2320-4CB2-B6CD-18CB5FB695B3-- From nobody Mon Apr 13 15:05:52 2015 Return-Path: X-Original-To: expand-draft-ietf-dane-srv.all@virtual.ietf.org Delivered-To: dane@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id BD0CA1A88D8; Mon, 13 Apr 2015 14:41:54 -0700 (PDT) X-Original-To: xfilter-draft-ietf-dane-srv.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-dane-srv.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D31F1A88D4 for ; Mon, 13 Apr 2015 14:41:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.879 X-Spam-Level: X-Spam-Status: No, score=-0.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021] 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 NQkYzD8PlibS for ; Mon, 13 Apr 2015 14:41:52 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6FFA1A88C1 for ; Mon, 13 Apr 2015 14:41:52 -0700 (PDT) Received: from smtp01.icann.org ([192.0.33.81]:39193 helo=smtp1.lax.icann.org) by zinfandel.tools.ietf.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Yhm75-0004Ar-Ti for draft-ietf-dane-srv.all@tools.ietf.org; Mon, 13 Apr 2015 14:41:52 -0700 Received: from request3.lax.icann.org (request1.lax.icann.org [10.32.11.221]) by smtp1.lax.icann.org (8.13.8/8.13.8) with ESMTP id t3DLfOHJ025518; Mon, 13 Apr 2015 21:41:24 GMT Received: by request3.lax.icann.org (Postfix, from userid 48) id E6D08C20812; Mon, 13 Apr 2015 21:41:24 +0000 (UTC) RT-Owner: amanda.baber From: "Amanda Baber via RT" In-Reply-To: <20150404020752.21750.22113.idtracker@ietfa.amsl.com> References: <20150404020752.21750.22113.idtracker@ietfa.amsl.com> Message-ID: X-RT-Loop-Prevention: IANA X-RT-Ticket: IANA #817123 X-Managed-BY: RT 4.2.9 (http://www.bestpractical.com/rt/) X-RT-Originator: amanda.baber@icann.org Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Precedence: bulk Date: Mon, 13 Apr 2015 21:41:24 +0000 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-SA-Exim-Connect-IP: 192.0.33.81 X-SA-Exim-Rcpt-To: draft-ietf-dane-srv.all@tools.ietf.org X-SA-Exim-Mail-From: iana-shared@icann.org X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Resent-To: draft-ietf-dane-srv.all@ietf.org Resent-Message-Id: <20150413214152.E6FFA1A88C1@ietfa.amsl.com> Resent-Date: Mon, 13 Apr 2015 14:41:52 -0700 (PDT) Resent-From: iana-shared@icann.org Archived-At: Archived-At: X-Mailman-Approved-At: Mon, 13 Apr 2015 15:05:51 -0700 Cc: draft-ietf-dane-srv.all@tools.ietf.org, iesg@ietf.org Subject: [dane] [IANA #817123] Last Call: (Using DNS-Based Authentication of Named Entities (DANE) TLSA Records with SRV Records) to Internet Standard X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Reply-To: drafts-lastcall@iana.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2015 21:41:54 -0000 (BEGIN IANA LAST CALL COMMENTS) IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-dane-srv-12, which is currently in Last Call, and has the following comments: We understand that this document doesn't require any IANA actions. While it is helpful for the IANA Considerations section of the document to remain in place upon publication, if the authors prefer to remove it, IANA doesn't object. If this assessment is not accurate, please respond as soon as possible. Thanks, Amanda Baber IANA Request Specialist ICANN (END IANA LAST CALL COMMENTS) On Sat Apr 04 02:08:17 2015, iesg-secretary@ietf.org wrote: > > The IESG has received a request from the DNS-based Authentication of > Named Entities WG (dane) to consider the following document: > - 'Using DNS-Based Authentication of Named Entities (DANE) TLSA Records > with SRV Records' > as Internet Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2015-04-17. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > > The DANE specification (RFC 6698) describes how to use TLSA resource > records secured by DNSSEC (RFC 4033) to associate a server's > connection endpoint with its TLS certificate. However, application > protocols that use SRV records (RFC 2782) to indirectly name the > target server connection endpoints for a service domain cannot apply > the rules from RFC 6698. Therefore this document provides guidelines > that enable such protocols to locate and use TLSA records. > > > > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-dane-srv/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-dane-srv/ballot/ > > > No IPR declarations have been submitted directly on this I-D. > > From nobody Mon Apr 13 15:06:26 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C4071ABD35; Mon, 13 Apr 2015 15:06:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QPCu3Gkf7Xzc; Mon, 13 Apr 2015 15:06:24 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E0D9B1A9250; Mon, 13 Apr 2015 15:06:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , , X-Test-IDTracker: no X-IETF-IDTracker: 6.0.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150413220607.32229.92947.idtracker@ietfa.amsl.com> Date: Mon, 13 Apr 2015 15:06:07 -0700 From: IETF Secretariat Archived-At: Subject: [dane] ID Tracker State Update Notice: X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2015 22:06:25 -0000 IANA review state changed to IANA OK - No Actions Needed ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-dane-srv/ From nobody Wed Apr 15 07:32:03 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43BED1B3596; Wed, 15 Apr 2015 07:32:01 -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 EDhLu3q3cszV; Wed, 15 Apr 2015 07:31:59 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B980B1B35AA; Wed, 15 Apr 2015 07:31:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150415143155.13985.46691.idtracker@ietfa.amsl.com> Date: Wed, 15 Apr 2015 07:31:55 -0700 Archived-At: Cc: dane@ietf.org Subject: [dane] I-D Action: draft-ietf-dane-srv-13.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2015 14:32:01 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS-based Authentication of Named Entities Working Group of the IETF. Title : Using DNS-Based Authentication of Named Entities (DANE) TLSA Records with SRV Records Authors : Tony Finch Matthew Miller Peter Saint-Andre Filename : draft-ietf-dane-srv-13.txt Pages : 15 Date : 2015-04-15 Abstract: The DANE specification (RFC 6698) describes how to use TLSA resource records secured by DNSSEC (RFC 4033) to associate a server's connection endpoint with its TLS certificate. However, application protocols that use SRV records (RFC 2782) to indirectly name the target server connection endpoints for a service domain cannot apply the rules from RFC 6698. Therefore this document provides guidelines that enable such protocols to locate and use TLSA records. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dane-srv/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dane-srv-13 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-dane-srv-13 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Apr 15 07:32:10 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B3E31B35A0; Wed, 15 Apr 2015 07:32:02 -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 PY8UgL7vRxOr; Wed, 15 Apr 2015 07:32:01 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C92D61B35AC; Wed, 15 Apr 2015 07:31:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: , , , , , , X-Test-IDTracker: no X-IETF-IDTracker: 6.0.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150415143155.13985.21167.idtracker@ietfa.amsl.com> Date: Wed, 15 Apr 2015 07:31:55 -0700 Archived-At: Subject: [dane] New Version Notification - draft-ietf-dane-srv-13.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2015 14:32:02 -0000 A new version (-13) has been submitted for draft-ietf-dane-srv: http://www.ietf.org/internet-drafts/draft-ietf-dane-srv-13.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-dane-srv/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-dane-srv-13 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. IETF Secretariat. From nobody Thu Apr 16 08:28:05 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96BF71A893B for ; Thu, 16 Apr 2015 08:28:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q6qDCgp22rOM for ; Thu, 16 Apr 2015 08:28:02 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C8151A8A04 for ; Thu, 16 Apr 2015 08:27:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 81FB7BF02 for ; Thu, 16 Apr 2015 16:27:32 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O48yRe2mfbZY for ; Thu, 16 Apr 2015 16:27:32 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 5459CBEFF for ; Thu, 16 Apr 2015 16:27:32 +0100 (IST) Message-ID: <552FD4E5.8080407@cs.tcd.ie> Date: Thu, 16 Apr 2015 16:27:33 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: dane OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [dane] AD review of draft-ietf-dane-smtp-with-dane X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2015 15:28:04 -0000 Hiya, Sorry for being slow with this but I've finally gotten my AD review for this done. (See below.) A couple of things to check before starting IETF LC: (1) What is the behaviour when all RRs required for this are published except for no DNSSEC RRs? I have heard tell of some people who would like to experiment in that way, and would like to know if the WG have a clear answer for them as to what ought happen. Is that answer here? (If so, it's fairly well hidden;-) (2) Doesn't this need to be consistent with other recent IETF documents, in particular the generic UTA BCP and deprecating SSL 3.0? I don't believe it current is entirely consistent with either. (See minor comments below for details.) Why is that ok? The rest (below) are more minor comments, please treat these as IETF LC comments. Cheers, S. - intro: end of 1st para could reference rfc7435, just to be sure that the opportunistic term is well defined in this context - 1.2, 2nd para: s/trusted public keys/public keys/ - 1.2, 2nd para: s/a new/the/ - 1.2, 3rd para: s/directly delegated/delegated/ - 1.2, 3rd para: s/data integrity/data origin authentication/ TLS provides data integrity for application PDUs in all cases - 1.3, 2nd para: s/traditional PKI/traditional Web PKI/ - 1.3.1, s/such as the use of PKIX// I don't think that says anything really and I've no clue what "use of PKIX" might mean exactly - better left out I'd say - 1.3.2, s/A PKIX TLS client/A TLS client/ - 1.3.2, The MX lookup is vulnerable as stated but isn't the A/AAAA similarly vulnerable? I think you ought note that too, but also that this specification can mean that DNSSEC for that lookup is not needed based on the name in the MX response being bound (via x.509 or tlsa) to the TLS server private key. (Well, that assumes I've gotten that correct:-) Without DNSSEC for the MX name->address mapping a bad actor could however, insert themselves into the path and gain whatever can be gained via traffic analysis of the SMTP/TLS session. - 2.1.1, 2nd para: s/must be used/MUST be used/? Not sure myself, but I'd make it uppercase for emphasis. (Other people will disagree from all points of view though, no matter what you do or don't do here;-) - 2.1.1, the term anchorless should probbaly get a mention in 1.1 with a forward pointer to 2.1.1. Or maybe you can avoid the term since it's not used much. (Just in 2 adjacent paragraphs.) - 2.1.1, what does "securely opted out" mean? - 2.2, I'd re-phrase "A connection to the MTA MUST be made using authenticated and encrypted TLS" as "Any connection to the MTA MUST be made using authenticated and encrypted TLS" The current text could be read to say that the client MUST make the connection, whereas I think you just mean if you do make a connection it MUST use TLS. - 2.2, Could "authenticated" here mean mutually authenticated with TLS client certs? If not, maybe say so. (And for the last sentence before 2.2.1, what about the client cert names - what's done with those?) - 2.2, 3rd bullet: Is it a good idea to mix the insecure TLSA RRSet and validated non-existence in one bullet? I find it confusing. Maybe it'd be better to have two bullets even if the new one says "do as above." - 2.2.1, last para: What is the other, to which the "Otherwise" at the start of the para applies? That confused me. - 2.2.2: bullet 1 - what's that mean? (In this context) This section generally has a bunch of paragraphs that start with a conditional, and it's not clear how they all fit. Could you add some more structure (e.g. pseudo-code) to clarify? - 3.1: All but the first and last two paras of this seem to be repetitive of 6698 and 7218. I don't see that it's a good idea to do that. (In what is already an over-long document.) - 3.1.2 - does the MUST include TA in the TLS handshake conflict with common implementations of 5246? 5246 section 7.4.2, says that the TA MAY be omitted, but I wonder if we might be causing ourselves trouble (some) with running code. - 3.1.3, last sentence: is that needed? It seems to invalidate the sentence before. (And it's vague.) - 3.2.2, various places: "MUST be included" where? - 8.1, para 1: We've (the IETF) just deprecated SSL 3.0, [1] so don't you need to reference that and say to not do that? At least the MAY at the end of that paragraph seems not to conform with the BCP. I think a ref to [1] is needed. [1] https://tools.ietf.org/html/draft-ietf-tls-sslv3-diediedie - 8.2: This is alrady handled by the generic UTA BCP. Why is it needed here? - 9.2, 2nd para: isn't that repetitive? That seems like a bad idea. From nobody Thu Apr 16 08:33:54 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE9CA1A8A8B; Thu, 16 Apr 2015 08:33:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=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 kuV6iLN7dq3B; Thu, 16 Apr 2015 08:33:51 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 44EF01A9006; Thu, 16 Apr 2015 08:32:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , , , , X-Test-IDTracker: no X-IETF-IDTracker: 6.0.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150416153253.23648.16043.idtracker@ietfa.amsl.com> Date: Thu, 16 Apr 2015 08:32:53 -0700 From: IETF Secretariat Archived-At: Subject: [dane] Telechat update notice: X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2015 15:33:52 -0000 Placed on agenda for telechat - 2015-04-23 ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-dane-srv/ From nobody Thu Apr 16 10:37:32 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD1F41B3368 for ; Thu, 16 Apr 2015 10:37:30 -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 vzkHeSHB5gIx for ; Thu, 16 Apr 2015 10:37:27 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFEC81B335F for ; Thu, 16 Apr 2015 10:37:24 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 3E1F1283032; Thu, 16 Apr 2015 17:37:23 +0000 (UTC) Date: Thu, 16 Apr 2015 17:37:23 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150416173722.GG17637@mournblade.imrryr.org> References: <552FD4E5.8080407@cs.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <552FD4E5.8080407@cs.tcd.ie> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dane] AD review of draft-ietf-dane-smtp-with-dane 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, 16 Apr 2015 17:37:30 -0000 On Thu, Apr 16, 2015 at 04:27:33PM +0100, Stephen Farrell wrote: > (1) What is the behaviour when all RRs required for this are > published except for no DNSSEC RRs? I have heard tell of some > people who would like to experiment in that way, and would > like to know if the WG have a clear answer for them as to > what ought happen. Is that answer here? (If so, it's fairly > well hidden;-) The specified and implemented (Postfix and Exim) behaviour is that the records are ignored when not "secure". Thus DNSSEC is a prerequisite. Opportunistic TLS happens anyway (even without TLSA record validation), so it is not clear why one would bother with incomplete (easily defeated) attempts at protecting against active attacks. > (2) Doesn't this need to be consistent with other recent IETF > documents, in particular the generic UTA BCP and deprecating > SSL 3.0? I don't believe it current is entirely consistent > with either. (See minor comments below for details.) Why is > that ok? This is an opportunistic protocol, hence some security is better than none. If all that the server has is SSL 3.0, it can still publish TLSA RRs, and POODLE et. al, are primary attacks on HTTPS not SMTP. In any case this draft was ready (and has been largely unchanged) for about a year now, *before* all the fuss about SSL 3.0. Clients MUST support at least TLS 1.0 (to use SNI). Servers MAY support SSL 3.0 (allowing them to publish TLSA RRs with whatever they're running today). At this point we can set the floor at TLS 1.0 if that's better "optics", the number of servers doing just SSL 3.0, whose admins might be tempted to publish DANE TLSA RRs is likely zero. There is no reason to require anything beyond SSL 3.0 (server-side) in this protocol, and it does not preclude other documents from setting a higher bar. > The rest (below) are more minor comments, please treat these > as IETF LC comments. > Responding to a subset, leaving out mostly editorial fixes. > - 1.3.2, The MX lookup is vulnerable as stated but isn't the > A/AAAA similarly vulnerable? I think you ought note that too, > but also that this specification can mean that DNSSEC for > that lookup is not needed based on the name in the MX > response being bound (via x.509 or tlsa) to the TLS server > private key. (Well, that assumes I've gotten that correct:-) > Without DNSSEC for the MX name->address mapping a bad actor > could however, insert themselves into the path and gain > whatever can be gained via traffic analysis of the SMTP/TLS > session. The address records are not security relevant. MX is because authenticating the origin domain does not work, and the MX, absent DNSSEC, is insecure (but widely done anyway). While, the A records don't a-priori need to be secured, we skip TLSA records for MX hosts whose A/AAAA records are "insecure" in order to avoid interop problems with (Microsoft's and similar) domains whose non-DNSSEC nameservers are allergic to unsupported RRtypes (the "mail.protection.outlook.com" nameservers botch TLSA queries). Traffic hijacking can be done with BGP (this is far more common, and is more difficult to observe) even without changing the addresses. Or by tapping into the cables. > - 2.1.1, the term anchorless should probably get a mention in > 1.1 with a forward pointer to 2.1.1. Or maybe you can avoid > the term since it's not used much. (Just in 2 adjacent > paragraphs.) Yeah, that's a bit tricky, just need some way to avoid local repetition and to make it clear when we're describing the "4034" type of "indeterminate" once the definition of the term is aligned with "4035". Specific suggestions welcome, if this is important to "fix". > - 2.1.1, what does "securely opted out" mean? That's about a parent domain providing proof of non-existence of DS records, possibly with NSEC or NSEC3 for the domain itself, or perhaps via NSEC3 for neighbour domains with the opt-out bit set. Thus the domain is an "insecure" sub-domain of a "secure" parent domain. I'm open to better language if the current is confusing. > - 2.2, Could "authenticated" here mean mutually authenticated > with TLS client certs? If not, maybe say so. (And for the > last sentence before 2.2.1, what about the client cert names > - what's done with those?) There is no protocol for specifying mutual authentication until someone (I volunteered) writes the DANE draft for locating client TLSA RRs and how that works for SMTP. Some of the signaling (client -> server: please check for my TLSA records) will be application protocol specific. > - 3.1.2 - does the MUST include TA in the TLS handshake > conflict with common implementations of 5246? 5246 section > 7.4.2, says that the TA MAY be omitted, but I wonder if we > might be causing ourselves trouble (some) with running code. No, this is not a conflict. 5246 allows a shorter chain, but does not require it. With DANE the "optimization" is not available. Since verification without the TA cert is impossible, there is no choice. The requirement is a statement of logical fact, not a design choice. Running code is working just fine. The only real consequence is that some Microsoft (surprise?) Exchange servers reportedly can't actually add self-signed certs to their chain, so if they use a DANE-TA(2) trust anchor, it needs to be an intermediate. [ Either the admin tooling, Schannel, or something else in the stack does not make it possible to specify a server chain that includes a root CA. ] > - 8.1, para 1: We've (the IETF) just deprecated SSL 3.0, [1] > so don't you need to reference that and say to not do that? > At least the MAY at the end of that paragraph seems not to > conform with the BCP. I think a ref to [1] is needed. > > [1] https://tools.ietf.org/html/draft-ietf-tls-sslv3-diediedie See above. The BCP does not claim applicability to opportunistic TLS. This protocol is (still) opportunistic TLS, but with authentication not just unauthenticated encryption. However, at this point SSL 3.0 has largely been phased out, so raising the bar to TLS 1.0 would have little practical effect. Server operators will ignore whatever we say here anyway and will support whatever they support. So whatever you want for "optics" is fine, though I still don't like erecting needless hurdles as a matter of principle. > - 8.2: This is already handled by the generic UTA BCP. Why is > it needed here? I don't see any discussion of anon-DH in the UTA BCP (which in any case disclaims applicability to opportunistic TLS). > - 9.2, 2nd para: isn't that repetitive? That seems like a bad > idea. Are we looking at the same draft version? Perhaps your 8.2/9.2 is not what I'm looking at (version 15). -- Viktor. From nobody Thu Apr 16 10:50:59 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A0231B33BF for ; Thu, 16 Apr 2015 10:50:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lfaa2lzpiYtg for ; Thu, 16 Apr 2015 10:50:56 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA9DB1B33D4 for ; Thu, 16 Apr 2015 10:50:49 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3lSSl91s9hz1Hm for ; Thu, 16 Apr 2015 19:50:45 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=pI9W3N7I X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id fowXgbOVaM9b for ; Thu, 16 Apr 2015 19:50:44 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for ; Thu, 16 Apr 2015 19:50:44 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 74B9D803E0 for ; Thu, 16 Apr 2015 13:50:43 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1429206643; bh=iKsc04LQUXWpuYZgay2iPedwXV8ui8k7FwRPGNSQz4s=; h=Date:From:To:Subject:In-Reply-To:References; b=pI9W3N7IgA5UeIh9GDZOnU7xMdW2xEGTrSzKAd9jdNHXNiTWSMXmVbZygkd1TB25A fQqdxamlZpA0rC/Xo0ZF8vfDchK6YS9CaM/heRXdIcTs1xmLt/b9YMuNT0BzA2Oi/Y 3sKqqwVgZmzCtAfPSKF2Z0vZ0dLlSX91jVvGJfJA= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id t3GHohtT003443 for ; Thu, 16 Apr 2015 13:50:43 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Thu, 16 Apr 2015 13:50:42 -0400 (EDT) From: Paul Wouters To: dane@ietf.org In-Reply-To: <20150416173722.GG17637@mournblade.imrryr.org> Message-ID: References: <552FD4E5.8080407@cs.tcd.ie> <20150416173722.GG17637@mournblade.imrryr.org> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dane] AD review of draft-ietf-dane-smtp-with-dane X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2015 17:50:58 -0000 On Thu, 16 Apr 2015, Viktor Dukhovni wrote: > In any case this draft was ready (and has been largely unchanged) > for about a year now, *before* all the fuss about SSL 3.0. Clients > MUST support at least TLS 1.0 (to use SNI). Servers MAY support > SSL 3.0 (allowing them to publish TLSA RRs with whatever they're > running today). At this point we can set the floor at TLS 1.0 if > that's better "optics", the number of servers doing just SSL 3.0, > whose admins might be tempted to publish DANE TLSA RRs is likely > zero. DANE should not say which TLS version to use. Leave that up to the TLS working group ? Paul From nobody Thu Apr 16 10:59:47 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1F771B33B4 for ; Thu, 16 Apr 2015 10:59:45 -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 dYRamJWLL_SS for ; Thu, 16 Apr 2015 10:59:44 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16E461B33F9 for ; Thu, 16 Apr 2015 10:59:44 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 32C2F283032; Thu, 16 Apr 2015 17:59:37 +0000 (UTC) Date: Thu, 16 Apr 2015 17:59:37 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150416175936.GH17637@mournblade.imrryr.org> References: <552FD4E5.8080407@cs.tcd.ie> <20150416173722.GG17637@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dane] AD review of draft-ietf-dane-smtp-with-dane 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, 16 Apr 2015 17:59:46 -0000 On Thu, Apr 16, 2015 at 01:50:42PM -0400, Paul Wouters wrote: > On Thu, 16 Apr 2015, Viktor Dukhovni wrote: > > >In any case this draft was ready (and has been largely unchanged) > >for about a year now, *before* all the fuss about SSL 3.0. Clients > >MUST support at least TLS 1.0 (to use SNI). Servers MAY support > >SSL 3.0 (allowing them to publish TLSA RRs with whatever they're > >running today). At this point we can set the floor at TLS 1.0 if > >that's better "optics", the number of servers doing just SSL 3.0, > >whose admins might be tempted to publish DANE TLSA RRs is likely > >zero. > > DANE should not say which TLS version to use. Leave that up to the TLS > working group ? Well, since the client MUST SNI, it must support at least TLS 1.0 and send an SSL 3.0 compatible HELLO (so SSL 2.0 is definitely out). Therefore, the server logically needs to support at least SSL 3.0, which is what I said, but perhaps as you note silence may suffice. So, should we not mention TLS versions at all, and just mention SNI, with the reader making the "obvious" conclusions? I prefer to make things explicit so that implementations don't make silly mistakes. -- Viktor. From nobody Thu Apr 16 11:06:20 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05CB91B2EC4; Thu, 16 Apr 2015 11:06:18 -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 sImgBld7OTdq; Thu, 16 Apr 2015 11:06:15 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DD8A1B2EA9; Thu, 16 Apr 2015 11:06:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , , X-Test-IDTracker: no X-IETF-IDTracker: 6.0.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150416180612.23655.86322.idtracker@ietfa.amsl.com> Date: Thu, 16 Apr 2015 11:06:12 -0700 From: IETF Secretariat Archived-At: Subject: [dane] ID Tracker State Update Notice: X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2015 18:06:18 -0000 IANA review state changed to IANA OK - No Actions Needed ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-dane-srv/ From nobody Thu Apr 16 11:29:18 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A6A01B342E for ; Thu, 16 Apr 2015 11:29:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rQEBLh1LUJhl for ; Thu, 16 Apr 2015 11:29:12 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FAA21B2F0D for ; Thu, 16 Apr 2015 11:29:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 7DFA7BEFC for ; Thu, 16 Apr 2015 19:29:09 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9J9e9QS0lA2y for ; Thu, 16 Apr 2015 19:29:06 +0100 (IST) Received: from [10.87.48.73] (unknown [86.41.51.113]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 39408BE8E for ; Thu, 16 Apr 2015 19:29:06 +0100 (IST) Message-ID: <552FFF6A.2040305@cs.tcd.ie> Date: Thu, 16 Apr 2015 19:28:58 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: dane@ietf.org References: <552FD4E5.8080407@cs.tcd.ie> <20150416173722.GG17637@mournblade.imrryr.org> In-Reply-To: <20150416173722.GG17637@mournblade.imrryr.org> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dane] AD review of draft-ietf-dane-smtp-with-dane X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2015 18:29:16 -0000 Hiya, On 16/04/15 18:37, Viktor Dukhovni wrote: > On Thu, Apr 16, 2015 at 04:27:33PM +0100, Stephen Farrell wrote: > >> (1) What is the behaviour when all RRs required for this are >> published except for no DNSSEC RRs? I have heard tell of some >> people who would like to experiment in that way, and would >> like to know if the WG have a clear answer for them as to >> what ought happen. Is that answer here? (If so, it's fairly >> well hidden;-) > > The specified and implemented (Postfix and Exim) behaviour is that > the records are ignored when not "secure". Thus DNSSEC is a > prerequisite. Opportunistic TLS happens anyway (even without TLSA > record validation), so it is not clear why one would bother with > incomplete (easily defeated) attempts at protecting against active > attacks. My understanding is that some people wanted to experiment with TLSA without having to have had DNSSEC deployed. But I take your answer to be that no such behaviour is defined here, which is fine. So consider this one answered. > >> (2) Doesn't this need to be consistent with other recent IETF >> documents, in particular the generic UTA BCP and deprecating >> SSL 3.0? I don't believe it current is entirely consistent >> with either. (See minor comments below for details.) Why is >> that ok? > > This is an opportunistic protocol, hence some security is better > than none. If all that the server has is SSL 3.0, it can still > publish TLSA RRs, and POODLE et. al, are primary attacks on HTTPS > not SMTP. > > In any case this draft was ready (and has been largely unchanged) > for about a year now, *before* all the fuss about SSL 3.0. Clients > MUST support at least TLS 1.0 (to use SNI). Servers MAY support > SSL 3.0 (allowing them to publish TLSA RRs with whatever they're > running today). At this point we can set the floor at TLS 1.0 if > that's better "optics", the number of servers doing just SSL 3.0, > whose admins might be tempted to publish DANE TLSA RRs is likely > zero. I see Paul has replied so I'll see how the discussion develops and join in later. A few bits more below on the non-blocking things. > > There is no reason to require anything beyond SSL 3.0 (server-side) > in this protocol, and it does not preclude other documents from > setting a higher bar. > >> The rest (below) are more minor comments, please treat these >> as IETF LC comments. >> > > Responding to a subset, leaving out mostly editorial fixes. > >> - 1.3.2, The MX lookup is vulnerable as stated but isn't the >> A/AAAA similarly vulnerable? I think you ought note that too, >> but also that this specification can mean that DNSSEC for >> that lookup is not needed based on the name in the MX >> response being bound (via x.509 or tlsa) to the TLS server >> private key. (Well, that assumes I've gotten that correct:-) >> Without DNSSEC for the MX name->address mapping a bad actor >> could however, insert themselves into the path and gain >> whatever can be gained via traffic analysis of the SMTP/TLS >> session. > > The address records are not security relevant. MX is because > authenticating the origin domain does not work, and the MX, > absent DNSSEC, is insecure (but widely done anyway). > > While, the A records don't a-priori need to be secured, we skip > TLSA records for MX hosts whose A/AAAA records are "insecure" in > order to avoid interop problems with (Microsoft's and similar) > domains whose non-DNSSEC nameservers are allergic to unsupported > RRtypes (the "mail.protection.outlook.com" nameservers botch > TLSA queries). > > Traffic hijacking can be done with BGP (this is far more common, > and is more difficult to observe) even without changing the addresses. > Or by tapping into the cables. So I think the threat is that someone who fakes the A record can do traffic analysis as they can direct the SMTP and STARTTLS traffic through their chosen host. I think that's work noting, in and of itself. If we had more to say (that's well founded) about traffic analysis if SMTP/TLS that'd be interesting but I'm not familiar with any work in the space (though I've not looked). > >> - 2.1.1, the term anchorless should probably get a mention in >> 1.1 with a forward pointer to 2.1.1. Or maybe you can avoid >> the term since it's not used much. (Just in 2 adjacent >> paragraphs.) > > Yeah, that's a bit tricky, just need some way to avoid local > repetition and to make it clear when we're describing the "4034" > type of "indeterminate" once the definition of the term is aligned > with "4035". Specific suggestions welcome, if this is important > to "fix". I'm fine if you just take a peek again and decide what to do. > >> - 2.1.1, what does "securely opted out" mean? > > That's about a parent domain providing proof of non-existence of > DS records, possibly with NSEC or NSEC3 for the domain itself, or > perhaps via NSEC3 for neighbour domains with the opt-out bit set. > Thus the domain is an "insecure" sub-domain of a "secure" parent > domain. I'm open to better language if the current is confusing. I think that's needed, or perhaps a reference. In my reading I never even considered DS RR's. Now that might be my relative ignorance of DNSSEC terminology, but that's a new one on me so please either define it if it's a neologism or else just add a reference if it's a know term of art. > >> - 2.2, Could "authenticated" here mean mutually authenticated >> with TLS client certs? If not, maybe say so. (And for the >> last sentence before 2.2.1, what about the client cert names >> - what's done with those?) > > There is no protocol for specifying mutual authentication until > someone (I volunteered) writes the DANE draft for locating client > TLSA RRs and how that works for SMTP. Some of the signaling > (client -> server: please check for my TLSA records) will be > application protocol specific. Could be worth saying that mutually authenticated TLS is out of scope so servers SHOULD (or MUST) NOT send a certificate request. > >> - 3.1.2 - does the MUST include TA in the TLS handshake >> conflict with common implementations of 5246? 5246 section >> 7.4.2, says that the TA MAY be omitted, but I wonder if we >> might be causing ourselves trouble (some) with running code. > > No, this is not a conflict. 5246 allows a shorter chain, > but does not require it. With DANE the "optimization" > is not available. > > Since verification without the TA cert is impossible, there is no > choice. The requirement is a statement of logical fact, not a > design choice. > > Running code is working just fine. The only real consequence is > that some Microsoft (surprise?) Exchange servers reportedly can't > actually add self-signed certs to their chain, so if they use a > DANE-TA(2) trust anchor, it needs to be an intermediate. [ Either > the admin tooling, Schannel, or something else in the stack does > not make it possible to specify a server chain that includes a root > CA. ] Ok, it's that latter I was after. If someone maintains that those specific server deployments are significant they can make that case during last call I guess. Ta. > >> - 8.1, para 1: We've (the IETF) just deprecated SSL 3.0, [1] >> so don't you need to reference that and say to not do that? >> At least the MAY at the end of that paragraph seems not to >> conform with the BCP. I think a ref to [1] is needed. >> >> [1] https://tools.ietf.org/html/draft-ietf-tls-sslv3-diediedie > > See above. The BCP does not claim applicability to opportunistic > TLS. This protocol is (still) opportunistic TLS, but with > authentication not just unauthenticated encryption. However, at > this point SSL 3.0 has largely been phased out, so raising the bar > to TLS 1.0 would have little practical effect. Server operators > will ignore whatever we say here anyway and will support whatever > they support. So whatever you want for "optics" is fine, though > I still don't like erecting needless hurdles as a matter of principle. I'll chime in later. > >> - 8.2: This is already handled by the generic UTA BCP. Why is >> it needed here? > > I don't see any discussion of anon-DH in the UTA BCP (which in any > case disclaims applicability to opportunistic TLS). Ditto. > >> - 9.2, 2nd para: isn't that repetitive? That seems like a bad >> idea. > > Are we looking at the same draft version? Perhaps your 8.2/9.2 is > not what I'm looking at (version 15). Sorry, I meant that lots of 9.2 repeats things said earlier in this document. Cheers, S. > From nobody Thu Apr 16 11:45:23 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AA5A1B3469 for ; Thu, 16 Apr 2015 11:45:21 -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 17H5MwsaYlCr for ; Thu, 16 Apr 2015 11:45:19 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACE681B3468 for ; Thu, 16 Apr 2015 11:45:19 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 2A009283032; Thu, 16 Apr 2015 18:45:18 +0000 (UTC) Date: Thu, 16 Apr 2015 18:45:18 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150416184517.GI17637@mournblade.imrryr.org> References: <552FD4E5.8080407@cs.tcd.ie> <20150416173722.GG17637@mournblade.imrryr.org> <552FFF6A.2040305@cs.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <552FFF6A.2040305@cs.tcd.ie> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dane] AD review of draft-ietf-dane-smtp-with-dane 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, 16 Apr 2015 18:45:21 -0000 On Thu, Apr 16, 2015 at 07:28:58PM +0100, Stephen Farrell wrote: > > While, the A records don't a-priori need to be secured, we skip > > TLSA records for MX hosts whose A/AAAA records are "insecure" in > > order to avoid interop problems with (Microsoft's and similar) > > domains whose non-DNSSEC nameservers are allergic to unsupported > > RRtypes (the "mail.protection.outlook.com" nameservers botch > > TLSA queries). > > > > Traffic hijacking can be done with BGP (this is far more common, > > and is more difficult to observe) even without changing the addresses. > > Or by tapping into the cables. > > So I think the threat is that someone who fakes the A record > can do traffic analysis as they can direct the SMTP and STARTTLS > traffic through their chosen host. I think that's work noting, > in and of itself. If we had more to say (that's well founded) > about traffic analysis if SMTP/TLS that'd be interesting but I'm > not familiar with any work in the space (though I've not looked). Note that for this protocol, both the address records and the TLSA records of the MX host are DNSSEC-validated, since when the address records are not, we don't even ask for the TLSA RRs. So I am not sure what you have in mind... When the MX host's DNS zone is signed, both the address and the TLSA records are signed, and off-path attackers don't get to use DNS to redirect the traffic to addresses that are on-path. They are of course still free to attempt to mess with the routing layer to whatever extent possible. > >> - 2.2, Could "authenticated" here mean mutually authenticated > >> with TLS client certs? If not, maybe say so. (And for the > >> last sentence before 2.2.1, what about the client cert names > >> - what's done with those?) > > > > There is no protocol for specifying mutual authentication until > > someone (I volunteered) writes the DANE draft for locating client > > TLSA RRs and how that works for SMTP. Some of the signaling > > (client -> server: please check for my TLSA records) will be > > application protocol specific. > > Could be worth saying that mutually authenticated TLS is out > of scope so servers SHOULD (or MUST) NOT send a certificate > request. Some SMTP servers send certificate requests anyway, most don't. Sending MTAs, most of which are not configured with client certs, just ignore the requests. Receiving MTAs complete the handshake even if no client certificats are sent, but don't grant whatever additional access rights one may get with some particular client cert (or simply can't, when absent, record any client cert details in "Received" headers or mail logs). So there's nothing really to say here, we're not changing the status quo in any way (yet). Once there's a protocol for client TLSA RRs, then there'll be something to say. -- Viktor. From nobody Thu Apr 16 12:10:43 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46BFF1A00DB for ; Thu, 16 Apr 2015 12:10:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fEws9CZgOs4Q for ; Thu, 16 Apr 2015 12:10:40 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDEFD1A040C for ; Thu, 16 Apr 2015 12:10:39 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3lSVWK2yLxz463; Thu, 16 Apr 2015 21:10:37 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=Ex5nhG/c X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id FkKCZFYLISY1; Thu, 16 Apr 2015 21:10:36 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Thu, 16 Apr 2015 21:10:36 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 0A6EF80416; Thu, 16 Apr 2015 15:10:35 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1429211435; bh=+nMg7aPqodNraDG3HpiB8tRNQsbaOHetP61EHcIFPrw=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=Ex5nhG/c7D7ZKRUQxU4HmEsdEPtn3ruRKr5LcXRem1jnn4MldMzxpQfz0MqO6wQWP UKru7RkFQGIrIQyzyYzSC79HHJOS6LwhfsSPcUQ2YeSxsFdKXVCH7LiWxjsPAJ11L4 TuoF7pWnClQ/jpNdMaNjehbBDAZwdWSCLo6Dxt3Q= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id t3GJAXps013810; Thu, 16 Apr 2015 15:10:34 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Thu, 16 Apr 2015 15:10:33 -0400 (EDT) From: Paul Wouters To: Stephen Farrell In-Reply-To: <552FFF6A.2040305@cs.tcd.ie> Message-ID: References: <552FD4E5.8080407@cs.tcd.ie> <20150416173722.GG17637@mournblade.imrryr.org> <552FFF6A.2040305@cs.tcd.ie> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: dane@ietf.org Subject: Re: [dane] AD review of draft-ietf-dane-smtp-with-dane X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2015 19:10:42 -0000 On Thu, 16 Apr 2015, Stephen Farrell wrote: > My understanding is that some people wanted to experiment with TLSA > without having to have had DNSSEC deployed. But I take your answer > to be that no such behaviour is defined here, which is fine. So > consider this one answered. I go back and forth with this one. It seems there is no good reason not to use an insecure trust anchor over no trust anchor, but the UI would have to be clearly different, which is where the real problem is I think. We could easilly use unsigned TLSA over completely unverified TLSA, but it would not be a good test because you cannot accept it as equal security in the UI without it becoming a downgrade attack. Those who want to test could add their zone to the DLV, at least for now - or configure a local trust anchor, if they are okay with a signed zone without DS record. Paul From nobody Thu Apr 16 12:36:58 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 248831B3564 for ; Thu, 16 Apr 2015 12:36:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aDCTS_wHn79M for ; Thu, 16 Apr 2015 12:36:54 -0700 (PDT) Received: from wizmail.org (wizmail.org [IPv6:2a00:1940:107::2:0:0]) (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 90BA41B3562 for ; Thu, 16 Apr 2015 12:36:54 -0700 (PDT) Received: from [46.33.133.68] (helo=lap.dom.ain) from_AS 51561 by wizmail.org with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.85_101-b3558d5) id 1Yipam-0000sK-Ct for dane@ietf.org (return-path ); Thu, 16 Apr 2015 19:36:52 +0000 Message-ID: <55300F53.6080103@wizmail.org> Date: Thu, 16 Apr 2015 20:36:51 +0100 From: Jeremy Harris User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: dane@ietf.org References: <552FD4E5.8080407@cs.tcd.ie> <20150416173722.GG17637@mournblade.imrryr.org> <552FFF6A.2040305@cs.tcd.ie> In-Reply-To: <552FFF6A.2040305@cs.tcd.ie> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Pcms-Received-Sender: [46.33.133.68] (helo=lap.dom.ain) Archived-At: Subject: Re: [dane] AD review of draft-ietf-dane-smtp-with-dane X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2015 19:36:56 -0000 On 16/04/15 19:28, Stephen Farrell wrote: >>> - 2.2, Could "authenticated" here mean mutually authenticated >>> with TLS client certs? If not, maybe say so. (And for the >>> last sentence before 2.2.1, what about the client cert names >>> - what's done with those?) >> >> There is no protocol for specifying mutual authentication until >> someone (I volunteered) writes the DANE draft for locating client >> TLSA RRs and how that works for SMTP. Some of the signaling >> (client -> server: please check for my TLSA records) will be >> application protocol specific. > > Could be worth saying that mutually authenticated TLS is out > of scope so servers SHOULD (or MUST) NOT send a certificate > request. This seems excessive; one could not then use both DANE/SMTP and some future specification for authenticating the client. Surely "out of scope" is sufficient? -- Jeremy From nobody Fri Apr 17 05:17:57 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ED881B2B90 for ; Fri, 17 Apr 2015 05:17:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rVr5KUpPkYqP for ; Fri, 17 Apr 2015 05:17:54 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AF491B2B87 for ; Fri, 17 Apr 2015 05:17:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 09B62BEEA; Fri, 17 Apr 2015 13:17:53 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AfNfgTatDpBK; Fri, 17 Apr 2015 13:17:52 +0100 (IST) Received: from [10.87.48.73] (unknown [86.46.17.62]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 7E2B5BF2A; Fri, 17 Apr 2015 13:17:45 +0100 (IST) Message-ID: <5530F9E9.108@cs.tcd.ie> Date: Fri, 17 Apr 2015 13:17:45 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Paul Wouters References: <552FD4E5.8080407@cs.tcd.ie> <20150416173722.GG17637@mournblade.imrryr.org> <552FFF6A.2040305@cs.tcd.ie> In-Reply-To: OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: dane@ietf.org Subject: Re: [dane] AD review of draft-ietf-dane-smtp-with-dane X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2015 12:17:55 -0000 On 16/04/15 20:10, Paul Wouters wrote: > On Thu, 16 Apr 2015, Stephen Farrell wrote: > >> My understanding is that some people wanted to experiment with TLSA >> without having to have had DNSSEC deployed. But I take your answer >> to be that no such behaviour is defined here, which is fine. So >> consider this one answered. > > I go back and forth with this one. It seems there is no good reason > not to use an insecure trust anchor over no trust anchor, but the UI > would have to be clearly different, which is where the real problem is > I think. We could easilly use unsigned TLSA over completely unverified > TLSA, but it would not be a good test because you cannot accept it as > equal security in the UI without it becoming a downgrade attack. > > Those who want to test could add their zone to the DLV, at least for > now - or configure a local trust anchor, if they are okay with a > signed zone without DS record. I still think I've been answered but just to clarify. The context here has no UI at all given it's between MTAs. And the people who wanted to experiment I believe wanted to play about with no DNSSEC at all, rather than with local trust anchors for DNS. Cheers, S. > > Paul > From nobody Fri Apr 17 05:18:20 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A9161B2B96 for ; Fri, 17 Apr 2015 05:18:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nR3ffaeQGsiK for ; Fri, 17 Apr 2015 05:18:18 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E85B1B2B95 for ; Fri, 17 Apr 2015 05:18:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 0592EBEEE; Fri, 17 Apr 2015 13:18:17 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lrr2vibozk0y; Fri, 17 Apr 2015 13:18:15 +0100 (IST) Received: from [10.87.48.73] (unknown [86.46.17.62]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id D52B1BEED; Fri, 17 Apr 2015 13:18:15 +0100 (IST) Message-ID: <5530FA07.1030007@cs.tcd.ie> Date: Fri, 17 Apr 2015 13:18:15 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Jeremy Harris , dane@ietf.org References: <552FD4E5.8080407@cs.tcd.ie> <20150416173722.GG17637@mournblade.imrryr.org> <552FFF6A.2040305@cs.tcd.ie> <55300F53.6080103@wizmail.org> In-Reply-To: <55300F53.6080103@wizmail.org> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dane] AD review of draft-ietf-dane-smtp-with-dane X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2015 12:18:19 -0000 On 16/04/15 20:36, Jeremy Harris wrote: > On 16/04/15 19:28, Stephen Farrell wrote: >>>> - 2.2, Could "authenticated" here mean mutually authenticated >>>> with TLS client certs? If not, maybe say so. (And for the >>>> last sentence before 2.2.1, what about the client cert names >>>> - what's done with those?) >>> >>> There is no protocol for specifying mutual authentication until >>> someone (I volunteered) writes the DANE draft for locating client >>> TLSA RRs and how that works for SMTP. Some of the signaling >>> (client -> server: please check for my TLSA records) will be >>> application protocol specific. >> >> Could be worth saying that mutually authenticated TLS is out >> of scope so servers SHOULD (or MUST) NOT send a certificate >> request. > > This seems excessive; one could not then use both DANE/SMTP > and some future specification for authenticating the client. > Surely "out of scope" is sufficient? Fair enough. That'd be fine by me. (And bear in mind this was just offered as a LC comment, not blocking in any way.) Cheers, S. > From nobody Fri Apr 17 05:24:50 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A76B1B2B96 for ; Fri, 17 Apr 2015 05:24:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uCXuCzILW6_f for ; Fri, 17 Apr 2015 05:24:47 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E1571B2B93 for ; Fri, 17 Apr 2015 05:24:47 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3lSxSX4Fmsz1bq; Fri, 17 Apr 2015 14:24:44 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=KQMXcZ3P X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id FuExNIpcwhmo; Fri, 17 Apr 2015 14:24:43 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Fri, 17 Apr 2015 14:24:43 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 3046F807D4; Fri, 17 Apr 2015 08:24:42 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1429273482; bh=wQMWFMXYS6oKUsTvS6P2K4N8qKi6nsXcjq2PEHNA7qY=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=KQMXcZ3PLbD3HoQuO259HwI6Xknjr5VvLdx9f2cXpYJ2RVm9lgf0mRWvGyXW5c1HS YqCQdH/0GwxQbpSGfXACaAfqKqDaI/N+s+64/BDzy5QYzYzXvfL7E67kF1YHl4C6Du G3Rq+iQGv3JkjQ3fnhZk0m5j6+GxJnGAhEqIq5jE= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id t3HCOeLS006525; Fri, 17 Apr 2015 08:24:41 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Fri, 17 Apr 2015 08:24:40 -0400 (EDT) From: Paul Wouters To: Stephen Farrell In-Reply-To: <5530F9E9.108@cs.tcd.ie> Message-ID: References: <552FD4E5.8080407@cs.tcd.ie> <20150416173722.GG17637@mournblade.imrryr.org> <552FFF6A.2040305@cs.tcd.ie> <5530F9E9.108@cs.tcd.ie> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: dane@ietf.org Subject: Re: [dane] AD review of draft-ietf-dane-smtp-with-dane X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2015 12:24:49 -0000 On Fri, 17 Apr 2015, Stephen Farrell wrote: >>> My understanding is that some people wanted to experiment with TLSA >>> without having to have had DNSSEC deployed. But I take your answer >>> to be that no such behaviour is defined here, which is fine. So >>> consider this one answered. >> >> I go back and forth with this one. It seems there is no good reason >> not to use an insecure trust anchor over no trust anchor, but the UI >> would have to be clearly different, which is where the real problem is >> I think. We could easilly use unsigned TLSA over completely unverified >> TLSA, but it would not be a good test because you cannot accept it as >> equal security in the UI without it becoming a downgrade attack. >> >> Those who want to test could add their zone to the DLV, at least for >> now - or configure a local trust anchor, if they are okay with a >> signed zone without DS record. > > I still think I've been answered but just to clarify. The context > here has no UI at all given it's between MTAs. That's not entirely true, surely the people testing will check the Received: headers for feedback on how the encryption went. > And the people who > wanted to experiment I believe wanted to play about with no DNSSEC > at all, rather than with local trust anchors for DNS. That does raise the question of what you are testing? While you might be able to test whether a transport was encrypted between two mail servers based on a TLSA key from DNS, you won't be testing whether a forged or bad DNS entry will cause the email to be queued up for later to protect it from being sent cleartext or encrypted via a forged key. Paul From nobody Fri Apr 17 05:58:41 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D73461B2C09 for ; Fri, 17 Apr 2015 05:58:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qhwrKwEs3cNP for ; Fri, 17 Apr 2015 05:58:38 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02ECD1B2C10 for ; Fri, 17 Apr 2015 05:58:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id BBED9BF14 for ; Fri, 17 Apr 2015 13:58:36 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id APn_cak2lxKp for ; Fri, 17 Apr 2015 13:58:35 +0100 (IST) Received: from [10.87.48.73] (unknown [86.46.17.62]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 1D62EBDCF for ; Fri, 17 Apr 2015 13:58:35 +0100 (IST) Message-ID: <5531037A.1050607@cs.tcd.ie> Date: Fri, 17 Apr 2015 13:58:34 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: dane@ietf.org References: <552FD4E5.8080407@cs.tcd.ie> <20150416173722.GG17637@mournblade.imrryr.org> <552FFF6A.2040305@cs.tcd.ie> <20150416184517.GI17637@mournblade.imrryr.org> In-Reply-To: <20150416184517.GI17637@mournblade.imrryr.org> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dane] AD review of draft-ietf-dane-smtp-with-dane X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2015 12:58:40 -0000 Hiya, On 16/04/15 19:45, Viktor Dukhovni wrote: > On Thu, Apr 16, 2015 at 07:28:58PM +0100, Stephen Farrell wrote: > >>> While, the A records don't a-priori need to be secured, we skip >>> TLSA records for MX hosts whose A/AAAA records are "insecure" in >>> order to avoid interop problems with (Microsoft's and similar) >>> domains whose non-DNSSEC nameservers are allergic to unsupported >>> RRtypes (the "mail.protection.outlook.com" nameservers botch >>> TLSA queries). >>> >>> Traffic hijacking can be done with BGP (this is far more common, >>> and is more difficult to observe) even without changing the addresses. >>> Or by tapping into the cables. >> >> So I think the threat is that someone who fakes the A record >> can do traffic analysis as they can direct the SMTP and STARTTLS >> traffic through their chosen host. I think that's work noting, >> in and of itself. If we had more to say (that's well founded) >> about traffic analysis if SMTP/TLS that'd be interesting but I'm >> not familiar with any work in the space (though I've not looked). > > Note that for this protocol, both the address records and the TLSA > records of the MX host are DNSSEC-validated, since when the address > records are not, we don't even ask for the TLSA RRs. So I am not > sure what you have in mind... Yep - this could be me being confused. If there's no way in which the MX and TLSA can be properly signed but where the A is not, then I agree my comment is moot and no change is needed. Cheers, S. PS: The rest below is fine. > > When the MX host's DNS zone is signed, both the address and the > TLSA records are signed, and off-path attackers don't get to use > DNS to redirect the traffic to addresses that are on-path. They > are of course still free to attempt to mess with the routing layer > to whatever extent possible. > >>>> - 2.2, Could "authenticated" here mean mutually authenticated >>>> with TLS client certs? If not, maybe say so. (And for the >>>> last sentence before 2.2.1, what about the client cert names >>>> - what's done with those?) >>> >>> There is no protocol for specifying mutual authentication until >>> someone (I volunteered) writes the DANE draft for locating client >>> TLSA RRs and how that works for SMTP. Some of the signaling >>> (client -> server: please check for my TLSA records) will be >>> application protocol specific. >> >> Could be worth saying that mutually authenticated TLS is out >> of scope so servers SHOULD (or MUST) NOT send a certificate >> request. > > Some SMTP servers send certificate requests anyway, most don't. > Sending MTAs, most of which are not configured with client certs, > just ignore the requests. Receiving MTAs complete the handshake > even if no client certificats are sent, but don't grant whatever > additional access rights one may get with some particular client > cert (or simply can't, when absent, record any client cert details > in "Received" headers or mail logs). > > So there's nothing really to say here, we're not changing the status > quo in any way (yet). Once there's a protocol for client TLSA RRs, > then there'll be something to say. > From nobody Fri Apr 17 09:39:46 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF84E1A6FF0 for ; Fri, 17 Apr 2015 09:39:45 -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 dADwI72AgAyc for ; Fri, 17 Apr 2015 09:39:44 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0CB61A6FEC for ; Fri, 17 Apr 2015 09:39:43 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id C93CE283031; Fri, 17 Apr 2015 16:39:42 +0000 (UTC) Date: Fri, 17 Apr 2015 16:39:42 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150417163942.GL17637@mournblade.imrryr.org> References: <552FD4E5.8080407@cs.tcd.ie> <20150416173722.GG17637@mournblade.imrryr.org> <552FFF6A.2040305@cs.tcd.ie> <20150416184517.GI17637@mournblade.imrryr.org> <5531037A.1050607@cs.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5531037A.1050607@cs.tcd.ie> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dane] AD review of draft-ietf-dane-smtp-with-dane 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, 17 Apr 2015 16:39:45 -0000 On Fri, Apr 17, 2015 at 01:58:34PM +0100, Stephen Farrell wrote: > > Note that for this protocol, both the address records and the TLSA > > records of the MX host are DNSSEC-validated, since when the address > > records are not, we don't even ask for the TLSA RRs. So I am not > > sure what you have in mind... > > Yep - this could be me being confused. If there's no way in which > the MX and TLSA can be properly signed but where the A is not, then > I agree my comment is moot and no change is needed. Well, though I don't know why we'd care protecting about the address records also (given routing layer attacks), ... There is (full disclosure) a corner case where the address records are not secure, but the TLSA records are. The case in question is a CNAME alias chain whose starting point (the "owner" name of the initial CNAME) is in a signed zone, but whose end-point is not secure: ; CNAME from signed zone into unsigned zone ; with TLSA records at start of CNAME chain. ; example.com. CNAME example.net. example.com. RRSIG CNAME ... _25._tcp.example.com. TLSA 3 1 1 ... _25._tcp.example.com. RRSIG TLSA ... ; Address records are in an unsigned zone ; example.net. IN A 192.0.2.1 In this case, mail to example.com is sent to the "insecure" IP address of example.net, with "secure" TLSA RRs coming from example.com. This case is rather rare, because most domains have MX records (rather than just receiving email at their A/AAAA records), and MX hostnames are supposed to not be aliases (and rarely are). Rare violators of the MX hostname is not a CNAME are however tolerated by most MTAs, and so Postfix will occasionally deliver mail to an authenticated peer via unauthenticated A records. Of course the administrator of the receiving domain willingly aliased their signed zone's hosts into an unsigned namespace. -- Viktor. From nobody Fri Apr 17 09:47:52 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 826201A8794 for ; Fri, 17 Apr 2015 09:47:49 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I_tE15TimsKo for ; Fri, 17 Apr 2015 09:47:47 -0700 (PDT) Received: from smtp76.ord1c.emailsrvr.com (smtp76.ord1c.emailsrvr.com [108.166.43.76]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 742CE1A8793 for ; Fri, 17 Apr 2015 09:47:47 -0700 (PDT) Received: from smtp2.relay.ord1c.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp2.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id CDD5F18008D; Fri, 17 Apr 2015 12:47:46 -0400 (EDT) Received: by smtp2.relay.ord1c.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id 802151802C2; Fri, 17 Apr 2015 12:47:46 -0400 (EDT) X-Sender-Id: ogud@ogud.com Received: from [10.20.30.43] (pool-74-96-189-218.washdc.fios.verizon.net [74.96.189.218]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:465 (trex/5.4.2); Fri, 17 Apr 2015 16:47:46 GMT Content-Type: multipart/alternative; boundary="Apple-Mail=_4FCD0B1B-5937-42ED-ADA0-7D966A4351E6" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Olafur Gudmundsson In-Reply-To: <552FFF6A.2040305@cs.tcd.ie> Date: Fri, 17 Apr 2015 12:47:45 -0400 Message-Id: References: <552FD4E5.8080407@cs.tcd.ie> <20150416173722.GG17637@mournblade.imrryr.org> <552FFF6A.2040305@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: dane@ietf.org Subject: Re: [dane] AD review of draft-ietf-dane-smtp-with-dane X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2015 16:47:49 -0000 --Apple-Mail=_4FCD0B1B-5937-42ED-ADA0-7D966A4351E6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Apr 16, 2015, at 2:28 PM, Stephen Farrell = wrote: >=20 >=20 > Hiya, >=20 > On 16/04/15 18:37, Viktor Dukhovni wrote: >> On Thu, Apr 16, 2015 at 04:27:33PM +0100, Stephen Farrell wrote: >>=20 >>> (1) What is the behaviour when all RRs required for this are >>> published except for no DNSSEC RRs? I have heard tell of some >>> people who would like to experiment in that way, and would >>> like to know if the WG have a clear answer for them as to >>> what ought happen. Is that answer here? (If so, it's fairly >>> well hidden;-) >>=20 >> The specified and implemented (Postfix and Exim) behaviour is that >> the records are ignored when not "secure". Thus DNSSEC is a >> prerequisite. Opportunistic TLS happens anyway (even without TLSA >> record validation), so it is not clear why one would bother with >> incomplete (easily defeated) attempts at protecting against active >> attacks. >=20 > My understanding is that some people wanted to experiment with TLSA > without having to have had DNSSEC deployed. But I take your answer > to be that no such behaviour is defined here, which is fine. So > consider this one answered. Stephen, I want to remind you of the conversations we had before and = after the IETF meeting in=20 Tapei, when this topic was going in circles.=20 Conclusion of discussion: DANE REQUIRES DNSSEC =20 if someone wants to publish TLSA records w/o DNSSEC that can work in = their environment but it is not going to be globally visible.=20 This and other WG document should not be in conflict with the principle = above.=20 Olafur=20= --Apple-Mail=_4FCD0B1B-5937-42ED-ADA0-7D966A4351E6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Apr 16, 2015, at 2:28 PM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:


Hiya,

On 16/04/15 18:37, Viktor = Dukhovni wrote:
On Thu, Apr 16, 2015 at 04:27:33PM +0100, Stephen = Farrell wrote:

(1) What is the behaviour when all RRs required for this = are
published except for no DNSSEC RRs? I have heard tell = of some
people who would like to experiment in that way, = and would
like to know if the WG have a clear answer for = them as to
what ought happen. Is that answer here? (If so, = it's fairly
well hidden;-)

The specified and implemented (Postfix and Exim) behaviour is = that
the records are ignored when not "secure".  Thus = DNSSEC is a
prerequisite.  Opportunistic TLS happens = anyway (even without TLSA
record validation), so it is not = clear why one would bother with
incomplete (easily = defeated) attempts at protecting against active
attacks.

My understanding is that = some people wanted to experiment with TLSA
without having to have had DNSSEC deployed. But = I take your answer
to be that no such = behaviour is defined here, which is fine. So
consider this one answered.

Stephen, I want = to remind you of the conversations we had before and after the IETF = meeting in 
Tapei, when this topic was going in = circles. 
Conclusion of discussion: DANE REQUIRES DNSSEC = <full stop> 

if someone = wants to publish TLSA records w/o DNSSEC that can work in their = environment but it is not
going to be globally = visible. 
This and other WG document should not be in = conflict with the principle above. 

Olafur 
= --Apple-Mail=_4FCD0B1B-5937-42ED-ADA0-7D966A4351E6-- From nobody Fri Apr 17 10:01:10 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F25BE1A8876 for ; Fri, 17 Apr 2015 10:01:08 -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 duwEc76l40yC for ; Fri, 17 Apr 2015 10:01:07 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9C2D1A887C for ; Fri, 17 Apr 2015 10:01:04 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 5C997283031; Fri, 17 Apr 2015 17:01:03 +0000 (UTC) Date: Fri, 17 Apr 2015 17:01:03 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150417170103.GN17637@mournblade.imrryr.org> References: <552FD4E5.8080407@cs.tcd.ie> <20150416173722.GG17637@mournblade.imrryr.org> <552FFF6A.2040305@cs.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dane] AD review of draft-ietf-dane-smtp-with-dane 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, 17 Apr 2015 17:01:09 -0000 On Fri, Apr 17, 2015 at 12:47:45PM -0400, Olafur Gudmundsson wrote: > > My understanding is that some people wanted to experiment with TLSA > > without having to have had DNSSEC deployed. But I take your answer > > to be that no such behaviour is defined here, which is fine. So > > consider this one answered. > > Stephen, I want to remind you of the conversations we had before and after the IETF meeting in > Tapei, when this topic was going in circles. > Conclusion of discussion: DANE REQUIRES DNSSEC > > If someone wants to publish TLSA records w/o DNSSEC that can work in their environment but it is not > going to be globally visible. > This and other WG document should not be in conflict with the principle above. I don't disagree, but to be fair, the original DANE discussions were likely not about opportunistic protocols. With opportunistic uses of DANE, one can argue that if "insecure" TLSA records are published, one might as well use them. Thus, for example, when address records are reported "insecure", instead of bypassing TLSA lookups, to avoid the potential interop issues, one could simply make "TLSA" lookup failure non-critical and then use "insecure" TLSA records when available, without claiming any security. Just log authentication failures, but deliver anyway. Such a mode of operation is not specified in the draft. I don't know whether there would be much demand/adoption of such an "variant" of the protocol. The present draft is a defense against active attacks, the variant would be some sort of tamper-evidence, though it is not clear exactly what "sort" unless the TLSA records observed are recorded, and regularly analyzed for "anomalies". -- Viktor. From nobody Fri Apr 17 13:26:20 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FAF51A0162 for ; Fri, 17 Apr 2015 13:26:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] 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 Sdjn-avfpnpq for ; Fri, 17 Apr 2015 13:26:18 -0700 (PDT) Received: from homiemail-a32.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 554601A0143 for ; Fri, 17 Apr 2015 13:26:18 -0700 (PDT) Received: from homiemail-a32.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a32.g.dreamhost.com (Postfix) with ESMTP id 2416E584075; Fri, 17 Apr 2015 13:26:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=c4z+eCEbC9VEf4 rNrEeXeV3+Qio=; b=NkdncVdaOEM7PyPTJjjPGOYOLbQtV+mu9p095TGk1WJOFv UEQHjEyiEIEe41N6VWKyRAnGV6z+W7/KZmFLIO2ShHnR8PSU/JgfJoZat6FPTefq v/g4wrwqRUwqGNgqG4gEb3Qt5HfqbGDjfuHk9OUqXsmMvqMsqX8hcasDtGyFo= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a32.g.dreamhost.com (Postfix) with ESMTPA id C0004584071; Fri, 17 Apr 2015 13:26:17 -0700 (PDT) Date: Fri, 17 Apr 2015 15:26:17 -0500 From: Nico Williams To: Olafur Gudmundsson Message-ID: <20150417202615.GI13041@localhost> References: <552FD4E5.8080407@cs.tcd.ie> <20150416173722.GG17637@mournblade.imrryr.org> <552FFF6A.2040305@cs.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: dane@ietf.org Subject: Re: [dane] AD review of draft-ietf-dane-smtp-with-dane X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2015 20:26:19 -0000 On Fri, Apr 17, 2015 at 12:47:45PM -0400, Olafur Gudmundsson wrote: > > On Apr 16, 2015, at 2:28 PM, Stephen Farrell wrote: > > On 16/04/15 18:37, Viktor Dukhovni wrote: > >> On Thu, Apr 16, 2015 at 04:27:33PM +0100, Stephen Farrell wrote: > >>> (1) What is the behaviour when all RRs required for this are > >>> published except for no DNSSEC RRs? I have heard tell of some > >>> people who would like to experiment in that way, and would > >>> like to know if the WG have a clear answer for them as to > >>> what ought happen. Is that answer here? (If so, it's fairly > >>> well hidden;-) > >> > >> The specified and implemented (Postfix and Exim) behaviour is that > >> the records are ignored when not "secure". Thus DNSSEC is a > >> prerequisite. Opportunistic TLS happens anyway (even without TLSA > >> record validation), so it is not clear why one would bother with > >> incomplete (easily defeated) attempts at protecting against active > >> attacks. > > > > My understanding is that some people wanted to experiment with TLSA > > without having to have had DNSSEC deployed. But I take your answer > > to be that no such behaviour is defined here, which is fine. So > > consider this one answered. > > Stephen, I want to remind you of the conversations we had before and > after the IETF meeting in Tapei, when this topic was going in circles. > Conclusion of discussion: DANE REQUIRES DNSSEC +1 > if someone wants to publish TLSA records w/o DNSSEC that can work in > their environment but it is not going to be globally visible. There's nothing wrong when unsigned TLSA RRSets being publicly visible. What's wrong is shipping code that uses unsigned TLSA RRSets. To test, I'd use a recursive, validating server, and prime its cache (or the stub resolver's). Done. Nico -- From nobody Fri Apr 17 13:32:00 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E05A1A7018 for ; Fri, 17 Apr 2015 13:31:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.266 X-Spam-Level: X-Spam-Status: No, score=-0.266 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] 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 AJ_xdjDehtF2 for ; Fri, 17 Apr 2015 13:31:57 -0700 (PDT) Received: from homiemail-a111.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 9602B1A0104 for ; Fri, 17 Apr 2015 13:31:57 -0700 (PDT) Received: from homiemail-a111.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a111.g.dreamhost.com (Postfix) with ESMTP id 5DE2F2005E61C for ; Fri, 17 Apr 2015 13:31:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:subject:message-id:references:mime-version:content-type :in-reply-to; s=cryptonector.com; bh=UMT1BJOBSStGR+n+NUVpug+DlFs =; b=SkBLP+iz+02hn0g4+bcKzNwVXUoV2INMpb68FdRlHpVqGZF10qv02e3gXvz RQCe1/aoPcTsLQiCEv8+iwjmT6sqS0b4TWSUz3je3LGdGsj8OrIoWxfvG8YTuWs6 I8bozhZFGcKhyKsKblOJhdM0LJIZgP0ERKVjGCa/Vn/q2EC4= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a111.g.dreamhost.com (Postfix) with ESMTPA id 38DE42005E605 for ; Fri, 17 Apr 2015 13:31:57 -0700 (PDT) Date: Fri, 17 Apr 2015 15:31:56 -0500 From: Nico Williams To: dane@ietf.org Message-ID: <20150417203156.GJ13041@localhost> References: <552FD4E5.8080407@cs.tcd.ie> <20150416173722.GG17637@mournblade.imrryr.org> <552FFF6A.2040305@cs.tcd.ie> <20150416184517.GI17637@mournblade.imrryr.org> <5531037A.1050607@cs.tcd.ie> <20150417163942.GL17637@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150417163942.GL17637@mournblade.imrryr.org> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [dane] AD review of draft-ietf-dane-smtp-with-dane X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2015 20:31:58 -0000 On Fri, Apr 17, 2015 at 04:39:42PM +0000, Viktor Dukhovni wrote: > Well, though I don't know why we'd care protecting about the address > records also (given routing layer attacks), ... There is (full > disclosure) a corner case where the address records are not secure, > but the TLSA records are. > > The case in question is a CNAME alias chain whose starting point > (the "owner" name of the initial CNAME) is in a signed zone, but > whose end-point is not secure: This sort of thing is fine in general: get the TLSA RRSet for the original name, chase aliasing regardless of whether aliasing RRs are signed, then insist on the server using certificates that validate per-the TLSA RRSet found in the beginning. Though preferably we should sign everything -- it's easier to think about this. Changing the origin is a different -but related- topic, about which see the threads from the URI RR's IETF LC. Nico -- From nobody Fri Apr 17 13:42:04 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 905291A87A1 for ; Fri, 17 Apr 2015 13:42:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] 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 SE0tuPHOLEZ8 for ; Fri, 17 Apr 2015 13:42:00 -0700 (PDT) Received: from homiemail-a97.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id D08621A8791 for ; Fri, 17 Apr 2015 13:41:57 -0700 (PDT) Received: from homiemail-a97.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a97.g.dreamhost.com (Postfix) with ESMTP id A0943286074; Fri, 17 Apr 2015 13:41:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=pSfYBHqsiA2EFl zvK9BRjVBk1oQ=; b=bWf/yZtb5DuLY4PiUoEK2p3oxFX9SEyDVif9uIh/2iabNU fZSyQUZmv6YmM2vyMzRNwK+pTMEhj5h99Zj7UZ3xnnEfF6dyx3WIl8Q9VqCAhQ5P LR/dUQmU/baEUIlZJrpVsUS2klNVtN92SGCjARON4YUP2uE2u3rY4fCwOAWAk= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a97.g.dreamhost.com (Postfix) with ESMTPA id 58EA5286057; Fri, 17 Apr 2015 13:41:57 -0700 (PDT) Date: Fri, 17 Apr 2015 15:41:56 -0500 From: Nico Williams To: Stephen Farrell Message-ID: <20150417204155.GK13041@localhost> References: <552FD4E5.8080407@cs.tcd.ie> <20150416173722.GG17637@mournblade.imrryr.org> <552FFF6A.2040305@cs.tcd.ie> <5530F9E9.108@cs.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5530F9E9.108@cs.tcd.ie> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: Paul Wouters , dane@ietf.org Subject: Re: [dane] AD review of draft-ietf-dane-smtp-with-dane X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2015 20:42:01 -0000 On Fri, Apr 17, 2015 at 01:17:45PM +0100, Stephen Farrell wrote: > I still think I've been answered but just to clarify. The context > here has no UI at all given it's between MTAs. And the people who > wanted to experiment I believe wanted to play about with no DNSSEC > at all, rather than with local trust anchors for DNS. As Paul says, there is a UI here: logs for sysadmins, Received headers for users and sysadmins. For testing, just prime a cache at the validating resolver. Incidentally, testing with DNS is hard. The biggest problem, of course, is hardwiring the port number, which means that automated tests can't simply spin up a server on some other port, which then means that VMs with virtualized networking are needed in order to automate tests, which then completely changes how tests run (i.e., "make check" won't do, and/or it will be slow). Of course, the fact that DNS is always on port 53 has its benefits, but an option to put NSs on a different port would sure help. Stub resolvers can help by having an option for priming a cache (including pretending that the records in the cache were signed, and the signatures validated). Nico -- From nobody Fri Apr 17 16:11:03 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC9151B30D8 for ; Fri, 17 Apr 2015 16:11:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bio610GSshOB for ; Fri, 17 Apr 2015 16:10:59 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 537961B30D2 for ; Fri, 17 Apr 2015 16:10:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 31027BEEA for ; Sat, 18 Apr 2015 00:10:57 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bJQni2hiAhwr for ; Sat, 18 Apr 2015 00:10:56 +0100 (IST) Received: from [10.87.48.73] (unknown [86.46.17.62]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 2F325BE39 for ; Sat, 18 Apr 2015 00:10:56 +0100 (IST) Message-ID: <553192FF.2040204@cs.tcd.ie> Date: Sat, 18 Apr 2015 00:10:55 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: dane@ietf.org References: <552FD4E5.8080407@cs.tcd.ie> <20150416173722.GG17637@mournblade.imrryr.org> <552FFF6A.2040305@cs.tcd.ie> <20150416184517.GI17637@mournblade.imrryr.org> <5531037A.1050607@cs.tcd.ie> <20150417163942.GL17637@mournblade.imrryr.org> In-Reply-To: <20150417163942.GL17637@mournblade.imrryr.org> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dane] AD review of draft-ietf-dane-smtp-with-dane X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2015 23:11:02 -0000 On 17/04/15 17:39, Viktor Dukhovni wrote: > Well, though I don't know why we'd care protecting about the address > records also (given routing layer attacks), ... There is (full > disclosure) a corner case where the address records are not secure, > but the TLSA records are. Right, that's what I was wondering about. I think the question for the WG is whether or not to note that that allows for potential traffic re-direction and traffic analysis of the TLS protected data. You are also correct that this could be done via BGP (and is perhaps more likely to be done) but if one was worried about this, then the error could also be done at this level (as shown by your example) which is an argument to call this out but not get into BGP issues. S. From nobody Fri Apr 17 16:13:22 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D78F61B30DA for ; Fri, 17 Apr 2015 16:13:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l826JglRPfeh for ; Fri, 17 Apr 2015 16:13:20 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC0441B30D8 for ; Fri, 17 Apr 2015 16:13:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id A8C79BEEA; Sat, 18 Apr 2015 00:13:18 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gmnAlY3wCLID; Sat, 18 Apr 2015 00:13:17 +0100 (IST) Received: from [10.87.48.73] (unknown [86.46.17.62]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id A3934BEE8; Sat, 18 Apr 2015 00:13:17 +0100 (IST) Message-ID: <5531938D.3020209@cs.tcd.ie> Date: Sat, 18 Apr 2015 00:13:17 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Nico Williams References: <552FD4E5.8080407@cs.tcd.ie> <20150416173722.GG17637@mournblade.imrryr.org> <552FFF6A.2040305@cs.tcd.ie> <5530F9E9.108@cs.tcd.ie> <20150417204155.GK13041@localhost> In-Reply-To: <20150417204155.GK13041@localhost> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Paul Wouters , dane@ietf.org Subject: Re: [dane] AD review of draft-ietf-dane-smtp-with-dane X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2015 23:13:21 -0000 On 17/04/15 21:41, Nico Williams wrote: > As Paul says, there is a UI here: logs for sysadmins, Received headers > for users and sysadmins. Paul's initial mail on this referred to UI and downgrade attack possibilities. I don't believe there is any such UI related downgrade attack in this case, but if there is, I'd be interested. S. From nobody Fri Apr 17 19:25:52 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 054751A6EE4 for ; Fri, 17 Apr 2015 19:25:51 -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 vFDfZRboWtWq for ; Fri, 17 Apr 2015 19:25:49 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85A1D1A6EE0 for ; Fri, 17 Apr 2015 19:25:49 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id CE12B283031; Sat, 18 Apr 2015 02:25:47 +0000 (UTC) Date: Sat, 18 Apr 2015 02:25:47 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150418022547.GB3576@mournblade.imrryr.org> References: <552FD4E5.8080407@cs.tcd.ie> <20150416173722.GG17637@mournblade.imrryr.org> <552FFF6A.2040305@cs.tcd.ie> <20150416184517.GI17637@mournblade.imrryr.org> <5531037A.1050607@cs.tcd.ie> <20150417163942.GL17637@mournblade.imrryr.org> <553192FF.2040204@cs.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <553192FF.2040204@cs.tcd.ie> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dane] AD review of draft-ietf-dane-smtp-with-dane X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Apr 2015 02:25:51 -0000 On Sat, Apr 18, 2015 at 12:10:55AM +0100, Stephen Farrell wrote: > On 17/04/15 17:39, Viktor Dukhovni wrote: > > > Well, though I don't know why we'd care protecting about the address > > records also (given routing layer attacks), ... There is (full > > disclosure) a corner case where the address records are not secure, > > but the TLSA records are. > > Right, that's what I was wondering about. Almost no domains lie in this corner case. > I think the question for the WG is whether or not to > note that that allows for potential traffic re-direction > and traffic analysis of the TLS protected data. I don't see why opportunistic DANE TLS for SMTP should attempt to protect against this "attack", which even mandatory TLS for HTTPS ignores. The folks interested in traffic analysis will learn what they need whether the IP addresses are forged or not. In fact I rather doubt they'd want to be that visible just for traffic analysis. > You are also correct that this could be done via BGP (and > is perhaps more likely to be done) but if one was worried > about this, then the error could also be done at this level > (as shown by your example) which is an argument to call > this out but not get into BGP issues. I'd prefer to not discuss this side-track in the draft. -- Viktor. From nobody Fri Apr 17 20:21:15 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C2A61A8891 for ; Fri, 17 Apr 2015 20:21:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.41 X-Spam-Level: X-Spam-Status: No, score=-1.41 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_44=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yPS0XJtsOoJe for ; Fri, 17 Apr 2015 20:21:12 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02F331A88E6 for ; Fri, 17 Apr 2015 20:21:12 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3lTKLr0Rgcz1JB; Sat, 18 Apr 2015 05:21:08 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=MwZRPTs/ X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id Z8oP5LcSuVUl; Sat, 18 Apr 2015 05:21:06 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Sat, 18 Apr 2015 05:21:06 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 75AEE807D4; Fri, 17 Apr 2015 23:21:05 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1429327265; bh=ikYYhX3KKeZiqQKbMAho49JC3/rDR/1XjVH4LiCbE3Y=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=MwZRPTs/75TZSHL9ZAWpkbf4W4HwluQ63OtQAHYonpDgKFe9XMGliXKbzcHEgwgPp M+nB6k9CRvkqkmkP8xIKliPiKiRPzN62nlh4qPpm3j4u3WTUny8GxCbrT57L53Uu+n SHYnFM5M7HlUiVSnrBdtPk3H0SpRMnaq+qfLB5WI= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id t3I3L45H008201; Fri, 17 Apr 2015 23:21:04 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Fri, 17 Apr 2015 23:21:04 -0400 (EDT) From: Paul Wouters To: Stephen Farrell In-Reply-To: <5531938D.3020209@cs.tcd.ie> Message-ID: References: <552FD4E5.8080407@cs.tcd.ie> <20150416173722.GG17637@mournblade.imrryr.org> <552FFF6A.2040305@cs.tcd.ie> <5530F9E9.108@cs.tcd.ie> <20150417204155.GK13041@localhost> <5531938D.3020209@cs.tcd.ie> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: dane@ietf.org Subject: Re: [dane] AD review of draft-ietf-dane-smtp-with-dane X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Apr 2015 03:21:13 -0000 On Sat, 18 Apr 2015, Stephen Farrell wrote: > On 17/04/15 21:41, Nico Williams wrote: >> As Paul says, there is a UI here: logs for sysadmins, Received headers >> for users and sysadmins. > > Paul's initial mail on this referred to UI and downgrade > attack possibilities. I don't believe there is any such UI > related downgrade attack in this case, but if there is, I'd > be interested. In case of this email of yours, my UI has elements like: Authentication-Results: bofh.nohats.ca; dkim=pass reason="1024-bit key; unprotected key" header.d=ietf.org header.i=@ietf.org header.b=x912mqog; dkim-adsp=none (unprotected policy) It might not be a fancy colourful padlock, but it's a UI :) Paul From nobody Sat Apr 18 02:51:04 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A360A1A1B84 for ; Sat, 18 Apr 2015 02:51:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bJm7SmoRbCCi for ; Sat, 18 Apr 2015 02:51:00 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 705BF1A1B8C for ; Sat, 18 Apr 2015 02:51:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 67F9DBEE5 for ; Sat, 18 Apr 2015 10:50:58 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dntkIVu1fmiM for ; Sat, 18 Apr 2015 10:50:56 +0100 (IST) Received: from [127.0.0.1] (unknown [86.46.17.62]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 54E63BED7 for ; Sat, 18 Apr 2015 10:50:55 +0100 (IST) X-Priority: 3 To: dane@ietf.org From: stephen.farrell@cs.tcd.ie In-Reply-To: <20150418022547.GB3576@mournblade.imrryr.org> References: <552FD4E5.8080407@cs.tcd.ie> <20150416173722.GG17637@mournblade.imrryr.org> <552FFF6A.2040305@cs.tcd.ie> <20150416184517.GI17637@mournblade.imrryr.org> <5531037A.1050607@cs.tcd.ie> <20150417163942.GL17637@mournblade.imrryr.org> <553192FF.2040204@cs.tcd.ie> <20150418022547.GB3576@mournblade.imrryr.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Date: Sat, 18 Apr 2015 09:50:48 +0000 Message-ID: <3n7gef.nmzy0v.2vaesh-qmf@mercury.scss.tcd.ie> MIME-Version: 1.0 Archived-At: Subject: Re: [dane] AD review of draft-ietf-dane-smtp-with-dane X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Apr 2015 09:51:02 -0000 DQoNCk9uIFNhdCBBcHIgMTggMDM6MjU6NDcgMjAxNSBHTVQrMDEwMCwgVmlrdG9yIER1a2hvdm5p IHdyb3RlOg0KPiBPbiBTYXQsIEFwciAxOCwgMjAxNSBhdCAxMjoxMDo1NUFNICswMTAwLCBTdGVw aGVuIEZhcnJlbGwgd3JvdGU6DQo+IA0KPiA+IE9uIDE3LzA0LzE1IDE3OjM5LCBWaWt0b3IgRHVr aG92bmkgd3JvdGU6DQo+ID4NCj4gPiA+IFdlbGwsIHRob3VnaCBJIGRvbid0IGtub3cgd2h5IHdl J2QgY2FyZSBwcm90ZWN0aW5nIGFib3V0IHRoZSBhZGRyZXNzDQo+ID4gPiByZWNvcmRzIGFsc28g KGdpdmVuIHJvdXRpbmcgbGF5ZXIgYXR0YWNrcyksIC4uLiAgVGhlcmUgaXMgKGZ1bGwNCj4gPiA+ IGRpc2Nsb3N1cmUpIGEgY29ybmVyIGNhc2Ugd2hlcmUgdGhlIGFkZHJlc3MgcmVjb3JkcyBhcmUg bm90IHNlY3VyZSwNCj4gPiA+IGJ1dCB0aGUgVExTQSByZWNvcmRzIGFyZS4NCj4gPiANCj4gPiBS aWdodCwgdGhhdCdzIHdoYXQgSSB3YXMgd29uZGVyaW5nIGFib3V0Lg0KPiANCj4gQWxtb3N0IG5v IGRvbWFpbnMgbGllIGluIHRoaXMgY29ybmVyIGNhc2UuDQo+IA0KPiA+IEkgdGhpbmsgdGhlIHF1 ZXN0aW9uIGZvciB0aGUgV0cgaXMgd2hldGhlciBvciBub3QgdG8NCj4gPiBub3RlIHRoYXQgdGhh dCBhbGxvd3MgZm9yIHBvdGVudGlhbCB0cmFmZmljIHJlLWRpcmVjdGlvbg0KPiA+IGFuZCB0cmFm ZmljIGFuYWx5c2lzIG9mIHRoZSBUTFMgcHJvdGVjdGVkIGRhdGEuDQo+IA0KPiBJIGRvbid0IHNl ZSB3aHkgb3Bwb3J0dW5pc3RpYyBEQU5FIFRMUyBmb3IgU01UUCBzaG91bGQgYXR0ZW1wdCB0bw0K PiBwcm90ZWN0IGFnYWluc3QgdGhpcyAiYXR0YWNrIiwNCg0KSSB3YXNuJ3QgYXJndWluZyB0byBw cm90ZWN0IGFnYWluc3QgdGhpcyBidXQgdG8gZG9jdW1lbnQgdGhlIHNlY3VyaXR5IGNvbnNpZGVy YXRpb24uIFNvcnJ5IGlmIHRoYXQgd2Fzbid0IGNsZWFyLiBBbmQgaXQncyBzdGlsbCBvayBpZiB0 aGUgd2cgcHJlZmVyIHRvIG5vdCBtZW50aW9uIGl0Lg0KDQpTLg0KDQoNCj4gd2hpY2ggZXZlbiBt YW5kYXRvcnkgVExTIGZvciBIVFRQUw0KPiBpZ25vcmVzLiAgVGhlIGZvbGtzIGludGVyZXN0ZWQg aW4gdHJhZmZpYyBhbmFseXNpcyB3aWxsIGxlYXJuIHdoYXQNCj4gdGhleSBuZWVkIHdoZXRoZXIg dGhlIElQIGFkZHJlc3NlcyBhcmUgZm9yZ2VkIG9yIG5vdC4gIEluIGZhY3QgSQ0KPiByYXRoZXIg ZG91YnQgdGhleSdkIHdhbnQgdG8gYmUgdGhhdCB2aXNpYmxlIGp1c3QgZm9yIHRyYWZmaWMNCj4g YW5hbHlzaXMuDQo+IA0KPiA+IFlvdSBhcmUgYWxzbyBjb3JyZWN0IHRoYXQgdGhpcyBjb3VsZCBi ZSBkb25lIHZpYSBCR1AgKGFuZA0KPiA+IGlzIHBlcmhhcHMgbW9yZSBsaWtlbHkgdG8gYmUgZG9u ZSkgYnV0IGlmIG9uZSB3YXMgd29ycmllZA0KPiA+IGFib3V0IHRoaXMsIHRoZW4gdGhlIGVycm9y IGNvdWxkIGFsc28gYmUgZG9uZSBhdCB0aGlzIGxldmVsDQo+ID4gKGFzIHNob3duIGJ5IHlvdXIg ZXhhbXBsZSkgd2hpY2ggaXMgYW4gYXJndW1lbnQgdG8gY2FsbA0KPiA+IHRoaXMgb3V0IGJ1dCBu b3QgZ2V0IGludG8gQkdQIGlzc3Vlcy4NCj4gDQo+IEknZCBwcmVmZXIgdG8gbm90IGRpc2N1c3Mg dGhpcyBzaWRlLXRyYWNrIGluIHRoZSBkcmFmdC4NCj4gDQo+IC0tIA0KPiAJVmlrdG9yLg0KPiAN Cj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gZGFu ZSBtYWlsaW5nIGxpc3QNCj4gZGFuZUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2RhbmUNCj4= From nobody Mon Apr 20 07:41:18 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42D861B2BCC for ; Mon, 20 Apr 2015 07:41:16 -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 TCejt79f8Vkg for ; Mon, 20 Apr 2015 07:41:15 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DED911A03D5 for ; Mon, 20 Apr 2015 07:41:14 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id C6D67283032; Mon, 20 Apr 2015 14:41:13 +0000 (UTC) Date: Mon, 20 Apr 2015 14:41:13 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150420144113.GC25758@mournblade.imrryr.org> References: <20150220220921.GH1260@mournblade.imrryr.org> <98BDCF0E-88CD-4392-9194-DABB8AA62532@ogud.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <98BDCF0E-88CD-4392-9194-DABB8AA62532@ogud.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: [dane] OPS? (was: WGLC: DANE-SRV & DANE-SMTP) 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, 20 Apr 2015 14:41:16 -0000 On Fri, Feb 20, 2015 at 05:13:01PM -0500, Olafur Gudmundsson wrote: > We plan to start a WGLC on the related OPS document RSN and will live with > cross references between the documents as they will all be published at > the same time Is it RSN yet? Just got a robo-email that the OPS draft is about to "expire"... -- Viktor. From nobody Mon Apr 20 07:50:54 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC3801B2BD2; Mon, 20 Apr 2015 07:50:52 -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 wiiV_3d3N7cM; Mon, 20 Apr 2015 07:50:51 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D6811A03A9; Mon, 20 Apr 2015 07:50:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Brian Haberman" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150420145051.12174.16885.idtracker@ietfa.amsl.com> Date: Mon, 20 Apr 2015 07:50:51 -0700 Archived-At: Cc: dane-chairs@ietf.org, dane@ietf.org, draft-ietf-dane-srv.shepherd@ietf.org, draft-ietf-dane-srv@ietf.org, draft-ietf-dane-srv.ad@ietf.org Subject: [dane] Brian Haberman's No Objection on draft-ietf-dane-srv-13: (with COMMENT) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2015 14:50:52 -0000 Brian Haberman has entered the following ballot position for draft-ietf-dane-srv-13: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-dane-srv/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- * The reference to Section 4 of draft-ietf-dane-smtp-with-dane in the Note within section 3.1 seems out-of-date. * The intro to Section 3.2 says "A and/or AAAA", but the first two bullets in the list seems to assume that both A and AAAA lookups are performed. From nobody Mon Apr 20 08:29:56 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A5BF1B2EF5 for ; Mon, 20 Apr 2015 08:29:54 -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 rHr7u_tnCMOk for ; Mon, 20 Apr 2015 08:29:53 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F15581B2EF4 for ; Mon, 20 Apr 2015 08:29:52 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 1F2FD283032; Mon, 20 Apr 2015 15:29:52 +0000 (UTC) Date: Mon, 20 Apr 2015 15:29:52 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150420152951.GD25758@mournblade.imrryr.org> References: <20150420145051.12174.16885.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150420145051.12174.16885.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dane] Brian Haberman's No Objection on draft-ietf-dane-srv-13: (with COMMENT) 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, 20 Apr 2015 15:29:54 -0000 On Mon, Apr 20, 2015 at 07:50:51AM -0700, Brian Haberman wrote: > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > * The reference to Section 4 of draft-ietf-dane-smtp-with-dane in the > Note within section 3.1 seems out-of-date. Don't know how that became section 4, this was a reference to section 2.1 in version 12 (previous) of the draft, which was correct. > * The intro to Section 3.2 says "A and/or AAAA", but the first two > bullets in the list seems to assume that both A and AAAA lookups are > performed. Some clients only have IPv4 connectivity, and will only make A queries. Other clients only have IPv6 connectivity and will only make AAAA queries, some will perform both. The client avoids TLSA queries when none of the address records it found were secure. In practice since the A and AAAA records belong to the same "owner", it would be very surprising if they had a different security status. The only way that happens is if the cached DS RRset (or negative entry) expires from the cache between the two queries, and the zone's DNSSEC status changed since last queried. -- Viktor. From nobody Mon Apr 20 08:50:19 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D9051B2F3E; Mon, 20 Apr 2015 08:50:17 -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 uxbjA3UosxqQ; Mon, 20 Apr 2015 08:50:16 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 829F51B2F3D; Mon, 20 Apr 2015 08:50:16 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 48127880ED; Mon, 20 Apr 2015 08:50:16 -0700 (PDT) Received: from Brians-MacBook-Pro.local (swifi-nat.jhuapl.edu [128.244.87.133]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 0082271B0001; Mon, 20 Apr 2015 08:50:15 -0700 (PDT) Message-ID: <5535202E.1030804@innovationslab.net> Date: Mon, 20 Apr 2015 11:50:06 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: dane@ietf.org, iesg@ietf.org References: <20150420145051.12174.16885.idtracker@ietfa.amsl.com> <20150420153616.GE25758@mournblade.imrryr.org> In-Reply-To: <20150420153616.GE25758@mournblade.imrryr.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="sSvNMCb25CUdu8JjKpAuemDLa7nBVNUuD" Archived-At: Subject: Re: [dane] Brian Haberman's No Objection on draft-ietf-dane-srv-13: (with COMMENT) 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, 20 Apr 2015 15:50:17 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --sSvNMCb25CUdu8JjKpAuemDLa7nBVNUuD Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Viktor, On 4/20/15 11:36 AM, Viktor Dukhovni wrote: > On Mon, Apr 20, 2015 at 07:50:51AM -0700, Brian Haberman wrote: >=20 >> ----------------------------------------------------------------------= >> COMMENT: >> ----------------------------------------------------------------------= >> >> * The intro to Section 3.2 says "A and/or AAAA", but the first two >> bullets in the list seems to assume that both A and AAAA lookups are >> performed. >=20 > Some clients only have IPv4 connectivity, and will only make A > queries. Other clients only have IPv6 connectivity and will only > make AAAA queries, some will perform both. Agreed on the actions of the client based on availability of v4 and v6 service. The wording in the first two bullets could be made clearer. Would this substitution capture the intent? OLD: o If either the A or AAAA RRSets are "secure", the client ... o If both RRsets are "insecure", the client ... NEW: o If a returned RRSet is "secure", the client ... o If no returned RRsets are "secure", the client ... Regards, Brian --sSvNMCb25CUdu8JjKpAuemDLa7nBVNUuD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJVNSAuAAoJEBOZRqCi7goqIQ0IAMva9Vu/aaNaT/vsqzma0ca8 9v8RWdnDmhHWtZqBvQre8PdgYdftD5JAgCSINQcJkZmB6RooxS2NT7JRo0Zws/Q5 ZfhS22mfjSzOZjaUs8pFaxz+f2CUEUbERUIjCuU/sKkET6Fr19BrO4EE5/XaIQL+ 6cqpy/KQiphtp+2PSEwT/bScI5R9JZQDxtEdmB809uOlJmcPkvNieu3wz/5Aadtd cBd8GTF7dtmke4S77yEt+x6p6c03YjkSjqOkWuBlqzdwahgUaw/ALaeIqa3QqbSe LEDXUtfR0/IIonwSt3OOc3eOEwYQ8n1grp+85fYV6TqTeYFgScjTpt+lGRJjD9w= =HK2/ -----END PGP SIGNATURE----- --sSvNMCb25CUdu8JjKpAuemDLa7nBVNUuD-- From nobody Mon Apr 20 08:58:30 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E44221B2F1A; Mon, 20 Apr 2015 08:58:27 -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 huh6oWYAGGoy; Mon, 20 Apr 2015 08:58:26 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F0011B2A69; Mon, 20 Apr 2015 08:58:26 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id DF211283032; Mon, 20 Apr 2015 15:58:25 +0000 (UTC) Date: Mon, 20 Apr 2015 15:58:25 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150420155825.GH25758@mournblade.imrryr.org> References: <20150420145051.12174.16885.idtracker@ietfa.amsl.com> <20150420153616.GE25758@mournblade.imrryr.org> <5535202E.1030804@innovationslab.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5535202E.1030804@innovationslab.net> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: iesg@ietf.org Subject: Re: [dane] Brian Haberman's No Objection on draft-ietf-dane-srv-13: (with COMMENT) 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, 20 Apr 2015 15:58:28 -0000 On Mon, Apr 20, 2015 at 11:50:06AM -0400, Brian Haberman wrote: > > Some clients only have IPv4 connectivity, and will only make A > > queries. Other clients only have IPv6 connectivity and will only > > make AAAA queries, some will perform both. > > Agreed on the actions of the client based on availability of v4 and v6 > service. The wording in the first two bullets could be made clearer. > Would this substitution capture the intent? > > OLD: > o If either the A or AAAA RRSets are "secure", the client ... > > o If both RRsets are "insecure", the client ... > > NEW: > o If a returned RRSet is "secure", the client ... > > o If no returned RRsets are "secure", the client ... I think so, with luck the authors and others will also agree. -- Viktor. From nobody Mon Apr 20 09:01:33 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16B991B2EB9 for ; Mon, 20 Apr 2015 09:01:32 -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 AuduTrMgf3YA for ; Mon, 20 Apr 2015 09:01:26 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B4F81B2CB4 for ; Mon, 20 Apr 2015 09:01:26 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 76983283032; Mon, 20 Apr 2015 16:01:25 +0000 (UTC) Date: Mon, 20 Apr 2015 16:01:25 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150420160125.GI25758@mournblade.imrryr.org> References: <552FD4E5.8080407@cs.tcd.ie> <20150416173722.GG17637@mournblade.imrryr.org> <552FFF6A.2040305@cs.tcd.ie> <20150416184517.GI17637@mournblade.imrryr.org> <5531037A.1050607@cs.tcd.ie> <20150417163942.GL17637@mournblade.imrryr.org> <553192FF.2040204@cs.tcd.ie> <20150418022547.GB3576@mournblade.imrryr.org> <3n7gef.nmzy0v.2vaesh-qmf@mercury.scss.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3n7gef.nmzy0v.2vaesh-qmf@mercury.scss.tcd.ie> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dane] AD review of draft-ietf-dane-smtp-with-dane 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, 20 Apr 2015 16:01:32 -0000 Should I cut another version with editorial changes based on your review prior to IETF LC? -- Viktor. From nobody Mon Apr 20 09:07:49 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5FCF1B2F50 for ; Mon, 20 Apr 2015 09:07:46 -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=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A1AlMTDtyzVS for ; Mon, 20 Apr 2015 09:07:45 -0700 (PDT) Received: from mail-ig0-f170.google.com (mail-ig0-f170.google.com [209.85.213.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1EBA1B2F51 for ; Mon, 20 Apr 2015 09:07:45 -0700 (PDT) Received: by igblo3 with SMTP id lo3so63235611igb.1 for ; Mon, 20 Apr 2015 09:07:44 -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=YshwVPLHFeZ1+pN4GzLFawjJxV6GjD0Dw+yegdi2mQs=; b=GAyUWJTpj4ZARnDBQeisFRf03fdzh69p5S0m8V8+R9joABAvcQBedILB52ZLbk4yYl x85krTddkbt0OepRzpY7EE6aLbwYEl4mZ4fyXaIYtkdaG6a3uftQxw0BNB1j+gmyg4n8 qSodAPsEWpkuiOiEI4WvEyH0Wfoe5/Ud9Ah4W50RbA0s62axyECAr0qMhQl5FmtlyPCp TQTbWK39tOzJeYyfdj7K92p+XxlhnYm6qmQQB2Vx5rGFl+IpI7ivjC9bmDkDRPxlc8rv Uv2dIgSkCgk2w96QlRPcPQCxIWlmY8JiNUFr7m44EUj+NfVDI/Hh77ZUfCP3kutMPVL/ ol0g== X-Gm-Message-State: ALoCoQnqqOfR170kpZ+OF9sRZV6tmQKSQKzFOXAZC3/BlzMvpDloGrO5yaaeOz9nTEgZ2vSOB7gu X-Received: by 10.42.38.208 with SMTP id d16mr19548837ice.45.1429546064450; Mon, 20 Apr 2015 09:07:44 -0700 (PDT) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id o80sm11646781ioi.3.2015.04.20.09.07.43 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Apr 2015 09:07:43 -0700 (PDT) Message-ID: <5535244D.8040909@andyet.net> Date: Mon, 20 Apr 2015 10:07:41 -0600 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: dane@ietf.org References: <20150420145051.12174.16885.idtracker@ietfa.amsl.com> <20150420153616.GE25758@mournblade.imrryr.org> <5535202E.1030804@innovationslab.net> <20150420155825.GH25758@mournblade.imrryr.org> In-Reply-To: <20150420155825.GH25758@mournblade.imrryr.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: iesg@ietf.org Subject: Re: [dane] Brian Haberman's No Objection on draft-ietf-dane-srv-13: (with COMMENT) 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, 20 Apr 2015 16:07:47 -0000 On 4/20/15 9:58 AM, Viktor Dukhovni wrote: > On Mon, Apr 20, 2015 at 11:50:06AM -0400, Brian Haberman wrote: > >>> Some clients only have IPv4 connectivity, and will only make A >>> queries. Other clients only have IPv6 connectivity and will only >>> make AAAA queries, some will perform both. >> >> Agreed on the actions of the client based on availability of v4 and v6 >> service. The wording in the first two bullets could be made clearer. >> Would this substitution capture the intent? >> >> OLD: >> o If either the A or AAAA RRSets are "secure", the client ... >> >> o If both RRsets are "insecure", the client ... >> >> NEW: >> o If a returned RRSet is "secure", the client ... >> >> o If no returned RRsets are "secure", the client ... > > I think so, with luck the authors and others will also agree. That seems fine to me. And I'm not sure how we got that section pointer wrong in 3.1, will fix. Peter -- Peter Saint-Andre https://andyet.com/ From nobody Mon Apr 20 09:08:57 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A91A1B2F57 for ; Mon, 20 Apr 2015 09:08:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XIqg25TxJXXq for ; Mon, 20 Apr 2015 09:08:50 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46E5F1B2F60 for ; Mon, 20 Apr 2015 09:08:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 0F98BBE80 for ; Mon, 20 Apr 2015 17:08:47 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 55CQvvpwdGp9 for ; Mon, 20 Apr 2015 17:08:46 +0100 (IST) Received: from [10.87.48.73] (unknown [86.46.17.62]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 12F1EBE7C for ; Mon, 20 Apr 2015 17:08:46 +0100 (IST) Message-ID: <5535248D.3090307@cs.tcd.ie> Date: Mon, 20 Apr 2015 17:08:45 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: dane@ietf.org References: <552FD4E5.8080407@cs.tcd.ie> <20150416173722.GG17637@mournblade.imrryr.org> <552FFF6A.2040305@cs.tcd.ie> <20150416184517.GI17637@mournblade.imrryr.org> <5531037A.1050607@cs.tcd.ie> <20150417163942.GL17637@mournblade.imrryr.org> <553192FF.2040204@cs.tcd.ie> <20150418022547.GB3576@mournblade.imrryr.org> <3n7gef.nmzy0v.2vaesh-qmf@mercury.scss.tcd.ie> <20150420160125.GI25758@mournblade.imrryr.org> In-Reply-To: <20150420160125.GI25758@mournblade.imrryr.org> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dane] AD review of draft-ietf-dane-smtp-with-dane X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2015 16:08:55 -0000 On 20/04/15 17:01, Viktor Dukhovni wrote: > > Should I cut another version with editorial changes based on your > review prior to IETF LC? I guess that's one for the WG chairs. But I don't think we bottomed out on the TLS versioning thing and the relationship with recent related BCPs did we? Thanks, S. From nobody Mon Apr 20 09:35:03 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A079A1A017A for ; Mon, 20 Apr 2015 09:35:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QPtnMklyAvAp for ; Mon, 20 Apr 2015 09:34:57 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEDF81A0187 for ; Mon, 20 Apr 2015 09:34:56 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id D886C283032; Mon, 20 Apr 2015 16:34:49 +0000 (UTC) Date: Mon, 20 Apr 2015 16:34:49 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150420163449.GK25758@mournblade.imrryr.org> References: <20150416173722.GG17637@mournblade.imrryr.org> <552FFF6A.2040305@cs.tcd.ie> <20150416184517.GI17637@mournblade.imrryr.org> <5531037A.1050607@cs.tcd.ie> <20150417163942.GL17637@mournblade.imrryr.org> <553192FF.2040204@cs.tcd.ie> <20150418022547.GB3576@mournblade.imrryr.org> <3n7gef.nmzy0v.2vaesh-qmf@mercury.scss.tcd.ie> <20150420160125.GI25758@mournblade.imrryr.org> <5535248D.3090307@cs.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5535248D.3090307@cs.tcd.ie> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dane] AD review of draft-ietf-dane-smtp-with-dane 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, 20 Apr 2015 16:35:00 -0000 On Mon, Apr 20, 2015 at 05:08:45PM +0100, Stephen Farrell wrote: > On 20/04/15 17:01, Viktor Dukhovni wrote: > > Should I cut another version with editorial changes based on your > > review prior to IETF LC? > > I guess that's one for the WG chairs. OK. Any word from the chairs then? > But I don't think we bottomed out on the TLS versioning thing and > the relationship with recent related BCPs did we? I don't expect much/any further discussion. I am ready to replace all mention of SSL 3.0 with TLS 1.0. Given that the protocol is opportunistic, requiring anything stronger is I think counter-productive. Can we move forward with s/SSL 3.0/TLS 1.0/g? This modifies just the first paragraph of 8.1 and is not a big deal. I don't recall seeing any other recent BCPs at issue in this thread. -- Viktor. From nobody Mon Apr 20 09:52:04 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 529541A1A39 for ; Mon, 20 Apr 2015 09:52:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ae_ZGadYlOlO for ; Mon, 20 Apr 2015 09:52:02 -0700 (PDT) Received: from smtp92.ord1c.emailsrvr.com (smtp92.ord1c.emailsrvr.com [108.166.43.92]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF2331A0377 for ; Mon, 20 Apr 2015 09:52:01 -0700 (PDT) Received: from smtp4.relay.ord1c.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp4.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 485A718061F for ; Mon, 20 Apr 2015 12:52:01 -0400 (EDT) Received: by smtp4.relay.ord1c.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id 27B771800FB for ; Mon, 20 Apr 2015 12:52:01 -0400 (EDT) X-Sender-Id: ogud@ogud.com Received: from [10.20.30.43] (pool-74-96-189-218.washdc.fios.verizon.net [74.96.189.218]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:465 (trex/5.4.2); Mon, 20 Apr 2015 16:52:01 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Olafur Gudmundsson In-Reply-To: <20150420163449.GK25758@mournblade.imrryr.org> Date: Mon, 20 Apr 2015 12:51:59 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <475C2B2C-5BC8-4B30-811B-535B5CA71DAF@ogud.com> References: <20150416173722.GG17637@mournblade.imrryr.org> <552FFF6A.2040305@cs.tcd.ie> <20150416184517.GI17637@mournblade.imrryr.org> <5531037A.1050607@cs.tcd.ie> <20150417163942.GL17637@mournblade.imrryr.org> <553192FF.2040204@cs.tcd.ie> <20150418022547.GB3576@mournblade.imrryr.org> <3n7gef.nmzy0v.2vaesh-qmf@mercury.scss.tcd.ie> <20150420160125.GI25758@mournblade.imrryr.org> <5535248D.3090307@cs.tcd.ie> <20150420163449.GK25758@mournblade.imrryr.org> To: dane@ietf.org X-Mailer: Apple Mail (2.2070.6) Archived-At: Subject: Re: [dane] AD review of draft-ietf-dane-smtp-with-dane X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2015 16:52:03 -0000 > On Apr 20, 2015, at 12:34 PM, Viktor Dukhovni = wrote: >=20 > On Mon, Apr 20, 2015 at 05:08:45PM +0100, Stephen Farrell wrote: >=20 >> On 20/04/15 17:01, Viktor Dukhovni wrote: >=20 >>> Should I cut another version with editorial changes based on your >>> review prior to IETF LC? >>=20 >> I guess that's one for the WG chairs. >=20 > OK. Any word from the chairs then? Update,=20 >=20 >> But I don't think we bottomed out on the TLS versioning thing and >> the relationship with recent related BCPs did we? >=20 > I don't expect much/any further discussion. I am ready to replace > all mention of SSL 3.0 with TLS 1.0. Given that the protocol is > opportunistic, requiring anything stronger is I think = counter-productive. >=20 > Can we move forward with s/SSL 3.0/TLS 1.0/g? This modifies just > the first paragraph of 8.1 and is not a big deal. >=20 > I don't recall seeing any other recent BCPs at issue in this thread. >=20 > --=20 > Viktor. >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From nobody Mon Apr 20 12:36:44 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 444E81A882B for ; Mon, 20 Apr 2015 12:36:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jTy8ith74i1i for ; Mon, 20 Apr 2015 12:36:42 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3333B1A87D5 for ; Mon, 20 Apr 2015 12:36:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id C4E0CBE97 for ; Mon, 20 Apr 2015 20:36:40 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Yc22e0HkfHx for ; Mon, 20 Apr 2015 20:36:39 +0100 (IST) Received: from [10.87.48.73] (unknown [86.46.17.62]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 56A43BE8E for ; Mon, 20 Apr 2015 20:36:39 +0100 (IST) Message-ID: <55355547.40003@cs.tcd.ie> Date: Mon, 20 Apr 2015 20:36:39 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: dane@ietf.org References: <20150416173722.GG17637@mournblade.imrryr.org> <552FFF6A.2040305@cs.tcd.ie> <20150416184517.GI17637@mournblade.imrryr.org> <5531037A.1050607@cs.tcd.ie> <20150417163942.GL17637@mournblade.imrryr.org> <553192FF.2040204@cs.tcd.ie> <20150418022547.GB3576@mournblade.imrryr.org> <3n7gef.nmzy0v.2vaesh-qmf@mercury.scss.tcd.ie> <20150420160125.GI25758@mournblade.imrryr.org> <5535248D.3090307@cs.tcd.ie> <20150420163449.GK25758@mournblade.imrryr.org> In-Reply-To: <20150420163449.GK25758@mournblade.imrryr.org> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dane] AD review of draft-ietf-dane-smtp-with-dane X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2015 19:36:43 -0000 On 20/04/15 17:34, Viktor Dukhovni wrote: > On Mon, Apr 20, 2015 at 05:08:45PM +0100, Stephen Farrell wrote: > >> On 20/04/15 17:01, Viktor Dukhovni wrote: > >>> Should I cut another version with editorial changes based on your >>> review prior to IETF LC? >> >> I guess that's one for the WG chairs. > > OK. Any word from the chairs then? > >> But I don't think we bottomed out on the TLS versioning thing and >> the relationship with recent related BCPs did we? > > I don't expect much/any further discussion. I am ready to replace > all mention of SSL 3.0 with TLS 1.0. Given that the protocol is > opportunistic, requiring anything stronger is I think counter-productive. > > Can we move forward with s/SSL 3.0/TLS 1.0/g? This modifies just > the first paragraph of 8.1 and is not a big deal. > > I don't recall seeing any other recent BCPs at issue in this thread. One could encourage adhering to the generic UTA BCP though as well right? If the WG don't pushback at me (and please do if I'm wrong), I think s/SSL 3.0/TLS 1.0/g and adding a recommendation to follow the UTA BCP would be just fine to move forward. (I'm ok if the UTA BCP is a SHOULD or RECOMMENDED and could live with a non-2119 type recommendation either.) S. > From nobody Mon Apr 20 14:03:10 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D785B1B31CC for ; Mon, 20 Apr 2015 14:03:08 -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 yPHlQBGicMUy for ; Mon, 20 Apr 2015 14:03:06 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5523C1B31C3 for ; Mon, 20 Apr 2015 14:03:06 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 1E818283032; Mon, 20 Apr 2015 21:03:05 +0000 (UTC) Date: Mon, 20 Apr 2015 21:03:05 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150420210305.GM25758@mournblade.imrryr.org> References: <20150416184517.GI17637@mournblade.imrryr.org> <5531037A.1050607@cs.tcd.ie> <20150417163942.GL17637@mournblade.imrryr.org> <553192FF.2040204@cs.tcd.ie> <20150418022547.GB3576@mournblade.imrryr.org> <3n7gef.nmzy0v.2vaesh-qmf@mercury.scss.tcd.ie> <20150420160125.GI25758@mournblade.imrryr.org> <5535248D.3090307@cs.tcd.ie> <20150420163449.GK25758@mournblade.imrryr.org> <55355547.40003@cs.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55355547.40003@cs.tcd.ie> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dane] AD review of draft-ietf-dane-smtp-with-dane 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, 20 Apr 2015 21:03:09 -0000 On Mon, Apr 20, 2015 at 08:36:39PM +0100, Stephen Farrell wrote: > > Can we move forward with s/SSL 3.0/TLS 1.0/g? This modifies just > > the first paragraph of 8.1 and is not a big deal. > > > > I don't recall seeing any other recent BCPs at issue in this thread. > > One could encourage adhering to the generic UTA BCP though > as well right? There is AFAIK no UTA BCP for opportunistic TLS. Even though once usable TLSA records are found (DANE) authenticated TLS becomes mandatory, the client is (a-priori) opportunistic and was willing to send cleartext. The client is honouring the server's preference for authenticated TLS, but should not be unduly strict with respect to the server's TLS protocol capabilities, which are not advertised as part of the TLSA records which the client uses to "commit" to using TLS. Opportunistic DANE TLS will be disabled by users if it enforces TLS settings with which more a negligible fraction of servers cannot comply. This protocol needs to have conservatively low expectations of server TLS capabilities. What that means will vary over time. What Postfix does when TLS is mandatory is to disable low-grade ciphersuites and obsolete TLS protocol versions. http://www.postfix.org/postconf.5.html#smtp_tls_mandatory_ciphers http://www.postfix.org/postconf.5.html#smtp_tls_mandatory_protocols Are you looking for something that elaborates on the text below from Section 3 of RFC 7435? With unauthenticated, encrypted communication, OS protocols may employ more liberal settings than would be best practice when security is mandated by policy. Some legacy systems support encryption, but implement only outdated algorithms or protocol versions. Compatibility with these systems avoids the need to resort to cleartext fallback. For greater assurance of channel security, an OS protocol may enforce more stringent cryptographic parameters when the session is authenticated. For example, the set of enabled Transport Layer Security (TLS) [RFC5246] cipher suites might exclude deprecated algorithms that would be tolerated with unauthenticated, encrypted communication. In particular the second quoted paragraph hints at the possibility of being a bit more strict when authentication is mandatory and active attack protection is expected. What specifically in the UTA BCP should be referenced in this draft? -- Viktor. From nobody Mon Apr 20 14:13:11 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BE701B31DB for ; Mon, 20 Apr 2015 14:13:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WFuTcaHTC4Sp for ; Mon, 20 Apr 2015 14:13:00 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AC5C1B31DD for ; Mon, 20 Apr 2015 14:13:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 656B1BE8E for ; Mon, 20 Apr 2015 22:12:58 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3JVAafxvZ8BM for ; Mon, 20 Apr 2015 22:12:56 +0100 (IST) Received: from [10.87.48.73] (unknown [86.46.17.62]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 78536BE97 for ; Mon, 20 Apr 2015 22:12:56 +0100 (IST) Message-ID: <55356BD8.2030908@cs.tcd.ie> Date: Mon, 20 Apr 2015 22:12:56 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: dane@ietf.org References: <20150416184517.GI17637@mournblade.imrryr.org> <5531037A.1050607@cs.tcd.ie> <20150417163942.GL17637@mournblade.imrryr.org> <553192FF.2040204@cs.tcd.ie> <20150418022547.GB3576@mournblade.imrryr.org> <3n7gef.nmzy0v.2vaesh-qmf@mercury.scss.tcd.ie> <20150420160125.GI25758@mournblade.imrryr.org> <5535248D.3090307@cs.tcd.ie> <20150420163449.GK25758@mournblade.imrryr.org> <55355547.40003@cs.tcd.ie> <20150420210305.GM25758@mournblade.imrryr.org> In-Reply-To: <20150420210305.GM25758@mournblade.imrryr.org> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dane] AD review of draft-ietf-dane-smtp-with-dane X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2015 21:13:03 -0000 On 20/04/15 22:03, Viktor Dukhovni wrote: > On Mon, Apr 20, 2015 at 08:36:39PM +0100, Stephen Farrell wrote: > >>> Can we move forward with s/SSL 3.0/TLS 1.0/g? This modifies just >>> the first paragraph of 8.1 and is not a big deal. >>> >>> I don't recall seeing any other recent BCPs at issue in this thread. >> >> One could encourage adhering to the generic UTA BCP though >> as well right? > > There is AFAIK no UTA BCP for opportunistic TLS. Agreed. > > Even though once usable TLSA records are found (DANE) authenticated > TLS becomes mandatory, the client is (a-priori) opportunistic and > was willing to send cleartext. > > The client is honouring the server's preference for authenticated > TLS, but should not be unduly strict with respect to the server's > TLS protocol capabilities, which are not advertised as part of the > TLSA records which the client uses to "commit" to using TLS. > > Opportunistic DANE TLS will be disabled by users if it enforces Did I mention "enforcing"? If so that wasn't what I meant. But in any case, the UTA BCP is designed not to require things that aren't commonly available. > TLS settings with which more a negligible fraction of servers cannot > comply. This protocol needs to have conservatively low expectations > of server TLS capabilities. What that means will vary over time. > > What Postfix does when TLS is mandatory is to disable low-grade > ciphersuites and obsolete TLS protocol versions. > > http://www.postfix.org/postconf.5.html#smtp_tls_mandatory_ciphers > http://www.postfix.org/postconf.5.html#smtp_tls_mandatory_protocols > > Are you looking for something that elaborates on the text below > from Section 3 of RFC 7435? > > With unauthenticated, encrypted communication, OS protocols may > employ more liberal settings than would be best practice when > security is mandated by policy. Some legacy systems support > encryption, but implement only outdated algorithms or protocol > versions. Compatibility with these systems avoids the need to resort > to cleartext fallback. > > For greater assurance of channel security, an OS protocol may enforce > more stringent cryptographic parameters when the session is > authenticated. For example, the set of enabled Transport Layer > Security (TLS) [RFC5246] cipher suites might exclude deprecated > algorithms that would be tolerated with unauthenticated, encrypted > communication. No, not that I think. > > In particular the second quoted paragraph hints at the possibility > of being a bit more strict when authentication is mandatory and > active attack protection is expected. > > What specifically in the UTA BCP should be referenced in this draft? How about: "BCPxxx [draft-ietf-uta-tls-bcp] documents current best practice recommendations for TLS, e.g. which ciphersuites are best to adopt etc. Implementations and deployments are encouraged to adopt those practices." Cheers, S. > > From nobody Tue Apr 21 16:32:09 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DC711B2E08; Tue, 21 Apr 2015 16:00:30 -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 rbShMhvmU3GX; Tue, 21 Apr 2015 16:00:25 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 481FA1B2E05; Tue, 21 Apr 2015 16:00:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150421230025.1610.45220.idtracker@ietfa.amsl.com> Date: Tue, 21 Apr 2015 16:00:25 -0700 Archived-At: X-Mailman-Approved-At: Tue, 21 Apr 2015 16:32:08 -0700 Cc: dane-chairs@ietf.org, dane@ietf.org, draft-ietf-dane-srv.shepherd@ietf.org, draft-ietf-dane-srv@ietf.org, draft-ietf-dane-srv.ad@ietf.org Subject: [dane] Ben Campbell's Yes on draft-ietf-dane-srv-13: (with COMMENT) 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, 21 Apr 2015 23:00:30 -0000 Ben Campbell has entered the following ballot position for draft-ietf-dane-srv-13: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-dane-srv/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for this. Protocols using SRV have been left out of the DANE party for too long :-) But I still have a couple of comments: 3.1, 2nd paragraph (note) I have mixed emotions about smtp-with-dane as an informational reference. Putting it in a "note" aside, can one safely implement and use dane-srv without reading that draft? (If the answer is really "yes", then I'm okay with it.) 3.2, first paragraph: Is this meant to imply that one must resolve every SRV target? I would assume that it follows the normal SRV rules and application protocol rules, which may or may not result in queries for every SRV target in the set. From nobody Tue Apr 21 17:10:51 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 086901B2DFB; Tue, 21 Apr 2015 17:10:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nLRxupEmqU4C; Tue, 21 Apr 2015 17:10:45 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C0821B2F21; Tue, 21 Apr 2015 17:10:45 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id B622D283032; Wed, 22 Apr 2015 00:10:43 +0000 (UTC) Date: Wed, 22 Apr 2015 00:10:43 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150422001043.GF25758@mournblade.imrryr.org> References: <20150421230025.1610.45220.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150421230025.1610.45220.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: The IESG Subject: Re: [dane] Ben Campbell's Yes on draft-ietf-dane-srv-13: (with COMMENT) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2015 00:10:47 -0000 On Tue, Apr 21, 2015 at 04:00:25PM -0700, Ben Campbell wrote: > 3.1, 2nd paragraph (note) > > I have mixed emotions about smtp-with-dane as an informational reference. > Putting it in a "note" aside, can one safely implement and use dane-srv > without reading that draft? (If the answer is really "yes", then I'm okay > with it.) It was decided after some WG discussion (for lack of an obvious alternative home) that the text describing how to deal with DNS errors was to remain in the SMTP draft rather than be duplicated in both. So I think that readers of the SRV draft need to read the DNS error handling text from the SMTP draft. > 3.2, first paragraph: > > Is this meant to imply that one must resolve every SRV target? I would > assume that it follows the normal SRV rules and application protocol > rules, which may or may not result in queries for every SRV target in the > set. I would *not* expect that every SRV target needs to be resolved. Rather it should suffice to resolve the targets one by one if the application wishes to move from one target to the next, until a satisfactory connection is established, at which point unresolved targets are simply ignored. All this subject to the usual precedence and weight rules. So the text (which I just noticed contains one "n" too many in "connnection"): For each SRV target server connnection endpoint, the client makes A and/or AAAA queries, performs DNSSEC validation on the address (A or AAAA) response, and continues as follows based on the results: really means for each "in turn", and only for as many as necessary. Though some applications might resolves them all "in parallel", in order to avoid latency costs when otherwise the first few might fail to resolve. -- Viktor. From nobody Tue Apr 21 23:08:50 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D71041B2CF9; Tue, 21 Apr 2015 23:08:46 -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 2q3cvXZKDFCC; Tue, 21 Apr 2015 23:08:45 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DC101B2D15; Tue, 21 Apr 2015 23:08:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150422060843.4941.65287.idtracker@ietfa.amsl.com> Date: Tue, 21 Apr 2015 23:08:43 -0700 Archived-At: Cc: dane@ietf.org Subject: [dane] I-D Action: draft-ietf-dane-smtp-with-dane-16.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2015 06:08:47 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS-based Authentication of Named Entities Working Group of the IETF. Title : SMTP security via opportunistic DANE TLS Authors : Viktor Dukhovni Wes Hardaker Filename : draft-ietf-dane-smtp-with-dane-16.txt Pages : 32 Date : 2015-04-21 Abstract: This memo describes a downgrade-resistant protocol for SMTP transport security between Mail Transfer Agents (MTAs) based on the DNS-Based Authentication of Named Entities (DANE) TLSA DNS record. Adoption of this protocol enables an incremental transition of the Internet email backbone to one using encrypted and authenticated Transport Layer Security (TLS). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dane-smtp-with-dane/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-16 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-dane-smtp-with-dane-16 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Apr 21 23:13:50 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 784FB1B2D53 for ; Tue, 21 Apr 2015 23:13:49 -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 yV-5-5dgZPff for ; Tue, 21 Apr 2015 23:13:46 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2C4F1B2D5C for ; Tue, 21 Apr 2015 23:13:28 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 82592283033; Wed, 22 Apr 2015 06:13:27 +0000 (UTC) Date: Wed, 22 Apr 2015 06:13:27 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150422061327.GK25758@mournblade.imrryr.org> References: <552FD4E5.8080407@cs.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <552FD4E5.8080407@cs.tcd.ie> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: [dane] SMTP draft -16 updates (was: AD review of draft-ietf-dane-smtp-with-dane) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2015 06:13:49 -0000 On Thu, Apr 16, 2015 at 04:27:33PM +0100, Stephen Farrell wrote: > - 1.2, 2nd para: s/trusted public keys/public keys/ > - 1.2, 2nd para: s/a new/the/ > - 1.2, 3rd para: s/directly delegated/delegated/ > - 1.2, 3rd para: s/data integrity/data origin authentication/ > TLS provides data integrity for application PDUs in all cases > - 1.3, 2nd para: s/traditional PKI/traditional Web PKI/ > - 1.3.1, s/such as the use of PKIX// I don't think that says > anything really and I've no clue what "use of PKIX" might > mean exactly - better left out I'd say > - 1.3.2, s/A PKIX TLS client/A TLS client/ > - 2.1.1, 2nd para: s/must be used/MUST be used/? Not sure > myself, but I'd make it uppercase for emphasis. (Other people > will disagree from all points of view though, no matter what > you do or don't do here;-) > - 2.2, I'd re-phrase "A connection to the MTA MUST be made > using authenticated and encrypted TLS" as "Any connection to the > MTA MUST be made using authenticated and encrypted TLS" The current > text could be read to say that the client MUST make the connection, > whereas I think you just mean if you do make a connection it MUST > use TLS. Adopted in -16, please check. > - 2.1.1, the term anchorless should probbaly get a mention in > 1.1 with a forward pointer to 2.1.1. Or maybe you can avoid > the term since it's not used much. (Just in 2 adjacent > paragraphs.) Rewritten (improved I think, thanks) in -16 to avoid "anchorless". > - 2.1.1, what does "securely opted out" mean? Rewritten in -16 to clarify. > - 2.2, Could "authenticated" here mean mutually authenticated > with TLS client certs? If not, maybe say so. (And for the > last sentence before 2.2.1, what about the client cert names > - what's done with those?) Per the list discussion, no client authentication. Definition rephrased in -16 to make the meaning more clear. > - 2.2.1, last para: What is the other, to which the > "Otherwise" at the start of the para applies? That confused > me. Rewritten in -16 to clarify this as 'When not "insecure"'. > - 2.2.2: bullet 1 - what's that mean? (In this context) This > section generally has a bunch of paragraphs that start with a > conditional, and it's not clear how they all fit. Could you > add some more structure (e.g. pseudo-code) to clarify? Reworked the bullets and paragraph above to make this clearer in -16. > - 3.1: All but the first and last two paras of this seem to > be repetitive of 6698 and 7218. I don't see that it's a good > idea to do that. (In what is already an over-long document.) Fat trimmed in -16, leaving just the meat and bones. > - 3.1.3, last sentence: is that needed? It seems to > invalidate the sentence before. (And it's vague.) NEW (in -16): SMTP client treatment of TLSA RRs with certificate usages PKIX-TA(0) or PKIX-EE(1) is undefined. As with any other unsuppored certificate usage, SMTP clients MAY treat such records as "unusable" > - 3.2.2, various places: "MUST be included" where? Reworded in -16. > - 8.1, para 1: We've (the IETF) just deprecated SSL 3.0, [1] > so don't you need to reference that and say to not do that? > At least the MAY at the end of that paragraph seems not to > conform with the BCP. I think a ref to [1] is needed. Simplified text in -16 omits all mention of SSL 3.0. Just reminds the reader that use of SNI precludes SSL 2.0 HELLO. > - 9.2, 2nd para: isn't that repetitive? That seems like a bad > idea. In -16 dropped the repetition of non-support for usage 0/1. > - 1.3.2, The MX lookup is vulnerable as stated but isn't the > A/AAAA similarly vulnerable? I think you ought note that too, > but also that this specification can mean that DNSSEC for > that lookup is not needed based on the name in the MX > response being bound (via x.509 or tlsa) to the TLS server > private key. (Well, that assumes I've gotten that correct:-) > Without DNSSEC for the MX name->address mapping a bad actor > could however, insert themselves into the path and gain > whatever can be gained via traffic analysis of the SMTP/TLS > session. Declined. > - 2.2, 3rd bullet: Is it a good idea to mix the insecure TLSA > RRSet and validated non-existence in one bullet? I find it > confusing. Maybe it'd be better to have two bullets even if > the new one says "do as above." Any guidance from the WG on this? I neither see this change as a compelling improvement, nor am I strongly opposed to it. Deferred for now. > - 3.1.2 - does the MUST include TA in the TLS handshake > conflict with common implementations of 5246? 5246 section > 7.4.2, says that the TA MAY be omitted, but I wonder if we > might be causing ourselves trouble (some) with running code. As discussed on the list, this is not a conflict nor a problem with running code. Section 9.2 mentioned the the Microsoft Exchange issue where servers are unable to send self-signed trust-anchors, and therefore must not use them in DANE-TA(2) records, employing intermediate TAs instead. In -16, shortened and moved that text to 3.1.2. > - 8.2: This is alrady handled by the generic UTA BCP. Why is > it needed here? This discusses use anonymous cipher suites in SMTP opportunistic TLS, which is not covered in the UTA BCP. Section retained. -- Viktor. From nobody Tue Apr 21 23:59:43 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4339D1B324A for ; Tue, 21 Apr 2015 23:59:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aRf8Uk_0lAJd for ; Tue, 21 Apr 2015 23:59:40 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE4301B3247 for ; Tue, 21 Apr 2015 23:59:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 8AF81BE56 for ; Wed, 22 Apr 2015 07:59:23 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VPf7Llcp8QaU for ; Wed, 22 Apr 2015 07:59:22 +0100 (IST) Received: from [10.87.48.73] (unknown [86.46.17.62]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id E688CBE2F for ; Wed, 22 Apr 2015 07:59:21 +0100 (IST) Message-ID: <553746C9.4090208@cs.tcd.ie> Date: Wed, 22 Apr 2015 07:59:21 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: dane@ietf.org References: <552FD4E5.8080407@cs.tcd.ie> <20150422061327.GK25758@mournblade.imrryr.org> In-Reply-To: <20150422061327.GK25758@mournblade.imrryr.org> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dane] SMTP draft -16 updates 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, 22 Apr 2015 06:59:42 -0000 Thanks, will get back to this later on today, by Friday worst case. Cheers, S. On 22/04/15 07:13, Viktor Dukhovni wrote: > On Thu, Apr 16, 2015 at 04:27:33PM +0100, Stephen Farrell wrote: > >> - 1.2, 2nd para: s/trusted public keys/public keys/ >> - 1.2, 2nd para: s/a new/the/ >> - 1.2, 3rd para: s/directly delegated/delegated/ >> - 1.2, 3rd para: s/data integrity/data origin authentication/ >> TLS provides data integrity for application PDUs in all cases >> - 1.3, 2nd para: s/traditional PKI/traditional Web PKI/ >> - 1.3.1, s/such as the use of PKIX// I don't think that says >> anything really and I've no clue what "use of PKIX" might >> mean exactly - better left out I'd say >> - 1.3.2, s/A PKIX TLS client/A TLS client/ >> - 2.1.1, 2nd para: s/must be used/MUST be used/? Not sure >> myself, but I'd make it uppercase for emphasis. (Other people >> will disagree from all points of view though, no matter what >> you do or don't do here;-) >> - 2.2, I'd re-phrase "A connection to the MTA MUST be made >> using authenticated and encrypted TLS" as "Any connection to the >> MTA MUST be made using authenticated and encrypted TLS" The current >> text could be read to say that the client MUST make the connection, >> whereas I think you just mean if you do make a connection it MUST >> use TLS. > > Adopted in -16, please check. > >> - 2.1.1, the term anchorless should probbaly get a mention in >> 1.1 with a forward pointer to 2.1.1. Or maybe you can avoid >> the term since it's not used much. (Just in 2 adjacent >> paragraphs.) > > Rewritten (improved I think, thanks) in -16 to avoid "anchorless". > >> - 2.1.1, what does "securely opted out" mean? > > Rewritten in -16 to clarify. > >> - 2.2, Could "authenticated" here mean mutually authenticated >> with TLS client certs? If not, maybe say so. (And for the >> last sentence before 2.2.1, what about the client cert names >> - what's done with those?) > > Per the list discussion, no client authentication. Definition > rephrased in -16 to make the meaning more clear. > >> - 2.2.1, last para: What is the other, to which the >> "Otherwise" at the start of the para applies? That confused >> me. > > Rewritten in -16 to clarify this as 'When not "insecure"'. > >> - 2.2.2: bullet 1 - what's that mean? (In this context) This >> section generally has a bunch of paragraphs that start with a >> conditional, and it's not clear how they all fit. Could you >> add some more structure (e.g. pseudo-code) to clarify? > > Reworked the bullets and paragraph above to make this clearer > in -16. > >> - 3.1: All but the first and last two paras of this seem to >> be repetitive of 6698 and 7218. I don't see that it's a good >> idea to do that. (In what is already an over-long document.) > > Fat trimmed in -16, leaving just the meat and bones. > >> - 3.1.3, last sentence: is that needed? It seems to >> invalidate the sentence before. (And it's vague.) > > NEW (in -16): > > SMTP client treatment of TLSA RRs with certificate usages > PKIX-TA(0) or PKIX-EE(1) is undefined. As with any other > unsuppored certificate usage, SMTP clients MAY treat such > records as "unusable" > >> - 3.2.2, various places: "MUST be included" where? > > Reworded in -16. > >> - 8.1, para 1: We've (the IETF) just deprecated SSL 3.0, [1] >> so don't you need to reference that and say to not do that? >> At least the MAY at the end of that paragraph seems not to >> conform with the BCP. I think a ref to [1] is needed. > > Simplified text in -16 omits all mention of SSL 3.0. Just reminds > the reader that use of SNI precludes SSL 2.0 HELLO. > >> - 9.2, 2nd para: isn't that repetitive? That seems like a bad >> idea. > > In -16 dropped the repetition of non-support for usage 0/1. > >> - 1.3.2, The MX lookup is vulnerable as stated but isn't the >> A/AAAA similarly vulnerable? I think you ought note that too, >> but also that this specification can mean that DNSSEC for >> that lookup is not needed based on the name in the MX >> response being bound (via x.509 or tlsa) to the TLS server >> private key. (Well, that assumes I've gotten that correct:-) >> Without DNSSEC for the MX name->address mapping a bad actor >> could however, insert themselves into the path and gain >> whatever can be gained via traffic analysis of the SMTP/TLS >> session. > > Declined. > >> - 2.2, 3rd bullet: Is it a good idea to mix the insecure TLSA >> RRSet and validated non-existence in one bullet? I find it >> confusing. Maybe it'd be better to have two bullets even if >> the new one says "do as above." > > Any guidance from the WG on this? I neither see this change as a > compelling improvement, nor am I strongly opposed to it. Deferred > for now. > >> - 3.1.2 - does the MUST include TA in the TLS handshake >> conflict with common implementations of 5246? 5246 section >> 7.4.2, says that the TA MAY be omitted, but I wonder if we >> might be causing ourselves trouble (some) with running code. > > As discussed on the list, this is not a conflict nor a problem with > running code. > > Section 9.2 mentioned the the Microsoft Exchange issue where servers > are unable to send self-signed trust-anchors, and therefore must > not use them in DANE-TA(2) records, employing intermediate TAs > instead. In -16, shortened and moved that text to 3.1.2. > >> - 8.2: This is alrady handled by the generic UTA BCP. Why is >> it needed here? > > This discusses use anonymous cipher suites in SMTP opportunistic > TLS, which is not covered in the UTA BCP. Section retained. > From nobody Thu Apr 23 09:43:42 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EE8B1AC3CE for ; Thu, 23 Apr 2015 09:43:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xfjqC3pdccS1 for ; Thu, 23 Apr 2015 09:43:37 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A28F1AC43B for ; Thu, 23 Apr 2015 09:43:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id CCAD9BEE4 for ; Thu, 23 Apr 2015 17:43:26 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nXkhGKANKrtg for ; Thu, 23 Apr 2015 17:43:24 +0100 (IST) Received: from [10.87.48.73] (unknown [86.42.29.198]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id CD2EEBEE0 for ; Thu, 23 Apr 2015 17:43:24 +0100 (IST) Message-ID: <5539212C.2090607@cs.tcd.ie> Date: Thu, 23 Apr 2015 17:43:24 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: dane@ietf.org References: <552FD4E5.8080407@cs.tcd.ie> <20150422061327.GK25758@mournblade.imrryr.org> <553746C9.4090208@cs.tcd.ie> In-Reply-To: <553746C9.4090208@cs.tcd.ie> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dane] SMTP draft -16 updates 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, 23 Apr 2015 16:43:39 -0000 On 22/04/15 07:59, Stephen Farrell wrote: > > Thanks, will get back to this later on today, by Friday > worst case. Sorry, I didn't get a chance to look that over in detail and now probably won't tomorrow either, so I've requested IETF LC start and I'll take a peek at it again during the LC. Thanks, S. > > Cheers, > S. > > On 22/04/15 07:13, Viktor Dukhovni wrote: >> On Thu, Apr 16, 2015 at 04:27:33PM +0100, Stephen Farrell wrote: >> >>> - 1.2, 2nd para: s/trusted public keys/public keys/ >>> - 1.2, 2nd para: s/a new/the/ >>> - 1.2, 3rd para: s/directly delegated/delegated/ >>> - 1.2, 3rd para: s/data integrity/data origin authentication/ >>> TLS provides data integrity for application PDUs in all cases >>> - 1.3, 2nd para: s/traditional PKI/traditional Web PKI/ >>> - 1.3.1, s/such as the use of PKIX// I don't think that says >>> anything really and I've no clue what "use of PKIX" might >>> mean exactly - better left out I'd say >>> - 1.3.2, s/A PKIX TLS client/A TLS client/ >>> - 2.1.1, 2nd para: s/must be used/MUST be used/? Not sure >>> myself, but I'd make it uppercase for emphasis. (Other people >>> will disagree from all points of view though, no matter what >>> you do or don't do here;-) >>> - 2.2, I'd re-phrase "A connection to the MTA MUST be made >>> using authenticated and encrypted TLS" as "Any connection to the >>> MTA MUST be made using authenticated and encrypted TLS" The current >>> text could be read to say that the client MUST make the connection, >>> whereas I think you just mean if you do make a connection it MUST >>> use TLS. >> >> Adopted in -16, please check. >> >>> - 2.1.1, the term anchorless should probbaly get a mention in >>> 1.1 with a forward pointer to 2.1.1. Or maybe you can avoid >>> the term since it's not used much. (Just in 2 adjacent >>> paragraphs.) >> >> Rewritten (improved I think, thanks) in -16 to avoid "anchorless". >> >>> - 2.1.1, what does "securely opted out" mean? >> >> Rewritten in -16 to clarify. >> >>> - 2.2, Could "authenticated" here mean mutually authenticated >>> with TLS client certs? If not, maybe say so. (And for the >>> last sentence before 2.2.1, what about the client cert names >>> - what's done with those?) >> >> Per the list discussion, no client authentication. Definition >> rephrased in -16 to make the meaning more clear. >> >>> - 2.2.1, last para: What is the other, to which the >>> "Otherwise" at the start of the para applies? That confused >>> me. >> >> Rewritten in -16 to clarify this as 'When not "insecure"'. >> >>> - 2.2.2: bullet 1 - what's that mean? (In this context) This >>> section generally has a bunch of paragraphs that start with a >>> conditional, and it's not clear how they all fit. Could you >>> add some more structure (e.g. pseudo-code) to clarify? >> >> Reworked the bullets and paragraph above to make this clearer >> in -16. >> >>> - 3.1: All but the first and last two paras of this seem to >>> be repetitive of 6698 and 7218. I don't see that it's a good >>> idea to do that. (In what is already an over-long document.) >> >> Fat trimmed in -16, leaving just the meat and bones. >> >>> - 3.1.3, last sentence: is that needed? It seems to >>> invalidate the sentence before. (And it's vague.) >> >> NEW (in -16): >> >> SMTP client treatment of TLSA RRs with certificate usages >> PKIX-TA(0) or PKIX-EE(1) is undefined. As with any other >> unsuppored certificate usage, SMTP clients MAY treat such >> records as "unusable" >> >>> - 3.2.2, various places: "MUST be included" where? >> >> Reworded in -16. >> >>> - 8.1, para 1: We've (the IETF) just deprecated SSL 3.0, [1] >>> so don't you need to reference that and say to not do that? >>> At least the MAY at the end of that paragraph seems not to >>> conform with the BCP. I think a ref to [1] is needed. >> >> Simplified text in -16 omits all mention of SSL 3.0. Just reminds >> the reader that use of SNI precludes SSL 2.0 HELLO. >> >>> - 9.2, 2nd para: isn't that repetitive? That seems like a bad >>> idea. >> >> In -16 dropped the repetition of non-support for usage 0/1. >> >>> - 1.3.2, The MX lookup is vulnerable as stated but isn't the >>> A/AAAA similarly vulnerable? I think you ought note that too, >>> but also that this specification can mean that DNSSEC for >>> that lookup is not needed based on the name in the MX >>> response being bound (via x.509 or tlsa) to the TLS server >>> private key. (Well, that assumes I've gotten that correct:-) >>> Without DNSSEC for the MX name->address mapping a bad actor >>> could however, insert themselves into the path and gain >>> whatever can be gained via traffic analysis of the SMTP/TLS >>> session. >> >> Declined. >> >>> - 2.2, 3rd bullet: Is it a good idea to mix the insecure TLSA >>> RRSet and validated non-existence in one bullet? I find it >>> confusing. Maybe it'd be better to have two bullets even if >>> the new one says "do as above." >> >> Any guidance from the WG on this? I neither see this change as a >> compelling improvement, nor am I strongly opposed to it. Deferred >> for now. >> >>> - 3.1.2 - does the MUST include TA in the TLS handshake >>> conflict with common implementations of 5246? 5246 section >>> 7.4.2, says that the TA MAY be omitted, but I wonder if we >>> might be causing ourselves trouble (some) with running code. >> >> As discussed on the list, this is not a conflict nor a problem with >> running code. >> >> Section 9.2 mentioned the the Microsoft Exchange issue where servers >> are unable to send self-signed trust-anchors, and therefore must >> not use them in DANE-TA(2) records, employing intermediate TAs >> instead. In -16, shortened and moved that text to 3.1.2. >> >>> - 8.2: This is alrady handled by the generic UTA BCP. Why is >>> it needed here? >> >> This discusses use anonymous cipher suites in SMTP opportunistic >> TLS, which is not covered in the UTA BCP. Section retained. >> > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > > From nobody Thu Apr 23 10:31:49 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 679861A1BFC; Thu, 23 Apr 2015 10:31:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c132DUUvEohK; Thu, 23 Apr 2015 10:31:46 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D6DB21ACE25; Thu, 23 Apr 2015 10:30:56 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.1.p1 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20150423173056.22775.96126.idtracker@ietfa.amsl.com> Date: Thu, 23 Apr 2015 10:30:56 -0700 Archived-At: Cc: dane@ietf.org Subject: [dane] Last Call: (SMTP security via opportunistic DANE TLS) to Proposed Standard X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2015 17:31:48 -0000 The IESG has received a request from the DNS-based Authentication of Named Entities WG (dane) to consider the following document: - 'SMTP security via opportunistic DANE TLS' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2015-05-07. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This memo describes a downgrade-resistant protocol for SMTP transport security between Mail Transfer Agents (MTAs) based on the DNS-Based Authentication of Named Entities (DANE) TLSA DNS record. Adoption of this protocol enables an incremental transition of the Internet email backbone to one using encrypted and authenticated Transport Layer Security (TLS). The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-dane-smtp-with-dane/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-dane-smtp-with-dane/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Thu Apr 23 14:50:47 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B37C71A8820; Thu, 23 Apr 2015 14:50:46 -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 1FVeQYa6WEP8; Thu, 23 Apr 2015 14:50:45 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 064321B34A4; Thu, 23 Apr 2015 14:50:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150423215036.22102.37702.idtracker@ietfa.amsl.com> Date: Thu, 23 Apr 2015 14:50:36 -0700 Archived-At: Cc: dane@ietf.org Subject: [dane] I-D Action: draft-ietf-dane-srv-14.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2015 21:50:46 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS-based Authentication of Named Entities Working Group of the IETF. Title : Using DNS-Based Authentication of Named Entities (DANE) TLSA Records with SRV Records Authors : Tony Finch Matthew Miller Peter Saint-Andre Filename : draft-ietf-dane-srv-14.txt Pages : 15 Date : 2015-04-23 Abstract: The DANE specification (RFC 6698) describes how to use TLSA resource records secured by DNSSEC (RFC 4033) to associate a server's connection endpoint with its TLS certificate (thus enabling administrators of domain names to specify the keys used in that domain's TLS servers). However, application protocols that use SRV records (RFC 2782) to indirectly name the target server connection endpoints for a service domain cannot apply the rules from RFC 6698. Therefore this document provides guidelines that enable such protocols to locate and use TLSA records. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dane-srv/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dane-srv-14 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-dane-srv-14 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Apr 23 14:53:05 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 145381A895E for ; Thu, 23 Apr 2015 14:53:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.211 X-Spam-Level: X-Spam-Status: No, score=-14.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uGSU4tovqJfS for ; Thu, 23 Apr 2015 14:53:02 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2364E1A8820 for ; Thu, 23 Apr 2015 14:52:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2620; q=dns/txt; s=iport; t=1429825975; x=1431035575; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=nF1bfM4h+SOZ0mGJIJQDkXOOdEIGWXgsA6cheYw0TmQ=; b=d6DfE5EfvYSpyL44X11HCSOU+DMAVvgSs+zwf7RRnRQaW+NYFpRxUkcF ndP9Nbyxl//8bSQ6SIy4i2ESQ2DOhxsZPvMR6jnZBcgxx0yrFN5SAC52E zKAYeHP2cUQtJwiOIs1V8dGCLGj+hwlbhchHxq/T1Se84ACswLdDiClAd c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BYBAAhaTlV/5xdJa1bgwxSVwUFgxXDCwmBRwqGBAKBNzgUAQEBAQEBAYEKhCEBAQQBAQEgSwoRCxgCAgUWCwICCQMCAQIBFTAGDQYCAQEFiCIIBbdXlQwBAQEBAQEBAwEBAQEBAQEbgSGKFoQ5GDoWglKBRQWLVIl3hjSBIjyDCYJPjhUjggIEHYFwUIFEgQABAQE X-IronPort-AV: E=Sophos;i="5.11,634,1422921600"; d="scan'208";a="144032342" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-5.cisco.com with ESMTP; 23 Apr 2015 21:52:54 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t3NLqsDH024529 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 23 Apr 2015 21:52:54 GMT Received: from [64.101.72.55] (64.101.72.55) by xhc-aln-x12.cisco.com (173.36.12.86) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 23 Apr 2015 16:52:54 -0500 Message-ID: <553969B5.6040508@cisco.com> Date: Thu, 23 Apr 2015 15:52:53 -0600 From: =?UTF-8?B?4oyYIE1hdHQgTWlsbGVy?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: References: <20150423215036.22102.37702.idtracker@ietfa.amsl.com> In-Reply-To: <20150423215036.22102.37702.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [64.101.72.55] Archived-At: Subject: Re: [dane] I-D Action: draft-ietf-dane-srv-14.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2015 21:53:04 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 This revision addresses the feedback from IESG review. - -- - - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. On 4/23/15 3:50 PM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the DNS-based > Authentication of Named Entities Working Group of the IETF. > > Title : Using DNS-Based Authentication of Named Entities > (DANE) TLSA Records with SRV Records Authors : Tony Finch > Matthew Miller Peter Saint-Andre Filename : > draft-ietf-dane-srv-14.txt Pages : 15 Date : > 2015-04-23 > > Abstract: The DANE specification (RFC 6698) describes how to use > TLSA resource records secured by DNSSEC (RFC 4033) to associate a > server's connection endpoint with its TLS certificate (thus > enabling administrators of domain names to specify the keys used in > that domain's TLS servers). However, application protocols that > use SRV records (RFC 2782) to indirectly name the target server > connection endpoints for a service domain cannot apply the rules > from RFC 6698. Therefore this document provides guidelines that > enable such protocols to locate and use TLSA records. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dane-srv/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-dane-srv-14 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-dane-srv-14 > > > Please note that it may take a couple of minutes from the time of > submission until the htmlized version and diff are available at > tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ dane mailing list > dane@ietf.org https://www.ietf.org/mailman/listinfo/dane > -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJVOWm1AAoJEDWi+S0W7cO1/7YH/2G2paEeLfMA74w4zNpmLeVw TwJTyLzG5d6oNDoxMS0+qvX4tQ44ytdhJRnJfFHFXFtnBO4tdYBkGG+nbBqoM++6 EJMen7LOx126YBnuC1TWRY6/cRmw/ZgJC/iWKbtCVas91DBkB6RMn3dOB0cXoq2P xBhgTRBS6qEG4MO7yzrag4NdXC9+JnWLvPHk1kSXuIaiCvCC0q1BRICY+jNGoI3H LpLC9z/4B8fO4+NhKB43B3+d2YtCTodGwJ8nQUGfv4fvEF3N93IQ30JM1qI1zIBI qjhz4YV5pX8O5QCJdlvuO5RLRyRSt7GaMsWGUVD7TF3WsmsEMcDXPkTBTllzD8s= =g5sl -----END PGP SIGNATURE----- From nobody Sun Apr 26 11:34:03 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76D011B2C2E for ; Sun, 26 Apr 2015 11:33:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 9ftK5J6IvK62 for ; Sun, 26 Apr 2015 11:33:57 -0700 (PDT) Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BE351B2C3C for ; Sun, 26 Apr 2015 11:33:57 -0700 (PDT) Received: by lbbuc2 with SMTP id uc2so67666372lbb.2 for ; Sun, 26 Apr 2015 11:33:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=gSHBe/R6TgPNTMCwaY4+9ADq1mEMcwNiNHSd4LeAY48=; b=NPS8CkRae/yaFyxmmkGGjoqaS6NUjm2O6hjzMQpXNQPkKlqPIM3ksdVU/oWapmyb10 iRVLMqyXU5c9gePDs7fSj2Pe7mukoWYNMfa1tqaTcQMYUyAN7Qo3LKbCgH0y9zCJO/LV pRQMaMT/u3OdrDxOXzIq0kVY3ccJAccmbdim3HDflsqusaoZksT4hLC9zdFA8X4FTjTy clVOTVDqmQXU07nvatHFGOkm83WbxynS9FhF49YRYYinaayE/uMAapXpY9UK4bMod3Lm G8H+61YwwJ7oYc16TxJ5mw5KL4+PnO3ds2vrjVhIcb5d1RAD+//ISn7N5fkZnxJfDewf 3imQ== MIME-Version: 1.0 X-Received: by 10.152.88.99 with SMTP id bf3mr6876748lab.97.1430073235721; Sun, 26 Apr 2015 11:33:55 -0700 (PDT) Received: by 10.114.176.169 with HTTP; Sun, 26 Apr 2015 11:33:55 -0700 (PDT) Date: Sun, 26 Apr 2015 19:33:55 +0100 Message-ID: From: Chris Monteiro To: dane@ietf.org Content-Type: multipart/alternative; boundary=001a11c3562e37d66b0514a4dffe Archived-At: Subject: [dane] Where to flesh out a DNSSEC extension proposal? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Apr 2015 18:33:58 -0000 --001a11c3562e37d66b0514a4dffe Content-Type: text/plain; charset=UTF-8 Hi all Apologies is this in an inappropriate list, but I'm unfamiliar with the channels for opening discussions about new web standards and this list seemed least inappropriate. :) I've blogged a proposal for a couple of DNS/ DNSSEC extensions that I would be interested in taking forward to the next stage. Would anyone be able to direct me to the correct channel for my proposal? http://pirate.london/2015/04/using-dns-records-to-build-a-more-secure-web/ --001a11c3562e37d66b0514a4dffe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all

Apologies is this in an inappropriate list, = but I'm unfamiliar with the channels for opening discussions about new = web standards and this list seemed least inappropriate. :)

I've = blogged a proposal for a couple of DNS/ DNSSEC extensions that I would be i= nterested in taking forward to the next stage.

Would anyone be able = to direct me to the correct channel for my proposal?
http://= pirate.london/2015/04/using-dns-records-to-build-a-more-secure-web/ --001a11c3562e37d66b0514a4dffe-- From nobody Sun Apr 26 11:37:21 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C23201B2C32 for ; Sun, 26 Apr 2015 11:37:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kyo2ZzS7hwJ3 for ; Sun, 26 Apr 2015 11:37:16 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 286DA1B2C3E for ; Sun, 26 Apr 2015 11:37:15 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3lZdJ908gvzC3P; Sun, 26 Apr 2015 20:37:13 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=TIHAJzYd X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id fZKqyOe4s1EF; Sun, 26 Apr 2015 20:37:11 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Sun, 26 Apr 2015 20:37:11 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id B042F809F8; Sun, 26 Apr 2015 14:37:09 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1430073429; bh=2GRfEA7IagnEUJnFQl4IBB4yvMeAAVe5+DscDRBSurQ=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=TIHAJzYdEsmFjOV2xzdgQqarruYmfwwJdGM04HDA53LIgCRRGCU41p3s5vfoHkS8t NuiYMuLGKMffnIkn01ZunOemSBuox5wIP9dZq88v2IX9VxgXL/B/7BzqSyzeYDUk8J BBUBPbkU3vtFzYocToOYdjUyKFyfNTTgZYez6lHs= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id t3QIb9uQ023548; Sun, 26 Apr 2015 14:37:09 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Sun, 26 Apr 2015 14:37:08 -0400 (EDT) From: Paul Wouters To: Chris Monteiro In-Reply-To: Message-ID: References: User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: dane@ietf.org Subject: Re: [dane] Where to flesh out a DNSSEC extension proposal? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Apr 2015 18:37:19 -0000 On Sun, 26 Apr 2015, Chris Monteiro wrote: > Apologies is this in an inappropriate list, but I'm unfamiliar with the channels for opening discussions about new web standards and this list seemed > least inappropriate. :) > > I've blogged a proposal for a couple of DNS/ DNSSEC extensions that I would be interested in taking forward to the next stage. > > Would anyone be able to direct me to the correct channel for my proposal? > http://pirate.london/2015/04/using-dns-records-to-build-a-more-secure-web/ Why publish HSTS information when you can publish the public key as well using a TLSA record? Basically, the presence of a TLSA record means the same as HSTS, "do connect with encryption please". Paul From nobody Sun Apr 26 12:41:37 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A6A71A036C for ; Sun, 26 Apr 2015 12:41:36 -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 Au5N4HJToMF0 for ; Sun, 26 Apr 2015 12:41:35 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03BCC1A0368 for ; Sun, 26 Apr 2015 12:41:34 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 9AC78283031; Sun, 26 Apr 2015 19:41:33 +0000 (UTC) Date: Sun, 26 Apr 2015 19:41:33 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150426194133.GZ25758@mournblade.imrryr.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dane] Where to flesh out a DNSSEC extension proposal? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Apr 2015 19:41:36 -0000 On Sun, Apr 26, 2015 at 02:37:08PM -0400, Paul Wouters wrote: > >I've blogged a proposal for a couple of DNS/ DNSSEC extensions that I would be interested in taking forward to the next stage. > > > >Would anyone be able to direct me to the correct channel for my proposal? > >http://pirate.london/2015/04/using-dns-records-to-build-a-more-secure-web/ > > Why publish HSTS information when you can publish the public key as well > using a TLSA record? Basically, the presence of a TLSA record means the > same as HSTS, "do connect with encryption please". Yes, to harden opportunistic TLS via DNSSEC, use DANE TLSA RRs, which for clients that support the approach kill two birds with one stone: * Whether to authenticate * How to authenticate https://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-16#section-2.2 https://tools.ietf.org/html/draft-ietf-dane-srv-13#section-4 -- Viktor. From nobody Sun Apr 26 13:50:36 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 210B41A909F for ; Sun, 26 Apr 2015 13:50:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, 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 VMccDVP4_fHJ for ; Sun, 26 Apr 2015 13:50:34 -0700 (PDT) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E87961A909B for ; Sun, 26 Apr 2015 13:50:33 -0700 (PDT) Received: by lbbuc2 with SMTP id uc2so68847499lbb.2 for ; Sun, 26 Apr 2015 13:50:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=kEIqdjXkn5JQhscwNUFGRaw+cXy9zF3yC1HiRi/c0K8=; b=nrKjTDFVgmDwVnZ2pQmhJPkABIzJe73L/OfbyEbWFITrC94lmv3ueRVJqj9Eh544M/ D+1anEOvHxuduXDWHSFkQWl12/iyHTaSWuNTeRhP0fvdKnmVzX9x4lMH833kT7dotAjw F+qaK3pUjck5jC5RBYX+GhDT53+HtAbYYN+2L3A6rfCDC2fs+aHWmgP4q9/CK/txl+8X szV9POPhX2my2umNi1KxUwLkwzvD2Yd97Hj6iQGgXKfNiEcoRuVFmc8SKQma1sMmbpU3 R4aNDqqQ1Gp4wzDZ9EMeOLfxvhShwYXPKUuv4CABkIyRgvcGFuvom/ceppDXfwXwZrBV e0Qg== MIME-Version: 1.0 X-Received: by 10.152.183.200 with SMTP id eo8mr7436913lac.57.1430081432453; Sun, 26 Apr 2015 13:50:32 -0700 (PDT) Received: by 10.114.176.169 with HTTP; Sun, 26 Apr 2015 13:50:32 -0700 (PDT) In-Reply-To: <20150426194133.GZ25758@mournblade.imrryr.org> References: <20150426194133.GZ25758@mournblade.imrryr.org> Date: Sun, 26 Apr 2015 21:50:32 +0100 Message-ID: From: Chris Monteiro To: dane@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [dane] Where to flesh out a DNSSEC extension proposal? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Apr 2015 20:50:35 -0000 Great, it looks like the proposed standard for hardening SMTP/TLS could be repurposed for either http(s) or arbitrary ports as per my proposal no? Separate email thread for my alternate names suggestions? On Sun, Apr 26, 2015 at 8:41 PM, Viktor Dukhovni wrote: > On Sun, Apr 26, 2015 at 02:37:08PM -0400, Paul Wouters wrote: > >> >I've blogged a proposal for a couple of DNS/ DNSSEC extensions that I would be interested in taking forward to the next stage. >> > >> >Would anyone be able to direct me to the correct channel for my proposal? >> >http://pirate.london/2015/04/using-dns-records-to-build-a-more-secure-web/ >> >> Why publish HSTS information when you can publish the public key as well >> using a TLSA record? Basically, the presence of a TLSA record means the >> same as HSTS, "do connect with encryption please". > > Yes, to harden opportunistic TLS via DNSSEC, use DANE TLSA RRs, > which for clients that support the approach kill two birds with > one stone: > > * Whether to authenticate > * How to authenticate > > https://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-16#section-2.2 > https://tools.ietf.org/html/draft-ietf-dane-srv-13#section-4 > > -- > Viktor. > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From nobody Sun Apr 26 13:59:22 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 344AB1A6F12 for ; Sun, 26 Apr 2015 13:59:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hwA6la8ocGSw for ; Sun, 26 Apr 2015 13:59:20 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEB7C1A8757 for ; Sun, 26 Apr 2015 13:59:19 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3lZhS34htWz9nj; Sun, 26 Apr 2015 22:59:15 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=T/EXmrrU X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id kCjYDbWeQ95f; Sun, 26 Apr 2015 22:59:13 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Sun, 26 Apr 2015 22:59:13 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id AE5B0817AF; Sun, 26 Apr 2015 16:59:12 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1430081952; bh=EO85tAEThseTqRpDkfqCjFvb/fM4a/cLw2Y+MfVAMaQ=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=T/EXmrrUCPMgQY7VwugiWs3NE8Zma03jPBQExoZVuFEDiWH/9CpnPGeAbuKY7fJdB HaH8pbZQf7XG7KvyND79T3waxyzymUjI9VNxg/5AifILO4D/julI1iwl5vzgj3JZCS BrOXda/DjkPOa/HntwAI1qutJ6m77dKvRU9lu7LU= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id t3QKxCns009132; Sun, 26 Apr 2015 16:59:12 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Sun, 26 Apr 2015 16:59:12 -0400 (EDT) From: Paul Wouters To: Chris Monteiro In-Reply-To: Message-ID: References: <20150426194133.GZ25758@mournblade.imrryr.org> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: dane@ietf.org Subject: Re: [dane] Where to flesh out a DNSSEC extension proposal? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Apr 2015 20:59:22 -0000 On Sun, 26 Apr 2015, Chris Monteiro wrote: > Great, it looks like the proposed standard for hardening SMTP/TLS > could be repurposed for either http(s) or arbitrary ports as per my > proposal no? There is nothing left to harden. The presence of TLSA means, never go to the insecure port. I tried to get this meaing into the original TLSA spec, and there was resistence to it. It was sidetracked into the HASTLS record, which never saw the light. I'm not sure if the DANE OPS (SRV) draft clarifies this, but any sane client implementation of TLSA should really assume this. Paul From nobody Sun Apr 26 14:26:18 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 759B11A1B34 for ; Sun, 26 Apr 2015 14:26:17 -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 fcHWi9tg8IZx for ; Sun, 26 Apr 2015 14:26:16 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BCD01A1BE7 for ; Sun, 26 Apr 2015 14:26:16 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id D3266283031; Sun, 26 Apr 2015 21:26:14 +0000 (UTC) Date: Sun, 26 Apr 2015 21:26:14 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150426212614.GB25758@mournblade.imrryr.org> References: <20150426194133.GZ25758@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dane] Where to flesh out a DNSSEC extension proposal? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Apr 2015 21:26:17 -0000 On Sun, Apr 26, 2015 at 04:59:12PM -0400, Paul Wouters wrote: > >Great, it looks like the proposed standard for hardening SMTP/TLS > >could be repurposed for either http(s) or arbitrary ports as per my > >proposal no? > > There is nothing left to harden. The presence of TLSA means, never go > to the insecure port. Yes, when the client is not already committed to using TLS, i.e. it is opportunistic. > I tried to get this meaing into the original TLSA spec, and there was > resistence to it. It was sidetracked into the HASTLS record, which never > saw the light. I'm not sure if the DANE OPS (SRV) draft clarifies this, > but any sane client implementation of TLSA should really assume this. We don't currently have a generic "opportunistic DANE TLS" document, the SMTP draft directly specifies this behaviour for SMTP. The SRV draft mostly does the same, withouth explicitly calling this out as being opportunistic. I expect the OPS draft LC to start any day now. If it should generalize this observation, this is a good time to suggest suitable language. When I started work on what is now the SMTP draft, it originally was a generic opportunistic DANE TLS document. It later split into SMTP and OPS, with the former not covering non-SMTP use-cases, and the latter not covering opportunistic security. -- Viktor. From nobody Sun Apr 26 15:42:09 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BDB61A9118 for ; Sun, 26 Apr 2015 15:42:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dcSZemTdgL2u for ; Sun, 26 Apr 2015 15:42:07 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 766741A89E1 for ; Sun, 26 Apr 2015 15:42:04 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3lZkkd5vYqz9nj for ; Mon, 27 Apr 2015 00:42:01 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=iVVklF+K X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id I2BEB25G3UOc for ; Mon, 27 Apr 2015 00:41:59 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for ; Mon, 27 Apr 2015 00:41:59 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 80982817AF for ; Sun, 26 Apr 2015 18:41:58 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1430088118; bh=az5zd981TOMEAFoz/C7EkgkQG0L9s1OH73GPddpPz/s=; h=Date:From:To:Subject:In-Reply-To:References; b=iVVklF+Kb5eSFgot6tNCkj1bxkYR8rCIywENzfuXUFbsMuNCFNyUJ6Swe10hNowgi E49ULDsJ2Z6PX/Matb7qRmI1xAv87zvX5JmvnVwXqPSoHTWUbafr5U51S0wnkCbpky sIKcFuwtvBI4he0kQVVcnyV/gyrE+jkZpmZOiMyE= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id t3QMfwAa012689 for ; Sun, 26 Apr 2015 18:41:58 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Sun, 26 Apr 2015 18:41:58 -0400 (EDT) From: Paul Wouters To: dane@ietf.org In-Reply-To: <20150426212614.GB25758@mournblade.imrryr.org> Message-ID: References: <20150426194133.GZ25758@mournblade.imrryr.org> <20150426212614.GB25758@mournblade.imrryr.org> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dane] Where to flesh out a DNSSEC extension proposal? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Apr 2015 22:42:09 -0000 On Sun, 26 Apr 2015, Viktor Dukhovni wrote: > On Sun, Apr 26, 2015 at 04:59:12PM -0400, Paul Wouters wrote: > >>> Great, it looks like the proposed standard for hardening SMTP/TLS >>> could be repurposed for either http(s) or arbitrary ports as per my >>> proposal no? >> >> There is nothing left to harden. The presence of TLSA means, never go >> to the insecure port. > > Yes, when the client is not already committed to using TLS, i.e. it is > opportunistic. Unfortunately, the use of the standalone word "opportunistic" is confusing as it means different things. >> I tried to get this meaing into the original TLSA spec, and there was >> resistence to it. It was sidetracked into the HASTLS record, which never >> saw the light. I'm not sure if the DANE OPS (SRV) draft clarifies this, >> but any sane client implementation of TLSA should really assume this. > > We don't currently have a generic "opportunistic DANE TLS" document, > the SMTP draft directly specifies this behaviour for SMTP. The > SRV draft mostly does the same, withouth explicitly calling this > out as being opportunistic. > > I expect the OPS draft LC to start any day now. If it should > generalize this observation, this is a good time to suggest suitable > language. I'm behind on my dane and dnsop document reading :( > When I started work on what is now the SMTP draft, it originally > was a generic opportunistic DANE TLS document. It later split into > SMTP and OPS, with the former not covering non-SMTP use-cases, and > the latter not covering opportunistic security. The opportune part is "hey, they are publishing a key to use for crypto". Once you're at that stage, doing TLS is not optional, but mandatory (IMHO, because people did not want to commit to this in the original DANE RFC) Paul From nobody Sun Apr 26 15:46:19 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 142FA1A9168 for ; Sun, 26 Apr 2015 15:46:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 pP_Fw8SFlGtF for ; Sun, 26 Apr 2015 15:46:16 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 179311A9167 for ; Sun, 26 Apr 2015 15:46:16 -0700 (PDT) Received: from kitterma-e6430.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 3E302C4016C for ; Sun, 26 Apr 2015 17:46:15 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1430088375; bh=VhU9Y9izHRGgS9jgXRADqd7h++dunalT6d1R4W5flVo=; h=From:To:Subject:Date:In-Reply-To:References:From; b=tSfajfyZ9V4SwCtiwxZAKE0mLJlUG6oaulRmJZxQk9SdtAyvtyHUg9fpgyNqnHNDd mY9eh8cYZ8xtvUX3GwrPLCaG+h38DDVOmrGtv2PGCjekhAHfsupOlXTFAtHqRLfHud /gp1tN9A6XY0Gyi35SvMDhB3WlqD2JTDh7A+Lzds= From: Scott Kitterman To: dane@ietf.org Date: Sun, 26 Apr 2015 18:46:15 -0400 Message-ID: <1831414.1DyHzYZhP0@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-49-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: References: <20150426212614.GB25758@mournblade.imrryr.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dane] Where to flesh out a DNSSEC extension proposal? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Apr 2015 22:46:18 -0000 On Sunday, April 26, 2015 06:41:58 PM Paul Wouters wrote: > On Sun, 26 Apr 2015, Viktor Dukhovni wrote: > > On Sun, Apr 26, 2015 at 04:59:12PM -0400, Paul Wouters wrote: > >>> Great, it looks like the proposed standard for hardening SMTP/TLS > >>> could be repurposed for either http(s) or arbitrary ports as per my > >>> proposal no? > >> > >> There is nothing left to harden. The presence of TLSA means, never go > >> to the insecure port. > > > > Yes, when the client is not already committed to using TLS, i.e. it is > > opportunistic. > > Unfortunately, the use of the standalone word "opportunistic" is > confusing as it means different things. > > >> I tried to get this meaing into the original TLSA spec, and there was > >> resistence to it. It was sidetracked into the HASTLS record, which never > >> saw the light. I'm not sure if the DANE OPS (SRV) draft clarifies this, > >> but any sane client implementation of TLSA should really assume this. > > > > We don't currently have a generic "opportunistic DANE TLS" document, > > the SMTP draft directly specifies this behaviour for SMTP. The > > SRV draft mostly does the same, withouth explicitly calling this > > out as being opportunistic. > > > > I expect the OPS draft LC to start any day now. If it should > > generalize this observation, this is a good time to suggest suitable > > language. > > I'm behind on my dane and dnsop document reading :( > > > When I started work on what is now the SMTP draft, it originally > > was a generic opportunistic DANE TLS document. It later split into > > SMTP and OPS, with the former not covering non-SMTP use-cases, and > > the latter not covering opportunistic security. > > The opportune part is "hey, they are publishing a key to use for > crypto". Once you're at that stage, doing TLS is not optional, but > mandatory (IMHO, because people did not want to commit to this > in the original DANE RFC) Given https://tools.ietf.org/html/rfc7435 I don't see where there's ambiguity about what opportunistic is. Scott K From nobody Sun Apr 26 15:51:38 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1E811A9233 for ; Sun, 26 Apr 2015 15:51:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, 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 fnwuW3qEBM1y for ; Sun, 26 Apr 2015 15:51:36 -0700 (PDT) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEBA61A9175 for ; Sun, 26 Apr 2015 15:51:35 -0700 (PDT) Received: by labbd9 with SMTP id bd9so67839430lab.2 for ; Sun, 26 Apr 2015 15:51:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=zrAbflOQeVRdoFb0euHBPDW4bRNhp0Q1CngAqgoX1D8=; b=mf3s4R1vbi0P1Jgy8yroAq/CqZ41qj7V8e2KFdz0Icu1QU0CKl4o6YleJ6C1afx7D/ AyBLPr6YEKG0JcEU07HQsSxdfcxr/JCmJkQshHO2yBWbbUZGyhmtoI5b5M5oxxz/ue/J hpKxa0htEL89micVOA8K8LOM03WJyzwWbEVOtTQxeQEy29zs24jz9+JoOpUPFswjapdX aYnrCIuDwy08M42Rayv8C8fpwJPJBfcW4EvwwotQcosqvAv6Tqo/k1MhsPjO/NG0jlh3 618a7aluOAjvxmCiRYjO9koT4XI07/VvA6aXtgVuJuZrdBLLGb3M5CqKYB3IFrGY/lu0 94kw== MIME-Version: 1.0 X-Received: by 10.112.72.132 with SMTP id d4mr7676671lbv.1.1430088694214; Sun, 26 Apr 2015 15:51:34 -0700 (PDT) Received: by 10.114.176.169 with HTTP; Sun, 26 Apr 2015 15:51:34 -0700 (PDT) In-Reply-To: References: <20150426194133.GZ25758@mournblade.imrryr.org> Date: Sun, 26 Apr 2015 23:51:34 +0100 Message-ID: From: Chris Monteiro To: dane@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [dane] Where to flesh out a DNSSEC extension proposal? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Apr 2015 22:51:37 -0000 Reading up on HASTLS, it appears at first glance that the ins-port / sec-port etc combinations covers my use-case of advertising and preferring a secure connection. Is there any activity with HASTLS that I could contribute to? On Sun, Apr 26, 2015 at 9:59 PM, Paul Wouters wrote: > On Sun, 26 Apr 2015, Chris Monteiro wrote: > >> Great, it looks like the proposed standard for hardening SMTP/TLS >> could be repurposed for either http(s) or arbitrary ports as per my >> proposal no? > > > There is nothing left to harden. The presence of TLSA means, never go > to the insecure port. > > I tried to get this meaing into the original TLSA spec, and there was > resistence to it. It was sidetracked into the HASTLS record, which never > saw the light. I'm not sure if the DANE OPS (SRV) draft clarifies this, > but any sane client implementation of TLSA should really assume this. > > Paul From nobody Sun Apr 26 15:56:23 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62A051A92B0 for ; Sun, 26 Apr 2015 15:56:21 -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 9gIxbTBnDxqh for ; Sun, 26 Apr 2015 15:56:20 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30FE11A924B for ; Sun, 26 Apr 2015 15:56:20 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 015B7283031; Sun, 26 Apr 2015 22:56:18 +0000 (UTC) Date: Sun, 26 Apr 2015 22:56:18 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150426225618.GC25758@mournblade.imrryr.org> References: <20150426194133.GZ25758@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dane] Where to flesh out a DNSSEC extension proposal? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Apr 2015 22:56:21 -0000 On Sun, Apr 26, 2015 at 11:51:34PM +0100, Chris Monteiro wrote: > Reading up on HASTLS, it appears at first glance that the ins-port / > sec-port etc combinations covers my use-case of advertising and > preferring a secure connection. > > Is there any activity with HASTLS that I could contribute to? He's dead Jim. TLSA records subsume whatever purpose HASTLS might have served. Long live the King. -- Viktor. From nobody Sun Apr 26 16:23:46 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 585BA1ACD10 for ; Sun, 26 Apr 2015 16:23:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, 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 SXHhgHiPGg_3 for ; Sun, 26 Apr 2015 16:23:43 -0700 (PDT) Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21C6F1ACD0A for ; Sun, 26 Apr 2015 16:23:43 -0700 (PDT) Received: by lbbzk7 with SMTP id zk7so70116371lbb.0 for ; Sun, 26 Apr 2015 16:23:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=m620wllcuLZzycZU0NPlQQZrQTk2ZQmEufxJv2evKbA=; b=j6Pi3iXI38NiXhWsqPymh5gJoo1PESL1KpxjNK7tlvV3AEj5dFl4Tjv6DhFxp1fccS HsgIWkvzZLRO0Zw7RkA3/DeczEgQgqhpbomW0gYBzSsG0H1RSweCVwP+mZg5E80Q98CM DH/bdy5lu+5mvLV1KnXdYemU1nwfdIld7yZmnnkayHQRx/Y46Oy7mr1EC/n9JUmLGEYG A4wjNGW9QyoyPixj6MYIRoaIIjJ3MyekloP9fC/xQTzFDQeVbBK/8wmdogzvdGZvbqx+ qHspYxDh8qCIhuMi4kJMqMz2KeszXzJ4kox6a5HY9lmgTaldqM1N7s58OBa6GefLa6GF Qbvg== MIME-Version: 1.0 X-Received: by 10.152.22.72 with SMTP id b8mr7756912laf.1.1430090620623; Sun, 26 Apr 2015 16:23:40 -0700 (PDT) Received: by 10.114.176.169 with HTTP; Sun, 26 Apr 2015 16:23:40 -0700 (PDT) In-Reply-To: <20150426225618.GC25758@mournblade.imrryr.org> References: <20150426194133.GZ25758@mournblade.imrryr.org> <20150426225618.GC25758@mournblade.imrryr.org> Date: Mon, 27 Apr 2015 00:23:40 +0100 Message-ID: From: Chris Monteiro To: dane@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [dane] Where to flesh out a DNSSEC extension proposal? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Apr 2015 23:23:45 -0000 Right, so reading up on TLSA, I can see how the port, certificate and certificate metadata are defined together and obviously I think this is a great implementation to kill of CAs as we know them. However, I don't see why the TLSA syntax must require the preferred port AND the certificate hash as well. A systems administrator want to only specify use of say 443/TLS whilst relying on the existing CA system for certificate validation. Sure this is not where we want to be long term, but allowing to implement partial TLSA features would simplify things wouldn't it? Therefore I believe my proposal is to allow a cut-down implementation of TLSA for this purpose. On Sun, Apr 26, 2015 at 11:56 PM, Viktor Dukhovni wrote: > On Sun, Apr 26, 2015 at 11:51:34PM +0100, Chris Monteiro wrote: > >> Reading up on HASTLS, it appears at first glance that the ins-port / >> sec-port etc combinations covers my use-case of advertising and >> preferring a secure connection. >> >> Is there any activity with HASTLS that I could contribute to? > > He's dead Jim. TLSA records subsume whatever purpose HASTLS might > have served. Long live the King. > > -- > Viktor. > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From nobody Sun Apr 26 16:35:23 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F72D1AC442 for ; Sun, 26 Apr 2015 16:35:22 -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 Em9f1pJ_r_Mq for ; Sun, 26 Apr 2015 16:35:21 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BFAF1AC3FF for ; Sun, 26 Apr 2015 16:35:21 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id E1BCD283031; Sun, 26 Apr 2015 23:35:19 +0000 (UTC) Date: Sun, 26 Apr 2015 23:35:19 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150426233519.GE25758@mournblade.imrryr.org> References: <20150426194133.GZ25758@mournblade.imrryr.org> <20150426225618.GC25758@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dane] Where to flesh out a DNSSEC extension proposal? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Apr 2015 23:35:22 -0000 On Mon, Apr 27, 2015 at 12:23:40AM +0100, Chris Monteiro wrote: > Right, so reading up on TLSA, I can see how the port, certificate and > certificate metadata are defined together and obviously I think this > is a great implementation to kill of CAs as we know them. This is the DANE working group mailing list, I think this is off topic. > However, I don't see why the TLSA syntax must require the preferred > port AND the certificate hash as well. A systems administrator want to > only specify use of say 443/TLS whilst relying on the existing CA > system for certificate validation. Sure this is not where we want to > be long term, but allowing to implement partial TLSA features would > simplify things wouldn't it? The administrator can use DANE-TA(2) or PKIX-TA(0) (whichever is better applicable to the application protocol in question). And then need not publish the particular server certificate. > Therefore I believe my proposal is to allow a cut-down implementation > of TLSA for this purpose. No, you're just new to the issues, and have not thought them through yet. Take your time. You can follow-up on dane-users@sys4.de if you like, that's a user forum, not an IETF WG list. -- Viktor. From nobody Sun Apr 26 18:16:39 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC0E41B2CE2 for ; Sun, 26 Apr 2015 18:16:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.752 X-Spam-Level: X-Spam-Status: No, score=-0.752 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FB_YOU_CAN_BECOME=1.258, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gfK0nUC1nwQg for ; Sun, 26 Apr 2015 18:16:36 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AE6D1B2CD1 for ; Sun, 26 Apr 2015 18:16:36 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3lZp8v48lgz9nj; Mon, 27 Apr 2015 03:16:31 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=XN9A37vA X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id FnouL-njv42V; Mon, 27 Apr 2015 03:16:30 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Mon, 27 Apr 2015 03:16:30 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 4FD9A809F8; Sun, 26 Apr 2015 21:16:29 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1430097389; bh=oVEsW1CVQWa+uPPh99Fva+SL46p9FN1A2ipWtNIVETw=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=XN9A37vAm7VDikYsOGrfVom9B3zuQxTPS78S7sGTYlSK9PhKSy/EIJ9e1Cp8JZ5If CvvuOAdIpfOSC1IqwPA0KMQrMEeB7Yz8rDvVaCSA63c11kTArZjVuOtCetuqkMj2fg 9ccnoCbvr4Slf1xxxH4TU31U/gA6P1nS2MV3LjcI= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id t3R1GSeW017979; Sun, 26 Apr 2015 21:16:29 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Sun, 26 Apr 2015 21:16:28 -0400 (EDT) From: Paul Wouters To: Scott Kitterman In-Reply-To: <1831414.1DyHzYZhP0@kitterma-e6430> Message-ID: References: <20150426212614.GB25758@mournblade.imrryr.org> <1831414.1DyHzYZhP0@kitterma-e6430> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: dane@ietf.org Subject: Re: [dane] Where to flesh out a DNSSEC extension proposal? 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, 27 Apr 2015 01:16:38 -0000 On Sun, 26 Apr 2015, Scott Kitterman wrote: >>>> There is nothing left to harden. The presence of TLSA means, never go >>>> to the insecure port. >>> >>> Yes, when the client is not already committed to using TLS, i.e. it is >>> opportunistic. >> The opportune part is "hey, they are publishing a key to use for >> crypto". Once you're at that stage, doing TLS is not optional, but >> mandatory (IMHO, because people did not want to commit to this >> in the original DANE RFC) > > Given https://tools.ietf.org/html/rfc7435 I don't see where there's ambiguity > about what opportunistic is. In Viktor's wording of "not already committed to using TLS" being equal to opportunistic. During the opportunistic (security) process you can become committed, so the phrasing of committed versus opportunistic is a little confusing/misleading, because opportunistic implies "can result in plaintext". In my view, using opportunistic can result in a commitment (hard fail) to TLS. That's why I thought Viktor's choice of words were confusing. Paul From nobody Sun Apr 26 19:50:47 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECBD91A1BAE for ; Sun, 26 Apr 2015 19:50:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.642 X-Spam-Level: X-Spam-Status: No, score=-0.642 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FB_YOU_CAN_BECOME=1.258] 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 04ad2IDKTfyr for ; Sun, 26 Apr 2015 19:50:44 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89DC61A1ABF for ; Sun, 26 Apr 2015 19:50:44 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 10783283031; Mon, 27 Apr 2015 02:50:43 +0000 (UTC) Date: Mon, 27 Apr 2015 02:50:43 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150427025042.GF25758@mournblade.imrryr.org> References: <20150426212614.GB25758@mournblade.imrryr.org> <1831414.1DyHzYZhP0@kitterma-e6430> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dane] Where to flesh out a DNSSEC extension proposal? 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, 27 Apr 2015 02:50:46 -0000 On Sun, Apr 26, 2015 at 09:16:28PM -0400, Paul Wouters wrote: > >Given https://tools.ietf.org/html/rfc7435 I don't see where there's ambiguity > >about what opportunistic is. > > In Viktor's wording of "not already committed to using TLS" being equal > to opportunistic. Sorry, "not initially/a-priori committed to using TLS". > During the opportunistic (security) process you can become committed, > so the phrasing of committed versus opportunistic is a little > confusing/misleading, because opportunistic implies "can result in > plaintext". > > In my view, using opportunistic can result in a commitment (hard fail) to TLS. 100% agreement. > That's why I thought Viktor's choice of words were confusing. Sorry about that. -- Viktor. From chrismmonteiro1@gmail.com Sun Apr 26 11:29:09 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 308251B2C23 for ; Sun, 26 Apr 2015 11:29:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, 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 X99CeH_8_0Fm for ; Sun, 26 Apr 2015 11:29:08 -0700 (PDT) Received: from mail-lb0-f170.google.com (mail-lb0-f170.google.com [209.85.217.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 138341B2C22 for ; Sun, 26 Apr 2015 11:29:08 -0700 (PDT) Received: by lbbuc2 with SMTP id uc2so67626032lbb.2 for ; Sun, 26 Apr 2015 11:29:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=; b=bNzkwZT0/HkT8tEE/o1NL2BXzM36OApq9UgzNqmUZKSxzS3Gkg4c3pXrogEzNcsBI+ Xwxu8p4Gf44i4FtS+LbpeAVgpfbslfXNxBEu8ljbfHfJzHqkk+Qx3CCdeWP0lJ1cjOIj TmaiY5P6U1M/lZ/TuBcawUmM5wUGT/rglvRzslGzOICBNX4u+Icmd173LqkMiVkpArWR imxTdWbam7KFYvzqOjxkwfHKB7jLFPaXNgOLAj5t4ykqjXWnckKJBrCSq3I4pvKxlyV5 rjQIjQaVGYXvqRdDBoEkO7Nn9TfMhil7ZcS2Eo5pMcD+UmnH3h3Wc3O5p7OzUPj9WW9W ZT8w== MIME-Version: 1.0 X-Received: by 10.112.72.132 with SMTP id d4mr7044998lbv.1.1430072945924; Sun, 26 Apr 2015 11:29:05 -0700 (PDT) Received: by 10.114.176.169 with HTTP; Sun, 26 Apr 2015 11:29:05 -0700 (PDT) Date: Sun, 26 Apr 2015 19:29:05 +0100 Message-ID: From: Chris Monteiro To: dane@ietfa.amsl.com Content-Type: text/plain; charset=UTF-8 Archived-At: X-Mailman-Approved-At: Mon, 27 Apr 2015 08:18:26 -0700 Subject: [dane] Where to flesh out a DNSSEC extension proposal? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Apr 2015 18:31:21 -0000 From nobody Mon Apr 27 09:14:37 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0C6B1A892F for ; Mon, 27 Apr 2015 09:14:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WDZvS09U29bR for ; Mon, 27 Apr 2015 09:14:34 -0700 (PDT) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B2021A8946 for ; Mon, 27 Apr 2015 09:14:34 -0700 (PDT) Received: by wiun10 with SMTP id n10so95980099wiu.1 for ; Mon, 27 Apr 2015 09:14:33 -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=I3TBJeGTUJiA2fJmsaDqkXFMUBLdHx46xoUdHFae/WI=; b=k1njT8fdj0F1R+U77X7RZoScoPhDft6XlEdivReyrKoQNjQlS37qCVnHCpsfhfPO5x o71pFcpIaK/ZXi1RxYBI5ujA2xLiCQbENVkCB7Dz41coF85wnKgsJpW1kPcYysYHobdF Ih3MlFSNL87ikK1QS8I+OLegSUfoJ+GqJ5pQOdH5fg0PSNW0zC9Ht596Nfx3DTcM1oD7 RaMzXOaBSJ1vWoVqMpaO6iH71uZv5YgWsSSWE74/GLvbMItX8VCaq1ufW01JigGhzK9p aQ5gpfn9hfn5nnTHPf01+WbeZmKIswTu4WWwAu2CTwwUm8S0a5/k/XuYvrkiq/SgCMeY smsA== X-Gm-Message-State: ALoCoQnIGM8UphLcw3PSjb8it02tN+QJTzVyZQKk7CkeOxJGFdq3KMrA4HvLMUYvC3yTbF/y1H20 MIME-Version: 1.0 X-Received: by 10.194.104.201 with SMTP id gg9mr23398240wjb.113.1430151272948; Mon, 27 Apr 2015 09:14:32 -0700 (PDT) Received: by 10.194.47.36 with HTTP; Mon, 27 Apr 2015 09:14:32 -0700 (PDT) Date: Mon, 27 Apr 2015 12:14:32 -0400 Message-ID: From: Warren Kumari To: "" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [dane] WGLC for draft-ietf-dane-ops-07 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, 27 Apr 2015 16:14:36 -0000 Dear DANE WG, The authors of draft-ietf-dane-ops have indicated that they believe that the document is ready, and have asked for Working Group Last Call (actually, they requested this a while back, we'd delayed while doing toe other docs...) The draft is available here: https://datatracker.ietf.org/doc/draft-ietf-dane-ops/ Please review this draft to see if you think it is ready for publication and send comments to the list, clearly stating your view. This WGLC ends Mon 11-May-2015. In addition, to satisfy RFC 6702 ("Promoting Compliance with Intellectual Property Rights (IPR)"): Are you personally aware of any IPR that applies to draft-ietf-dane-ops? If so, has this IPR been disclosed in compliance with IETF IPR rules? (See RFCs 3979, 4879, 3669, and 5378 for more details.) Thanks, Warren Kumari (as DANE WG co-chair) -- 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 Apr 27 11:01:28 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35EFB1A9064 for ; Mon, 27 Apr 2015 11:01:26 -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 SXUWNUpXbffa for ; Mon, 27 Apr 2015 11:01:24 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9960A1A904E for ; Mon, 27 Apr 2015 11:01:24 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 23F2B283032; Mon, 27 Apr 2015 18:01:23 +0000 (UTC) Date: Mon, 27 Apr 2015 18:01:23 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150427180122.GH20186@mournblade.imrryr.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dane] WGLC for draft-ietf-dane-ops-07 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, 27 Apr 2015 18:01:26 -0000 On Mon, Apr 27, 2015 at 12:14:32PM -0400, Warren Kumari wrote: > The authors of draft-ietf-dane-ops have indicated that they believe > that the document is ready, and have asked for Working Group Last Call > (actually, they requested this a while back, we'd delayed while doing > toe other docs...) > > The draft is available here: > https://datatracker.ietf.org/doc/draft-ietf-dane-ops/ > > Please review this draft to see if you think it is ready for > publication and send comments to the list, clearly stating your view. Thanks for getting this started. Much appreciated. This draft is normative for both the SRV and SMTP drafts which have progressed to the IESG and IETF LC respectively. So it is important to get this reviewed and moving along the process. Please read this draft carefully, and provide feedback as soon as you can. I'm not available for editing from mid May through early June, so I'd like to see the WG LC complete before then, and be back in action to make any changes that come out of IETF LC in June (IETF LC last week of May, first week of June would work fine). -- Viktor.