From nobody Mon Jun 1 07:06: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 4664D1ACE24 for ; Mon, 1 Jun 2015 07:06:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.885 X-Spam-Level: ** X-Spam-Status: No, score=2.885 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, 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 u1JHE-3QkSBj for ; Mon, 1 Jun 2015 07:06:07 -0700 (PDT) Received: from drpepper.rename-it.nl (drpepper.rename-it.nl [217.119.238.16]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7B1E1ACE23 for ; Mon, 1 Jun 2015 07:06:06 -0700 (PDT) Received: from lab.inertia-technology.com ([217.119.239.130]:54674 helo=[192.168.1.109]) by drpepper.rename-it.nl with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1YzQLq-0002TG-NQ for dane@ietf.org; Mon, 01 Jun 2015 16:06:04 +0200 Message-ID: <556C66B6.3050209@rename-it.nl> Date: Mon, 01 Jun 2015 16:05:42 +0200 From: Stephan Bosch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: dane@ietf.org Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-RenameIT-MailScanner-SpamScore: -2.3 (--) X-RenameIT-MailScanner-SpamCheck: No, score=-2.3 required=5.0 tests=ALL_TRUSTED, BAYES_00 autolearn=ham version=3.3.1 Archived-At: Subject: [dane] 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, 01 Jun 2015 14:06:10 -0000 Hi, I just read the dane-openpgpkey document and discussed it a bit with a friend. And now, we have a question. I must say, I haven't followed the discussions on this mailing list much lately, but I couldn't find an answer to this question by quickly browsing through the openpgp-related threads. From what I can tell, this document only describes how to publish and retrieve a key in DNS/DNSSEC, i.e. in what format. I don't see any mention of a procedure by which a key would get published. Since the domain would be controlled by the mail provider, the user cannot do this directly. So, how does a user go about getting his public key published in the DNS? What kind of interaction do you envision between the service provider and the mail user? Some kind of provider-specific web interface? Would it be useful to devise some standardized (sub-)protocol for this, so that a MUA can easily arrange this for the user (e.g. just after it generated the key pair)? Regards, Stephan. From nobody Mon Jun 1 08:47:34 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 2E2BD1B2B6C for ; Mon, 1 Jun 2015 08:47:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.69 X-Spam-Level: X-Spam-Status: No, score=0.69 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 gdCX4TDogD2e for ; Mon, 1 Jun 2015 08:47:31 -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 5439A1B2B09 for ; Mon, 1 Jun 2015 08:45:05 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3m0gmt4nNHz7tr; Mon, 1 Jun 2015 17:45:02 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=TsdzLxE8 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 6P11amKA4Dgq; Mon, 1 Jun 2015 17:45:01 +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, 1 Jun 2015 17:45:01 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 4717F800B6; Mon, 1 Jun 2015 11:45:00 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1433173500; bh=U7bqD78R8tJr12JWGyfKu8KBHyen0j92/MpbHuWUWNY=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=TsdzLxE8KR0v9P++JCoPTEJwrRdyz8W6876uytUUSawoUCa0MhXA8J6mjz1LSsjnz gFhukSR1L5dUO1ZyF3fRaHba22tmNrzwv4PSZRoUmIqffC/kst++nqWv0edp9wzsqN qFJpKeOzq4ROIF5I3KBdGOCRMeMDn9kY4nGfmhdo= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.15.1/8.15.1/Submit) with ESMTP id t51Fixm6008581; Mon, 1 Jun 2015 11:45:00 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Mon, 1 Jun 2015 11:44:59 -0400 (EDT) From: Paul Wouters To: Stephan Bosch In-Reply-To: <556C66B6.3050209@rename-it.nl> Message-ID: References: <556C66B6.3050209@rename-it.nl> User-Agent: Alpine 2.11 (LFD 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] 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, 01 Jun 2015 15:47:33 -0000 On Mon, 1 Jun 2015, Stephan Bosch wrote: > From what I can tell, this document only describes how to publish and > retrieve a key in DNS/DNSSEC, i.e. in what format. I don't see any mention of > a procedure by which a key would get published. Since the domain would be > controlled by the mail provider, the user cannot do this directly. So, how > does a user go about getting his public key published in the DNS? What kind > of interaction do you envision between the service provider and the mail > user? Some kind of provider-specific web interface? Would it be useful to > devise some standardized (sub-)protocol for this, so that a MUA can easily > arrange this for the user (e.g. just after it generated the key pair)? While that would be nice, the problem is how you authenticate that to your ISP or mail hoster, DNS hoster or DNS webgui interface. I doubt that you could find enough common ground for an authentication method between those parties. There are tools (like hash-slinger's openpgpkey command) that can generate the DNS records. Those have to somehow get inserted into the zone. Whatever the method is to get an A record in, is the method to get an OPENPGPKEY record in. It would be awesome if facebook (who announced pgp support today) or google or yahoo would allow some method of receiving your public key[*] but I would think those parties would convert your message into the appropriate DNS record format. Paul [*] For instance a message "please publis my key" signed with that key uploaded through their HTTPS / authentiacted website. From nobody Mon Jun 1 09:19: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 602681A0121 for ; Mon, 1 Jun 2015 09:19:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.084 X-Spam-Level: ** X-Spam-Status: No, score=2.084 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, 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 MZcIP74dnk7P for ; Mon, 1 Jun 2015 09:19:07 -0700 (PDT) Received: from drpepper.rename-it.nl (drpepper.rename-it.nl [217.119.238.16]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B573A1B2BDD for ; Mon, 1 Jun 2015 09:17:25 -0700 (PDT) Received: from lab.inertia-technology.com ([217.119.239.130]:56600 helo=[192.168.1.109]) by drpepper.rename-it.nl with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1YzSOv-0004pm-QF; Mon, 01 Jun 2015 18:17:23 +0200 Message-ID: <556C857A.7070509@rename-it.nl> Date: Mon, 01 Jun 2015 18:16:58 +0200 From: Stephan Bosch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Paul Wouters References: <556C66B6.3050209@rename-it.nl> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-RenameIT-MailScanner-SpamScore: -2.3 (--) X-RenameIT-MailScanner-SpamCheck: No, score=-2.3 required=5.0 tests=ALL_TRUSTED, BAYES_00 autolearn=ham version=3.3.1 Archived-At: Cc: dane@ietf.org Subject: Re: [dane] 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, 01 Jun 2015 16:19:10 -0000 Hi Paul, Paul Wouters schreef op 1-6-2015 om 17:44: > On Mon, 1 Jun 2015, Stephan Bosch wrote: > >> From what I can tell, this document only describes how to publish and >> retrieve a key in DNS/DNSSEC, i.e. in what format. I don't see any >> mention of a procedure by which a key would get published. Since the >> domain would be controlled by the mail provider, the user cannot do >> this directly. So, how does a user go about getting his public key >> published in the DNS? What kind of interaction do you envision >> between the service provider and the mail user? Some kind of >> provider-specific web interface? Would it be useful to devise some >> standardized (sub-)protocol for this, so that a MUA can easily >> arrange this for the user (e.g. just after it generated the key pair)? > > While that would be nice, the problem is how you authenticate that to > your ISP or mail hoster, DNS hoster or DNS webgui interface. Well, I suppose using the same credentials used to read/send e-mail? For this, I am assuming the mail hoster is the same entity that controls the domain and can freely modify the _openpgpkey.mail.domain.tld zone. So this would mean that a DNS update results from a user's key publication request, as received from a yet-to-devise protocol that is authenticated using SASL with the same credentials as IMAP/POP3 and SMTP-submission. It could even be done from within those protocols with some extension, e.g. using IMAP METADATA. Any other means would be fine too, as long as it is simple enough and a standard that MUAs can rely upon. > I doubt that you could find enough common ground for an authentication > method > between those parties. I hope there is some common ground to be found. Otherwise, I fear this new technology could fail in terms of user/MUA adoption. Getting the key out there should be as easy as possible. > There are tools (like hash-slinger's openpgpkey command) that can > generate the DNS records. Those have to somehow get inserted into the > zone. Whatever the method is to get an A record in, is the method to > get an OPENPGPKEY record in. > > It would be awesome if facebook (who announced pgp support today) or > google or yahoo would allow some method of receiving your public key[*] > but I would think those parties would convert your message into the > appropriate DNS record format. > [*] For instance a message "please publis my key" signed with that key > uploaded through their HTTPS / authentiacted website. Yes, but all of this would be provider-specific, which I think is bad. Regards, Stephan. From nobody Mon Jun 1 09:39: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 08A3D1B2ACC for ; Mon, 1 Jun 2015 09:39:04 -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 mlUhtdlHWhDn for ; Mon, 1 Jun 2015 09:39: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 8E8F91A1AB2 for ; Mon, 1 Jun 2015 09:39:02 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3m0hz91M26z7tr; Mon, 1 Jun 2015 18:39:01 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=Y1hmH92j 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 ZrQcdvV6S3b1; Mon, 1 Jun 2015 18:38:58 +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, 1 Jun 2015 18:38:58 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 7B4628004A; Mon, 1 Jun 2015 12:38:56 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1433176736; bh=BZQsS+fonbZh1rIJWFomWYYs3cU9mKDUlE62fckxQHA=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=Y1hmH92jK4fWHn4OVGZ6zYwhhY3q6+3VWAbAbmBH80O2JEAgeJLkFrLdz4e21MlCK Ffztu9MWMr/zitdmq7VCazFJA9DteS4MNJrBXsdOgf26fcjWGn0YRs7vcj2HVQfSzs dugiPszjwtnAlHmLbgELtWXjemxJ5S5xgdoM2z7E= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.15.1/8.15.1/Submit) with ESMTP id t51GctAm017522; Mon, 1 Jun 2015 12:38:56 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Mon, 1 Jun 2015 12:38:55 -0400 (EDT) From: Paul Wouters To: Stephan Bosch In-Reply-To: <556C857A.7070509@rename-it.nl> Message-ID: References: <556C66B6.3050209@rename-it.nl> <556C857A.7070509@rename-it.nl> User-Agent: Alpine 2.11 (LFD 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] 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, 01 Jun 2015 16:39:04 -0000 On Mon, 1 Jun 2015, Stephan Bosch wrote: >> While that would be nice, the problem is how you authenticate that to >> your ISP or mail hoster, DNS hoster or DNS webgui interface. > > Well, I suppose using the same credentials used to read/send e-mail? For > this, I am assuming the mail hoster is the same entity that controls the > domain and can freely modify the _openpgpkey.mail.domain.tld zone. So this > would mean that a DNS update results from a user's key publication request, > as received from a yet-to-devise protocol that is authenticated using SASL > with the same credentials as IMAP/POP3 and SMTP-submission. It could even be > done from within those protocols with some extension, e.g. using IMAP > METADATA. While this works, you have now reduced the openpgpkey security to an email password. Anyone with that password can now replace the openpgpkey of the user. While it is a good starting point, there would have to be more to secure it, for instance replacing could require a signing by the old key of the new key (or manual intervention using support@isp) > I hope there is some common ground to be found. Otherwise, I fear this new > technology could fail in terms of user/MUA adoption. Getting the key out > there should be as easy as possible. Agreed. And I think it would be useful to write another document on an SMTP/IMAP extension for doing so. I don't think it should go into the existing OPENPGPKEY DNS/DANE draft. > Yes, but all of this would be provider-specific, which I think is bad. Agreed it is terrible, but you'd want the openpgpkey to be somehow more secure than an email password (reset). Paul From nobody Mon Jun 1 11:32: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 360FB1B30CA; Mon, 1 Jun 2015 11:32:29 -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 y70WVZBb5Z8T; Mon, 1 Jun 2015 11:32:28 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A5D01B30DC; Mon, 1 Jun 2015 11:32:20 -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.3.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150601183220.17292.84613.idtracker@ietfa.amsl.com> Date: Mon, 01 Jun 2015 11:32:20 -0700 Archived-At: Cc: dane mailing list , dane chair , RFC Editor Subject: [dane] Protocol Action: 'SMTP security via opportunistic DANE TLS' to Proposed Standard (draft-ietf-dane-smtp-with-dane-19.txt) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2015 18:32:29 -0000 The IESG has approved the following document: - 'SMTP security via opportunistic DANE TLS' (draft-ietf-dane-smtp-with-dane-19.txt) as Proposed Standard This document is the product of the DNS-based Authentication of Named Entities Working Group. The IESG contact persons are Stephen Farrell and Kathleen Moriarty. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-dane-smtp-with-dane/ Technical Summary This document explains in detail how MTAs (Mail-Transfer-Agent) use TLSA records in setting up TLS protected sessions. This document is based on implementation and deployment experience. The document covers offers guidance on many corner cases in both in DANE TLS setup as well in mail transport. This document has been implemented in two major MTA distributions, and there is growing usage base. Working Group Summary There has been good solid discussion on this document, there is strong consensus about the whole document. Document Quality The document is detailed and covers many corner cases some of with are DNS related to email. The protocol specified here is tested in practice and that is reflected in the document. The document educates the readers about choices to avoid pitfalls in implementations and operations. Email people are encouraged to review the document. It is helpful to read this document along with its companion document draft-ietf-dane-srv-xx. The two document cross reference each other to avoid duplication. Personnel Document Shepherd: Olafur Gudmundsson Area Director: Stephen Farrell From nobody Mon Jun 1 11:44: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 42ABE1B311C for ; Mon, 1 Jun 2015 11:44:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.185 X-Spam-Level: X-Spam-Status: No, score=0.185 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, 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 eyxsE4SFnlmT for ; Mon, 1 Jun 2015 11:44:39 -0700 (PDT) Received: from drpepper.rename-it.nl (drpepper.rename-it.nl [217.119.238.16]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69D681B310D for ; Mon, 1 Jun 2015 11:44:38 -0700 (PDT) Received: from klara.student.utwente.nl ([130.89.162.218]:60275 helo=[10.168.3.2]) by drpepper.rename-it.nl with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1YzUhP-0007KH-88; Mon, 01 Jun 2015 20:44:37 +0200 Message-ID: <556CA7F2.7030200@rename-it.nl> Date: Mon, 01 Jun 2015 20:44:02 +0200 From: Stephan Bosch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Paul Wouters References: <556C66B6.3050209@rename-it.nl> <556C857A.7070509@rename-it.nl> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-RenameIT-MailScanner-SpamScore: -2.3 (--) X-RenameIT-MailScanner-SpamCheck: No, score=-2.3 required=5.0 tests=ALL_TRUSTED, BAYES_00 autolearn=ham version=3.3.1 Archived-At: Cc: dane@ietf.org Subject: Re: [dane] 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, 01 Jun 2015 18:44:41 -0000 Hi Paul, On 6/1/2015 6:38 PM, Paul Wouters wrote: > On Mon, 1 Jun 2015, Stephan Bosch wrote: > >>> While that would be nice, the problem is how you authenticate that t= o >>> your ISP or mail hoster, DNS hoster or DNS webgui interface. >> >> Well, I suppose using the same credentials used to read/send e-mail? >> For this, I am assuming the mail hoster is the same entity that >> controls the domain and can freely modify the >> _openpgpkey.mail.domain.tld zone. So this would mean that a DNS >> update results from a user's key publication request, as received >> from a yet-to-devise protocol that is authenticated using SASL with >> the same credentials as IMAP/POP3 and SMTP-submission. It could even >> be done from within those protocols with some extension, e.g. using >> IMAP METADATA. > > While this works, you have now reduced the openpgpkey security to an > email password. Anyone with that password can now replace the > openpgpkey of the user. While it is a good starting point, there would > have to be more to secure it, for instance replacing could require > a signing by the old key of the new key (or manual intervention using > support@isp) I think manual intervention is best avoided if at all possible. We could devise this new protocol (or whatever) as only a standard entry point for submitting a new key. What happens after submission does not strictly need to be standard. It could then involve some side-channel like sms or snailmail with some sort of (PIN) code and some subsequent confirmation, so that the key is only posted to the DNS once this provider-specific procedure is completed successfully. Submitting the final PIN code (or whatever) could also be part of the new protocol. So, then only the means by which this code is conveyed would be left unspecified. Also, if security requirements are less high, this secondary verification stage could be omitted, relying solely on the SASL authentication. This kind of procedure is used quite often already in the field for various types web services, and I think it could help here as well. >> I hope there is some common ground to be found. Otherwise, I fear >> this new technology could fail in terms of user/MUA adoption. Getting >> the key out there should be as easy as possible. > > Agreed. And I think it would be useful to write another document on an > SMTP/IMAP extension for doing so. Same story for S/MIME of course. > I don't think it should go into the existing OPENPGPKEY DNS/DANE draft.= > I agree. >> Yes, but all of this would be provider-specific, which I think is bad.= > > Agreed it is terrible, but you'd want the openpgpkey to be somehow more= > secure than an email password (reset). Yes. Regards, Stephan. From nobody Mon Jun 1 18:54:08 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 A2BC51A8837 for ; Mon, 1 Jun 2015 18:54:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 aULw01hphWBJ for ; Mon, 1 Jun 2015 18:54:06 -0700 (PDT) Received: from smtp124.ord1c.emailsrvr.com (smtp124.ord1c.emailsrvr.com [108.166.43.124]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D68C71A882E for ; Mon, 1 Jun 2015 18:54:05 -0700 (PDT) Received: from smtp8.relay.ord1c.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp8.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 7B4E5807B5 for ; Mon, 1 Jun 2015 21:54:04 -0400 (EDT) Received: by smtp8.relay.ord1c.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id EB6E28074A for ; Mon, 1 Jun 2015 21:54:02 -0400 (EDT) X-Sender-Id: ogud@ogud.com Received: from [192.168.1.61] (208-90-212-141.PUBLIC.monkeybrains.net [208.90.212.141]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:465 (trex/5.4.2); Tue, 02 Jun 2015 01:54:04 GMT From: Olafur Gudmundsson Content-Type: multipart/alternative; boundary="Apple-Mail=_B8B9288F-1D26-43CA-92F2-C1CF82A1521E" Message-Id: Date: Mon, 1 Jun 2015 21:54:02 -0400 To: dane WG list Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) X-Mailer: Apple Mail (2.2098) Archived-At: Subject: [dane] dane-smtp and Dane future X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 02 Jun 2015 01:54:07 -0000 --Apple-Mail=_B8B9288F-1D26-43CA-92F2-C1CF82A1521E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear Colleagues,=20 The latest version of the dane-smtp draft addresses all the issues = raised in IETF and IESG reviews and has entered the RFC editors queue = where it will wait for OPS document to catch up.=20 The chairs want to thank Victor for his outstanding work on getting the = draft to this point. This means that now that both the =E2=80=9CService=E2=80=9D DANE = documents have now entered the RFC editors queue and the OPS document is in IESG review. =20 We are reaching the point that the core DANE protocol work is complete.=20= At this point the WG has a choice as to what direction to take a) Finish work on OPENPGP and S/MIME documents and close down b) Start work on DANE-bis document(s) that combines the Protocol parts = of the 4 documents that define the DANE protocol.=20 c) Just work on promoting existing RFC along the standards track d) Identify and adopt other documents that are needed for DANE = adoptions/operations/specifications=20 Please provide guidance to chairs=20 Olafur & Warren=20 > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: [dane] I-D Action: draft-ietf-dane-smtp-with-dane-19.txt > Date: May 29, 2015 at 10:53:00 AM EDT > To: > > Cc: dane@ietf.org >=20 >=20 > 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. >=20 > Title : SMTP security via opportunistic DANE TLS > Authors : Viktor Dukhovni > Wes Hardaker > Filename : draft-ietf-dane-smtp-with-dane-19.txt > Pages : 32 > Date : 2015-05-29 --Apple-Mail=_B8B9288F-1D26-43CA-92F2-C1CF82A1521E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Dear Colleagues, 

The latest version of the dane-smtp draft addresses all the = issues raised in IETF and IESG reviews and has entered the RFC editors = queue where it will wait for OPS document to catch up. 
The chairs want to thank Victor for his outstanding work on = getting the draft to this point.

This means that now that both the = =E2=80=9CService=E2=80=9D DANE documents have now entered the RFC = editors queue
and the OPS document is in IESG = review.  

We are reaching the point that the core DANE protocol work is = complete. 
At this point the WG has a choice = as to what direction to take
a) Finish work on = OPENPGP and S/MIME documents and close down
b) = Start work on DANE-bis document(s) that combines the Protocol parts of = the 4 documents that define the DANE protocol. 
c) Just work on promoting existing RFC along the standards = track
d) Identify and adopt other documents that = are needed for DANE adoptions/operations/specifications 

Please provide guidance = to chairs 
Olafur & Warren 

Begin forwarded message:

From: internet-drafts@ietf.org
Subject: [dane] I-D Action: = draft-ietf-dane-smtp-with-dane-19.txt
Date: May 29, = 2015 at 10:53:00 AM EDT
To: <i-d-announce@ietf.org>
Cc: dane@ietf.org


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
          &nb= sp;            = ;  Wes Hardaker
Filename =        : = draft-ietf-dane-smtp-with-dane-19.txt
Pages =           : 32
= Date =            : = 2015-05-29
= --Apple-Mail=_B8B9288F-1D26-43CA-92F2-C1CF82A1521E-- From nobody Mon Jun 1 18:55: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 D6E061A883E for ; Mon, 1 Jun 2015 18:55: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 s7MthVamBanJ for ; Mon, 1 Jun 2015 18:55:43 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C1B91A884B for ; Mon, 1 Jun 2015 18:55:43 -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.3.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150602015543.561.31693.idtracker@ietfa.amsl.com> Date: Mon, 01 Jun 2015 18:55:43 -0700 From: IETF Secretariat Archived-At: Subject: [dane] Milestones changed for dane WG 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, 02 Jun 2015 01:55:45 -0000 Changed milestone "Advance DANE OPENPGP document to IESG", resolved as "Done". URL: https://datatracker.ietf.org/wg/dane/charter/ From nobody Mon Jun 1 19:16: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 05DD61A899F for ; Mon, 1 Jun 2015 19:16: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, 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 3Oxb87fV7eiZ for ; Mon, 1 Jun 2015 19:16: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 A89541A89A2 for ; Mon, 1 Jun 2015 19:16:15 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 93AC9284B56; Tue, 2 Jun 2015 02:16:14 +0000 (UTC) Date: Tue, 2 Jun 2015 02:16:14 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150602021614.GB5090@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] dane-smtp and Dane future X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2015 02:16:17 -0000 On Mon, Jun 01, 2015 at 09:54:02PM -0400, Olafur Gudmundsson wrote: > We are reaching the point that the core DANE protocol work is complete. > At this point the WG has a choice as to what direction to take > a) Finish work on OPENPGP and S/MIME documents and close down > b) Start work on DANE-bis document(s) that combines the Protocol parts of the 4 documents that define the DANE protocol. > c) Just work on promoting existing RFC along the standards track > d) Identify and adopt other documents that are needed for DANE adoptions/operations/specifications > > Please provide guidance to chairs I'm still inclined to write a client auth document for SMTP with DANE and perhaps more broadly, though signalling from the client to the server that triggers DANE authentication of the client will be application protocol specific. I was waiting for closure on the prior documents. I am also concerned that the working group does not have very many active participants, so getting feedback is a significant problem. If we're going to produce more documents, we need more active participation. -- Viktor. From nobody Mon Jun 1 19:24:07 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 B34631A8A0D for ; Mon, 1 Jun 2015 19:24:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XcM63PSwM9-J for ; Mon, 1 Jun 2015 19:24:05 -0700 (PDT) Received: from mail-ie0-f171.google.com (mail-ie0-f171.google.com [209.85.223.171]) (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 C39A71A8A08 for ; Mon, 1 Jun 2015 19:24:03 -0700 (PDT) Received: by iebgx4 with SMTP id gx4so123006523ieb.0 for ; Mon, 01 Jun 2015 19:24:03 -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=mA6Pnibd9XzBJYAKQCk1VOHeBi0Cv9//wBMpfu3bUcw=; b=JmdJySY0WI3UF2tq6bBS5rdzTYmQq/wmb/SnIXpBTNfVm+HqeMW50QqC+4KDpXH3Ap G/IR/GH0Kqw5Xio/wnY/pREkS5w8EbSxk+Y/96izuSDlKz7f041phnlcywCPjNXExsmo c0c7gcS8lU93ce9KPMvlniBJDqUt+Fn9Sx5cW7Ryse38I53dyxTpFSK1Dmd9TDL8gv/9 HjWjdhOtd50YjbdcTt+adbNeKUXiqX5uG/lReOlgCp4uWmrJayACri4rUJAYHc4ft/WN u/GDmR6egaFDht8pKErXD4rUz1GzT/Gyx5uUQ02HNWz78tfpWot85YnJIY/D2EoIqG51 L6XA== X-Gm-Message-State: ALoCoQnRrP5LOG95ux5Lx0UagkSrH2aNiAv16BC1gPw76w++2E8NXenIUWgf6JwlBUA6d0m5+RJs X-Received: by 10.107.165.210 with SMTP id o201mr31340452ioe.2.1433211842979; Mon, 01 Jun 2015 19:24:02 -0700 (PDT) Received: from aither.local ([2601:1:8200:3a60:2dae:f389:f39d:f97f]) by mx.google.com with ESMTPSA id f10sm9135976igt.7.2015.06.01.19.24.00 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 01 Jun 2015 19:24:01 -0700 (PDT) Message-ID: <556D13BF.9010605@andyet.net> Date: Mon, 01 Jun 2015 20:23:59 -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.7.0 MIME-Version: 1.0 To: dane@ietf.org References: <20150602021614.GB5090@mournblade.imrryr.org> In-Reply-To: <20150602021614.GB5090@mournblade.imrryr.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dane] dane-smtp and Dane future X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 02 Jun 2015 02:24:06 -0000 On 6/1/15 8:16 PM, Viktor Dukhovni wrote: > On Mon, Jun 01, 2015 at 09:54:02PM -0400, Olafur Gudmundsson wrote: > >> We are reaching the point that the core DANE protocol work is complete. >> At this point the WG has a choice as to what direction to take >> a) Finish work on OPENPGP and S/MIME documents and close down >> b) Start work on DANE-bis document(s) that combines the Protocol parts of the 4 documents that define the DANE protocol. >> c) Just work on promoting existing RFC along the standards track >> d) Identify and adopt other documents that are needed for DANE adoptions/operations/specifications >> >> Please provide guidance to chairs > > I'm still inclined to write a client auth document for SMTP with > DANE and perhaps more broadly, though signalling from the client > to the server that triggers DANE authentication of the client will > be application protocol specific. > > I was waiting for closure on the prior documents. > > I am also concerned that the working group does not have very many > active participants, so getting feedback is a significant problem. > > If we're going to produce more documents, we need more active > participation. Traditionally at the IETF, working groups start with a bang and end with a whimper. Expect less participation in the future, not more. We don't have to like it, but it's good to accept reality. Peter -- Peter Saint-Andre https://andyet.com/ From nobody Mon Jun 1 19:25:08 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 5B1EB1A8A0C for ; Mon, 1 Jun 2015 19:25:06 -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 OP_X37JLwr2U for ; Mon, 1 Jun 2015 19:25:05 -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 3E29D1A8A0B for ; Mon, 1 Jun 2015 19:25:05 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 51A24284B56; Tue, 2 Jun 2015 02:25:04 +0000 (UTC) Date: Tue, 2 Jun 2015 02:25:04 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150602022504.GC5090@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] dane-smtp and Dane future X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2015 02:25:06 -0000 On Mon, Jun 01, 2015 at 09:54:02PM -0400, Olafur Gudmundsson wrote: > This means that now that both the "Service" DANE documents have now entered > the RFC editors queue and the OPS document is in IESG review. Thanks. One quick note, I made a mistake in the most recent update to the OPS document. I'll push a "-12" version that fixes the problem. This will also add a note to explain why mixing "3 1 1" for a past SPKI with "2 0 1" for a replacement cert is wrong and the migragation from DANE-EE(3) to DANE-TA(2) was correct in "-10" (and is now wrong in "-11"). This is not anything new, just application of previous text to the migration example, but the example will help to clarify the text. -- Viktor. From nobody Mon Jun 1 20:04: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 882481A903A for ; Mon, 1 Jun 2015 20:04:51 -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 3AY6tQBXBS5W for ; Mon, 1 Jun 2015 20:04: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 A81041A8FD5 for ; Mon, 1 Jun 2015 20:04:49 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3m0ys9175kz7CL; Tue, 2 Jun 2015 05:04:45 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=O797xtwq 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 7VhW1lRo6MGN; Tue, 2 Jun 2015 05:04: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; Tue, 2 Jun 2015 05:04:43 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 6DF9180042; Mon, 1 Jun 2015 23:04:42 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1433214282; bh=6VNb+w8BysBeJyBLWzem6/HPpCtmArcUoSrzjCYdGuk=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=O797xtwqtiMd51KqtAONjTLIl6E/5WqGYh2E+ONJFzUH+N+xBaQfWAScc1kfe34+A ysrSqWiuUEbx9EByFE2c2D8JvQ7hS9RsyF0itVQLuWO6tNDREBTiL55ExV2cFHchgr yjxC1hHfWRiA+V3s4JXWykzIfNQ7p02uusOkJP6E= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.15.1/8.15.1/Submit) with ESMTP id t5234dOd010206; Mon, 1 Jun 2015 23:04:41 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Mon, 1 Jun 2015 23:04:38 -0400 (EDT) From: Paul Wouters To: Olafur Gudmundsson In-Reply-To: Message-ID: References: User-Agent: Alpine 2.11 (LFD 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Cc: dane WG list Subject: Re: [dane] dane-smtp and Dane future X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 02 Jun 2015 03:04:51 -0000 On Mon, 1 Jun 2015, Olafur Gudmundsson wrote: > The chairs want to thank Victor for his outstanding work on getting the draft to this point. Indeed. Thanks for your hard work on the specification and the implementation Viktor! > We are reaching the point that the core DANE protocol work is complete.  > At this point the WG has a choice as to what direction to take > a) Finish work on OPENPGP and S/MIME documents and close down Not against that. > b) Start work on DANE-bis document(s) that combines the Protocol parts of the 4 documents that define the > DANE protocol.  Not against that either, although that should not be interpreted as volunteering :) > c) Just work on promoting existing RFC along the standards track I'm a little concerned if we don't do this, where those documents will go to get discussed at all. SAAG? Then again, I think most of the new work would mostly be based on the existing documents, and not contain much "invention" that needs the guidance of experts. So this is a possible option as well. > d) Identify and adopt other documents that are needed for DANE adoptions/operations/specifications  I still have an IPsec one pending, but most of those issues are with IPsec and not with the relatively simple DANE, so that could find an audience in ipsecme (providing it is not closing down too) Paul From nobody Tue Jun 2 07:00: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 E62FC1A1AB5; Tue, 2 Jun 2015 07:00:35 -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 JCm2jATKW6m1; Tue, 2 Jun 2015 07:00:33 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B071D1A92DC; Tue, 2 Jun 2015 07:00:25 -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.3.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150602140025.26039.27915.idtracker@ietfa.amsl.com> Date: Tue, 02 Jun 2015 07:00:25 -0700 Archived-At: Cc: dane@ietf.org Subject: [dane] I-D Action: draft-ietf-dane-ops-12.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2015 14:00:36 -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 : Updates to and Operational Guidance for the DANE Protocol Authors : Viktor Dukhovni Wes Hardaker Filename : draft-ietf-dane-ops-12.txt Pages : 29 Date : 2015-06-02 Abstract: This document clarifies and updates the DNS-Based Authentication of Named Entities (DANE) TLSA specification (RFC6698) based on subsequent implementation experience. It also contains guidance for implementers, operators and protocol developers who want to make use of DANE records. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dane-ops/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dane-ops-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dane-ops-12 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 Jun 2 07:04: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 DD3A81A92B4 for ; Tue, 2 Jun 2015 07:03:59 -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 ExwrXMH4LMr5 for ; Tue, 2 Jun 2015 07:03:58 -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 886171A923E for ; Tue, 2 Jun 2015 07:03:58 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 93779284B54; Tue, 2 Jun 2015 14:03:57 +0000 (UTC) Date: Tue, 2 Jun 2015 14:03:57 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150602140357.GF5090@mournblade.imrryr.org> References: <20150602140025.26039.27915.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150602140025.26039.27915.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dane] I-D Action: draft-ietf-dane-ops-12.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2015 14:04:00 -0000 On Tue, Jun 02, 2015 at 07:00:25AM -0700, internet-drafts@ietf.org wrote: > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-dane-ops-12 This fixes Section 8.2, which I incorrectly simplified in version 11. In this iteration the reasons for the original being right, and the -11 version being wrong are explicitly stated. -- Viktor. From nobody Tue Jun 2 10:10: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 E2C651B2B80 for ; Tue, 2 Jun 2015 10:10:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.663 X-Spam-Level: * X-Spam-Status: No, score=1.663 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 PdzJLmM0DSTo for ; Tue, 2 Jun 2015 10:10:29 -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 E4F951B2B47 for ; Tue, 2 Jun 2015 10:10:28 -0700 (PDT) Received: (qmail 60871 invoked from network); 2 Jun 2015 17:10:36 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 2 Jun 2015 17:10:36 -0000 Date: 2 Jun 2015 17:10:05 -0000 Message-ID: <20150602171005.35130.qmail@ary.lan> From: "John Levine" To: dane@ietf.org In-Reply-To: <556C66B6.3050209@rename-it.nl> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dane] 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: Tue, 02 Jun 2015 17:10:30 -0000 > From what I can tell, this document only describes how to publish and >retrieve a key in DNS/DNSSEC, i.e. in what format. I don't see any >mention of a procedure by which a key would get published. ... As others have noted, that's true. For one thing, this draft and the companion S/MIME draft have serious design problems* that make it unlikely that they will be adopted outside of small niches, so I wouldn't put a lot of effort into fixing them. But more important, most DNS management systems are protected with passwords now. That's how the management consoles at domain registrars work (they control the NS records) and it's how most DNS management consoles work. Some use hardware or software tokens or client certs, but most don't, so there's little point in building a steel door for those cardboard boxes. Even if there are super-secure HSMs for zone signing, they can only sign what the DNS management system already has. The PGP certs you would retrieve would presumably have the same WoT endorsements as if you retrieved them any other way, so you can continue to use WoT to decide whether to accept them. R's, John * - not just the address guessing issue, see zillions of messages in the list archive for details From nobody Wed Jun 3 07:15: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 416D01A88D2 for ; Wed, 3 Jun 2015 07:15:00 -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 OBsx0SRnthp5 for ; Wed, 3 Jun 2015 07:14:58 -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 C23F81A88CF for ; Wed, 3 Jun 2015 07:14:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 9AB13BF0B for ; Wed, 3 Jun 2015 15:14:56 +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 pJ3Zj695mQ19 for ; Wed, 3 Jun 2015 15:14:56 +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 30A5DBF09 for ; Wed, 3 Jun 2015 15:14:56 +0100 (IST) Message-ID: <556F0BDF.6090603@cs.tcd.ie> Date: Wed, 03 Jun 2015 15:14:55 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.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-ops-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: Wed, 03 Jun 2015 14:15:00 -0000 Hiya, My review of this is below. I'm fine with starting the IETF LC and you handling these as last call comments along with others but since there are a bunch of 'em (and I bet Viktor will not be silent anyway:-) please tell me (Warren, as shepherd) if you prefer me to start the IETF LC now, or wait until we've chatted about these a bit. (And I'm fine either way.) Cheers and thanks for the work on this, S. - general: this was a bit of a slog - the draft is both dense (loads of 2119 terms) and long, which makes it a hard read. I'm not saying it's possible to do better, but just noting that in case someone has a good idea about how to make it easier to read. - intro, 3rd para: I don't think this is very clear and it'd be great if it were - isn't there a way to provide clarity about the name that goes with the TLS session in which cases? - 1.1, I think you need to define "TLSA base domain" here (or is it elsewhere? I didn't find it in 6698) - section 2: Why duplicate so much of 7218? I think it'd be better not to (or to obsolete that with this) but I don't care that much really. - section 2: last sentence before 2.1 - is that saying that the MUST applies to section 9? If not, I'm not sure what it means, but it's not quite clear. - section 3: saying TLS1.2 is a SHOULD is fine but what about when TLS1.3 is done (next year). Wouldn't it be better to say that the latest TLS version is a SHOULD and is currently 1.2? - section 4: I read this as you calling DNSSEC "illusory incremental security" which I don't think is really what you mean and which interpretation calls into question the strength of the RECOMMENDATION here. 4.1 similarly says "PKIX-TA(0) and PKIX-EE(1) TLSA records do not provide additional security" which is too definitive, where is the evidence? (Not opinion or argument, but evidence.) In the absence of evidence I think we should omit these (and they are not needed.) - 4.2: Did we check that CT is unlikely to make sense with DANE-TA records? In principle, public logs could add enterprise CAs without having real spam issues. I agree it's unlikely to happen in practice, and it's probably fine to revise this if that starts happening a lot, but since it could in principle, I wondered if we'd checked with the trans list (and I don't recall that we have) - 5.1, last para: that's a bit coy about the "extra logic" - wouldn't it be better to explain? If not, why not? - 5.2.1: 2nd para says "do honour constraints" but earlier (for DANE-EE+Cert) you explicitly said to ignore validity, subject etc. I think it'd be better to explicitly say here whether or not validity and naming need to match and if they do, then how. As-is, I suspect developers are likely to randomly either ignore validity and naming here too, or not;-) And if enough of 'em do different things, then that'd be bad. (If there were a good list of subsections of 5280 to honor or ignore that might work, but would be a bit tedious to figure out and might not work - I've not checked.) - 5.2.3, last para: What is "are encouraged to" in 2119 terms? - 5.4: "SHOULD NOT always stop" isn't clear, and the next sentence seems to have the MUST that clarified, so maybe drop the 2119 "SHOULD NOT"? - section 6: what is a "master" TLSA record? Maybe better to not introduce a new term like that. - section 8, 2nd para: saying "are only compatible with" seems like an overstatement to me - 8.2: I think in this example you generate a new key pair for the TLS server at the time that your are transitioning from DANE-EE to DANE-TA. Saying that would help, as there could be another transition case where the same TLS server key pair is maintained and an x.509 certificate (issued under the DANE-TA) for that same key is deployed on the TLS server. I'm not saying that's a better transition but only that it could presumably be done and arguably easier if it worked. But the only change I'd suggest for now is to just point out that a new key pair is generated for this example. - 8.3: lowercase "should" often confuses as to whether that means 2119 or not. I don't care how you resolve. - 8.4, I think last sentence of 1st bullet could be worth a bullet of its own - 8.4, I'm not sure the last bullet is clear enough to be a useful summary - its a doozy of a sentence in any case;-) - section 9: your background is showing:-) "by the MTA administrator" should presumably be "on the TLS client (e.g. by an MTA administrator)" or similar. - 10.1.1: I guess we don't consider that it'd be good to give a reference to the TC bit? I'm ok with that but someone else might like to have one. - 10.2: "The server name used for this comparison SHOULD be the base domain of the TLSA RRset." I think that works ok, but isn't that a change in client behaviour compared to a non-DANE TLS client? If to, then don't you need to call that out much more clearly? Do we actually need a "differences between DANE TLS clients and non-DANE TLS clients" section? - section 11: I think s/public CA PKI/public CA WebPKI/ would be more accurate - section 11: I don't get the logic for recommending weekly signing - once you automate signing (which you have to) then daily seems like it should work for everyone and weekly hasn't any benefit. So I don't get the reasoning here. (And a week seems bad when I read section 13 too.) From nobody Wed Jun 3 13:41: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 F005A1A8958 for ; Wed, 3 Jun 2015 13:41:12 -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 FIbF7NZ10wq9 for ; Wed, 3 Jun 2015 13:41: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 5D15C1A8860 for ; Wed, 3 Jun 2015 13:41:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 2736BBF09 for ; Wed, 3 Jun 2015 21:41:10 +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 qWCGUQadPSGd for ; Wed, 3 Jun 2015 21:41:08 +0100 (IST) Received: from [10.87.48.73] (unknown [86.46.31.250]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id C0BA3BF08 for ; Wed, 3 Jun 2015 21:41:08 +0100 (IST) Message-ID: <556F6664.8020800@cs.tcd.ie> Date: Wed, 03 Jun 2015 21:41:08 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.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-openpgpkey-03 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2015 20:41:13 -0000 Hiya, I've done my AD review of this one too. In this case I do have a few questions I'd like to chat about before starting IETF LC, four of 'em actually;-) But they should be quickly dealt with. And of course I've a bunch of nitty comments too, below, but those can just be handled as last call comments. Cheers, S. Stuff I'd like to chat about before starting IETF LC: (1) Given the email-addr-in-DNS issues with this, would this not be better as experimental? I think the WG did consider that, but I forget, and in any case even if you did, I want to ask again, to be sure to be sure:-) My concern is that we not end up arguing against other folks who may want to standardise some form(s) of key server on the basis that this is *the* standard way to do it. One way to handle that would be for this to be experimental and for us to see if it gets deployed or not. Another could be to just say in the text that this proposed standard is one way of distributing keys, but that others can be equally valid. (2) The intro is very wordy. It could really lose the editorialising generally. (Various examples below.) Is that fair comment? Are the opinionated bits really needed in the RFC? (3) Can you briefly convince me that sections 2.1 and 2.2 are sufficient to write interoperable code. Section 5.5.1.1 of 4880 does not seem to be the right place at which to point for that, to me. But I've not implemented PGP so I may be wrong. (4) 6.2 still refers to sha-224, which is wrong now isn't it? ---- detailed comments/nits/etc. - intro: HKP needs a reference - intro: "Worse, ..." the value judgement isn't needed. Say (exactly) why it's worse or say nothing. And the IETF does not have consensus that TOFU is "worse" unless you say what it is "worse" than. - intro: "have no method" - how do you know? It could be they make no claims of validating things but that they do internal stuff, who knows. - intro: lack of secure lookup does not "prevent" encryption, that's just wrong. I send encrypted mail all the time without that. - intro: "forcing...unencrypted" is also wrong given S/MIME - while this is about PGP, please don't deny reality. - intro: "This document describes..." - you could delete almost all the text before this para. And some after it;-) - intro: "Trust Signature model" needs a reference - intro: "otherwise have to be" is false (same as above) - Appendix A: This would be much better work a worked example, incl. a public key one could import to re-generate the outputs required. - section 3: do you really need 28 octets? wouldn't fewer be good enough and not risk collisions? Just wondering. - 4.2 - that MUST fail if local/DNS differ is a shame. Did the WG consider adding a label or key version to the RR that might allow for some update cases to work? - section 5: is "recommended" there meant as a 2119 thing? If so, it's usually better in uppercase. - 6.2 - in theory using the mail author's email address might not mean publishing that I guess. But your text is fine as-is, just noting that possibility. - 6.3 - what if an application has no user? Does this section apply then? From nobody Thu Jun 4 07:22: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 5FEB11B3536 for ; Thu, 4 Jun 2015 07:22:57 -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 caH3vcp6-jFn for ; Thu, 4 Jun 2015 07:22: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 2F92E1B353F for ; Thu, 4 Jun 2015 07:22:53 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id AC465283031; Thu, 4 Jun 2015 14:22:51 +0000 (UTC) Date: Thu, 4 Jun 2015 14:22:51 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150604142251.GI5090@mournblade.imrryr.org> References: <556F0BDF.6090603@cs.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <556F0BDF.6090603@cs.tcd.ie> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dane] AD review of draft-ietf-dane-ops-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, 04 Jun 2015 14:22:57 -0000 On Wed, Jun 03, 2015 at 03:14:55PM +0100, Stephen Farrell wrote: > - general: this was a bit of a slog - the draft is > both dense (loads of 2119 terms) and long, which > makes it a hard read. I'm not saying it's possible > to do better, but just noting that in case someone > has a good idea about how to make it easier to read. I'm open to suggestions and will give this some more thought. > - intro, 3rd para: I don't think this is very clear > and it'd be great if it were - isn't there a way to > provide clarity about the name that goes with the > TLS session in which cases? While the intent is primarily to raise the issue, this could be more specific. I'll try to improve this. > - 1.1, I think you need to define "TLSA base domain" > here (or is it elsewhere? I didn't find it in 6698) It is step 3, near the top of section 3, but is not really singled out as a definition: 3. The base domain name is appended to the result of step 2 to complete the prepared domain name. The base domain name is the fully qualified DNS domain name [RFC1035] of the TLS server, with the additional restriction that every label MUST meet the rules of [RFC0952]. The latter restriction means that, if the query is for an internationalized domain name, it MUST use the A-label form as defined in [RFC5890]. I'll add a definition to the terminology section. > - section 2: Why duplicate so much of 7218? I think > it'd be better not to (or to obsolete that with > this) but I don't care that much really. This can probably be made shorter, ... > - section 2: last sentence before 2.1 - is that > saying that the MUST applies to section 9? If not, > I'm not sure what it means, but it's not quite > clear. Quote: Server operators MUST publish TLSA RRsets that are compatible with digest algorithm agility. While, Section 9 says: To make digest algorithm agility possible, all published DANE TLSA RRsets MUST conform to the requirements of Section 8. so the quoted text in 2 ultimately refers to the requiremens of section 8 as illustrated by the examples in the sub-sections. Perhaps forward references to sections 8/9 would help. > - section 3: saying TLS1.2 is a SHOULD is fine but > what about when TLS1.3 is done (next year). > Wouldn't it be better to say that the latest TLS > version is a SHOULD and is currently 1.2? Or just "TLS 1.2 or later". > - section 4: I read this as you calling DNSSEC > "illusory incremental security" which I don't think > is really what you mean and which interpretation > calls into question the strength of the > RECOMMENDATION here. Illusory additional security by comparison with DANE-TA/EE. That is, this text calls into question whether PKIX-TA/PKIX-EE have any value when the client also supports the DANE-TA/EE usages. Any additional perceived security from a public CA signature is illusory when it is optional. > 4.1 similarly says "PKIX-TA(0) and PKIX-EE(1) TLSA records do not provide > additional security" which is too definitive, where is the evidence? (Not > opinion or argument, but evidence.) My university training was in pure mathematics. For me a compelling logical argument (proof if you like) is better than mere empirical evidence. I stand by the claims in the draft. When DANE-TA/DANE-EE are acceptable (web-PKI CA signatures are optional), any successful attack on DNSSEC can simply replace PKIX-TA/EE with DANE-TA/EE. Insisting on additional Web-PKI CA checks is pointless when one relies on DNS records to enable these checks. If DNSSEC is not compromised, then DANE-TA/DANE-EE are sufficient (and less prone to failure due to mismatched trusted CA, problems with building chains, ...). > - 4.2: Did we check that CT is unlikely to make > sense with DANE-TA records? In principle, public > logs could add enterprise CAs without having real > spam issues. I agree it's unlikely to happen in > practice, and it's probably fine to revise this if > that starts happening a lot, but since it could in > principle, I wondered if we'd checked with the trans > list (and I don't recall that we have) This was based in part on feedback from Ben Laurie who at the time agreed that CT was only for public CAs. And it seems rather unlikely that anything different will happen for some time. If something different happens in the future, we can publish a suitable update. > - 5.1, last para: that's a bit coy about the "extra > logic" - wouldn't it be better to explain? If not, > why not? I've seen little evidence of DANE implementors going the extra mile to handle rare corner cases (on the contrary implemetors are rather lazy and make many, sometimes critical, compromises). So I expect that unless I end up contributing DANE support to all of OpenSSL, LibreSSL, mTLS (formerly PolarSSL) and GnuTLS, ... at least some of these will not jump through hoops to support RPK with "3 0 0" TLSA records. > - 5.2.1: 2nd para says "do honour constraints" but > earlier (for DANE-EE+Cert) you explicitly said to > ignore validity, subject etc. ONLY and EXCLUSIVELY when a certificate or public key is matched via DANE-EE records. It would be folly to suggest that DANE-TA(2) trust-anchor issued chains should bypass leaf certificate validation. > I think it'd be better > to explicitly say here whether or not validity and > naming need to match and if they do, then how. With DANE-TA(2), a trust chain is constructed in the usual way, from the certificates sent by the peer, which must include the TA certificate, plus any required intermediates. > As-is, I suspect developers are likely to randomly > either ignore validity and naming here too, or > not;-) I don't think there's any suggestion to skip name checks or expiration checks for usage 2. As for implementations other than mine, they almost universally totally mess up usage 2, and don't even build a chain! They just check that the peer sent some matching certificate along, whether there's a chain from that to the server keys or not! So any hope that a typical "developer" will get this right is unfounded. Instead we need to integrate robust DANE support into TLS toolkits, so that "developers" aren't tempted to implement DANE for themselves. > And if enough of 'em do different things, > then that'd be bad. (If there were a good list of > subsections of 5280 to honor or ignore that might > work, but would be a bit tedious to figure out and > might not work - I've not checked.) For DANE-TA(2), they need to apply everything from 5280 in the usual way, except that the trust-anchor is part of the peer chain and is trusted on the basis of a matching DNSSEC TLSA record. In Postfix (and the related ssl_dane library on github) I specifically disable all lookups against the local trust store when doing DANE-TA(2). This makes the behaviour more predictable, and discourages blame-shifting by server system operators who might say that thir setup "works for everyone else". If you don't include your TA in the wire certificate message, verification *will* always fail. This is better than failing some of the time. > - 5.2.3, last para: What is "are encouraged to" in > 2119 terms? Good question. I don't know the answer. Postfix and ssl_dane support this. I've not seen it done by anyone else. So I am not comfortable promising server operators that this is likely to work, but at the same time arguably clients SHOULD do this. Is SHOULD sufficiently weaselly to allow various implementations to punt on this? Or do I need to raise the bar for clients and make this a requirement? > - 5.4: "SHOULD NOT always stop" isn't clear, and the > next sentence seems to have the MUST that clarified, > so maybe drop the 2119 "SHOULD NOT"? Fair enough, I'll take a stab at fixing this. > - section 6: what is a "master" TLSA record? Maybe > better to not introduce a new term like that. Yes, the word "master" is unnecessary and counter-productive. I think the idea here is that aliases to records at the provider are not "master" records, but there are better ways to say that. > - section 8, 2nd para: saying "are only compatible > with" seems like an overstatement to me The ONLY other potentially compatible TLSA parameter combination is "3 0 0", from which a public key can be extracted. The draft suggests not to expecting this to work. > - 8.2: I think in this example you generate a new > key pair for the TLS server at the time that your > are transitioning from DANE-EE to DANE-TA. Yes, that's often unavoidable, when the DANE-EE(3) cert is typically self-signed. > Saying > that would help, as there could be another > transition case where the same TLS server key pair > is maintained and an x.509 certificate (issued under > the DANE-TA) for that same key is deployed on the > TLS server. Sure, there is a simpler transition in which the DANE-EE chain is aleready signed by the desired TA, that'll be rare, but can be mentioned. > But the only > change I'd suggest for now is to just point out that > a new key pair is generated for this example. Tried to do that by using the phrase "new chain". If that's not clear enough, a longer phrase or sentence can be inserted. > - 8.3: lowercase "should" often confuses as to > whether that means 2119 or not. I don't care how you > resolve. SHOULD will work for -13 (before or after IETF LC as instructed). > - 8.4, I think last sentence of 1st bullet could be > worth a bullet of its own Sure. > - 8.4, I'm not sure the last bullet is clear enough > to be a useful summary - its a doozy of a sentence > in any case;-) Yeah, I can give that another go. > - section 9: your background is showing:-) "by the > MTA administrator" should presumably be "on the TLS > client (e.g. by an MTA administrator)" or similar. Oops, thanks. Originally there was only one draft covering SMTP, OPS and more. This slipped through the surgery that created two separate drafts. Will fix. > - 10.1.1: I guess we don't consider that it'd be > good to give a reference to the TC bit? I'm ok with > that but someone else might like to have one. No strong opinion on my part. I just thought it is well known that that one should avoid DNS UDP fragmentation whenever possible. > - 10.2: "The server name used for this comparison > SHOULD be the base domain of the TLSA RRset." I > think that works ok, but isn't that a change in > client behaviour compared to a non-DANE TLS client? In some cases yes, but the server has published TLSA records at the base domain, thereby designating that base domain as the appropriate name for the service endpoint. For HTTP, almost always the TLSA base domain will be the same as the domain in the URL. However, in the presence of "secure" CNAME chains, and TLSA RRs at the expanded CNAME, the client will expect the expanded name primarily and may also match the original name secondarily (as in the SMTP and SRV drafts). The specifics were left to individual protocol documents, if none are expected to be forthcoming from working groups describing how apply DANE in their particular application protocols, we could state a default approach (allow either domain as with SRV and MX). > If so, then don't you need to call that out much > more clearly? Do we actually need a "differences > between DANE TLS clients and non-DANE TLS clients" > section? I don't think we need a "differences" section, but we might need a default when there is no application-specific standard. > - section 11: I think s/public CA PKI/public CA > WebPKI/ would be more accurate Sure. > - section 11: I don't get the logic for recommending > weekly signing - once you automate signing (which > you have to) then daily seems like it should work > for everyone and weekly hasn't any benefit. So I > don't get the reasoning here. (And a week seems bad > when I read section 13 too.) The problem is that signature validity needs to be larger than the "expire time" in the SOA record to avoid secondary nameservers routinely publishing records with expired signatures. And that time needs to reflect operational reality (how quickly is synchronization between primary and secondary servers restored when it fails). For professionally operated domains, this time can be short. For smaller domains (such as mine) with arms-length secondary servers, very short signature lifetimes are impractical. -- Viktor. From nobody Thu Jun 4 13:02: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 05D301A907F; Thu, 4 Jun 2015 12:56:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.012 X-Spam-Level: X-Spam-Status: No, score=-0.012 tagged_above=-999 required=5 tests=[BAYES_20=-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 AtWHPnwmXi2j; Thu, 4 Jun 2015 12:56:12 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C775C1A0018; Thu, 4 Jun 2015 12:56:11 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id BE31D20098; Thu, 4 Jun 2015 16:10:11 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 8430463AEC; Thu, 4 Jun 2015 15:56:09 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 6ADAF637FE; Thu, 4 Jun 2015 15:56:09 -0400 (EDT) From: Michael Richardson To: saag@ietf.org X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: X-Mailman-Approved-At: Thu, 04 Jun 2015 13:02:12 -0700 Cc: dane@ietf.org Subject: [dane] HTTPS everywhere question --- donated mirrors X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2015 19:56:18 -0000 --=-=-= Content-Type: text/plain So you may know I mismanage www.tcpdump.org. We have a half-dozen mirrors of the site (and code) around the world, all of them donated. 100M of disk space or something... Most answer to www.tcpdump.org as a virtual host, some have their own URLs. HTTP based virtual hosting is simple and cheap, and anyone can put up a mirror using rsync, and then I put the A and AAAA records in along with an extra name like www.us.tcpdump.org (hosted by wireshark). Now, www.us.tcpdump.org shares a host with www.wireshark.org, and https://www.wireshark.org also exists, and my impression is that some browsers are now doing things like trying port-443, and if it works, assuming that the same content is there. (No, you can't exactly try, because I pulled that IP from www.tcpdump.org pending resolution) Let's assume that I want to make this true (that www.tcpdump.org is https-everywhere), we need at a minimum, universal SNI or I need to enable this only when there is a unique v6 (because v4 is too scarce) available. Okay, that solves the VirtualHost issue... but it seems that I still have a certificate and private key issue. I could buy certificates for all sites, or... ? is there some technology I've missed? I could go DANE with self-signed certificates, which has some advantage. In theory, one could have a dozen TLSA RR in DNS, and fortunately they won't clog up the apex; but in practice are browsers that support DANE smart enough at this point to search all the records? Going DANE assumes browsers new enough to do SNI, which I guess is good. I wish we had signed HTTP objects instead, so that I could just sign the web site *contents*, and let the content distribution systems do their job, and let me do mine. (hey, the entire http site contents is also on github) Privacy could be machine to machine, while authentication be browser to web site owner... {I'm allowed to dream, aren't I?} I know that we have this issue with SMTP pointing MX records for example.com at ISP mail.example.net, and the names not matching, and I guess we are doing something there. Am I missing some piece of the puzzle? Some contemplated aspect of TLSA which might let me say, "www.wireshark.org is an allowed name for www.tcpdump.org"?? -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVXCtWYCLcPvd0N1lAQLtpwgAqPmP54Y0BMaNT6e3Kmx5yzDGcIxepr0/ W5tk9CaBUwTaKGPrBGaUbQ7ogLKx8Oz9OItjXfLI7OJArFznytXY6/VMYYjb3cg+ OXWPy00zPcnj9Nm/zoZTyrsRDVAOu5PSYjuJz7bl7xApyXIZSRwCgUe/18aGhZps 00RpZtMkxQ8GXW/PsgkVyOz9EmOLONGI3YVeugImY/VbOEnx3yJrdTntUE2u6SmM JiPdkZ9a+qBdsbSTbbiI0SumHNoyvjhOfb84od0uo8Whsa/vXNbRobo2TKDjSRns Pa2KVEWsT8iUdSKhlSczmX9c0hQaQVMsZZFf/RPHpNZG6/nqFiIWWA== =Fmuh -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Jun 4 17:01: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 EF4E51ACD86; Thu, 4 Jun 2015 17:01:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 5SvxMcwsIfe6; Thu, 4 Jun 2015 17:01:49 -0700 (PDT) Received: from ore.jhcloos.com (ore.jhcloos.com [IPv6:2604:2880::b24d:a297]) (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 3E0021ACD82; Thu, 4 Jun 2015 17:01:49 -0700 (PDT) Received: by ore.jhcloos.com (Postfix, from userid 10) id 894D41E038; Fri, 5 Jun 2015 00:01:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore14; t=1433462508; bh=KEvi2FoinE4aPfYSrNsCm8RgdliNO5WOFrHxSldU/1U=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=D3uO8vC3W6XWanxYfQjiqylpz47pX64PlCS3HhxwonSsj+LLdzwKYmfJHwnvZ6uNO YGiASc3SKjltzaUeaR6Th+W/HtwedYFXsfV8+IPSM/rwqZRx25dJD77uBwOdoQUZct 7TzH3HmMWOvHpIO9jFSFKHFzk9PjGHOs805sadW4= Received: by carbon.jhcloos.org (Postfix, from userid 500) id B4AD8106FD888; Fri, 5 Jun 2015 00:00:38 +0000 (UTC) From: James Cloos To: Michael Richardson In-Reply-To: <15980.1433447769@sandelman.ca> (Michael Richardson's message of "Thu, 04 Jun 2015 15:56:09 -0400") References: <15980.1433447769@sandelman.ca> 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: Thu, 04 Jun 2015 20:00:38 -0400 Message-ID: Lines: 28 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:28:150605:mcr+ietf@sandelman.ca::4SBQhbnDpLwY2Jqw:0000000000000000000000000000000000000001t2uU X-Hashcash: 1:28:150605:saag@ietf.org::deOlm4k3lxUsy34j:000BgnuV X-Hashcash: 1:28:150605:dane@ietf.org::Usq0/Kt1SxFmQxoW:000BEvXD Archived-At: Cc: saag@ietf.org, dane@ietf.org Subject: Re: [dane] HTTPS everywhere question --- donated mirrors X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2015 00:01:51 -0000 >>>>> "MR" == Michael Richardson writes: MR> We have a half-dozen mirrors of the site (and code) around the world, all of MR> them donated. 100M of disk space or something... MR> Most answer to www.tcpdump.org as a virtual host, some have their own MR> URLs. HTTP based virtual hosting is simple and cheap, and anyone can put up MR> a mirror using rsync, and then I put the A and AAAA records in along with an MR> extra name like www.us.tcpdump.org (hosted by wireshark). MR> Let's assume that I want to make this true (that www.tcpdump.org is MR> https-everywhere), we need at a minimum, universal SNI or I need to enable MR> this only when there is a unique v6 (because v4 is too scarce) available. [Apologies for any typos. I'm in the process of re-learnin how to type; left hand doesn't wok quite right anymore... -JimC] For mirror netwoks like that you need to have each of them get their own certs (or their own names) and have downloads redirect rom the main site to mirrors with something like an http 302. The main site an distribute the redirrecs using things like geoip or (optionally weighted) round robin, or whatever. There really isn't any other secure way to do it. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 From nobody Mon Jun 8 11:56: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 683171B3186; Mon, 8 Jun 2015 11:35:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 wRrSbrD0ZLxV; Mon, 8 Jun 2015 11:35:50 -0700 (PDT) Received: from mail-yh0-x22c.google.com (mail-yh0-x22c.google.com [IPv6:2607:f8b0:4002:c01::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 3EFF21ACCD9; Mon, 8 Jun 2015 11:35:50 -0700 (PDT) Received: by yhak3 with SMTP id k3so39279935yha.2; Mon, 08 Jun 2015 11:35:49 -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=p32g8caXrc1Fsmyoz3rf1YZEj1SaltQR7Q1CFpOsENg=; b=wyV1xbDofxq8BwNRO00z748bNDaYhXlGr4EJSj1uY4P5xITIF6DZISmXwEadWdecMv OUK+mF3CL+y3d+0FLSieit6MXqEBtQgBcm1niIwq90fUHTRYTWS75Ghkj9r6BDlYYvbn QCAsnB1A9h/sH8wZuEUdhYIMFGr4jjWlRbW/2JQj+b2z/u2lcYzO8yL+3kbFE3UnZXZK ocEyyPsOPmgOO5s/YiEKsm+c8tKcezE7M46O+UD7W4XxrQjPh0+tH57qq++h/LztmP0s OlKgDWF3l9OQHCBnN+HOwFv+h3TNRBmRy+ywH3BITK89rvpzGpccf3tffbFBKfYZh9qB f7ag== MIME-Version: 1.0 X-Received: by 10.13.247.3 with SMTP id h3mr18217413ywf.154.1433788549582; Mon, 08 Jun 2015 11:35:49 -0700 (PDT) Received: by 10.129.110.138 with HTTP; Mon, 8 Jun 2015 11:35:49 -0700 (PDT) In-Reply-To: <15980.1433447769@sandelman.ca> References: <15980.1433447769@sandelman.ca> Date: Mon, 8 Jun 2015 11:35:49 -0700 Message-ID: From: Martin Thomson To: Michael Richardson Content-Type: text/plain; charset=UTF-8 Archived-At: X-Mailman-Approved-At: Mon, 08 Jun 2015 11:56:08 -0700 Cc: saag , dane@ietf.org Subject: Re: [dane] [saag] HTTPS everywhere question --- donated mirrors X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2015 18:35:51 -0000 On 4 June 2015 at 12:56, Michael Richardson wrote: > Am I missing some piece of the puzzle? Some contemplated aspect of TLSA > which might let me say, "www.wireshark.org is an allowed name for > www.tcpdump.org"?? Well... ACME will let wireshark.org get a certificate for tcpdump.org, now that you have setup DNS. If you want them to be able to use your name, then allow them to have a certificate for it. SNI is a problem, but you might decide that IE 6 and Android 2.2 users aren't that important. I know several people running services that rely on SNI alone happily. From nobody Mon Jun 8 12:18: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 A96DD1B3229; Mon, 8 Jun 2015 12:18:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 xDr1xYuoF49Q; Mon, 8 Jun 2015 12:18:02 -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 CBE571A0105; Mon, 8 Jun 2015 12:18:01 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id A0EED283033; Mon, 8 Jun 2015 19:18:00 +0000 (UTC) Date: Mon, 8 Jun 2015 19:18:00 +0000 From: Viktor Dukhovni To: dane@ietf.org, saag@ietf.org Message-ID: <20150608191800.GK5512@mournblade.imrryr.org> References: <15980.1433447769@sandelman.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <15980.1433447769@sandelman.ca> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dane] HTTPS everywhere question --- donated mirrors X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: saag@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2015 19:18:03 -0000 On Thu, Jun 04, 2015 at 03:56:09PM -0400, Michael Richardson wrote: > Now, www.us.tcpdump.org shares a host with www.wireshark.org, and > https://www.wireshark.org also exists, and my impression is that some > browsers are now doing things like trying port-443, and if it works, > assuming that the same content is there. (No, you can't exactly try, because > I pulled that IP from www.tcpdump.org pending resolution) Assuming that port 443 is semantically identical to port 80 is rather unwise. Are browsers really doing that, or is the host in question configured to publish alternative service access via 443? > In theory, one could have a dozen TLSA RR in DNS, and fortunately they won't > clog up the apex; but in practice are browsers that support DANE smart enough > at this point to search all the records? Going DANE assumes browsers new > enough to do SNI, which I guess is good. There are essentially no browsers that support DANE. There are some experimental plugins, but nothing mainstream anyone should rely on. > Am I missing some piece of the puzzle? Some contemplated aspect of TLSA > which might let me say, "www.wireshark.org is an allowed name for > www.tcpdump.org"? Unfortunately, HTTP does not use SRV records. If HTTP had used SRV records, and if browsers supported DANE, then the DANE SRV draft (approved and in the RFC editor queue) would do precisely what you want, in that each target host's own name from the SRV record would be used for TLSA record lookup and any peername checks. This is not how HTTPS works today. There is no service indirection via DNS for HTTP, so you have to do that at the application layer via an HTTPS redirector (that can somehow guess which servers are up and reachable by the client). -- Viktor. From nobody Tue Jun 9 04:14: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 53D811A0062 for ; Tue, 9 Jun 2015 04:14:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.895 X-Spam-Level: ** X-Spam-Status: No, score=2.895 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] 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 8bxkWj0XGCbQ for ; Tue, 9 Jun 2015 04:14:00 -0700 (PDT) Received: from shannon.7bits.nl (shannon.7bits.nl [IPv6:2a01:1b0:202:40::1]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24D651A00E7 for ; Tue, 9 Jun 2015 04:14:00 -0700 (PDT) Received: from [10.8.82.2] (unknown [46.145.181.110]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: peter) by shannon.7bits.nl (Postfix) with ESMTPSA id D3A611C409; Tue, 9 Jun 2015 13:13:56 +0200 (CEST) From: "Peter van Dijk" To: dane Date: Tue, 09 Jun 2015 13:13:56 +0200 Message-ID: <06D0C5A0-6C9C-42F6-8513-9335A87E0A5A@powerdns.com> In-Reply-To: <556F6664.8020800@cs.tcd.ie> References: <556F6664.8020800@cs.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.1r5084) Archived-At: Subject: Re: [dane] AD review of draft-ietf-dane-openpgpkey-03 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 09 Jun 2015 11:14:03 -0000 Hello Stephen, thank you for your extensive coverage of the draft. On 3 Jun 2015, at 22:41, Stephen Farrell wrote: > Stuff I'd like to chat about before starting IETF LC: > > (1) Given the email-addr-in-DNS issues with this, would > this not be better as experimental? I think the WG did > consider that, but I forget, and in any case even if you > did, I want to ask again, to be sure to be sure:-) My > concern is that we not end up arguing against other > folks who may want to standardise some form(s) of key > server on the basis that this is *the* standard way to > do it. One way to handle that would be for this to be > experimental and for us to see if it gets deployed or > not. Another could be to just say in the text that this > proposed standard is one way of distributing keys, but > that others can be equally valid. Even experimental seems a bit strong for a lookup method that has seen so much debate without serious improvement. The hashing method is poorly specified, and stronger text would not help - we are still preventing lookups in case of lower/uppercase differences, subadresses (peter+foo), dot insertion (gmail). Let me emphasize that: the draft is, in its current form, undeployable for Google Mail. While I don't expect that they want to, this is a strong signal that the draft is broken. I have strong objections to the texts "Both of these issues have been refuted" and "There is not much more we can do at this point to address it." under question 6 in http://datatracker.ietf.org/doc/draft-ietf-dane-openpgpkey/shepherdwriteup/; similar "this is the best we can do"-language in other sections seem equally wrong. I also never got the feeling that WG consensus on the full content of the draft was "strong" but I may be mistaken here. Better methods than hashing have been proposed. For example, split base32 is better in every way (and, as a bonus, actually deployable, unlike the hashing method) except perhaps address privacy concerns (which the draft explicitly dismisses in section 6.2 anyway). However, the split base32. has been shot down because, and I quote, "I do not understand the advantage of base32 in the QNAME." No other arguments have been put forward. Moving the draft forward in its current form, onto Standards Track, would be a mistake. Moving it forward as Experimental would be somewhat better, but I suggest using even stronger language explaining that this RFC only defines an RRtype, keeping the lookup mechanism as no more than a weak suggestion. While personally I feel split base32 would be fine to use in an RFC (be it Experimental or Standards Track), your point of 'not end up arguing against other folks' is valid, and in that case one could consider removing all lookup text from the RFC, and making it just about the RRtype. > - section 5: is "recommended" there meant as a 2119 > thing? If so, it's usually better in uppercase. The mention of TCP here, as in 6.1, is a weird operational sidestep for this document. DNS operators know about big records and responses, and can deal with them accordingly, without singling out specific RRtypes. Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ From nobody Tue Jun 9 06:52:07 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 7E6391B2CBE for ; Tue, 9 Jun 2015 06:52:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.29 X-Spam-Level: * X-Spam-Status: No, score=1.29 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_92=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 QSfxc2BvE4K5 for ; Tue, 9 Jun 2015 06:52:04 -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 83E7D1B2C5C for ; Tue, 9 Jun 2015 06:50:58 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3m5XsX69l4z3tR for ; Tue, 9 Jun 2015 15:50:56 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=lUznr+Ov 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 Q5PZvBOwGxQo for ; Tue, 9 Jun 2015 15:50:55 +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 ; Tue, 9 Jun 2015 15:50:55 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id CC1AD800A3 for ; Tue, 9 Jun 2015 09:50:53 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1433857853; bh=EYhWr2VMMZjk4yavnUfzyf6wUvUYXd8CPdkjLMdnvVU=; h=Date:From:To:Subject:In-Reply-To:References; b=lUznr+Ovemo215dfP5gwz/KJpSnWTm6qwojLuenjsDW9DGYlLTDleO4TFCpnTr8q7 eXVKDWmS57tnUIZFch5e1jC3xpLbLTHfyknmI/iLWsFMvw/kku0WAAFLAr7tabkpTi sXt5AtsEBE5CeYqBLivAWAJg2hoTu1xaalv4HhXs= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.15.1/8.15.1/Submit) with ESMTP id t59Dorsb005606 for ; Tue, 9 Jun 2015 09:50:53 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Tue, 9 Jun 2015 09:50:53 -0400 (EDT) From: Paul Wouters To: dane WG list In-Reply-To: <06D0C5A0-6C9C-42F6-8513-9335A87E0A5A@powerdns.com> Message-ID: References: <556F6664.8020800@cs.tcd.ie> <06D0C5A0-6C9C-42F6-8513-9335A87E0A5A@powerdns.com> User-Agent: Alpine 2.11 (LFD 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Archived-At: Subject: Re: [dane] AD review of draft-ietf-dane-openpgpkey-03 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 09 Jun 2015 13:52:06 -0000 On Tue, 9 Jun 2015, Peter van Dijk wrote: > Even experimental seems a bit strong for a lookup method that has seen so > much debate without serious improvement. Actually, the improvement has been to no longer require multiple records to support Uppercase'ed email addresses often accidentally created on virtual keyboard devices. This change came after a lot of discussion on the list and in person at the last IETF, both in the dane meeting and outside of it. It seemed (to me) the consensus was that the lookup problem was a separate problem that could be solved by SMTP protocol extensions, but that such extension should not be defined by this document. > The hashing method is poorly specified, and stronger text would not help I think you actually mean to say you do not like the hashing method. The specification itself is very carefully and clearly specified. If you feel it is poorly written down to its intend, please supply a suggested text change for us to consider. > - we are still preventing lookups > in case of lower/uppercase differences Some of the SMTP/Email folks said themselves that case sensitive mailboxes do not exist in real life, only in historic RFC specifications. To complain about not supporting PAUL being different from paul is not very different from not supporting UUCP !bang addresses, which are technically still valid email address formats. The confusion that paul@nohats.ca is not PAUL@nohats.ca is in itself a problem much larger than not finding the 'right' crypto key for PAUL@nohats.ca >, subadresses (peter+foo) Nothing prevents you from adding an OPENPGPKEY for hash(lower("peter+foo")) You are prevented from making things up on the fly without backing up the thing you just made up. Well, what would people do when they see peter+todaysmailbox@powerdns.com leading to a PGP key which only has peter@powerdns.com on it? How can I know those are not actually two different peter's? Supporting +wildcarding just moves the problem. > , dot > insertion (gmail). Nothing prevents you from adding an OPENPGPKEY for hash(lower("peter.......@powerdns.com)) You are again prevented from making things up on the fly without backing up the thing you just made up. It relies on humans making a decision that there probably are not two peter's at powerdns.com, assumptions that cannot be made for email domains like gmail or yahoo. > Let me emphasize that: the draft is, in its current form, undeployable for > Google Mail. I fail to see that. What I see is that mailbox auto expansion has a problem very similar to the public suffix problem. It depends on human knowledge that is not made available reliable for automated tools. Still, google could add openpgpkey records based on the rewrite rules only they and their customers know about. > Better methods than hashing have been proposed. For example, split base32 is > better in every way Can you explain that, because I do not see that. Let's say we would use chopped up base32 without lowercase without hash. How would Google Mail be able to support peter....@powerdns.com or peTER+foo@powerdns.com better? They still need to either get from you a list of permutations to generate many records, or you still have to have logic on the client stripping out things sending multiple queries, and then it won't matter whether the attempts are for hashed or split base32. How would clients know that peter+foo is or is not the same mailbox as peter? The problem is the sender using made up things and forcing the receiver to depend on a human to determine that some local part is or is not, the same person. This draft does not pretend that problem is solvable. > (and, as a bonus, actually deployable, unlike the hashing > method) Odd statement, as fedoraproject.org and mail.de have deployed this. > Moving the draft forward in its current form, onto Standards Track, would be > a mistake. Moving it forward as Experimental would be somewhat better, but I > suggest using even stronger language explaining that this RFC only defines an > RRtype, keeping the lookup mechanism as no more than a weak suggestion. That would be a terrible solution and reduce one of the key features this draft solves - key discovery. It would also lead to interop failures of developers who have "implemented" the document yet only implemented it partially. >> - section 5: is "recommended" there meant as a 2119 >> thing? If so, it's usually better in uppercase. > > The mention of TCP here, as in 6.1, is a weird operational sidestep for this > document. DNS operators know about big records and responses, and can deal > with them accordingly, without singling out specific RRtypes. Unforutnately, most DNS amplification attacks are not the fault of DNS operators who know what they are doing, and having an RFC reference to point out broken and unwise behaviour makes it much easier to patch broken implementations. I talked to various people about how much I should put in, for example there are also issues about cache size and using openpgpkey records to cause other records to be removed from the cache, and especially after talking to Mark Andrews and Andrew Sullivan it was clear that those considerations did not belong in this document. If we have a better and generic RFC that goes in depth to the operational issues of amplification and DDOS attacks, I could reference that document instead. Unfortunately, I do not think such a document exist. Paul From nobody Tue Jun 9 07:13:35 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 511D21B2CB2 for ; Tue, 9 Jun 2015 07:13:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.663 X-Spam-Level: * X-Spam-Status: No, score=1.663 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 HPmJl86twL7P for ; Tue, 9 Jun 2015 07:13:31 -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 AE0A81B2CAE for ; Tue, 9 Jun 2015 07:13:30 -0700 (PDT) Received: (qmail 39446 invoked from network); 9 Jun 2015 14:13:38 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 9 Jun 2015 14:13:38 -0000 Date: 9 Jun 2015 14:13:07 -0000 Message-ID: <20150609141307.1369.qmail@ary.lan> From: "John Levine" To: dane@ietf.org In-Reply-To: <06D0C5A0-6C9C-42F6-8513-9335A87E0A5A@powerdns.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: peter.van.dijk@powerdns.com Subject: Re: [dane] AD review of draft-ietf-dane-openpgpkey-03 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 09 Jun 2015 14:13:33 -0000 >Even experimental seems a bit strong for a lookup method that has seen >so much debate without serious improvement. The hashing method is poorly >specified, and stronger text would not help - we are still preventing >lookups in case of lower/uppercase differences, subadresses (peter+foo), >dot insertion (gmail). > >Let me emphasize that: the draft is, in its current form, undeployable >for Google Mail. While I don't expect that they want to, this is a >strong signal that the draft is broken. Don't forget the equally serious scaling problem. Since hashes aren't reversible, if you have a mail system with 100,000,000 users who have keys (not implausible considering the current size of Gmail, Yahoo, and Hotmail), you have to precompute all 100,000,000 hashes before you can answer any queries. If the records are on average 3K, that's a 300 gigabyte zone file. The largest existing signed zone file of which I am aware, the .COM TLD, is about 10 gb before signing. I realize computers are getting faster every day, but a design that requires static zone files an order of magnitude bigger than any that exist now doesn't seem like a great idea. Different encodings could address this issue, too. R's, John From nobody Tue Jun 9 09:26: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 EEF8B1AC44E for ; Tue, 9 Jun 2015 09:26:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.049 X-Spam-Level: * X-Spam-Status: No, score=1.049 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_DE=0.35, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qwsTsE4k_y_0 for ; Tue, 9 Jun 2015 09:26:35 -0700 (PDT) Received: from mail.somaf.de (mail.somaf.de [IPv6:2001:a60:f0b4:e503:2cdb:beff:feaa:880b]) (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 9A15E1AC529 for ; Tue, 9 Jun 2015 09:26:34 -0700 (PDT) Received: from andreasschulze.de (andreasschulze.de [IPv6:2001:a60:f0b4:e503:d86e:8dce:a73e:2fec]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: sca@andreasschulze.de) by mail.somaf.de (Postfix) with ESMTPSA id 3m5cK42y2BzDbk for ; Tue, 9 Jun 2015 18:26:32 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=andreasschulze.de; s=J4bWGJQcBmxMQ; t=1433867192; bh=p7V1HOBpTEAxVR9KONRXN0cByszlvCVCTzY6lKjgszg=; h=Date:From:To:Subject; b=gWtiyt5mG/6/fI7EnjK8xeqyn4XmfR/WZCeNMgU4TnSlD9agQzD40I3YXysfN+2+O i1ShEiMjKgiGvILDx5NY+be0WLvKUKkhOrH30PjaT18iWFJnDCHD0G4MERp3Btunx6 RK1DO85fpkxQPdMn9Zpy7xRPzp5uedGCWa8FVsQXGor9r+9q7HxeT5lgLQdXdEsJPu lB26ox/tZRLNQkcKhYXeDrCZGP20DMNxOH2cogU9jvV0WbE/XEs4Ko5sCenC8yaxq0 Drj21fw8u7lZSnC2BaMygOluZpo3C1hiP6Oj2bH517hEYlB4Z5J8bWVeE3PT6UyZs0 XnLfgM9PY8AkS9cvOVsrsBrNti8IBmpCWwzc28hr2SDIEL4dZakU8TFoihFufdUId2 +SDZZNSUiwLWch8L3qd23RjT60zNQ0KH4ZSsyslWFyhshJaXgx1LrVT/y57g0Lelg8 BkIc6pVxDOj0Gj4Yl22/KTTCq4Z/3RYOvfSESFnOcwjQmjCAPNdwjMYPAIncFOATD/ HalFwe1XWZNI6vmbhoDJgjNQdGw2YCHCAZbAO4mVTJkHRgTh9M6ITr3BuqhJ5gdyXE 0f2zXXsyBnDuRBDNOjpvLpGO2WFJYXOfh88AwlDfPss8zbE7738d51QO2mptBPiabW 4elmj89cnH4npqDmwxZqANy0= Received: from 62-50-200-74.client.stsn.net (62-50-200-74.client.stsn.net [62.50.200.74]) by andreasschulze.de (Horde Framework) with HTTP; Tue, 09 Jun 2015 18:26:31 +0200 Date: Tue, 09 Jun 2015 18:26:27 +0200 Message-ID: <20150609182627.Horde._HGuwHi4HNqgLptnKCecj_l@andreasschulze.de> From: "A. Schulze" To: dane@ietf.org User-Agent: Horde Application Framework 5 Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline Archived-At: Subject: [dane] DANE works, thanks X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 09 Jun 2015 16:26:36 -0000 Hello, Barry Leiba encourage me to write this "it works" message. We're a ISP in Germany. Since years we run validating DNS resolvers in our infrastructure. Using postfix as MTA any outbound messages benefits from DANE. OK, the total number of DNSSEC enabled destinations is small. Really small. But for these destinations we're simply sure we transfer message securely to the right receiver. YES, - it works - it does not hurt Thanks for DANE! Andreas From nobody Tue Jun 9 09:39: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 193111A1B1D for ; Tue, 9 Jun 2015 09:39:16 -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 sZ9eQrx1loUl for ; Tue, 9 Jun 2015 09:39:14 -0700 (PDT) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) (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 E189B1A1B13 for ; Tue, 9 Jun 2015 09:39:13 -0700 (PDT) Received: by labko7 with SMTP id ko7so16504799lab.2 for ; Tue, 09 Jun 2015 09:39:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=rLcaOSSYKmZzR8jL7crqIWaR0uDDFzaRKxm3UOVa4O8=; b=V8DBEUnIevmdWmGJO4QXtzb5AH1FHM/ZhhDnlv/QNnZFRkbqy8K+1mCJINSk36h0K2 QU6Zwu9ZfnBNlzo7PhFT3Ayqopiyo0x/o8BW2HRIQidsTt18PTmX74ntcVvAJsMhhswe z+6yqEOvRE4h34GOS6lJyCUxq4kqkEbQdSD4kaoJI2PLXWHvSvJWoxmX8InbTt1+7jKh W3/EP7vYf6qJodGU5vaKwe8qUE965UMVgNKMICog8ElxoWMFNkRmd+LFi1G5Tk6sRZnt j6tLxQ81krA7OjYxrslVt13Mla7q1EJN10kKyRS4bQtq4tLywxjTNQBIlvra4xUbUXA8 2zZg== X-Gm-Message-State: ALoCoQlR6KVwNUXsRg9iMI0aqLOemvIv3fAloa5shIIt6NChuJfn6CsV0Fd6sifjopuwRp9KebPp X-Received: by 10.152.22.4 with SMTP id z4mr23675263lae.14.1433867952415; Tue, 09 Jun 2015 09:39:12 -0700 (PDT) Received: from [2.67.171.137] (2.67.171.137.mobile.tre.se. [2.67.171.137]) by mx.google.com with ESMTPSA id s10sm1517387lae.47.2015.06.09.09.39.11 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 09 Jun 2015 09:39:11 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Leif Johansson X-Mailer: iPhone Mail (12F70) In-Reply-To: <20150609182627.Horde._HGuwHi4HNqgLptnKCecj_l@andreasschulze.de> Date: Tue, 9 Jun 2015 18:39:10 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <52D9C88E-66C4-4814-A3F5-5D6269FA1D0F@mnt.se> References: <20150609182627.Horde._HGuwHi4HNqgLptnKCecj_l@andreasschulze.de> To: "A. Schulze" Archived-At: Cc: "dane@ietf.org" Subject: Re: [dane] DANE works, thanks X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 09 Jun 2015 16:39:16 -0000 > 9 jun 2015 kl. 18:26 skrev A. Schulze : >=20 >=20 > Hello, >=20 > Barry Leiba encourage me to write this "it works" message. >=20 > We're a ISP in Germany. Since years we run validating DNS resolvers in our= infrastructure. > Using postfix as MTA any outbound messages benefits from DANE. >=20 > OK, the total number of DNSSEC enabled destinations is small. Really small= . > But for these destinations we're simply sure we transfer message securely t= o the right receiver. >=20 > YES, > - it works > - it does not hurt >=20 > Thanks for DANE! > Andreas >=20 nice! >=20 >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From nobody Tue Jun 9 09:43: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 2CE601ACDD2 for ; Tue, 9 Jun 2015 09:43:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 hlsisEw6dGGc for ; Tue, 9 Jun 2015 09:42:58 -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 B550A1A90F9 for ; Tue, 9 Jun 2015 09:42:58 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id C002728494C; Tue, 9 Jun 2015 16:42:57 +0000 (UTC) Date: Tue, 9 Jun 2015 16:42:57 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150609164257.GQ5512@mournblade.imrryr.org> References: <20150609182627.Horde._HGuwHi4HNqgLptnKCecj_l@andreasschulze.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150609182627.Horde._HGuwHi4HNqgLptnKCecj_l@andreasschulze.de> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dane] DANE works, thanks X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2015 16:43:00 -0000 On Tue, Jun 09, 2015 at 06:26:27PM +0200, A. Schulze wrote: > Barry Leiba encourage me to write this "it works" message. Thanks for the confirmation. > OK, the total number of DNSSEC enabled destinations is small. Really small. > But for these destinations we're simply sure we transfer message securely to > the right receiver. > > YES, > - it works > - it does not hurt Still increasing gradually. I have curated ~1400 domains now, but only 19 of them are "large enough" to be listed in the TLS statistics in Google's email transparency report. That much smaller number is also rising gradually, just a few months ago it was 13. I hope that once the SMTP, SRV and "ops" drafts are published RFCs, the adoption rate will pick up. It would also be nice to see even fewer of the early adopters messing up key rotation (forgetting to update TLSA RRs when replacing certs). The number of broken domains is only small, because I send alerts now and then to the domains that get it wrong. Fully automating this is on the TODO list, but cycles are scarce. -- Viktor. From nobody Tue Jun 9 10:40: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 916181B2DA9 for ; Tue, 9 Jun 2015 10:40:05 -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 lV9ZSGXft8Fv for ; Tue, 9 Jun 2015 10:40:03 -0700 (PDT) Received: from mail-oi0-f45.google.com (mail-oi0-f45.google.com [209.85.218.45]) (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 0697F1B2D99 for ; Tue, 9 Jun 2015 10:40:02 -0700 (PDT) Received: by oihb142 with SMTP id b142so16533066oih.3 for ; Tue, 09 Jun 2015 10:40:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=Dgs4VJY5TIk+mph7jXWTx8JBwbM9pI+wW5XyQciUsk8=; b=PHA4nnG83zvD6BAyxDr1LuIi08+/tEGrgs8xCKmoGQnKuP6OczEmiwSu5kwRtP9yol 4g4ZdTs3YzjjJCNOEKrpBlsGnfQjzWigH5C8EkN+arRIUaXCjASwgB+AuXOjgjuCBU8y YFAxXS4NUj2gZQQjCM4t/kqfFFmmI6ZEYEJ7/ZTMgJUosg6MaMmwgzqIvfJ0+gs1wn6c sI8S5oaNHkcjDnDLp/DLb2P0NGnW6+usmKsxVhDOzEDT5WadoaqntxdpMsYQ4ymt8GB3 jMjUOnRq9/pMLhlkPK6v85fbgGnn6SA0JjR9/rgCeDGoIxqKgZEeSs0UQbS4a40KmFZV 8kYg== X-Gm-Message-State: ALoCoQl+2/fHPYJovDfLy7ahTVMWQT2qSDAGNhd6xV30MDWK5jOAjkMfVaD/28wlONmQboAiag6K MIME-Version: 1.0 X-Received: by 10.60.145.228 with SMTP id sx4mr20241036oeb.79.1433871600247; Tue, 09 Jun 2015 10:40:00 -0700 (PDT) Received: by 10.202.196.75 with HTTP; Tue, 9 Jun 2015 10:40:00 -0700 (PDT) In-Reply-To: <20150609164257.GQ5512@mournblade.imrryr.org> References: <20150609182627.Horde._HGuwHi4HNqgLptnKCecj_l@andreasschulze.de> <20150609164257.GQ5512@mournblade.imrryr.org> Date: Tue, 9 Jun 2015 13:40:00 -0400 Message-ID: From: Warren Kumari To: "" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [dane] DANE works, thanks X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 09 Jun 2015 17:40:05 -0000 On Tue, Jun 9, 2015 at 12:42 PM, Viktor Dukhovni wrote: > On Tue, Jun 09, 2015 at 06:26:27PM +0200, A. Schulze wrote: > >> Barry Leiba encourage me to write this "it works" message. > > Thanks for the confirmation. > >> OK, the total number of DNSSEC enabled destinations is small. Really small. >> But for these destinations we're simply sure we transfer message securely to >> the right receiver. >> >> YES, >> - it works >> - it does not hurt > > Still increasing gradually. I have curated ~1400 domains now, but > only 19 of them are "large enough" to be listed in the TLS statistics > in Google's email transparency report. That much smaller number > is also rising gradually, just a few months ago it was 13. > > I hope that once the SMTP, SRV and "ops" drafts are published RFCs, > the adoption rate will pick up. > > It would also be nice to see even fewer of the early adopters > messing up key rotation (forgetting to update TLSA RRs when > replacing certs). Something that I have found is useful for things like this is to inset a large comment in the MTA config file saying something like: # ************************************************* # NOTE NOTE NOTE NOTE NOTE NOTE # # Don't forget to update the TLSA record # when replacing this certificate, or you will # look like a dumdum... #************************************************* right above the smtpd_tls_cert_file = (or equivalent) line. That way I'm (hopefully!) sure to notice and remember... > > The number of broken domains is only small, because I send alerts > now and then to the domains that get it wrong. Thank you -- this seems to have made a significant difference. > Fully automating this > is on the TODO list, but cycles are scarce. Fair enough, W > > -- > Viktor. > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane -- 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 Tue Jun 9 11:07: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 02DB41B2E26 for ; Tue, 9 Jun 2015 11:07:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 HNP2e5aPvchj for ; Tue, 9 Jun 2015 11:06:58 -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 58DC71B2E1B for ; Tue, 9 Jun 2015 11:06:56 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 3747A28494C; Tue, 9 Jun 2015 18:06:55 +0000 (UTC) Date: Tue, 9 Jun 2015 18:06:55 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150609180654.GV5512@mournblade.imrryr.org> References: <20150609182627.Horde._HGuwHi4HNqgLptnKCecj_l@andreasschulze.de> <20150609164257.GQ5512@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] DANE works, thanks X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2015 18:07:00 -0000 On Tue, Jun 09, 2015 at 01:40:00PM -0400, Warren Kumari wrote: > Something that I have found is useful for things like this is to inset > a large comment in the MTA config file saying something like: > # ************************************************* > # NOTE NOTE NOTE NOTE NOTE NOTE > # > # Don't forget to update the TLSA record > # when replacing this certificate, or you will > # look like a dumdum... > #************************************************* > right above the smtpd_tls_cert_file = (or equivalent) line. My inclination is to recommend placing this in the certificate file itself (PEM certificate files can contain ignored text above the "-----BEGIN/END...." blocks) as well a CERT_UPDATE_README file in the directory containing the certificate file and keys. We can also recommend that the user insert similar text near the certificate settings infthe MTA configuration file, but we can't do it for them. There are too many different tools for managing the config files. -- Viktor. From nobody Tue Jun 9 11:23:34 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 5FBF41B2E3E for ; Tue, 9 Jun 2015 11:23:33 -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_40=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9OIrWkXq3ann for ; Tue, 9 Jun 2015 11:23:31 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0067.outbound.protection.outlook.com [65.55.169.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 528631B2E3B for ; Tue, 9 Jun 2015 11:23:31 -0700 (PDT) Received: from CY1PR0601MB1657.namprd06.prod.outlook.com (25.163.232.19) by CY1PR0601MB1658.namprd06.prod.outlook.com (25.163.232.20) with Microsoft SMTP Server (TLS) id 15.1.184.17; Tue, 9 Jun 2015 18:23:29 +0000 Received: from CY1PR0601MB1657.namprd06.prod.outlook.com ([25.163.232.19]) by CY1PR0601MB1657.namprd06.prod.outlook.com ([25.163.232.19]) with mapi id 15.01.0184.014; Tue, 9 Jun 2015 18:23:29 +0000 From: Dan York To: IETF DANE Mailinglist Thread-Topic: FYI - DANE experiments with SMTP at Go6 Lab in Slovenia Thread-Index: AQHQouFhG+O5M99r6E2uDPdomN/V6A== Date: Tue, 9 Jun 2015 18:23:28 +0000 Message-ID: <5BF94512-2001-4F7F-A6B9-A5313571BB80@isoc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [74.69.229.215] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0601MB1658; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(520003)(3002001); SRVR:CY1PR0601MB1658; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0601MB1658; x-forefront-prvs: 06022AA85F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(69234005)(87936001)(2900100001)(2656002)(189998001)(19617315012)(54356999)(46102003)(15975445007)(102836002)(66066001)(229853001)(77156002)(40100003)(450100001)(107886002)(5001960100002)(86362001)(122556002)(83716003)(110136002)(62966003)(82746002)(106116001)(19580405001)(99286002)(15395725005)(50986999)(5002640100001)(16236675004)(36756003)(33656002)(92566002)(19580395003)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR0601MB1658; H:CY1PR0601MB1657.namprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_5BF9451220014F7FA6B9A5313571BB80isocorg_" MIME-Version: 1.0 X-OriginatorOrg: isoc.org X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jun 2015 18:23:28.4057 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0601MB1658 Archived-At: Subject: [dane] FYI - DANE experiments with SMTP at Go6 Lab in Slovenia X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 09 Jun 2015 18:23:33 -0000 --_000_5BF9451220014F7FA6B9A5313571BB80isocorg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable FYI, my Internet Society colleague Jan Zorz has been doing some work with D= ANE and SMTP at his Go6 Lab in Slovenia. He recent wrote up his work thus = far in two blog posts: Testing DANE For Sending Secure Email at the Go6lab http://www.internetsociety.org/deploy360/blog/2015/05/testing-dane-for-send= ing-secure-email-at-the-go6lab/ More DANE / DNSSEC / TLS Testing From Go6lab http://www.internetsociety.org/deploy360/blog/2015/06/more-dane-dnssec-tls-= testing-from-go6lab/ In this second post he recounts how he created some scripts to analyze the = top 1 million Alexa domain names and to determine how many of them are publ= ishing TLSA records. And his scripts went out and initiated connections to= over 473,000 mail servers to find out how many were using TLS in general a= nd how many were using TLSA specifically. All of his statistics and other = information can be found in that post. I thought some of you might find this of interest... Dan -- Dan York Senior Content Strategist, Internet Society york@isoc.org +1-802-735-1624 Jabber: york@jabber.isoc.org Skype: danyork http://twitter.com/danyork http://www.internetsociety.org/ --_000_5BF9451220014F7FA6B9A5313571BB80isocorg_ Content-Type: text/html; charset="us-ascii" Content-ID: <497CFA2AF0A8B64DB529EEE21157D5CA@namprd06.prod.outlook.com> Content-Transfer-Encoding: quoted-printable FYI, my Internet Society colleague Jan Zorz has been doing some work with D= ANE and SMTP at his Go6 Lab in Slovenia.  He recent wrote up his work = thus far in two blog posts:

Testing DANE For Sending Secure Email at the Go6lab
http= ://www.internetsociety.org/deploy360/blog/2015/05/testing-dane-for-sending-= secure-email-at-the-go6lab/ 

More DANE / DNSSEC / TLS Testing From Go6lab
http://www.inte= rnetsociety.org/deploy360/blog/2015/06/more-dane-dnssec-tls-testing-from-go= 6lab/ 

In this second post he recounts how he created some scripts= to analyze the top 1 million Alexa domain names and to determine how many = of them are publishing TLSA records.  And his scripts went out and ini= tiated connections to over 473,000 mail servers to find out how many were using TLS in general and how many were u= sing TLSA specifically.  All of his statistics and other information c= an be found in that post.

I thought some of you might find this of interest...
Dan

--
Dan York
Senior Content Strategist, Int= ernet Society
york@isoc.org   +1-802-735-1624
Jabber: york@jabber.isoc.org 
Skype: danyork   http://twitter.com/danyork

http://www.internetsociety.org/



--_000_5BF9451220014F7FA6B9A5313571BB80isocorg_-- From nobody Tue Jun 9 12:21: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 938DB1B2EC4 for ; Tue, 9 Jun 2015 12:21: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, 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 NeaEw1ZpH8wV for ; Tue, 9 Jun 2015 12:21: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 517321ACCD9 for ; Tue, 9 Jun 2015 12:21:46 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id EE0B5282FBB; Tue, 9 Jun 2015 19:21:44 +0000 (UTC) Date: Tue, 9 Jun 2015 19:21:44 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150609192144.GX5512@mournblade.imrryr.org> References: <5BF94512-2001-4F7F-A6B9-A5313571BB80@isoc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5BF94512-2001-4F7F-A6B9-A5313571BB80@isoc.org> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dane] FYI - DANE experiments with SMTP at Go6 Lab in Slovenia X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2015 19:21:49 -0000 On Tue, Jun 09, 2015 at 06:23:28PM +0000, Dan York wrote: > Testing DANE For Sending Secure Email at the Go6lab > > http://www.internetsociety.org/deploy360/blog/2015/05/testing-dane-for-sending-secure-email-at-the-go6lab/ Good to see folks getting their feet wet. They posted some settings they used: smtpd_use_tls = yes smtpd_tls_security_level = may smtpd_tls_key_file = /etc/postfix/ssl/server.pem smtpd_tls_cert_file = /etc/postfix/ssl/server.pem smtpd_tls_auth_only = no smtpd_tls_loglevel = 1 smtpd_tls_received_header = yes smtpd_tls_session_cache_timeout = 3600s smtp_tls_security_level = dane smtp_use_tls = yes smtp_tls_note_starttls_offer = yes smtp_tls_loglevel = 1 tls_random_exchange_name = /var/run/prng_exch tls_random_source = dev:/dev/urandom tls_smtp_use_tls = yes I suggest dropping a few of these: # Obsolete smtpd_use_tls = yes smtp_use_tls = yes # Unwise, best to restrict SASL to TLS clients smtpd_tls_auth_only = no # This is already the default value smtpd_tls_session_cache_timeout = 3600s # Unnecessary when TLS is enabled for all smtp_tls_note_starttls_offer = yes # No such parameter exists. tls_smtp_use_tls = yes They neglected to mention: smtp_dns_support_level = dnssec http://www.postfix.org/postconf.5.html#smtp_dns_support_level As mentioned above, Postfix is not a validating stub resolver; it relies on the system's configured DNSSEC-validating recursive nameserver to perform all DNSSEC validation. Since this nameserver's DNSSEC-validated responses will be fully trusted, it is strongly recommended that the MTA host have a local DNSSEC-validating recursive caching nameserver listening on a loopback address, and be configured to use only this nameserver for all lookups. Otherwise, Postfix may remain subject to man-in-the-middle attacks that forge responses from the recursive nameserver And I think everyone needs to mention the need to handle TLSA record updates on future key/cert rotation. All well and good to get DANE working initially, but not so good if it is forgotten, and breaks later. I'm sorry they found the documentation of "dane-only" unclear. It behaves as promised, DANE authentication is required. This is for explicit policy with specific "partner" domains. > In this second post he recounts how he created some scripts to analyze > the top 1 million Alexa domain names and to determine how many of them > are publishing TLSA records. And his scripts went out and initiated > connections to over 473,000 mail servers to find out how many were using > TLS in general and how many were using TLSA specifically. All of his > statistics and other information can be found in that post. As for Alexa, it is a compilation of web sites, not SMTP domains, so it is not a comprehensive source for the latter. The list of domains they report is not quite right, for example mail.netbsd.org is not DNSSEC validated. Out of ~1400 domains I found with working MX host TLSA records, only 39 were listed by Alexa (at some point in the last year). Of the 19 that are also in Google's email transparency report, only 7 are listed by Alexa. -- Viktor. From nobody Tue Jun 9 12:34: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 CBCF71B2F87 for ; Tue, 9 Jun 2015 12:34:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 HFi3zpSJxghW for ; Tue, 9 Jun 2015 12:34:36 -0700 (PDT) Received: from mx.karotte.org (mx.karotte.org [IPv6:2a01:4f8:150:7142::25]) (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 881661B2F86 for ; Tue, 9 Jun 2015 12:34:36 -0700 (PDT) Received: from danton.fire-world.de (unknown [IPv6:2001:4c50:62f:c000:654b:42cc:eb56:eecd]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "danton.fire-world.de", Issuer "danton.fire-world.de" (not verified)) by mx.karotte.org (Postfix) with ESMTPSA id 3m5hV24cggzCr2D for ; Tue, 9 Jun 2015 21:34:34 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=karotte.org; s=snowcrash; t=1433878474; bh=2rb3GT59Ll0EQrvJkW82JbO6wOQXiGsJ7GMZhlZDCOg=; h=Date:From:To:Subject:References:In-Reply-To; b=DTx4viDceaupLJ6PtoXMKUEebU4aBpJEsmK3AclJWMTob0ggPLimspJeTtuhxWBFb mq4DjGOEb5KiJn9JF647XrqYJLHLnQ0VyVEB1Mag9MMdCfIJW8LWC3G5odqKNIVPk6 Ev2pZh7hiEMiZhxRulrqE8WCSfIivb+lwNTSkPHI= Received: by danton.fire-world.de (Postfix, from userid 1000) id 3m5hV21b7wz12bF6; Tue, 9 Jun 2015 21:34:34 +0200 (CEST) Date: Tue, 9 Jun 2015 21:34:34 +0200 From: Sebastian Wiesinger Sender: ietf.dane@ml.karotte.org To: dane@ietf.org Message-ID: <20150609193434.GA10240@danton.fire-world.de> Mail-Followup-To: dane@ietf.org References: <20150609182627.Horde._HGuwHi4HNqgLptnKCecj_l@andreasschulze.de> <20150609164257.GQ5512@mournblade.imrryr.org> <20150609180654.GV5512@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="r5Pyd7+fXNt84Ff3" Content-Disposition: inline In-Reply-To: <20150609180654.GV5512@mournblade.imrryr.org> X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [dane] DANE works, thanks X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 09 Jun 2015 19:34:38 -0000 --r5Pyd7+fXNt84Ff3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Viktor Dukhovni [2015-06-09 20:09]: > On Tue, Jun 09, 2015 at 01:40:00PM -0400, Warren Kumari wrote: >=20 > > Something that I have found is useful for things like this is to inset > > a large comment in the MTA config file saying something like: > > # ************************************************* > > # NOTE NOTE NOTE NOTE NOTE NOTE > > # > > # Don't forget to update the TLSA record > > # when replacing this certificate, or you will > > # look like a dumdum... > > #************************************************* > > right above the smtpd_tls_cert_file =3D (or equivalent) line. >=20 > My inclination is to recommend placing this in the certificate file > itself (PEM certificate files can contain ignored text above the > "-----BEGIN/END...." blocks) as well a CERT_UPDATE_README file in > the directory containing the certificate file and keys. What would help a lot of people would be a drop-in nagios check which compares TLSA to actual cert. Probably easy to do for connections which start with TLS, not so trivial for STARTTLS types of connections. Regards Sebastian --=20 GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SC= YTHE. -- Terry Pratchett, The Fifth Elephant --r5Pyd7+fXNt84Ff3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQF6BAEBCgBkBQJVdz/JMxSAAAAAABUAFXBrYS1hZGRyZXNzQGdudXBnLm9yZ3Nl YmFzdGlhbkBrYXJvdHRlLm9yZykaaHR0cHM6Ly93d3cua2Fyb3R0ZS5vcmcvcGdw LXBvbGljeS5zaHRtbAAKCRBYotlKk6C5zih5CACMaOHd5K+4dRzvVuR+711pyDTO r589Zqorx61k/MkOeA3Y3IwnGQ2ppQLJDMjRiBKuKG0Pb4oqvGvq/CZykuvr9Ixu jfgjpEt/8+LLLJ+5pRkIx2ndlJqNa5pVA/3kOpEus4BTJrES6CghXeYMgw9NtgST +Xdzyk7DAymg95YU1bWThrdwqomgCb+ocEy7+dOVJItzWjB2CY7z4iQjrE9dnVYp R2IkN7l9zVe31NAKoke+v5ifYZXsbWMy/K4Grv4BfCC7AxjiIOjZp+X4USRDj1/v fk6WLPeJWrskNeqWejbUuKaNCNDdaFc0j0L96iCTSj9WlJblth4Dpg1JAkMR =cYTP -----END PGP SIGNATURE----- --r5Pyd7+fXNt84Ff3-- From nobody Tue Jun 9 12:48: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 3EB2B1B2FE4 for ; Tue, 9 Jun 2015 12:48: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, 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 EnmXslXgQ5zj for ; Tue, 9 Jun 2015 12:48:13 -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 F35771B2FDA for ; Tue, 9 Jun 2015 12:48:12 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 14D1D282FBB; Tue, 9 Jun 2015 19:48:12 +0000 (UTC) Date: Tue, 9 Jun 2015 19:48:12 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150609194811.GZ5512@mournblade.imrryr.org> References: <20150609182627.Horde._HGuwHi4HNqgLptnKCecj_l@andreasschulze.de> <20150609164257.GQ5512@mournblade.imrryr.org> <20150609180654.GV5512@mournblade.imrryr.org> <20150609193434.GA10240@danton.fire-world.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150609193434.GA10240@danton.fire-world.de> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dane] DANE works, thanks X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2015 19:48:18 -0000 On Tue, Jun 09, 2015 at 09:34:34PM +0200, Sebastian Wiesinger wrote: > > My inclination is to recommend placing this in the certificate file > > itself (PEM certificate files can contain ignored text above the > > "-----BEGIN/END...." blocks) as well a CERT_UPDATE_README file in > > the directory containing the certificate file and keys. > > What would help a lot of people would be a drop-in nagios check which > compares TLSA to actual cert. Probably easy to do for connections > which start with TLS, not so trivial for STARTTLS types of > connections. STARTTLS is not difficult to test. We were thinking of having folks sign up for monitoring by sys4.de, with the results published via DNS, and nagios can then just do a quick DNS lookup. The advantage of a remote monitoring service, is that it can may see DNS issues that are only apparent from outside the site's own network. The remote service can also make it easier for sites connecting to a domain that has problems to check whether others are also having the same issue. This has not moved past the discussion stage yet. -- Viktor. From nobody Tue Jun 9 13:46: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 3F51D1A010E for ; Tue, 9 Jun 2015 13:46:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.239 X-Spam-Level: ** X-Spam-Status: No, score=2.239 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_BRBL_LASTEXT=1.449, 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 0RJ3BwLDRsMb for ; Tue, 9 Jun 2015 13:46:10 -0700 (PDT) Received: from new.toad.com (new.toad.com [209.237.225.253]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (112/168 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9337D1A00CF for ; Tue, 9 Jun 2015 13:46:10 -0700 (PDT) Received: from new.toad.com (localhost.localdomain [127.0.0.1]) by new.toad.com (8.12.9/8.12.9) with ESMTP id t59Kk7CF006919 for ; Tue, 9 Jun 2015 13:46:07 -0700 Message-Id: <201506092046.t59Kk7CF006919@new.toad.com> To: "" In-reply-to: References: <20150609182627.Horde._HGuwHi4HNqgLptnKCecj_l@andreasschulze.de> <20150609164257.GQ5512@mournblade.imrryr.org> Comments: In-reply-to Warren Kumari message dated "Tue, 09 Jun 2015 13:40:00 -0400." Date: Tue, 09 Jun 2015 13:46:07 -0700 From: John Gilmore Archived-At: Subject: Re: [dane] DANE works, thanks X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 09 Jun 2015 20:46:11 -0000 > Still increasing gradually. I have curated ~1400 domains now, but > only 19 of them are "large enough" to be listed in the TLS statistics > in Google's email transparency report. That much smaller number > is also rising gradually, just a few months ago it was 13. It sounds like the number of domains you have curated using DNSSEC and DANE is larger than the number of domains on the ARPANET. And look what that grew into! John :-) From nobody Tue Jun 9 14:00: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 2A2F81A1A98 for ; Tue, 9 Jun 2015 14:00:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.861 X-Spam-Level: X-Spam-Status: No, score=0.861 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_HELO_PASS=-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 JhpkQ7tEdEDF for ; Tue, 9 Jun 2015 14:00:37 -0700 (PDT) Received: from oj.bangj.com (amt0.gin.ntt.net [129.250.11.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 072B61A017E for ; Tue, 9 Jun 2015 14:00:37 -0700 (PDT) Received: from [10.208.99.135] (mobile-166-173-248-055.mycingular.net [166.173.248.55]) by oj.bangj.com (Postfix) with ESMTPA id 671C311EDC for ; Tue, 9 Jun 2015 16:56:12 -0400 (EDT) From: Tom Pusateri Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Message-Id: <00674BF8-AC5B-4B91-8EE9-5ADE017AC951@bangj.com> Date: Tue, 9 Jun 2015 17:00:34 -0400 References: <20150609182627.Horde._HGuwHi4HNqgLptnKCecj_l@andreasschulze.de> <20150609164257.GQ5512@mournblade.imrryr.org> In-Reply-To: <20150609164257.GQ5512@mournblade.imrryr.org> To: "dane@ietf.org" X-Mailer: iPhone Mail (12F70) Archived-At: Subject: Re: [dane] DANE works, thanks X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 09 Jun 2015 21:00:38 -0000 > On Jun 9, 2015, at 12:42 PM, Viktor Dukhovni wrot= e: >=20 >> On Tue, Jun 09, 2015 at 06:26:27PM +0200, A. Schulze wrote: >>=20 >> Barry Leiba encourage me to write this "it works" message. >=20 > Thanks for the confirmation. >=20 >> OK, the total number of DNSSEC enabled destinations is small. Really smal= l. >> But for these destinations we're simply sure we transfer message securely= to >> the right receiver. >>=20 >> YES, >> - it works >> - it does not hurt >=20 > Still increasing gradually. I have curated ~1400 domains now, but > only 19 of them are "large enough" to be listed in the TLS statistics > in Google's email transparency report. That much smaller number > is also rising gradually, just a few months ago it was 13. >=20 > I hope that once the SMTP, SRV and "ops" drafts are published RFCs, > the adoption rate will pick up. >=20 > It would also be nice to see even fewer of the early adopters > messing up key rotation (forgetting to update TLSA RRs when > replacing certs). >=20 > The number of broken domains is only small, because I send alerts > now and then to the domains that get it wrong. Fully automating this > is on the TODO list, but cycles are scarce. >=20 > --=20 > Viktor. >=20 I have some spare cycles to do development. Can I assist? Tom= From nobody Wed Jun 10 16:59: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 DFA641A8AD2 for ; Wed, 10 Jun 2015 16:59:51 -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 ijMMAzQdqVEk for ; Wed, 10 Jun 2015 16:59:47 -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 2C4781A8AC1 for ; Wed, 10 Jun 2015 16:59:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 34C4EBEE1 for ; Thu, 11 Jun 2015 00:59:45 +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 0hiLDiuQ5Q7B for ; Thu, 11 Jun 2015 00:59:42 +0100 (IST) Received: from [10.87.48.73] (unknown [86.46.23.15]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id AA920BEDF for ; Thu, 11 Jun 2015 00:59:42 +0100 (IST) Message-ID: <5578CF6D.9060905@cs.tcd.ie> Date: Thu, 11 Jun 2015 00:59:41 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: dane References: <556F0BDF.6090603@cs.tcd.ie> In-Reply-To: <556F0BDF.6090603@cs.tcd.ie> 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-ops-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: Wed, 10 Jun 2015 23:59:52 -0000 So I didn't see a response from the shepherd and since I'm heading off now on holiday I've asked for the IETF LC to be started. I'd like to continue this discussion when I'm back after IETF LC. (And yes I saw Viktor's response but haven't had a chance to get back on that sorry) Cheers, S. On 03/06/15 15:14, Stephen Farrell wrote: > > Hiya, > > My review of this is below. I'm fine with starting the IETF LC > and you handling these as last call comments along with others > but since there are a bunch of 'em (and I bet Viktor will not > be silent anyway:-) please tell me (Warren, as shepherd) if you > prefer me to start the IETF LC now, or wait until we've chatted > about these a bit. (And I'm fine either way.) > > Cheers and thanks for the work on this, > S. > > - general: this was a bit of a slog - the draft is > both dense (loads of 2119 terms) and long, which > makes it a hard read. I'm not saying it's possible > to do better, but just noting that in case someone > has a good idea about how to make it easier to read. > > - intro, 3rd para: I don't think this is very clear > and it'd be great if it were - isn't there a way to > provide clarity about the name that goes with the > TLS session in which cases? > > - 1.1, I think you need to define "TLSA base domain" > here (or is it elsewhere? I didn't find it in 6698) > > - section 2: Why duplicate so much of 7218? I think > it'd be better not to (or to obsolete that with > this) but I don't care that much really. > > - section 2: last sentence before 2.1 - is that > saying that the MUST applies to section 9? If not, > I'm not sure what it means, but it's not quite > clear. > > - section 3: saying TLS1.2 is a SHOULD is fine but > what about when TLS1.3 is done (next year). > Wouldn't it be better to say that the latest TLS > version is a SHOULD and is currently 1.2? > > - section 4: I read this as you calling DNSSEC > "illusory incremental security" which I don't think > is really what you mean and which interpretation > calls into question the strength of the > RECOMMENDATION here. 4.1 similarly says "PKIX-TA(0) > and PKIX-EE(1) TLSA records do not provide > additional security" which is too definitive, where > is the evidence? (Not opinion or argument, but > evidence.) In the absence of evidence I think we > should omit these (and they are not needed.) > > - 4.2: Did we check that CT is unlikely to make > sense with DANE-TA records? In principle, public > logs could add enterprise CAs without having real > spam issues. I agree it's unlikely to happen in > practice, and it's probably fine to revise this if > that starts happening a lot, but since it could in > principle, I wondered if we'd checked with the trans > list (and I don't recall that we have) > > - 5.1, last para: that's a bit coy about the "extra > logic" - wouldn't it be better to explain? If not, > why not? > > - 5.2.1: 2nd para says "do honour constraints" but > earlier (for DANE-EE+Cert) you explicitly said to > ignore validity, subject etc. I think it'd be better > to explicitly say here whether or not validity and > naming need to match and if they do, then how. > As-is, I suspect developers are likely to randomly > either ignore validity and naming here too, or > not;-) And if enough of 'em do different things, > then that'd be bad. (If there were a good list of > subsections of 5280 to honor or ignore that might > work, but would be a bit tedious to figure out and > might not work - I've not checked.) > > - 5.2.3, last para: What is "are encouraged to" in > 2119 terms? > > - 5.4: "SHOULD NOT always stop" isn't clear, and the > next sentence seems to have the MUST that clarified, > so maybe drop the 2119 "SHOULD NOT"? > > - section 6: what is a "master" TLSA record? Maybe > better to not introduce a new term like that. > > - section 8, 2nd para: saying "are only compatible > with" seems like an overstatement to me > > - 8.2: I think in this example you generate a new > key pair for the TLS server at the time that your > are transitioning from DANE-EE to DANE-TA. Saying > that would help, as there could be another > transition case where the same TLS server key pair > is maintained and an x.509 certificate (issued under > the DANE-TA) for that same key is deployed on the > TLS server. I'm not saying that's a better > transition but only that it could presumably be done > and arguably easier if it worked. But the only > change I'd suggest for now is to just point out that > a new key pair is generated for this example. > > - 8.3: lowercase "should" often confuses as to > whether that means 2119 or not. I don't care how you > resolve. > > - 8.4, I think last sentence of 1st bullet could be > worth a bullet of its own > > - 8.4, I'm not sure the last bullet is clear enough > to be a useful summary - its a doozy of a sentence > in any case;-) > > - section 9: your background is showing:-) "by the > MTA administrator" should presumably be "on the TLS > client (e.g. by an MTA administrator)" or similar. > > - 10.1.1: I guess we don't consider that it'd be > good to give a reference to the TC bit? I'm ok with > that but someone else might like to have one. > > - 10.2: "The server name used for this comparison > SHOULD be the base domain of the TLSA RRset." I > think that works ok, but isn't that a change in > client behaviour compared to a non-DANE TLS client? > If to, then don't you need to call that out much > more clearly? Do we actually need a "differences > between DANE TLS clients and non-DANE TLS clients" > section? > > - section 11: I think s/public CA PKI/public CA > WebPKI/ would be more accurate > > - section 11: I don't get the logic for recommending > weekly signing - once you automate signing (which > you have to) then daily seems like it should work > for everyone and weekly hasn't any benefit. So I > don't get the reasoning here. (And a week seems bad > when I read section 13 too.) > > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > > From nobody Wed Jun 10 17:21: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 298E41A8A85; Wed, 10 Jun 2015 17:21:07 -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 2cwXdO7eygxY; Wed, 10 Jun 2015 17:21:01 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A2EFC1A8A86; Wed, 10 Jun 2015 17:21:01 -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.3.p2 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20150611002101.10330.94232.idtracker@ietfa.amsl.com> Date: Wed, 10 Jun 2015 17:21:01 -0700 Archived-At: Cc: dane@ietf.org Subject: [dane] Last Call: (Updates to and Operational Guidance for the DANE Protocol) 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, 11 Jun 2015 00:21:07 -0000 The IESG has received a request from the DNS-based Authentication of Named Entities WG (dane) to consider the following document: - 'Updates to and Operational Guidance for the DANE Protocol' 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-06-24. 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 document clarifies and updates the DNS-Based Authentication of Named Entities (DANE) TLSA specification (RFC6698) based on subsequent implementation experience. It also contains guidance for implementers, operators and protocol developers who want to make use of DANE records. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-dane-ops/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-dane-ops/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Wed Jun 10 22:37: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 1ACA41A008B for ; Wed, 10 Jun 2015 22:37:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 Wr1WHdnyjOYM for ; Wed, 10 Jun 2015 22:37:24 -0700 (PDT) Received: from smtp100.ord1c.emailsrvr.com (smtp100.ord1c.emailsrvr.com [108.166.43.100]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C54651A007F for ; Wed, 10 Jun 2015 22:37:23 -0700 (PDT) Received: from smtp5.relay.ord1c.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp5.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 2A98018023F; Thu, 11 Jun 2015 01:37:23 -0400 (EDT) Received: by smtp5.relay.ord1c.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id 1F32818022E; Thu, 11 Jun 2015 01:37:21 -0400 (EDT) X-Sender-Id: ogud@ogud.com Received: from [192.168.1.61] (208-90-212-141.PUBLIC.monkeybrains.net [208.90.212.141]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:465 (trex/5.4.2); Thu, 11 Jun 2015 05:37:23 GMT Content-Type: multipart/alternative; boundary="Apple-Mail=_2C613CF5-6F66-4793-9004-3CF9BC88609F" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Olafur Gudmundsson In-Reply-To: <06D0C5A0-6C9C-42F6-8513-9335A87E0A5A@powerdns.com> Date: Thu, 11 Jun 2015 01:37:19 -0400 Message-Id: <493CD5D9-4D9F-40DF-9735-A30D4A370800@ogud.com> References: <556F6664.8020800@cs.tcd.ie> <06D0C5A0-6C9C-42F6-8513-9335A87E0A5A@powerdns.com> To: Peter van Dijk X-Mailer: Apple Mail (2.2098) Archived-At: Cc: dane Subject: Re: [dane] AD review of draft-ietf-dane-openpgpkey-03 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 11 Jun 2015 05:37:27 -0000 --Apple-Mail=_2C613CF5-6F66-4793-9004-3CF9BC88609F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Peter,=20 > On Jun 9, 2015, at 7:13 AM, Peter van Dijk = wrote: >=20 > Hello Stephen, >=20 > thank you for your extensive coverage of the draft. >=20 > On 3 Jun 2015, at 22:41, Stephen Farrell wrote: >=20 >> Stuff I'd like to chat about before starting IETF LC: >>=20 >> (1) Given the email-addr-in-DNS issues with this, would >> this not be better as experimental? I think the WG did >> consider that, but I forget, and in any case even if you >> did, I want to ask again, to be sure to be sure:-) My >> concern is that we not end up arguing against other >> folks who may want to standardise some form(s) of key >> server on the basis that this is *the* standard way to >> do it. One way to handle that would be for this to be >> experimental and for us to see if it gets deployed or >> not. Another could be to just say in the text that this >> proposed standard is one way of distributing keys, but >> that others can be equally valid. >=20 > Even experimental seems a bit strong for a lookup method that has seen = so much debate without serious improvement. The hashing method is poorly = specified, and stronger text would not help - we are still preventing = lookups in case of lower/uppercase differences, subadresses (peter+foo), = dot insertion (gmail). >=20 This is a strong statement, I have a problem with your word "preventing" = . My reading of the draft is that mail sender can perform the Hash() = operation on any name she/he has/guesses for the receiver, and looks each one up = in until a match is found or the sender gives up.=20 Right now we do not really know if this will scale, some think it will, = some do not think it will thus the=20 experimental status.=20 The fundamental problem is the mess called "email addresses" we are not = the right forum to solve that problem.=20 > Let me emphasize that: the draft is, in its current form, undeployable = for Google Mail. While I don't expect that they want to, this is a = strong signal that the draft is broken. Well another strong statement, while for scale reason I may agree with = you. But google has shown over the years that they can address scaling = issues in many different ways. So while they may balk at this one they = may select another mechanism that makes no sense for small operators. Just because we may suspect some operators may or may not be able to = deploy something absent of a statement from them we are just = speculating.=20 John Levine in a followup message was trying to calculate the size of a = gmail PGP zone file, and I agree with him it would be big but on-line = signing like PowerDNS provides could address that issue, with a large = backend DB.=20 >=20 > I have strong objections to the texts "Both of these issues have been = refuted" and "There is not much more we can do at this point to address = it." under question 6 in = http://datatracker.ietf.org/doc/draft-ietf-dane-openpgpkey/shepherdwriteup= /; similar "this is the best we can do"-language in other sections seem = equally wrong. I also never got the feeling that WG consensus on the = full content of the draft was "strong" but I may be mistaken here. The chairs can only go by what they hear either in public or private = when judging consensus. Most of the objections I heard during the = discussion on this draft were related to output format of the Hash = function rather than the technique of the hashing.=20 In my mind that was addressed by the editor, If I=E2=80=99m mistaken I = happy to correct myself.=20 >=20 > Better methods than hashing have been proposed. For example, split = base32 is better in every way (and, as a bonus, actually deployable, = unlike the hashing method) except perhaps address privacy concerns = (which the draft explicitly dismisses in section 6.2 anyway). However, = the split base32. has been shot down because, and I quote, "I do not = understand the advantage of base32 in the QNAME." No other arguments = have been put forward. The argument here is hash has fixed length, the base32 encoding of long = email name is broken into multiple tables.=20 If email people tell us that that is better than what is proposes we = will listen.=20 >=20 > Moving the draft forward in its current form, onto Standards Track, = would be a mistake. Moving it forward as Experimental would be somewhat = better, but I suggest using even stronger language explaining that this = RFC only defines an RRtype, keeping the lookup mechanism as no more than = a weak suggestion. what the document status is not a big deal, RRtype needs a RFC.=20 >=20 > While personally I feel split base32 would be fine to use in an RFC = (be it Experimental or Standards Track), your point of 'not end up = arguing against other folks' is valid, and in that case one could = consider removing all lookup text from the RFC, and making it just about = the RRtype. We had that discussion early on, and the argument was how do I find it = was asked. So while a replacement of this document may define a better = solution we do not at this point know if that exists. A failure of = deployment would be a good indicator.=20 >=20 >> - section 5: is "recommended" there meant as a 2119 >> thing? If so, it's usually better in uppercase. >=20 > The mention of TCP here, as in 6.1, is a weird operational sidestep = for this document. DNS operators know about big records and responses, = and can deal with them accordingly, without singling out specific = RRtypes. >=20 Good question I will leave this to the editor to address > Kind regards, Thanks for starting a good discussion now lets hope others chime in.=20 Olafur > --=20 > Peter van Dijk > PowerDNS.COM BV - https://www.powerdns.com/ >=20 > __ --Apple-Mail=_2C613CF5-6F66-4793-9004-3CF9BC88609F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Peter, 

On Jun 9, 2015, at 7:13 AM, = Peter van Dijk <peter.van.dijk@powerdns.com> wrote:

Hello Stephen,

thank you for your extensive coverage of the = draft.

On 3 Jun 2015, at 22:41, Stephen = Farrell wrote:

Stuff I'd like to chat about before starting IETF LC:

(1) Given the email-addr-in-DNS issues with = this, would
this not be better as experimental? I think = the WG did
consider that, but I forget, and in any case = even if you
did, I want to ask again, to be sure to be = sure:-) My
concern is that we not end up arguing against = other
folks who may want to standardise some form(s) of = key
server on the basis that this is *the* standard way = to
do it. One way to handle that would be for this to = be
experimental and for us to see if it gets deployed = or
not. Another could be to just say in the text that = this
proposed standard is one way of distributing keys, = but
that others can be equally valid.

Even experimental seems a bit = strong for a lookup method that has seen so much debate without serious = improvement. The hashing method is poorly specified, and stronger text = would not help - we are still preventing lookups in case of = lower/uppercase differences, subadresses (peter+foo), dot insertion = (gmail).


This is a = strong statement, I have a problem with your word "preventing" = .
My reading of the draft = is that mail sender can perform the Hash() operation
on any name she/he has/guesses for = the receiver, and looks each one up in until a match is found or the = sender gives up. 
Right = now we do not really know if this will scale, some think it will, some = do not think it will thus the 
experimental status. 
The fundamental problem is the mess = called "email addresses" we are not the right forum to solve that = problem. 

Let = me emphasize that: the draft is, in its current form, undeployable for = Google Mail. While I don't expect that they want to, this is a strong = signal that the draft is broken.
Well another strong statement, while for scale reason = I may agree with you. But google has shown over the years that they can = address scaling issues in many different ways. So while they may balk at = this one they may select another mechanism that makes no sense for small = operators.
Just because we may suspect some operators may or = may not be able to deploy something absent of a statement from them we = are just speculating. 
John Levine in a followup message = was trying to calculate the size of a gmail PGP zone file, and I agree = with him it would be big but on-line signing like PowerDNS provides = could address that issue, with a large backend DB. 



I have strong objections to = the texts "Both of these issues have been refuted" and "There is not = much more we can do at this point to address it." under question 6 in http://datatracker.ietf.org/doc/draft-ietf-dane-openpgpkey/shep= herdwriteup/; similar "this is the best we can do"-language in other = sections seem equally wrong. I also never got the feeling that WG = consensus on the full content of the draft was "strong" but I may be = mistaken here.

The chairs can only go by what they hear either in = public or private when judging consensus. Most of the objections I heard = during the discussion on this draft were related to output format of the = Hash function rather than the technique of the = hashing. 
In my mind that was addressed by the editor, If = I=E2=80=99m mistaken I happy to correct myself. 



Better methods than hashing = have been proposed. For example, split base32 is better in every way = (and, as a bonus, actually deployable, unlike the hashing method) except = perhaps address privacy concerns (which the draft explicitly dismisses = in section 6.2 anyway). However, the split base32. has been shot down = because, and I quote, "I do not understand the advantage of base32 in = the QNAME." No other arguments have been put forward.

The argument = here is hash has fixed length, the base32 encoding of long email name is = broken into multiple tables. 
If email people tell us = that that is better than what is proposes we will = listen. 


Moving the draft forward in = its current form, onto Standards Track, would be a mistake. Moving it = forward as Experimental would be somewhat better, but I suggest using = even stronger language explaining that this RFC only defines an RRtype, = keeping the lookup mechanism as no more than a weak suggestion.

what the = document status is not a big deal, RRtype needs a = RFC. 


While personally I feel split = base32 would be fine to use in an RFC (be it Experimental or Standards = Track), your point of 'not end up arguing against other folks' is valid, = and in that case one could consider removing all lookup text from the = RFC, and making it just about the RRtype.

We had that = discussion early on, and the argument was how do I find it was asked. So = while a replacement of this document may define a better solution we do = not at this point know if that exists. A failure of deployment would be = a good indicator. 


- section 5: is "recommended" there meant as a 2119
thing? If so, it's usually better in uppercase.

The mention of TCP here, as in = 6.1, is a weird operational sidestep for this document. DNS operators = know about big records and responses, and can deal with them = accordingly, without singling out specific RRtypes.


Good question I = will leave this to the editor to address


Kind regards,

Thanks for = starting a good discussion now lets hope others chime = in. 

= Olafur

--
Peter van Dijk
PowerDNS.COM = BV - https://www.powerdns.com/

__
= --Apple-Mail=_2C613CF5-6F66-4793-9004-3CF9BC88609F-- From nobody Thu Jun 11 03:39: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 E7CDD1ACE38 for ; Thu, 11 Jun 2015 03:39:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.663 X-Spam-Level: * X-Spam-Status: No, score=1.663 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 vC1CxKLiZkZe for ; Thu, 11 Jun 2015 03:39: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 6DACB1B2F28 for ; Thu, 11 Jun 2015 03:39:42 -0700 (PDT) Received: (qmail 42933 invoked from network); 11 Jun 2015 10:39:51 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 11 Jun 2015 10:39:51 -0000 Date: 11 Jun 2015 10:39:19 -0000 Message-ID: <20150611103919.9594.qmail@ary.lan> From: "John Levine" To: dane@ietf.org In-Reply-To: <493CD5D9-4D9F-40DF-9735-A30D4A370800@ogud.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dane] AD review of draft-ietf-dane-openpgpkey-03 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 11 Jun 2015 10:39:44 -0000 >This is a strong statement, I have a problem with your word "preventing" . >My reading of the draft is that mail sender can perform the Hash() operation >on any name she/he has/guesses for the receiver, and looks each one up in until a >match is found or the sender gives up. >Right now we do not really know if this will scale, ... But we do know that it is absolutely forbidden by any normal reading of the mail RFCs. I am baffled that a design that is supposed to be about security would include guessing addresses that might or might not be the party to which you want to send your highly secure mail, and that the WG has repeatedly rejected small changes that could solve that problem. R's, John From nobody Thu Jun 11 05:41:34 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 8D1FA1ACEAE for ; Thu, 11 Jun 2015 05:41:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.112 X-Spam-Level: X-Spam-Status: No, score=-0.112 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 lfM3_7SUGhuz for ; Thu, 11 Jun 2015 05:41:32 -0700 (PDT) Received: from mx.karotte.org (mx.karotte.org [IPv6:2a01:4f8:150:7142::25]) (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 BD7A51ACEB1 for ; Thu, 11 Jun 2015 05:41:31 -0700 (PDT) Received: from danton.fire-world.de (unknown [IPv6:2001:4c50:62f:c000:b19a:aab4:3253:9301]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "danton.fire-world.de", Issuer "danton.fire-world.de" (not verified)) by mx.karotte.org (Postfix) with ESMTPSA id 3m6lDS3bgNzCrFD for ; Thu, 11 Jun 2015 14:41:28 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=karotte.org; s=snowcrash; t=1434026488; bh=UvwUYQ5mqM5MrQkyee1zH9j4O8ub/ZFw/VYahaE53PI=; h=Date:From:To:Subject:References:In-Reply-To; b=pu9gjS2s/F4A/BsXnwfoMHQI63rGhGwyg7ztq+LSxRu9Kmr3eafhRlx+ST4T7fYGK KcGwNTUMNQhPVyPmOPU3DHDH5of4tya/tZ2Fwil9p6PQX6wsyUoIUJdfD1mfHecWEL A6LvjZkh+5zig+jdHzVXg/z9O/qsbu4sSEPnsdHY= Received: by danton.fire-world.de (Postfix, from userid 1000) id 3m6lDS09KmzgQqm; Thu, 11 Jun 2015 14:41:27 +0200 (CEST) Date: Thu, 11 Jun 2015 14:41:27 +0200 From: Sebastian Wiesinger Sender: ietf.dane@ml.karotte.org To: dane@ietf.org Message-ID: <20150611124127.GC10439@danton.fire-world.de> Mail-Followup-To: dane@ietf.org References: <20150609193434.GA10240@danton.fire-world.de> <20150609194811.GZ5512@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="yVhtmJPUSI46BTXb" Content-Disposition: inline In-Reply-To: <20150609194811.GZ5512@mournblade.imrryr.org> X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [dane] DANE works, thanks X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 11 Jun 2015 12:41:33 -0000 --yVhtmJPUSI46BTXb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Viktor Dukhovni [2015-06-09 21:51]: > On Tue, Jun 09, 2015 at 09:34:34PM +0200, Sebastian Wiesinger wrote: >=20 > > > My inclination is to recommend placing this in the certificate file > > > itself (PEM certificate files can contain ignored text above the > > > "-----BEGIN/END...." blocks) as well a CERT_UPDATE_README file in > > > the directory containing the certificate file and keys. > >=20 > > What would help a lot of people would be a drop-in nagios check which > > compares TLSA to actual cert. Probably easy to do for connections > > which start with TLS, not so trivial for STARTTLS types of > > connections. >=20 > STARTTLS is not difficult to test. >=20 > We were thinking of having folks sign up for monitoring by sys4.de, > with the results published via DNS, and nagios can then just do a > quick DNS lookup. >=20 > The advantage of a remote monitoring service, is that it can may > see DNS issues that are only apparent from outside the site's own > network. I see that but I would prefer to have my monitoring in-house and not dependent on external services. What DNS issues with DANE would only be apparent from the outside? Different views? Even so, I have an external monitoring point running Nagios for exactly these reasons. :) So for me a nagios check would be better. But perhaps I'll have some time and do it myself. Regards Sebastian --=20 GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SC= YTHE. -- Terry Pratchett, The Fifth Elephant --yVhtmJPUSI46BTXb Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQF6BAEBCgBkBQJVeYH3MxSAAAAAABUAFXBrYS1hZGRyZXNzQGdudXBnLm9yZ3Nl YmFzdGlhbkBrYXJvdHRlLm9yZykaaHR0cHM6Ly93d3cua2Fyb3R0ZS5vcmcvcGdw LXBvbGljeS5zaHRtbAAKCRBYotlKk6C5zm+ECAC8ACmS+/AqoSpTSQYcHYirXpQO 8v1hhEoxaFJW82jHBTmFL+U+wlRIn3GgXBGFQwpH1EYPfFhAZAes/kyn3Vr9SB9z X3qx4ylnMxTHdLJAUNcRN530yJe9bgI3Jp+rhbr1ZombUQJxsDsRq3UvB7+BYyL3 cKBtQ9fyCUovLizEYoZ3wu/TAt7HT+DZTNfyx1Lwuxno6EMMPmj4qbxwto6Tor+J dTlT0h9GZLpQPFi9IGMUmh+61/Q2cZjwYNe58rG88IRzFvF+v12LLP8wAUJjYbDW b5d3X9AAwfw5TIBf3KLiEGADgSh/Frq7ZNyG2Hpq9ybp5rvKz+LNIkdOy42n =kkq7 -----END PGP SIGNATURE----- --yVhtmJPUSI46BTXb-- From nobody Thu Jun 11 07:48: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 4BD871A8782 for ; Thu, 11 Jun 2015 07:48:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.29 X-Spam-Level: * X-Spam-Status: No, score=1.29 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 UPxZ6m2K_iGX for ; Thu, 11 Jun 2015 07:48:26 -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 AFD301B3026 for ; Thu, 11 Jun 2015 07:48:25 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3m6p2v5Sldz2xg for ; Thu, 11 Jun 2015 16:48:23 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=uyXxPRPK 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 fXx3I_N9r8iy for ; Thu, 11 Jun 2015 16:48: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, 11 Jun 2015 16:48:22 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id D1F26800B6 for ; Thu, 11 Jun 2015 10:48:20 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1434034100; bh=nTuYSXW1g0qdiYmsElJ3okoSCXJrTQIOQEIRD2xTUCU=; h=Date:From:To:Subject:In-Reply-To:References; b=uyXxPRPK3gI4U8coEEbL+satxQnLPXzNZ4r7gEK1M2Mw801J1FbSmiTJdPhfORG9B t75WIU4Xy2ucUhInKpPq+YjCSzo8WoCRXmdgx0pB/8aS79zUVdONFiFQxWvMMfmeMD aoc+AVCapCi4c/E3+Xo/pfSshbdgNb4wHTZvrW5I= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.15.1/8.15.1/Submit) with ESMTP id t5BEmKml016879 for ; Thu, 11 Jun 2015 10:48:20 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Thu, 11 Jun 2015 10:48:20 -0400 (EDT) From: Paul Wouters To: dane WG list In-Reply-To: <20150611103919.9594.qmail@ary.lan> Message-ID: References: <20150611103919.9594.qmail@ary.lan> User-Agent: Alpine 2.11 (LFD 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dane] AD review of draft-ietf-dane-openpgpkey-03 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 11 Jun 2015 14:48:29 -0000 On Thu, 11 Jun 2015, John Levine wrote: >> This is a strong statement, I have a problem with your word "preventing" . >> My reading of the draft is that mail sender can perform the Hash() operation >> on any name she/he has/guesses for the receiver, and looks each one up in until a >> match is found or the sender gives up. > >> Right now we do not really know if this will scale, ... > > But we do know that it is absolutely forbidden by any normal reading > of the mail RFCs. Just like not supporting !UUCP email addresses is violating the mail RFCs? The paul@nohats.ca and PAUL@nohats.ca being allowed to be different mailbox targets is an 25+ year old artifact of VAX/VMS/Windows and my university's cost savings of their ADM3a egg terminal lowercase ROM purchase. And not a single actual deployment of it was demonstrated to me in the three years we worked on this document. > I am baffled that a design that is supposed to be > about security would include guessing addresses that might or might > not be the party to which you want to send your highly secure mail, > and that the WG has repeatedly rejected small changes that could solve > that problem. I have answered this a few times already, but let me try again. 1) If you reply to a message, there is no lookup guessing as the address is known exactly. 2) If I give you my email address on a business card, there is no lookup guessing but there gould be typoes or brainfarts. Like accidentally sending to paul@nohats.com which is not under my control. 3) If you make up an email address in your brain from memory, there is a chance of error. (and an even greater one if you MUST remember case) What we are talkng about here is 3) and that's an unsolvable problem to begin with, seeing how many people tried and failed to add me to their XMPP list as paul@nohats.com instead of paul@nohats.ca. So while getting the domain completely wrong is a complete security disaster, so is getting the local part. If you make up characters, eg paul.wouters@nohats.ca when I have given you paulwouters@nohats.ca, then if your software does not warn you, I can still accomodate you by putting in multiple hashes with the dot(s). But that is NO DIFFERENT from putting in several base32 entries to accomodate these. The base32 split up actually gains you nothing. Upon review by the WG, we did determine that any translations other than case are too dangerous because they are not universal, and there is no way you can query a domain for those policies. So any rewriting with + or . or - substituation should not be done and the draft does not tell you to. Let me write of saying my dad and his girlfriend have an email address of hisname+hername@bigisp.com, and that is NOT the same mailbox as hisname@bigisp.com. You submitted a proposed draft for a "email address confirmation lookup service". Once that is standardised we could look at adding support for that. But as noted, it being outside of DNSSEC/DANE, and requiring an SMTP (or otherwise direct link) to the target mail domain, I do not think that is a very realistic extension that many people will be able to actually use, with todays SMTP filters in place on behalve of the anti-spam people. Paul > R's, > John > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > From nobody Thu Jun 11 08:26: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 5AD001B2B32 for ; Thu, 11 Jun 2015 08:26:37 -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 6SA0S5AS51v8 for ; Thu, 11 Jun 2015 08:26:35 -0700 (PDT) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) (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 BA2F41B2AE2 for ; Thu, 11 Jun 2015 08:26:35 -0700 (PDT) Received: by obbsn1 with SMTP id sn1so6240552obb.1 for ; Thu, 11 Jun 2015 08:26:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=V/H4xhFompTNzzDQFmoa2GZe+65v4g51q6URMDIisws=; b=UVeWV2R/L4UZ2u7fu1cwE2bx4i22tfBAxyCmOjaHFCAbnfthPAtJC12Us1VZk4rNbh FkNhAYdOsHPGK1mOctlnfzsp75WrXd2Smus+zYUcONdvBn+/uYUxIxZ7uSjw1zIVfgOo yo+Dr67hg0W/2B8EbnqRq/vNFsGNet6MGtrc0y5dC1yigNTjVgMxw5PqV7nZgLiI0jeA tNH/stwF5WS/hF3x1eeW+1mOBsXaCSd/ue8pEsXyZrwLvPrEPaU2aEMQtdI/y+nXmfZr qJybyX/ZHctVpLcef9I7oeUxKTd60NZlKhh2knWYu4aOt4OFf2RmNSM+WHO10VWifoYt WjTQ== X-Gm-Message-State: ALoCoQklzyq7TCkmZjRJtSMNAbNEhMFClq/GJRgh4I7opor7k+siK6hAbaaTsuaB3a4k3ZEWmxpn MIME-Version: 1.0 X-Received: by 10.202.187.138 with SMTP id l132mr7723511oif.31.1434036395177; Thu, 11 Jun 2015 08:26:35 -0700 (PDT) Received: by 10.202.196.75 with HTTP; Thu, 11 Jun 2015 08:26:35 -0700 (PDT) In-Reply-To: <20150611124127.GC10439@danton.fire-world.de> References: <20150609193434.GA10240@danton.fire-world.de> <20150609194811.GZ5512@mournblade.imrryr.org> <20150611124127.GC10439@danton.fire-world.de> Date: Thu, 11 Jun 2015 11:26:35 -0400 Message-ID: From: Warren Kumari To: "" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [dane] DANE works, thanks X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 11 Jun 2015 15:26:37 -0000 On Thu, Jun 11, 2015 at 8:41 AM, Sebastian Wiesinger wrote: > * Viktor Dukhovni [2015-06-09 21:51]: >> On Tue, Jun 09, 2015 at 09:34:34PM +0200, Sebastian Wiesinger wrote: >> >> > > My inclination is to recommend placing this in the certificate file >> > > itself (PEM certificate files can contain ignored text above the >> > > "-----BEGIN/END...." blocks) as well a CERT_UPDATE_README file in >> > > the directory containing the certificate file and keys. >> > >> > What would help a lot of people would be a drop-in nagios check which >> > compares TLSA to actual cert. Probably easy to do for connections >> > which start with TLS, not so trivial for STARTTLS types of >> > connections. >> >> STARTTLS is not difficult to test. >> >> We were thinking of having folks sign up for monitoring by sys4.de, >> with the results published via DNS, and nagios can then just do a >> quick DNS lookup. >> >> The advantage of a remote monitoring service, is that it can may >> see DNS issues that are only apparent from outside the site's own >> network. > > I see that but I would prefer to have my monitoring in-house and not > dependent on external services. What DNS issues with DANE would only > be apparent from the outside? Different views? Even so, I have an > external monitoring point running Nagios for exactly these reasons. :) > So for me a nagios check would be better. But perhaps I'll have some > time and do it myself. If you do, please share it with the list / community. Good / multiple ways of monitoring is really useful for deployment - one of the things that has hurt DNSSEC deployment is the public outages - it would be great to not have DANE suffer from this too. W > > Regards > > Sebastian > > -- > GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) > 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. > -- Terry Pratchett, The Fifth Elephant > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > -- 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 Thu Jun 11 09:09: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 5A8841A8757 for ; Thu, 11 Jun 2015 09:09:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 vPmjI_kF50ho for ; Thu, 11 Jun 2015 09:09:00 -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 7F9951A004C for ; Thu, 11 Jun 2015 09:09:00 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 14F13284AD9; Thu, 11 Jun 2015 16:08:59 +0000 (UTC) Date: Thu, 11 Jun 2015 16:08:59 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150611160858.GL2050@mournblade.imrryr.org> References: <20150611103919.9594.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] AD review of draft-ietf-dane-openpgpkey-03 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, 11 Jun 2015 16:09:02 -0000 On Thu, Jun 11, 2015 at 10:48:20AM -0400, Paul Wouters wrote: > The base32 split up actually gains you nothing. > > Upon review by the WG, we did determine that any translations other than > case are too dangerous because they are not universal, and there is no > way you can query a domain for those policies. So any rewriting with + > or . or - substituation should not be done and the draft does not tell > you to. I agree with all of that. If it is to be DNS, then hashing works no worse than most other encodings. Since IIRC we're not at liberty to require case-insensitive matching, we can't just use the literal localpart unencoded, and all encodings suffer most of the same limitations. Hashing is in many ways the least bad of the available choices. So the choices are: A. Use DNS (with hashed lookup keys) B. Use some other lookup protocol, with a secure service endpoint specified via DANE, but a service other than DNS handling the database lookups. There are some advantages to each approach. The main disadvantage of not using DNS (B), is that no such service is readily available, so new code would be required to implement it. An argument for (B) would be much more effective if there were running code for such a service that could be readily integrated into various environments with pluggable database backends, extensible canonicalization rules, ... IIRC it was also pointed out that PGP public keys or SMIME certificaets obtained for something other than the literal requested address are not necessarily usable when the identity embedded in the PGP key or SMIME certificate is different from the one requested. In particular, trust-anchor certificate usages would run into significant problems since name matching must still be performed against the actual certificate or PGP key. So it is not unreasonable to adopt the view that secure email requires non-fuzzy peer identities, and that variant addresses (more than case difference) can't leverage end-to-end encrypted email without additional keys for each variant (or multiple names in PGP or SMIME keys when possible). -- Viktor. From nobody Fri Jun 12 11:59: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 5B3A11ACEF3 for ; Fri, 12 Jun 2015 11:59:22 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xnK3udgqCZIq for ; Fri, 12 Jun 2015 11:59:19 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0084.outbound.protection.outlook.com [65.55.169.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41AF01ACEEF for ; Fri, 12 Jun 2015 11:59:19 -0700 (PDT) Received: from CY1PR0601MB1657.namprd06.prod.outlook.com (10.163.232.19) by CY1PR0601MB1659.namprd06.prod.outlook.com (10.163.232.21) with Microsoft SMTP Server (TLS) id 15.1.190.14; Fri, 12 Jun 2015 18:59:17 +0000 Received: from CY1PR0601MB1657.namprd06.prod.outlook.com ([25.163.232.19]) by CY1PR0601MB1657.namprd06.prod.outlook.com ([25.163.232.19]) with mapi id 15.01.0184.014; Fri, 12 Jun 2015 18:59:17 +0000 From: Dan York To: IETF DANE Mailinglist Thread-Topic: DANE / DNSSEC added to IETF 93 Hackathon - anyone else interested? Thread-Index: AQHQpUHhXxHn718DvUaVCdwbSayI0w== Date: Fri, 12 Jun 2015 18:59:16 +0000 Message-ID: <29538CF8-CFED-4C4C-B971-841F028F0183@isoc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [74.69.229.215] x-microsoft-exchange-diagnostics: 1; CY1PR0601MB1659; 3:6C0m++KyPWCOTZN9ycBVZmqetdrLR2g2RnqZw2lJnqhcuIyXJBypEI+yE2H4agij+QLdrJ3gbrWrw/ckJQggJW8H8IylVocg/HoKpaZr/YsS3iboN/8yHREsqgAagtgIC5Jbk0B3G5gFT+Qz8RdgnA==; 10:n8SciDI30TPlZv5nu+oBEQKS1RzZUHDZxZeXSkAJFXovYpJJW3b6EKY4JAo43uf9cCZQTVo3kZlpJzj7JGRxdl6u8DjAoYtvqPqeAD5BxQY=; 6:45l88sbzwNJWJwROW9irS3KL79HECMZ+Q9W7WUKoOaPG40/Dj5x8TWNRrUSgWqPe x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0601MB1659; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(520003)(3002001); SRVR:CY1PR0601MB1659; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0601MB1659; x-forefront-prvs: 060503E79B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(51414003)(52044002)(16236675004)(19580395003)(15395725005)(66066001)(54356999)(106116001)(50986999)(46102003)(229853001)(99286002)(92566002)(19580405001)(19617315012)(33656002)(83716003)(2656002)(87936001)(86362001)(82746002)(40100003)(122556002)(5002640100001)(36756003)(189998001)(102836002)(566704002)(15975445007)(5001960100002)(110136002)(62966003)(2900100001)(5001920100001)(77156002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR0601MB1659; H:CY1PR0601MB1657.namprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_29538CF8CFED4C4CB971841F028F0183isocorg_" MIME-Version: 1.0 X-OriginatorOrg: isoc.org X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jun 2015 18:59:16.6736 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0601MB1659 Archived-At: Subject: [dane] DANE / DNSSEC added to IETF 93 Hackathon - anyone else interested? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 12 Jun 2015 18:59:22 -0000 --_000_29538CF8CFED4C4CB971841F028F0183isocorg_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 REFORSBXRyBwYXJ0aWNpcGFudHMsDQoNCkFyZSBhbnkgb2YgeW91IHBsYW5uaW5nIHRvIGJlIGF0 IHRoZSBoYWNrYXRob24gb24gdGhlIHdlZWtlbmQgYmVmb3JlIElFVEYgOTMgaW4gUHJhZ3VlPyAg QWxsaXNvbiBNYW5raW4gYW5kIEkgZGVjaWRlZCB0byBhZGQgIkRBTkUgLyBETlMgUHJpdmFjeSAv IEROU1NFQyIgdG8gdGhlIEhhY2thdGhvbiB3aWtpIChhbmQgdG8gY29tbWl0IHRvIGJlaW5nIHRo ZXJlKToNCg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmVnaXN0cmF0aW9uL01lZXRpbmdXaWtpL3dp a2kvOTNoYWNrYXRob24NCg0KKE1vcmUgaW5mbzogIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaGFja2F0 aG9uLzkzLWhhY2thdGhvbi5odG1sICkNCg0KQSBjb3VwbGUgb2Ygb3RoZXJzIGhhdmUgam9pbmVk IHVzIGFzICJjaGFtcGlvbnMiICh3aGljaCBtZWFucyB5b3UgaGVscCBpbnRyb2R1Y2UgdGhlIHRv cGljIGFuZCBhZ3JlZSB0byB3b3JrIG9uIGl0IGR1cmluZyB0aGUgZXZlbnQpLiAgSWYgYW55b25l IGVsc2Ugd2FudHMgdG8gam9pbiB1cyBhcyBhICJjaGFtcGlvbiIsIHdlJ3JlIGNlcnRhaW5seSBn bGFkIHRvIGFkZCBuYW1lcy4NCg0KSGVyZSdzIHdoYXQgd2Ugd3JvdGUgaW4gdGhlIHdpa2k6DQot LS0tDQrigKIgREFORSAvIEROUyBQcml2YWN5IC8gRE5TU0VDDQrigKIgQ29udHJpYnV0ZSB0byBh Y2Nlc3Mgb2YgZW5kLXN5c3RlbXMgdG8gbmV3IGRldmVsb3BtZW50cyBpbiBETlMNCuKAoiBQcm90 b2NvbHM6IERBTkUgc3VwcG9ydCBmb3Igd2VibWFpbCwgRE5TLW92ZXItVExTIChhcHBsaWNhdGlv biB1c2VzKSwgRE5TLW92ZXItRFRMUyAoc3RhY2sgYW5kIHVzZXMpLCBUTFNBIGNsaWVudCBjZXJ0 cywgY2xpZW50IHByaXZhY3kgZWxlY3Rpb24gZm9yIEVETlMgY2xpZW50LXN1Ym5ldCwgZ2V0ZG5z IGxhbmd1YWdlIGJpbmRpbmdzLCBldGMuDQrigKIgVG9vbHM6IHBvcnRhYmxlIHRvb2wgZm9yIGNy ZWF0aW5nIGFuZCBhZGRpbmcgREFORSBSUuKAmXMgdG8gem9uZXMsIGNoYW5nZXMgdG8gZXhpc3Rp bmcgdG9vbHMgdG8gc3VwcG9ydCBuZXcgY3J5cHRvIGFsZ29yaXRobXMsIGV0Yy4NCuKAoiBNZWFz dXJlbWVudDogTmV3IHRvb2xzIG9yIHNpdGVzIGZvciBtZWFzdXJpbmcgRE5TU0VDIG9yIERBTkUg ZGVwbG95bWVudA0K4oCiIEF2YWlsYWJsZSBvcGVuIHNvdXJjZSBsaWJyYXJpZXM6IGh0dHBzOi8v Z2l0aHViLmNvbS92ZXJpc2lnbi9zbWF1ZywgaHR0cHM6Ly9naXRodWIuY29tL2dldGRuc2FwaQ0K 4oCiIEF2YWlsYWJsZSBlbnZpcm9ubWVudCwgc3VwcG9ydCwgYW5kIGRpYWdub3N0aWMgdG9vbHM6 IGh0dHBzOi8vZG5zc2VjLXRvb2xzLm9yZywgaHR0cHM6Ly93d3cub3BlbmRuc3NlYy5vcmcNCuKA oiBDaGFtcGlvbnMNCuKAoiBEYW4gWW9yaywgSW50ZXJuZXQgU29jaWV0eSB5b3JrQGlzb2Mub3Jn PG1haWx0bzp5b3JrQGlzb2Mub3JnPg0K4oCiIEFsbGlzb24gTWFua2luLCBWZXJpc2lnbiBMYWJz IGFtYW5raW5AdmVyaXNpZ24uY29tPG1haWx0bzphbWFua2luQHZlcmlzaWduLmNvbT4NCuKAoiBX aWxsZW0gVG9vcm9wLCBOTG5ldCBMYWJzDQrigKIgU2FyYSBEaWNraW5zb24sIFNpbm9kdW4NCuKA oiBPdGhlcnMsIFRCQQ0KLS0tLQ0KDQpJbiBhIGhhY2thdGhvbiBsaWtlIHRoaXMsIGEgc21hbGwg dGVhbSBvZiBwZW9wbGUgYWdyZWVzIHRvIHdvcmsgb24gKGlkZWFsbHkhKSBhIGNsZWFybHktZGVm aW5lZCBwcm9qZWN0IHRoYXQgY2FuLCBpbiB0aGVvcnksIGJlIGNvbXBsZXRlZCBpbiB0d28gZGF5 cyBhbmQgaXMgc29tZXRoaW5nIHRoYXQgdGhlIGp1ZGdlcyBhbmQgb3RoZXJzIG1pZ2h0IGZpbmQg aW50ZXJlc3RpbmcgYW5kIHVzZWZ1bC4gIFRoZXJlIGNhbiBiZSBzZXZlcmFsIGRpZmZlcmVudCB0 ZWFtcyB1bmRlciB0aGlzIHRvcGljIHdvcmtpbmcgb24gZGlmZmVyZW50IHByb2plY3RzLiAgU3Vu ZGF5IGFmdGVybm9vbiBhdCAzcG0gdGhlIHRlYW1zIGFyZSBzdXBwb3NlZCB0byBzdG9wIGFuZCBj b21lIHVwIHdpdGggYSBwcmVzZW50YXRpb24uIFRob3NlIGFyZSBnaXZlbiBhdCA0cG0gYW5kIGF3 YXJkcyBhcmUgZ2l2ZW4gYXQgNXBtLg0KDQpZb3UgZG9uJ3QgaGF2ZSB0byBiZSB0aGVyZSBBTEwg dGhlIHRpbWUgKEkgc3VzcGVjdCBzb21lIHBlb3BsZSB3aWxsIGxlYXZlIFN1bmRheSBtb3JuaW5n IGZvciB0aGUgSUVQRyBtZWV0aW5nKSwgYnV0IG9idmlvdXNseSB0aGUgbW9yZSB0aW1lIHlvdSBj YW4gYmUgdGhlcmUgdGhlIGJldHRlci4NCg0KTHVuY2ggYW5kIGRpbm5lciBhcmUgcHJvdmlkZWQu IEl0J3MgZnJlZS4uLiBidXQgbGltaXRlZCB0byB0aGUgZmlyc3QgMTAwIGF0dGVuZGVlcy4gIChD dXJyZW50bHkgYXQgNjMgLSBodHRwczovL3d3dy5pZXRmLm9yZy9yZWdpc3RyYXRpb24vaWV0Zjkz L2hhY2thdGhvbmF0dGVuZGFuY2UucHk/c29ydGtleT0zJmxvZ2luPSUwQTxodHRwczovL3d3dy5p ZXRmLm9yZy9yZWdpc3RyYXRpb24vaWV0ZjkzL2hhY2thdGhvbmF0dGVuZGFuY2UucHk/c29ydGtl eT0zJmxvZ2luPT4gKQ0KDQpQTEVBU0UgSk9JTiBVUyEgIFRoZSBtb3JlIERBTkUvRE5TU0VDIGZv bGtzIHRoYXQgYXJlIHRoZXJlLCB0aGUgbW9yZSB3b3JrIHdlIGNhbiBkbyENCg0KUmVnaXN0cmF0 aW9uIGlzIGF0OiBodHRwczovL3d3dy5pZXRmLm9yZy9yZWdpc3RyYXRpb24vaWV0ZjkzL2hhY2th dGhvbnJlZ2lzdHJhdGlvbi5weQ0KDQpJZiB5b3UgY2FuJ3Qgam9pbiB1cyAob3IgaGFja2F0aG9u cyBhcmUganVzdCBub3QgeW91ciB0aGluZyksIHBsZWFzZSBkbyBmZWVsIGZyZWUgdG8gU0VORCBJ REVBUyENCg0KSWYgdGhlcmUncyBhIHRvb2wgeW91IHdpc2ggd2FzIG91dCB0aGVyZSBmb3IgREFO RS9ETlNTRUMvRE5TIFByaXZhY3kgLi4uIG9yIGEgc2VydmljZSBvciBzb21ldGhpbmcuLi4gb3Ig YW4gZXhpc3RpbmcgdG9vbCB5b3Ugd2lzaCBzdXBwb3J0ZWQgRE5TU0VDIG9yIERBTkUuLi4gcGxl YXNlIGxldCBBbGxpc29uIGFuZCBJIGtub3cgKG9yIGp1c3Qgc2VuZCBpdCBiYWNrIHRvIHRoaXMg bGlzdCkuDQoNCkkgbG9vayBmb3J3YXJkIHRvIHNlZWluZyBzb21lIG9mIHlvdSB0aGVyZSENCkRh bg0KDQpQLlMuIEV4dHJhIGJvbnVzIHBvaW50cyBpZiB0aGUgc3VnZ2VzdGlvbiBzb21laG93IGlu dm9sdmVzIGEgaHVtb3JvdXMgc2lkZS4uLg0KDQotLQ0KRGFuIFlvcmsNClNlbmlvciBDb250ZW50 IFN0cmF0ZWdpc3QsIEludGVybmV0IFNvY2lldHkNCnlvcmtAaXNvYy5vcmc8bWFpbHRvOnlvcmtA aXNvYy5vcmc+ICAgKzEtODAyLTczNS0xNjI0DQpKYWJiZXI6IHlvcmtAamFiYmVyLmlzb2Mub3Jn PG1haWx0bzp5b3JrQGphYmJlci5pc29jLm9yZz4NClNreXBlOiBkYW55b3JrICAgaHR0cDovL3R3 aXR0ZXIuY29tL2RhbnlvcmsNCg0KaHR0cDovL3d3dy5pbnRlcm5ldHNvY2lldHkub3JnLzxodHRw Oi8vd3d3LmludGVybmV0c29jaWV0eS5vcmcvZGVwbG95MzYwLz4NCg0KDQoNCg== --_000_29538CF8CFED4C4CB971841F028F0183isocorg_ Content-Type: text/html; charset="utf-8" Content-ID: <91D9F5A8483C3E4AB8C6849ED5A5F828@namprd06.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KREFORSBXRyBwYXJ0aWNpcGFudHMs DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5BcmUg YW55IG9mIHlvdSBwbGFubmluZyB0byBiZSBhdCB0aGUgaGFja2F0aG9uIG9uIHRoZSB3ZWVrZW5k IGJlZm9yZSBJRVRGIDkzIGluIFByYWd1ZT8gJm5ic3A7QWxsaXNvbiBNYW5raW4gYW5kIEkgZGVj aWRlZCB0byBhZGQgJnF1b3Q7REFORSAvIEROUyBQcml2YWN5IC8gRE5TU0VDJnF1b3Q7IHRvIHRo ZSBIYWNrYXRob24gd2lraSAoYW5kIHRvIGNvbW1pdCB0byBiZWluZyB0aGVyZSk6PC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YSBocmVm PSJodHRwczovL3d3dy5pZXRmLm9yZy9yZWdpc3RyYXRpb24vTWVldGluZ1dpa2kvd2lraS85M2hh Y2thdGhvbiIgY2xhc3M9IiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmVnaXN0cmF0aW9uL01lZXRp bmdXaWtpL3dpa2kvOTNoYWNrYXRob248L2E+Jm5ic3A7PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxi ciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4oTW9yZSBpbmZvOiAmbmJzcDs8YSBo cmVmPSJodHRwOi8vd3d3LmlldGYub3JnL2hhY2thdGhvbi85My1oYWNrYXRob24uaHRtbCIgY2xh c3M9IiI+aHR0cDovL3d3dy5pZXRmLm9yZy9oYWNrYXRob24vOTMtaGFja2F0aG9uLmh0bWw8L2E+ Jm5ic3A7KTwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+QSBjb3VwbGUgb2Ygb3RoZXJzIGhhdmUgam9pbmVkIHVzIGFzICZxdW90O2NoYW1w aW9ucyZxdW90OyAod2hpY2ggbWVhbnMgeW91IGhlbHAgaW50cm9kdWNlIHRoZSB0b3BpYyBhbmQg YWdyZWUgdG8gd29yayBvbiBpdCBkdXJpbmcgdGhlIGV2ZW50KS4gJm5ic3A7SWYgYW55b25lIGVs c2Ugd2FudHMgdG8gam9pbiB1cyBhcyBhICZxdW90O2NoYW1waW9uJnF1b3Q7LCB3ZSdyZSBjZXJ0 YWlubHkgZ2xhZCB0byBhZGQgbmFtZXMuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0i Ij4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5IZXJlJ3Mgd2hhdCB3ZSB3cm90ZSBpbiB0aGUgd2lr aTo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+LS0tLTwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYg Y2xhc3M9IiI+PHNwYW4gY2xhc3M9IkFwcGxlLXRhYi1zcGFuIiBzdHlsZT0id2hpdGUtc3BhY2U6 cHJlIj48L3NwYW4+4oCiIERBTkUgLyZuYnNwO0ROUyZuYnNwO1ByaXZhY3kgLyBETlNTRUM8YnIg Y2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxzcGFuIGNsYXNzPSJBcHBsZS10YWItc3BhbiIgc3R5 bGU9IndoaXRlLXNwYWNlOnByZSI+PC9zcGFuPuKAoiBDb250cmlidXRlIHRvIGFjY2VzcyBvZiBl bmQtc3lzdGVtcyB0byBuZXcgZGV2ZWxvcG1lbnRzIGluJm5ic3A7RE5TPGJyIGNsYXNzPSIiPg0K PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxzcGFuIGNsYXNzPSJBcHBsZS10YWItc3BhbiIgc3R5bGU9 IndoaXRlLXNwYWNlOnByZSI+PC9zcGFuPuKAoiBQcm90b2NvbHM6Jm5ic3A7REFORSBzdXBwb3J0 IGZvciB3ZWJtYWlsLCZuYnNwO0ROUy1vdmVyLVRMUyAoYXBwbGljYXRpb24gdXNlcyksJm5ic3A7 RE5TLW92ZXItRFRMUyAoc3RhY2sgYW5kJm5ic3A7dXNlcyksIFRMU0EgY2xpZW50IGNlcnRzLCBj bGllbnQgcHJpdmFjeSBlbGVjdGlvbiBmb3IgRUROUyBjbGllbnQtc3VibmV0LCBnZXRkbnMgbGFu Z3VhZ2UNCiBiaW5kaW5ncywgZXRjLjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij48c3BhbiBjbGFzcz0iQXBwbGUtdGFiLXNwYW4iIHN0eWxlPSJ3aGl0ZS1zcGFjZTpwcmUiPjwv c3Bhbj7igKIgVG9vbHM6IHBvcnRhYmxlIHRvb2wgZm9yIGNyZWF0aW5nJm5ic3A7YW5kIGFkZGlu ZyBEQU5FIFJS4oCZcyB0byB6b25lcywgY2hhbmdlcyB0byBleGlzdGluZyB0b29scyB0byBzdXBw b3J0Jm5ic3A7bmV3Jm5ic3A7Y3J5cHRvIGFsZ29yaXRobXMsIGV0Yy48YnIgY2xhc3M9IiI+DQo8 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PHNwYW4gY2xhc3M9IkFwcGxlLXRhYi1zcGFuIiBzdHlsZT0i d2hpdGUtc3BhY2U6cHJlIj48L3NwYW4+4oCiIE1lYXN1cmVtZW50OiBOZXcgdG9vbHMgb3Igc2l0 ZXMgZm9yIG1lYXN1cmluZyBETlNTRUMgb3IgREFORSBkZXBsb3ltZW50PGJyIGNsYXNzPSIiPg0K PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxzcGFuIGNsYXNzPSJBcHBsZS10YWItc3BhbiIgc3R5bGU9 IndoaXRlLXNwYWNlOnByZSI+PC9zcGFuPuKAoiBBdmFpbGFibGUgb3BlbiBzb3VyY2UgbGlicmFy aWVzOiZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS92ZXJpc2lnbi9zbWF1ZyIgY2xh c3M9IiI+aHR0cHM6Ly9naXRodWIuY29tL3ZlcmlzaWduL3NtYXVnPC9hPiwmbmJzcDtodHRwczov L2dpdGh1Yi5jb20vZ2V0ZG5zYXBpPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIi PjxzcGFuIGNsYXNzPSJBcHBsZS10YWItc3BhbiIgc3R5bGU9IndoaXRlLXNwYWNlOnByZSI+PC9z cGFuPuKAoiBBdmFpbGFibGUgZW52aXJvbm1lbnQsIHN1cHBvcnQsIGFuZCBkaWFnbm9zdGljIHRv b2xzOiZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vZG5zc2VjLXRvb2xzLm9yZyIgY2xhc3M9IiI+aHR0 cHM6Ly9kbnNzZWMtdG9vbHMub3JnPC9hPiwmbmJzcDtodHRwczovL3d3dy5vcGVuZG5zc2VjLm9y ZzxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48c3BhbiBjbGFzcz0iQXBwbGUt dGFiLXNwYW4iIHN0eWxlPSJ3aGl0ZS1zcGFjZTpwcmUiPjwvc3Bhbj7igKIgQ2hhbXBpb25zPGJy IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48c3BhbiBjbGFzcz0iQXBwbGUtdGFiLXNwYW4iIHN0 eWxlPSJ3aGl0ZS1zcGFjZTpwcmUiPjwvc3Bhbj7igKIgRGFuIFlvcmssIEludGVybmV0IFNvY2ll dHkmbmJzcDs8YSBocmVmPSJtYWlsdG86eW9ya0Bpc29jLm9yZyIgY2xhc3M9IiI+eW9ya0Bpc29j Lm9yZzwvYT48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PHNwYW4gY2xhc3M9 IkFwcGxlLXRhYi1zcGFuIiBzdHlsZT0id2hpdGUtc3BhY2U6cHJlIj48L3NwYW4+4oCiIEFsbGlz b24gTWFua2luLCBWZXJpc2lnbiBMYWJzJm5ic3A7PGEgaHJlZj0ibWFpbHRvOmFtYW5raW5AdmVy aXNpZ24uY29tIiBjbGFzcz0iIj5hbWFua2luQHZlcmlzaWduLmNvbTwvYT48YnIgY2xhc3M9IiI+ DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PHNwYW4gY2xhc3M9IkFwcGxlLXRhYi1zcGFuIiBzdHls ZT0id2hpdGUtc3BhY2U6cHJlIj48L3NwYW4+4oCiIFdpbGxlbSBUb29yb3AsIE5MbmV0IExhYnM8 YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PHNwYW4gY2xhc3M9IkFwcGxlLXRh Yi1zcGFuIiBzdHlsZT0id2hpdGUtc3BhY2U6cHJlIj48L3NwYW4+4oCiIFNhcmEgRGlja2luc29u LCBTaW5vZHVuPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxzcGFuIGNsYXNz PSJBcHBsZS10YWItc3BhbiIgc3R5bGU9IndoaXRlLXNwYWNlOnByZSI+PC9zcGFuPuKAoiBPdGhl cnMsIFRCQTwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+LS0tLTwvZGl2Pg0K PGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+SW4gYSBo YWNrYXRob24gbGlrZSB0aGlzLCBhIHNtYWxsIHRlYW0gb2YgcGVvcGxlIGFncmVlcyB0byB3b3Jr IG9uIChpZGVhbGx5ISkgYSBjbGVhcmx5LWRlZmluZWQgcHJvamVjdCB0aGF0IGNhbiwgaW4gdGhl b3J5LCBiZSBjb21wbGV0ZWQgaW4gdHdvIGRheXMgYW5kIGlzIHNvbWV0aGluZyB0aGF0IHRoZSBq dWRnZXMgYW5kIG90aGVycyBtaWdodCBmaW5kIGludGVyZXN0aW5nIGFuZCB1c2VmdWwuICZuYnNw O1RoZXJlIGNhbiBiZQ0KIHNldmVyYWwgZGlmZmVyZW50IHRlYW1zIHVuZGVyIHRoaXMgdG9waWMg d29ya2luZyBvbiBkaWZmZXJlbnQgcHJvamVjdHMuICZuYnNwO1N1bmRheSBhZnRlcm5vb24gYXQg M3BtIHRoZSB0ZWFtcyBhcmUgc3VwcG9zZWQgdG8gc3RvcCBhbmQgY29tZSB1cCB3aXRoIGEgcHJl c2VudGF0aW9uLiBUaG9zZSBhcmUgZ2l2ZW4gYXQgNHBtIGFuZCBhd2FyZHMgYXJlIGdpdmVuIGF0 IDVwbS48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNs YXNzPSIiPllvdSBkb24ndCBoYXZlIHRvIGJlIHRoZXJlIEFMTCB0aGUgdGltZSAoSSBzdXNwZWN0 IHNvbWUgcGVvcGxlIHdpbGwgbGVhdmUgU3VuZGF5IG1vcm5pbmcgZm9yIHRoZSBJRVBHIG1lZXRp bmcpLCBidXQgb2J2aW91c2x5IHRoZSBtb3JlIHRpbWUgeW91IGNhbiBiZSB0aGVyZSB0aGUgYmV0 dGVyLiAmbmJzcDs8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPkx1bmNoIGFuZCBkaW5uZXIgYXJlIHByb3ZpZGVkLiBJdCdzIGZyZWUuLi4g YnV0IGxpbWl0ZWQgdG8gdGhlIGZpcnN0IDEwMCBhdHRlbmRlZXMuICZuYnNwOyhDdXJyZW50bHkg YXQgNjMgLQ0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmVnaXN0cmF0aW9uL2lldGY5 My9oYWNrYXRob25hdHRlbmRhbmNlLnB5P3NvcnRrZXk9MyZhbXA7bG9naW49DQoiIGNsYXNzPSIi Pg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmVnaXN0cmF0aW9uL2lldGY5My9oYWNrYXRob25hdHRl bmRhbmNlLnB5P3NvcnRrZXk9MyZhbXA7bG9naW49JTBBPC9hPiZuYnNwOyk8L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlBMRUFTRSBKT0lO IFVTISAmbmJzcDtUaGUgbW9yZSBEQU5FL0ROU1NFQyBmb2xrcyB0aGF0IGFyZSB0aGVyZSwgdGhl IG1vcmUgd29yayB3ZSBjYW4gZG8hPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4N CjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5SZWdpc3RyYXRpb24gaXMgYXQ6IDxhIGhyZWY9Imh0dHBz Oi8vd3d3LmlldGYub3JnL3JlZ2lzdHJhdGlvbi9pZXRmOTMvaGFja2F0aG9ucmVnaXN0cmF0aW9u LnB5IiBjbGFzcz0iIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL3JlZ2lzdHJhdGlvbi9pZXRmOTMv aGFja2F0aG9ucmVnaXN0cmF0aW9uLnB5PC9hPiZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48 YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+SWYgeW91IGNhbid0IGpvaW4gdXMg KG9yIGhhY2thdGhvbnMgYXJlIGp1c3Qgbm90IHlvdXIgdGhpbmcpLCBwbGVhc2UgZG8gZmVlbCBm cmVlIHRvIFNFTkQgSURFQVMhPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj5JZiB0aGVyZSdzIGEgdG9vbCB5b3Ugd2lzaCB3YXMgb3V0IHRo ZXJlIGZvciBEQU5FL0ROU1NFQy9ETlMgUHJpdmFjeSAuLi4gb3IgYSBzZXJ2aWNlIG9yIHNvbWV0 aGluZy4uLiBvciBhbiBleGlzdGluZyB0b29sIHlvdSB3aXNoIHN1cHBvcnRlZCBETlNTRUMgb3Ig REFORS4uLiBwbGVhc2UgbGV0IEFsbGlzb24gYW5kIEkga25vdyAob3IganVzdCBzZW5kIGl0IGJh Y2sgdG8gdGhpcyBsaXN0KS4mbmJzcDs8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIi Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkkgbG9vayBmb3J3YXJkIHRvIHNlZWluZyBzb21lIG9m IHlvdSB0aGVyZSE8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+RGFuPC9kaXY+DQo8ZGl2IGNsYXNzPSIi PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5QLlMuIEV4dHJhIGJvbnVzIHBv aW50cyBpZiB0aGUgc3VnZ2VzdGlvbiBzb21laG93IGludm9sdmVzIGEgaHVtb3JvdXMgc2lkZS4u LiZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBsZXR0ZXItc3BhY2lu Zzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6 IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czog YXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsg d29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQt bGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCjxkaXYgYXBwbGUtY29u dGVudC1lZGl0ZWQ9InRydWUiIGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IENh bGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsgYmFja2dyb3VuZC1jb2xvcjogcmdi KDI1NSwgMjU1LCAyNTUpOyIgY2xhc3M9IiI+DQotLTwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1m YW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsgYmFja2dyb3VuZC1j b2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyIgY2xhc3M9IiI+DQo8Zm9udCBmYWNlPSJDYWxpYnJp LHNhbnMtc2VyaWYiIGNsYXNzPSIiPkRhbiBZb3JrPC9mb250PjwvZGl2Pg0KPGRpdiBzdHlsZT0i Zm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsgYmFja2dy b3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyIgY2xhc3M9IiI+DQo8Zm9udCBmYWNlPSJD YWxpYnJpLHNhbnMtc2VyaWYiIGNsYXNzPSIiPlNlbmlvciBDb250ZW50IFN0cmF0ZWdpc3QsIElu dGVybmV0IFNvY2lldHk8L2ZvbnQ+PC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQ2Fs aWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2Io MjU1LCAyNTUsIDI1NSk7IiBjbGFzcz0iIj4NCjxmb250IGZhY2U9IkNhbGlicmksc2Fucy1zZXJp ZiIgY2xhc3M9IiI+PGEgaHJlZj0ibWFpbHRvOnlvcmtAaXNvYy5vcmciIGNsYXNzPSIiPnlvcmtA aXNvYy5vcmc8L2E+Jm5ic3A7Jm5ic3A7ICYjNDM7MS04MDItNzM1LTE2MjQ8L2ZvbnQ+PC9kaXY+ DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXpl OiAxNHB4OyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7IiBjbGFzcz0iIj4N Cjxmb250IGZhY2U9IkNhbGlicmksc2Fucy1zZXJpZiIgY2xhc3M9IiI+SmFiYmVyOiZuYnNwOzxh IGhyZWY9Im1haWx0bzp5b3JrQGphYmJlci5pc29jLm9yZyIgY2xhc3M9IiI+eW9ya0BqYWJiZXIu aXNvYy5vcmc8L2E+Jm5ic3A7PC9mb250PjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6 IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsgYmFja2dyb3VuZC1jb2xvcjog cmdiKDI1NSwgMjU1LCAyNTUpOyIgY2xhc3M9IiI+DQo8Zm9udCBmYWNlPSJDYWxpYnJpLHNhbnMt c2VyaWYiIGNsYXNzPSIiPlNreXBlOiBkYW55b3JrICZuYnNwOyZuYnNwOzxhIGhyZWY9Imh0dHA6 Ly90d2l0dGVyLmNvbS9kYW55b3JrIiBjbGFzcz0iIj5odHRwOi8vdHdpdHRlci5jb20vZGFueW9y azwvYT48L2ZvbnQ+PC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fu cy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUs IDI1NSk7IiBjbGFzcz0iIj4NCjxmb250IGZhY2U9IkNhbGlicmksc2Fucy1zZXJpZiIgY2xhc3M9 IiI+PGJyIGNsYXNzPSIiPg0KPC9mb250PjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6 IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsgYmFja2dyb3VuZC1jb2xvcjog cmdiKDI1NSwgMjU1LCAyNTUpOyIgY2xhc3M9IiI+DQo8Zm9udCBmYWNlPSJDYWxpYnJpLHNhbnMt c2VyaWYiIGNsYXNzPSIiPjxhIGhyZWY9Imh0dHA6Ly93d3cuaW50ZXJuZXRzb2NpZXR5Lm9yZy9k ZXBsb3kzNjAvIiBjbGFzcz0iIj5odHRwOi8vd3d3LmludGVybmV0c29jaWV0eS5vcmcvPC9hPjwv Zm9udD48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdl LW5ld2xpbmUiPg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCjwvZGl2 Pg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_29538CF8CFED4C4CB971841F028F0183isocorg_-- From nobody Fri Jun 12 14:00: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 210901B2AA6 for ; Fri, 12 Jun 2015 14:00:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 iLVWi9YCvlwR for ; Fri, 12 Jun 2015 14:00: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 979FB1B2AA9 for ; Fri, 12 Jun 2015 14:00:07 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 7B89C28494C; Fri, 12 Jun 2015 21:00:06 +0000 (UTC) Date: Fri, 12 Jun 2015 21:00:06 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150612210006.GD2050@mournblade.imrryr.org> References: <29538CF8-CFED-4C4C-B971-841F028F0183@isoc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <29538CF8-CFED-4C4C-B971-841F028F0183@isoc.org> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dane] DANE / DNSSEC added to IETF 93 Hackathon - anyone else interested? 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, 12 Jun 2015 21:00:09 -0000 On Fri, Jun 12, 2015 at 06:59:16PM +0000, Dan York wrote: > In a hackathon like this, a small team of people agrees to work on > (ideally!) a clearly-defined project that can, in theory, be completed in > two days and is something that the judges and others might find interesting > and useful. There can be several different teams under this topic working > on different projects. Sunday afternoon at 3pm the teams are supposed to > stop and come up with a presentation. Those are given at 4pm and awards > are given at 5pm. I am concerned that this sends the message that a trustworthy DANE implementation is something one can quickly slap together in a very short time. This is not true, and the vast majority of implementations that make this assumption are deeply flawed. So while I'm all for DANE adoption, I am rather ambivalent about hackathons at this stage of the game if the output is intended to implement a trustworthy verifier. If the project just builds ancilliary tools (for managing zones and the like) then I am less concerned. I would very much like to not see yet another non-working DANE validator on Github, ... -- Viktor. From nobody Sat Jun 13 17:12: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 E14561A8A4E for ; Sat, 13 Jun 2015 17:12:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.663 X-Spam-Level: * X-Spam-Status: No, score=1.663 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 Rh612A60kJ6W for ; Sat, 13 Jun 2015 17:12:27 -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 99CE31A8870 for ; Sat, 13 Jun 2015 17:12:26 -0700 (PDT) Received: (qmail 36501 invoked from network); 14 Jun 2015 00:12:35 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 14 Jun 2015 00:12:35 -0000 Date: 14 Jun 2015 00:12:03 -0000 Message-ID: <20150614001203.18661.qmail@ary.lan> From: "John Levine" To: dane@ietf.org In-Reply-To: <20150611160858.GL2050@mournblade.imrryr.org> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dane] AD review of draft-ietf-dane-openpgpkey-03 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 14 Jun 2015 00:12:28 -0000 >I agree with all of that. If it is to be DNS, then hashing works >no worse than most other encodings. As I'm fairly sure I described in detail before, base32 provides the option of reversing the encoding at the server, looking up the local part using whatever fuzzy matching the server wants to use, and sending an appropriate response. There's be no need to do any of the ill-advised local part guessing that people seem to think is required. You'd need a stunt server, but if you're publishing 100,000,000 keys, you're not going to use BIND. If you think that couldn't work, could you explain why not? R's, John From nobody Sat Jun 13 17:57: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 17E261A8F40 for ; Sat, 13 Jun 2015 17:57:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.663 X-Spam-Level: * X-Spam-Status: No, score=1.663 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 CeyEzMOJlQup for ; Sat, 13 Jun 2015 17:57:36 -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 5F0191A8F3E for ; Sat, 13 Jun 2015 17:57:36 -0700 (PDT) Received: (qmail 42182 invoked from network); 14 Jun 2015 00:57:44 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 14 Jun 2015 00:57:44 -0000 Date: 14 Jun 2015 00:57:12 -0000 Message-ID: <20150614005712.18829.qmail@ary.lan> From: "John Levine" To: dane@ietf.org In-Reply-To: <20150611160858.GL2050@mournblade.imrryr.org> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dane] AD review of draft-ietf-dane-openpgpkey-03 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 14 Jun 2015 00:57:37 -0000 PS: >There are some advantages to each approach. The main disadvantage >of not using DNS (B), is that no such service is readily available, >so new code would be required to implement it. At the WG in Dallas, people familiar with mail ops seemed to think that webfinger would be suitable. R's, John From nobody Sun Jun 14 07:26: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 4959F1A86E9 for ; Sun, 14 Jun 2015 07:26:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.111 X-Spam-Level: X-Spam-Status: No, score=-0.111 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 H_0yF6Jx7ZCh for ; Sun, 14 Jun 2015 07:26: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 96F0F1A017A for ; Sun, 14 Jun 2015 07:26:55 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3m8dQj4yKNz1J4; Sun, 14 Jun 2015 16:26:53 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=fnRwI+v6 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 pjXmrQvRI2yR; Sun, 14 Jun 2015 16:26:52 +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, 14 Jun 2015 16:26:51 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 3F1CC800B6; Sun, 14 Jun 2015 10:26:50 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1434292010; bh=bAGj7m48DW0TrBohEhdC7fUzkK8RBbSlMFoexxxMiIg=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=fnRwI+v6L2vGH+7etL//pJDXOEsKgjL+7efq2wBC5Or8XirT2eZxKSG1aHXkyLoCN R8kdCyRYIvs8IDC0DaH/bmDQWpK4Dm5UKRYcYZm3f8yZamac05Ae2hMKyPd9/xMtLI XCrpSt1fjnKqeI69bRqgxbHmuZe+4eJsDfnHAAvE= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.15.1/8.15.1/Submit) with ESMTP id t5EEQnKu018456; Sun, 14 Jun 2015 10:26:49 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Sun, 14 Jun 2015 10:26:49 -0400 (EDT) From: Paul Wouters To: John Levine In-Reply-To: <20150614005712.18829.qmail@ary.lan> Message-ID: References: <20150614005712.18829.qmail@ary.lan> User-Agent: Alpine 2.11 (LFD 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] AD review of draft-ietf-dane-openpgpkey-03 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 14 Jun 2015 14:26:58 -0000 On Sat, 14 Jun 2015, John Levine wrote: >> There are some advantages to each approach. The main disadvantage >> of not using DNS (B), is that no such service is readily available, >> so new code would be required to implement it. > > At the WG in Dallas, people familiar with mail ops seemed to think > that webfinger would be suitable. And using another protocol/service such as webfinger does not need to use the query mechanism of hashing and lowercasing, so I don't see this as an objection to the currently drafted DNS query method which opts to use the existing DNSSEC security without adding an additional service that needs to be available, scallable, authenticated and withstand email enumeration attacks. Paul From nobody Sun Jun 14 07:40: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 002351A88A6 for ; Sun, 14 Jun 2015 07:40:21 -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 qfo3Txg4HipC for ; Sun, 14 Jun 2015 07:40:19 -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 7D4671A88A3 for ; Sun, 14 Jun 2015 07:40:19 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3m8dkB135Xzrl; Sun, 14 Jun 2015 16:40:18 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=fGTkGKaO 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 XbPX3_oiRkfF; Sun, 14 Jun 2015 16:40:17 +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, 14 Jun 2015 16:40:16 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 1B925800B6; Sun, 14 Jun 2015 10:40:16 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1434292816; bh=001i4Rc4fXaVAwOp3zs+sVy/tPw4j6B+66mSakGvSjg=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=fGTkGKaONOxok0hoG0BfYpRpfO7IgFgo4vOrOEndK1t8R1bZUIf7NEfS36PgzzzDj CVOJi6LvjxYtRresZpeaVRinAf90YGCAMUOar98CUCZpQQvNSwaPPQGb9t0y1Wmp3U sGPRFasojOV3YgJzDnR1dGI5vtZv600UhAfXxkz0= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.15.1/8.15.1/Submit) with ESMTP id t5EEeFbC018722; Sun, 14 Jun 2015 10:40:15 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Sun, 14 Jun 2015 10:40:15 -0400 (EDT) From: Paul Wouters To: John Levine In-Reply-To: <20150614001203.18661.qmail@ary.lan> Message-ID: References: <20150614001203.18661.qmail@ary.lan> User-Agent: Alpine 2.11 (LFD 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] AD review of draft-ietf-dane-openpgpkey-03 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 14 Jun 2015 14:40:21 -0000 On Sat, 14 Jun 2015, John Levine wrote: >> I agree with all of that. If it is to be DNS, then hashing works >> no worse than most other encodings. > > As I'm fairly sure I described in detail before, base32 provides the > option of reversing the encoding at the server, looking up the local > part using whatever fuzzy matching the server wants to use, and > sending an appropriate response. This pretends that the server can read the human mind of the sender. It's an equally insecure fuzzy matching logic, but now done at the server side instead of the client side. How is paul@ietf.org going to get matched by this server side? To me? to Paul Hoffman? To no one? If the human starts making up email addresses, it could go wrong. The client implementation can have a local policy to protect the user. For example, enigmail shows a big red THIS MESSAGE WILL NOT BE ENCRYPTED warning. > There's be no need to do any of the > ill-advised local part guessing that people seem to think is required. You started the guessing part at the client's human. Whether you outsource their lack of brain power to the email client or the email server does not matter much - both are insecure and prone to continue with its human error. > You'd need a stunt server, but if you're publishing 100,000,000 keys, > you're not going to use BIND. Why don't we let those people speak for themselves if they want to? It seems those with 100M accounts tend to know something about scaling, and some of them even wrote a complete DNSSEC server implementation backed by their own global database store. > If you think that couldn't work, could you explain why not? Using a red wax sealed envelope couriered by knight could also work. It is just that this document of the dane working group is proposing a solution that uses only DNSSEC, with the intension of not needing to rely on other out-of-band protocols that can be firewalled, DDOSed and in general do not have the resilience of a distributed DNS backend. For example, the weeks long attack against pgp.mit.edu would be something your solution would be equally vulnerable to. Paul From nobody Sun Jun 14 08:05: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 83C2A1A89BB for ; Sun, 14 Jun 2015 08:05:20 -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 pB_pyTTggjzl for ; Sun, 14 Jun 2015 08:05: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 ECA451A89AB for ; Sun, 14 Jun 2015 08:05:18 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id B1868284B71; Sun, 14 Jun 2015 15:05:17 +0000 (UTC) Date: Sun, 14 Jun 2015 15:05:17 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150614150517.GP2050@mournblade.imrryr.org> References: <20150614001203.18661.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] AD review of draft-ietf-dane-openpgpkey-03 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, 14 Jun 2015 15:05:20 -0000 On Sun, Jun 14, 2015 at 10:40:15AM -0400, Paul Wouters wrote: > >As I'm fairly sure I described in detail before, base32 provides the > >option of reversing the encoding at the server, looking up the local > >part using whatever fuzzy matching the server wants to use, and > >sending an appropriate response. > > This pretends that the server can read the human mind of the sender. No, it assumes that the server has access to the same canonicalization and aliasing data as the SMTP server that processes mail for the domain. If no such data is available then only exact matches will return results. With reversible encodings, the server might use the DNS protocol, but use something fancier than exact match to locate the right records. Because it is the server for the target domain, it might the canonical object corresponding to a given lookup key. One disadvantage of base32 is that it imposes new limits on the length of the email address localpart, unless splitting into multiple labels is introduced to handle longer inputs. Hashing imposes no such limits. However, we're then still left with the problem of dealing with certificates and/or PGP keys that don't match (via the enclosed user identifiers) the email correspondent that the user asked for. That requires new code in user-agents to bind additional addresses to an identity based on authenticated responses that return a key for Y when you asked for X. By now many of you have likely noticed that I'm on the fence on this issue. I have sympathies for both points of view. -- Viktor. From nobody Sun Jun 14 08:08: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 38CFE1A89C6 for ; Sun, 14 Jun 2015 08:08:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.762 X-Spam-Level: X-Spam-Status: No, score=0.762 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_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 m5U7IVTC2I6g for ; Sun, 14 Jun 2015 08:08: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 D2F641A899F for ; Sun, 14 Jun 2015 08:08:51 -0700 (PDT) Received: (qmail 75851 invoked from network); 14 Jun 2015 15:09:00 -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=1284a.557d990c.k1506; bh=svgAa72KdHiBRFwQiJcXtjShQdZECAZcUNSHTDP1T3k=; b=FYLFoE+nfPHwffH9+RLZHy6OmYArhnWdLxtUCjWDRVw/3WWD4/tW/ToG+VPRR1Pw0huaF/wHYpRs5p2i4VHEEB4/0nQY/i20kuL7a5iNRZsmkA77C0lsXfztsoUx5y4eWmzOmQFOPBJBOg2hX2GGhyQ6GNl2XC4oLJNdKdZSBKtJdn5CRMdElWiz+Id5V1SSndTDOJn8aFHg6QbTrY6Pfk7icRJqGvKIqkXqd/znrqeIvgklxkioiNR9112MuoSm 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=1284a.557d990c.k1506; bh=svgAa72KdHiBRFwQiJcXtjShQdZECAZcUNSHTDP1T3k=; b=dEAAbv8MBHpMEgmHhWeHGLA8QgcHf1vwg87o9HL0pisYffn/bhKWACGafi/RleQ0FGpZ6ElJuD1uZmnAjpkuTxUxiyAqEW0SF6r06CsWdYi6J6jLp0gCVy9DeLpyeyUWovaQUhN4fPpYHMNmZEsjOxXgaF8I9665s91nGW5RS3QmOlJRokBqrE2wvgcH9p9To2+G+TveG/waUn9PIIofLmA53uYT+TvxCoIuAHbbzQwwRZX7ZakMvIU8z1wmYdje Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 14 Jun 2015 15:09:00 -0000 Date: 14 Jun 2015 11:08:50 -0400 Message-ID: From: "John R Levine" To: "Paul Wouters" In-Reply-To: References: <20150614001203.18661.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] AD review of draft-ietf-dane-openpgpkey-03 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 14 Jun 2015 15:08:53 -0000 >> As I'm fairly sure I described in detail before, base32 provides the >> option of reversing the encoding at the server, looking up the local >> part using whatever fuzzy matching the server wants to use, and >> sending an appropriate response. > > This pretends that the server can read the human mind of the sender. No, it does not. Gratuitous insults like this are not helpful. > It's an equally insecure fuzzy matching logic, but now done at the > server side instead of the client side. How is paul@ietf.org going > to get matched by this server side? To me? to Paul Hoffman? To no one? Hmmn. The assumptions in this paragraph are a bit much. Having actually written mail servers, and written books about mail servers, and written a few stunt DNS servers, based on my personal experience it would not be unreasonably difficult to adapt a DNS server to use the mail server's address matching logic to find the account to which a local part actually corresponds so it can get the PGP (or whatever) key that goes with that account. There's nothing insecure about this, it's resolving the local part according to RFC 5321, the same way a mail server does. In your example, it's matched to whatever internal account paul@ietf.org corresponds to. Yeah, it requires the DNS server and mail server to talk to each other, or at least share a database, but that's the price you have to pay if you want to force SMTP features into the DNS. If you're saying you can't imagine how someone could do this, I won't argue but it doesn't impress me as a very good basis for protocol design. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Sun Jun 14 08:23: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 799BE1A8A16 for ; Sun, 14 Jun 2015 08:23: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 f6wlYZqniKKk for ; Sun, 14 Jun 2015 08:23: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 D5B911A8867 for ; Sun, 14 Jun 2015 08:23:24 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3m8fgt3g06zrl for ; Sun, 14 Jun 2015 17:23:22 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=vAUDDRC0 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 BfRbcz3pjFgu for ; Sun, 14 Jun 2015 17:23:21 +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 ; Sun, 14 Jun 2015 17:23:21 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 93C34800A3 for ; Sun, 14 Jun 2015 11:23:20 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1434295400; bh=cn/IWBsVcFX35Rk1nkbv3uzoo1jZhGQSVUogcmeZ0sI=; h=Date:From:To:Subject:In-Reply-To:References; b=vAUDDRC0f+SIqM4g5CcSuOWiVzxhTzBzt1f79hWLg53FKd3zBOojfivflRgXDLgvp mTaDTmlNWke72ylvLKfzsD/UN0zd5CHVaFuuUtYU38spO35mh6CE2rhyWyt02l+usl hicNdV1qDtd541phBSop7EHWbXWcgKucTtI81TBU= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.15.1/8.15.1/Submit) with ESMTP id t5EFNKBg019410 for ; Sun, 14 Jun 2015 11:23:20 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Sun, 14 Jun 2015 11:23:20 -0400 (EDT) From: Paul Wouters To: dane@ietf.org In-Reply-To: <20150614150517.GP2050@mournblade.imrryr.org> Message-ID: References: <20150614001203.18661.qmail@ary.lan> <20150614150517.GP2050@mournblade.imrryr.org> User-Agent: Alpine 2.11 (LFD 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dane] AD review of draft-ietf-dane-openpgpkey-03 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 14 Jun 2015 15:23:26 -0000 On Sun, 14 Jun 2015, Viktor Dukhovni wrote: >>> As I'm fairly sure I described in detail before, base32 provides the >>> option of reversing the encoding at the server, looking up the local >>> part using whatever fuzzy matching the server wants to use, and >>> sending an appropriate response. >> >> This pretends that the server can read the human mind of the sender. > > No, it assumes that the server has access to the same canonicalization > and aliasing data as the SMTP server that processes mail for the > domain. But that's not what this is about. This is about the user typing in an email address FOO and that address does not exist, and now some fuzzy matching will happen for the client/server to map it to a valid address with no guarantee that the user actually meant that target mailbox. It does not even relate to crypto keys! Then somehow, the crypto key lookup is can be enhanced by using base32 lookups so the server can return crypto keys? If you try to send an email and use the wrong email address, it will go to the wrong user. In our discussion, it will go encrypted to the wrong user or in plaintext to the wrong user. How does having done a base32 lookup versus a hashed lookup make any difference? > If no such data is available then only exact matches will > return results. With reversible encodings, the server might use > the DNS protocol, but use something fancier than exact match to > locate the right records. There are no "right records" when you email a non-existing, wrong address you made up or typoed on. This has nothing to do with crypto keys. > Because it is the server for the target > domain, it might the canonical object corresponding to a given > lookup key. And that could be a disservice to the user! Now the secret email you meant to send me gets encrypted and delivered to PaulHoffman isntead of PaulWouters? If you want to do fuzzy localpart matching, go and fix that problem. Once you have fixed that, and you can determine the True Local Part of a human's intention, you can just pick up the crypto key from the right location even when using hash(lowercase(True Name)) Paul From nobody Sun Jun 14 08:37: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 484971A8A7E for ; Sun, 14 Jun 2015 08:37:19 -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 b1K3tVXbZ2RI for ; Sun, 14 Jun 2015 08:37:17 -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 B9A591A008B for ; Sun, 14 Jun 2015 08:37:17 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id CC011284B71; Sun, 14 Jun 2015 15:37:16 +0000 (UTC) Date: Sun, 14 Jun 2015 15:37:16 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150614153716.GA14121@mournblade.imrryr.org> References: <20150614001203.18661.qmail@ary.lan> <20150614150517.GP2050@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-openpgpkey-03 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, 14 Jun 2015 15:37:19 -0000 On Sun, Jun 14, 2015 at 11:23:20AM -0400, Paul Wouters wrote: > >No, it assumes that the server has access to the same canonicalization > >and aliasing data as the SMTP server that processes mail for the > >domain. > > But that's not what this is about. This is about the user typing in an > email address FOO and that address does not exist, and now some fuzzy > matching will happen for the client/server to map it to a valid address > with no guarantee that the user actually meant that target mailbox. I think this assumption is part of the miscommunication in this thread. I don't think that's what being suggested. Rather, users may have lots of valid addresses, known to the receiving system as being the same user and in fact too many to create a separate DNS record for each one (as with user+ address extensions). So the question is whether it should be possible for the key server server (DNS or otherwise) to recognize address *variants* (not fuzzy matching). There's nothing fuzzy here, server's domain, server's matching rules. > Then somehow, the crypto key lookup is can be enhanced by using base32 > lookups so the server can return crypto keys? Well with base32, the original input string is recoverable as-is, and so the server can apply no rules and use the lookup key verbatime, or it might canonicalize the key in some manner that makes for localparts in the domain in question. > If you try to send an email and use the wrong email address, it will > go to the wrong user. That's not the use-case under discussion. Rather the concern is about *variant* addresses, not *wrong* addresses. > >Because it is the server for the target > >domain, it might the canonical object corresponding to a given > >lookup key. > > And that could be a disservice to the user! Now the secret email you > meant to send me gets encrypted and delivered to PaulHoffman isntead > of PaulWouters? You've got the wrong end of the stick there. Were not fuzzy matching "paul" to some random Paul. We're talking about "v.dukhovni" and "vdukhovni" being equivalent localparts for my Gmail mailbox and Google unequivocally knows this is the case, but user agents composing email do not (or at least should/must not). -- Viktor. From nobody Sun Jun 14 09:09: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 D9F201B2F9A for ; Sun, 14 Jun 2015 09:09:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.663 X-Spam-Level: * X-Spam-Status: No, score=1.663 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 rRF_8hz3pCoE for ; Sun, 14 Jun 2015 09:09:12 -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 7CD191A9089 for ; Sun, 14 Jun 2015 09:09:12 -0700 (PDT) Received: (qmail 84661 invoked from network); 14 Jun 2015 16:09:20 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 14 Jun 2015 16:09:20 -0000 Date: 14 Jun 2015 16:08:48 -0000 Message-ID: <20150614160848.25376.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] AD review of draft-ietf-dane-openpgpkey-03 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 14 Jun 2015 16:09:14 -0000 >But that's not what this is about. This is about the user typing in an >email address FOO and that address does not exist, and now some fuzzy >matching will happen for the client/server to map it to a valid address >with no guarantee that the user actually meant that target mailbox. I'm sorry, but this assertion is completely wrong, and suggests a rather serious failure to understand how mail works. When a mail server handles a locally addressed piece of mail, it maps the local-part of the address into some sort of internal identifier. The local identifier for FOO might be FOO or foo but it's as likely to be user1234. On my system, every case variation such as foO and fOo is an equally valid name for the mailbox. Something like foo+bar or FOO-bar might also be a name for the same mailbox, or might not, depending on how user1234 has configured her mail. Only the mail server knows how it resolves its local-parts which is why for 30 years the spec has said not to guess. The mapping from the local-part to the internal identifier is completely deterministic, and completely opaque to anyone outside. Hence the only way to make this crock work in the DNS is for the DNS server to be able to (conceptually) look inside the mail server for the domain to see what the rules for that domain are. R's, John From nobody Sun Jun 14 09:10: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 0F6521B2F9F for ; Sun, 14 Jun 2015 09:10:33 -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 vv_l8cyFy7Rd for ; Sun, 14 Jun 2015 09:10:31 -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 DD8121B2F9B for ; Sun, 14 Jun 2015 09:10:30 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3m8gkF4Lb7z1J6 for ; Sun, 14 Jun 2015 18:10:29 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=at+yZysE 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 Egb5V0HngDW4 for ; Sun, 14 Jun 2015 18:10:28 +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 ; Sun, 14 Jun 2015 18:10:28 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 9E859800A3 for ; Sun, 14 Jun 2015 12:10:27 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1434298227; bh=8mohhWHNGFOEQ8Dlt+kX5JN9nN6CdTa/aQFs2kyPJ8U=; h=Date:From:To:Subject:In-Reply-To:References; b=at+yZysE12ya7epG0gALxfZibZ4buta9tiF2t/2z6u5FiojVllt0tzfMd7igvD1ti W3W94AQHDE7qPq1pzfRrhhJ/shVM9Ii4nQfXlaxf4AjbUfhrnqXfI+Iqc5lC9pNXz+ W6yUL4Je0tUTrL2V1JrrdljrETkvZHRNjee7EzrY= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.15.1/8.15.1/Submit) with ESMTP id t5EGARXo020426 for ; Sun, 14 Jun 2015 12:10:27 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Sun, 14 Jun 2015 12:10:27 -0400 (EDT) From: Paul Wouters To: dane@ietf.org In-Reply-To: <20150614153716.GA14121@mournblade.imrryr.org> Message-ID: References: <20150614001203.18661.qmail@ary.lan> <20150614150517.GP2050@mournblade.imrryr.org> <20150614153716.GA14121@mournblade.imrryr.org> User-Agent: Alpine 2.11 (LFD 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dane] AD review of draft-ietf-dane-openpgpkey-03 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 14 Jun 2015 16:10:33 -0000 On Sun, 14 Jun 2015, Viktor Dukhovni wrote: > I think this assumption is part of the miscommunication in this > thread. I don't think that's what being suggested. Rather, users > may have lots of valid addresses, known to the receiving system as > being the same user and in fact too many to create a separate DNS > record for each one (as with user+ address extensions). > > So the question is whether it should be possible for the key server > server (DNS or otherwise) to recognize address *variants* (not > fuzzy matching). There's nothing fuzzy here, server's domain, > server's matching rules. Currently there is no mechanism where the server can advertise their rewriting rules. So a client implementation _could_ query for the key of foo+bar@example.com and if that fails try foo@example.com for those well known domains we know the rewriting happens, then check within the pgp key data for some confirmation or prompt the user. However, I was told I could not even suggest this in the draft. >> Then somehow, the crypto key lookup is can be enhanced by using base32 >> lookups so the server can return crypto keys? > > Well with base32, the original input string is recoverable as-is, > and so the server can apply no rules and use the lookup key verbatime, > or it might canonicalize the key in some manner that makes for localparts > in the domain in question. The problem is that for those who use offline DNSSEC signing, this is not an workable solution. And since the lowercase()ing would be removed, it means those with offline signing now have to stuff their zone with all possible lower/upper casing they think their users virtual keyboards might slip by, and the only way out there is to basically do the same thing as above, if you can't find split(base32(Paul@nohats.ca)) try split(base32(paul@nohats.ca)). Which I was told I could not even suggest in the draft. > We're talking about "v.dukhovni" and "vdukhovni" being equivalent > localparts for my Gmail mailbox and Google unequivocally knows this > is the case, but user agents composing email do not (or at least > should/must not). Yes, the + and the . use cases are very wel understood and easilly handled by the mail client doing the DNS lookup. The draft as currently proposd works with offline and online signing. And with the simple universally known rewrite rules can be made to work to support the + and . alias rewriting. The base32/split solution does not work with offline signing. And can be made to work to support offline signing and Casing by allowing the client to issue hash(original), then hash(lowercase) queries. So pick one. Paul From nobody Sun Jun 14 09:24:34 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 AE5E21A9121 for ; Sun, 14 Jun 2015 09:24:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.663 X-Spam-Level: * X-Spam-Status: No, score=1.663 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 2xGeoum1Lw27 for ; Sun, 14 Jun 2015 09:24:33 -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 AAC761A911A for ; Sun, 14 Jun 2015 09:24:32 -0700 (PDT) Received: (qmail 86817 invoked from network); 14 Jun 2015 16:24:41 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 14 Jun 2015 16:24:41 -0000 Date: 14 Jun 2015 16:24:09 -0000 Message-ID: <20150614162409.25438.qmail@ary.lan> From: "John Levine" To: dane@ietf.org In-Reply-To: <20150614150517.GP2050@mournblade.imrryr.org> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dane] AD review of draft-ietf-dane-openpgpkey-03 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 14 Jun 2015 16:24:33 -0000 >One disadvantage of base32 is that it imposes new limits on the >length of the email address localpart, unless splitting into multiple >labels is introduced to handle longer inputs. Hashing imposes no >such limits. If you'll review previous messages on this very topic, I proposed a base32 version that pads the local-part out to 64 bytes with 0xFF (a byte valid neither in ASCII nor UTF-8), splits it in half, and base32 encodes those as .. This can encode any local-part, and is trivial to reverse. Since most local-parts are less than 32 bytes, a minor optimization is to omit the highpart if it's all FF. You can't use a base32 or base32hex encoding exactly like the one in RFC4648 since it uses = for padding, but you could leave out the padding since you know how long the result is supposed to be. It's ugly, but so what? Only machines are going to look at it. R's, John From nobody Sun Jun 14 09:27: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 C61031B2FD4 for ; Sun, 14 Jun 2015 09:27:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.663 X-Spam-Level: * X-Spam-Status: No, score=1.663 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 rZKEbysFN-Hy for ; Sun, 14 Jun 2015 09:27:29 -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 1A62D1B2FD3 for ; Sun, 14 Jun 2015 09:27:29 -0700 (PDT) Received: (qmail 87134 invoked from network); 14 Jun 2015 16:27:38 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 14 Jun 2015 16:27:38 -0000 Date: 14 Jun 2015 16:27:06 -0000 Message-ID: <20150614162706.25485.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] AD review of draft-ietf-dane-openpgpkey-03 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 14 Jun 2015 16:27:29 -0000 >Currently there is no mechanism where the server can advertise their >rewriting rules. Mail servers don't have rewriting rules. They do have rules to map local-parts into internal identifiers which may or may not be local-parts. Please review previous messages on this topic. It would probably be helpful to read RFC 5321. R's, John From nobody Mon Jun 15 01:34: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 0A73A1B342A for ; Mon, 15 Jun 2015 01:34:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.895 X-Spam-Level: ** X-Spam-Status: No, score=2.895 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] 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 SXixF6-XcbKA for ; Mon, 15 Jun 2015 01:34:18 -0700 (PDT) Received: from shannon.7bits.nl (shannon.7bits.nl [IPv6:2a01:1b0:202:40::1]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45FEA1A891A for ; Mon, 15 Jun 2015 01:34:17 -0700 (PDT) Received: from [192.168.0.30] (e163253.upc-e.chello.nl [213.93.163.253]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: peter) by shannon.7bits.nl (Postfix) with ESMTPSA id 26FACC1B55 for ; Mon, 15 Jun 2015 10:34:13 +0200 (CEST) From: "Peter van Dijk" To: dane@ietf.org Date: Mon, 15 Jun 2015 10:34:26 +0200 Message-ID: In-Reply-To: References: <20150614001203.18661.qmail@ary.lan> <20150614150517.GP2050@mournblade.imrryr.org> <20150614153716.GA14121@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.1r5084) Archived-At: Subject: Re: [dane] AD review of draft-ietf-dane-openpgpkey-03 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 15 Jun 2015 08:34:20 -0000 Hello, On 14 Jun 2015, at 18:10, Paul Wouters wrote: > The base32/split solution does not work with offline signing. And can > be made to work to support offline signing and Casing by allowing the > client to issue hash(original), then hash(lowercase) queries. So let’s do this! Allow the client to lowercase (initially, or as a fallback) - I think everybody agrees there is no harm in this *in practice*, then encode with split base32. This works for offline signing exactly as well as lowercase+hashing, but anybody who wants more (support for dot stripping, variant addresses, etc.) can *choose to* switch to online signing and get these benefits. As for the argument “a key is no use if it does not exactly match the email address”: (1) keep in mind that whatever lookup mechanism we agree on will be copied for SMIMEA and, with any luck, other future protocols as well (2) with split base32, one *could* run a mail server that automatically issues keys/certs for variant addresses, broadening the scope of ‘opportunistic encryption’ to variant addresses without requiring client changes (3) clients *could* decide to trust the DNS server on the variant mapping 2 and 3 are not required, but it would be good to keep room for them. With split base32, we get this flexibility. With hashing, we lose it. Note that this requires very little changed text in the draft. Replace hashing with split base32, leave section 3.1 (variants) as is (with MUST NOT). Maybe add some text there about server-side (online signing) variant mapping. Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ From nobody Mon Jun 15 06:48: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 E90D31A90B3 for ; Mon, 15 Jun 2015 06:48:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[BAYES_40=-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 y4XTmhqjkv3w for ; Mon, 15 Jun 2015 06:48:10 -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 4742F1A9096 for ; Mon, 15 Jun 2015 06:48:10 -0700 (PDT) Received: from [46.33.133.68] (helo=lap.dom.ain) from_AS 51561 by wizmail.org with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.85_209-ea6646d) id 1Z4UkC-0006LL-P6 for dane@ietf.org (return-path ); Mon, 15 Jun 2015 13:48:08 +0000 Message-ID: <557ED798.3060000@wizmail.org> Date: Mon, 15 Jun 2015 14:48:08 +0100 From: Jeremy Harris User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: dane@ietf.org References: <20150614001203.18661.qmail@ary.lan> <20150614150517.GP2050@mournblade.imrryr.org> <20150614153716.GA14121@mournblade.imrryr.org> In-Reply-To: Content-Type: text/plain; charset=utf-8 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-openpgpkey-03 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 15 Jun 2015 13:48:15 -0000 On 15/06/15 09:34, Peter van Dijk wrote: > Allow the client to lowercase (initially, or as a fallback) - I think > everybody agrees there is no harm in this *in practice* What rules will you follow for UTF8 names? -- Jeremy From nobody Mon Jun 15 08:30: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 75F861B2E8A for ; Mon, 15 Jun 2015 08:30:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.663 X-Spam-Level: * X-Spam-Status: No, score=1.663 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 AVqQzz-kQGx6 for ; Mon, 15 Jun 2015 08:30:48 -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 19BE31B2EA2 for ; Mon, 15 Jun 2015 08:30:48 -0700 (PDT) Received: (qmail 9676 invoked from network); 15 Jun 2015 15:30:56 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 15 Jun 2015 15:30:56 -0000 Date: 15 Jun 2015 15:30:24 -0000 Message-ID: <20150615153024.30223.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: peter.van.dijk@powerdns.com Subject: Re: [dane] AD review of draft-ietf-dane-openpgpkey-03 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 15 Jun 2015 15:30:49 -0000 >Allow the client to lowercase (initially, or as a fallback) - I think >everybody agrees there is no harm in this *in practice*, then encode >with split base32. ... No, for two reasons. One is that RFC 5321 clearly says that case folding is forbidden, and the mail world is very big. Every time I've assumed, that regardless of what the spec says, nobody does something any more, it turns out that someone still does, usually for a perfectly sensible reason that hadn't occurred to me. It is painfully evident that few people in this discussion have any experience with mail systems other than their own, and none with large (millions of mailboxes), and generalizing from limited experience is never a good idea. Also, to point out the obvious, this is just guessing that the mailbox associated with BOB@blah is the same one as bob@blah. Once again, it's putting a ten ton steel door on a cardboard box, as we too often do, which is just bizarre for a spec that is intended to be about security. The other reason is EAI. Billions of people write their names in UTF-8, not in ASCII, and they are going to have EAI mailboxes with UTF-8 names. You cannot case fold UTF-8 unless you know what language the name is written in, and often not unless you also know what sub-version of the language, e.g., the rules for Canadian French are different from the ones for French, Belgian, or Swiss French, and often not even then. There's stuff like traditional and simplified Chinese characters which are equivalent except when they aren't, and which is the canonical version is a highly political question. As should be obvious, I think that trying to force mailbox names into the DNS is a fundamentally bad idea, but the least bad way to do it is a base32 encoding of the exact name to be looked up since, unlike the other options, it at least allows for the possibility of a correct implementation. R's, John From nobody Mon Jun 15 09:23: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 981891B2E70 for ; Mon, 15 Jun 2015 09:22:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.69 X-Spam-Level: X-Spam-Status: No, score=0.69 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 fHK-KiyrBWKx for ; Mon, 15 Jun 2015 09:22:57 -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 4BE5A1A8AC0 for ; Mon, 15 Jun 2015 09:22:57 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3m9Hy66m8nz2Cg for ; Mon, 15 Jun 2015 18:22:54 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=U/f6+x26 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 VJxcFENX-o4l for ; Mon, 15 Jun 2015 18:22:52 +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, 15 Jun 2015 18:22:52 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 36F0E800B6 for ; Mon, 15 Jun 2015 12:22:51 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1434385371; bh=in6MsJKB3wJroUhvy12d4rDgUFrY72zcsurjlBC6fq0=; h=Date:From:To:Subject:In-Reply-To:References; b=U/f6+x26UEf0vZzhj2FfEDW243MS0q+7Bo8HIf0+85ytxWuRLywdua8igEgQyT0oE lWE0C1W6a1KVwB2L+yCk/FiI3QozqJibtrw0eFmiMhskDV4QrmL7KKS/LXMQN4FBR4 d2sSUoUHg6sTtOobcJuZJlwGxW8cyp7hj3CX6BOw= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.15.1/8.15.1/Submit) with ESMTP id t5FGMow0014600 for ; Mon, 15 Jun 2015 12:22:51 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Mon, 15 Jun 2015 12:22:50 -0400 (EDT) From: Paul Wouters To: dane WG list In-Reply-To: <20150615153024.30223.qmail@ary.lan> Message-ID: References: <20150615153024.30223.qmail@ary.lan> User-Agent: Alpine 2.11 (LFD 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dane] AD review of draft-ietf-dane-openpgpkey-03 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 15 Jun 2015 16:22:59 -0000 On Mon, 15 Jun 2015, John Levine wrote: >> Allow the client to lowercase (initially, or as a fallback) - I think >> everybody agrees there is no harm in this *in practice*, then encode >> with split base32. ... > > No, for two reasons. One is that RFC 5321 clearly says that case > folding is forbidden, and the mail world is very big. And I have repeatedly asking for a single deployment where FOO != foo and not heard a single answer back. On the other hand, virtual phone keyboards autocapitalizationing is a real issue on about 4 billion phones. > generalizing from limited experience is never a good idea. So is generalizing everyone elses experience on this list too. No matter how you feel about RFC 5321, the lowercasing is needed. So we have two options. One is to let the client to two queries, the other is to store the local part encoded using a lower case call. If you say no to both, the RFC won't state anything about this, and all the software will send lowercase queries. It is the least desirable end result. > Also, to point out the obvious, this is just guessing that the mailbox > associated with BOB@blah is the same one as bob@blah. Which 4 billion humans (give or take 1) and 4 billion phones assume. If you _security_ depends on people remembering case differences, no amount of encryption can save you. It is a hypothetical non-realistic contrived use case for which I've repeatedly asked empirical evidence. > The other reason is EAI. Billions of people write their names in > UTF-8, not in ASCII, and they are going to have EAI mailboxes with > UTF-8 names. You cannot case fold UTF-8 unless you know what language > the name is written in, and often not unless you also know what > sub-version of the language, e.g., the rules for Canadian French are > different from the ones for French, Belgian, or Swiss French, and > often not even then. There's stuff like traditional and simplified > Chinese characters which are equivalent except when they aren't, and > which is the canonical version is a highly political question. Someone with knowledge on what common virtual keyboards in those languages do could help us and say if this is a problem, and if it is required. One possibly solution is to only attempt lowercase on those characters or languages where it makes sense, eg only on ASCII. Again, the choice is to specify this in the RFC so everyone performs this operational identically and we guarantee interoperability. Or we pretend this problem does not exist, and every piece of software will do their own lowercasing and we have interoperability issues. > As should be obvious, I think that trying to force mailbox names into > the DNS is a fundamentally bad idea, but the least bad way to do it is > a base32 encoding of the exact name to be looked up since, unlike the > other options, it at least allows for the possibility of a correct > implementation. It is only the least bad way if you make the assumption that I've only seen made by you. That case sensitive mailboxes exist in the real (non-cardboard box) world. Paul From nobody Mon Jun 15 09:57: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 9FF201A9235 for ; Mon, 15 Jun 2015 09:57:13 -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 7l_YwlhXzmLC for ; Mon, 15 Jun 2015 09:57:12 -0700 (PDT) Received: from mail.highwayman.com (happyday.demon.co.uk [80.177.121.10]) (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 726D71A9176 for ; Mon, 15 Jun 2015 09:57:01 -0700 (PDT) Received: from localhost ([127.0.0.1]:14599 helo=happyday.al.cl.cam.ac.uk) by mail.highwayman.com with esmtp (Exim 4.85) (envelope-from ) id 1Z4Xez-000CSt-S2; Mon, 15 Jun 2015 16:54:57 +0000 Message-ID: Date: Mon, 15 Jun 2015 17:55:58 +0100 To: Paul Wouters From: Richard Clayton References: <20150615153024.30223.qmail@ary.lan> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed;boundary="=_Turnpike_kHDKHbFdOwfVRICK="; protocol="application/pgp-signature";micalg=pgp-sha1 X-Mailer: Turnpike Integrated Version 5.03 M <$r6$+7gz77vOlMKLFmY+duj7Fx> Archived-At: Cc: dane WG list Subject: Re: [dane] AD review of draft-ietf-dane-openpgpkey-03 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 15 Jun 2015 16:57:13 -0000 This is a PGP signed message sent according to RFC2015 [PGP/MIME] --=_Turnpike_kHDKHbFdOwfVRICK= Content-Type: text/plain;charset=us-ascii Content-Transfer-Encoding: quoted-printable In message , Paul Wouters writes >On Mon, 15 Jun 2015, John Levine wrote: > >>> Allow the client to lowercase (initially, or as a fallback) - I think >>> everybody agrees there is no harm in this *in practice*, then encode >>> with split base32. ... >> >> No, for two reasons. One is that RFC 5321 clearly says that case >> folding is forbidden, and the mail world is very big. > >And I have repeatedly asking for a single deployment where FOO !=3D foo >and not heard a single answer back.=20 here's one (and it took me about 5 minutes to find it...) though you'll see that Yahoo decided it confused too many people and changed it. But that's pragmatism by a large provider introducing a new feature, not "fixing a bug" and certainly (and this is fundamentally John's point) not "having to change my mail system which has been working just fine for the last 30 years". >It is only the least bad way if you make the assumption that I've only >seen made by you.=20 John is an expert on email and so the other experts on email don't need to correct him ... When (implausibly) he says something which is not correct then you will see other email experts (of which there are a few on this list, but probably not all that many) will undoubtedly chip in >That case sensitive mailboxes exist in the real >(non-cardboard box) world. --=20 Dr Richard Clayton tel: 01223 763570, mobile: 07887 794090 Computer Laboratory, University of Cambridge, CB3 0FD --=_Turnpike_kHDKHbFdOwfVRICK= Content-Type: application/pgp-signature Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: PGPsdk version 1.7.1 iQA/AwUBVX8DnuINNVchEYfiEQIuFQCdENe2gjwq+RZ16NITZ8eOBtVyGHkAoIM6 GnlyKruINpKChRXrzduRBjjf =5PFJ -----END PGP SIGNATURE----- --=_Turnpike_kHDKHbFdOwfVRICK=-- From nobody Mon Jun 15 10:12:34 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 646FD1B2ADB for ; Mon, 15 Jun 2015 10:12:33 -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 tHR6OKBwqjBt for ; Mon, 15 Jun 2015 10:12:32 -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 6F56B1B2D09 for ; Mon, 15 Jun 2015 10:12:01 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3m9K2m05Fsz2Cg; Mon, 15 Jun 2015 19:12:00 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=dtXbfbTg 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 0fTMVM-7lNkM; Mon, 15 Jun 2015 19:11:58 +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, 15 Jun 2015 19:11:58 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 5431B800A3; Mon, 15 Jun 2015 13:11:57 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1434388317; bh=I7/TLjc9aecp16xjY5FQ9XzHF0zWexdVzmRFVfsFYxU=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=dtXbfbTg0WztCdvvzSf1eKAcgN/yxOG+mwe1KizIoNGikfEhDpCyGjEgc/Pv7T9hp 1oy6NNY32iThig95uVI8Nsbrv3jysebcvMak5T567SNywrEu+fPb1n0ePeXhC6xdfq 0OJgqeqZiXgxvCGjhxIk3tqaKmXNYY3SOKKuODi0= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.15.1/8.15.1/Submit) with ESMTP id t5FHBuo0015835; Mon, 15 Jun 2015 13:11:57 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Mon, 15 Jun 2015 13:11:56 -0400 (EDT) From: Paul Wouters To: Richard Clayton In-Reply-To: Message-ID: References: <20150615153024.30223.qmail@ary.lan> User-Agent: Alpine 2.11 (LFD 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] AD review of draft-ietf-dane-openpgpkey-03 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 15 Jun 2015 17:12:33 -0000 On Mon, 15 Jun 2015, Richard Clayton wrote: >> And I have repeatedly asking for a single deployment where FOO != foo >> and not heard a single answer back. > > here's one (and it took me about 5 minutes to find it...) > > address-case-sensitivity.html> > > though you'll see that Yahoo decided it confused too many people and > changed it. So that describes a deployment where they _accidentally_ introduced case sensitiveness and all hell broke lose and they fixed it. That only argues in favour of the assumption that case sensitive different mailboxes are dead. > But that's pragmatism by a large provider introducing a new > feature, not "fixing a bug" and certainly (and this is fundamentally > John's point) not "having to change my mail system which has been > working just fine for the last 30 years". openpgpkey does not modify email delivery at all for unmodified 30 year old servers or otherwise. At most, the 30 year old mail server will not receive as much pgp encrypted email as it could, had it stopped the unwise deployment of FOO != foo for their local parts - which I believe is still many times smaller than the autocorrect on virtual keyboard problem on offline signed zones that is left unaddressed when a lowercase() call is left out of this document. >> It is only the least bad way if you make the assumption that I've only >> seen made by you. > > John is an expert on email and so the other experts on email don't need > to correct him ... When (implausibly) he says something which is not > correct then you will see other email experts (of which there are a few > on this list, but probably not all that many) will undoubtedly chip in I'll leave this item on how to contribute and reach consensus to the chairs, but thank you for your public contribution of agreeing with John. Paul From nobody Mon Jun 15 10:59: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 746FC1A0193 for ; Mon, 15 Jun 2015 10:59:56 -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 JdgeVc-bwZok for ; Mon, 15 Jun 2015 10:59:54 -0700 (PDT) Received: from mail-ob0-f178.google.com (mail-ob0-f178.google.com [209.85.214.178]) (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 CA2C01A00E0 for ; Mon, 15 Jun 2015 10:59:41 -0700 (PDT) Received: by obctg8 with SMTP id tg8so10121495obc.3 for ; Mon, 15 Jun 2015 10:59:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type:content-transfer-encoding; bh=WEMuf/ahRg+iBn+bpscexCXhLsmrnQnn+txbuMd0nZA=; b=aA9/DawJAYRSFEICR7IWGY2J1kWwUwApCHleJQsDYT0kU/RJLTWtDqzFEGKD164Bnd KDv+ZHPJtrjA6ZdmNF2x3hxl2buC452zN/fq9tYyrCXrHfQYFJujm07qtc2ytHSiBixD h+mOXPjr+Njk7Mwn/BCFnOe4q7h3mXVU32t2x7eASldodNkqHf6VFqXVcEHvMd3lFyRz xzbO52mCdvc3s0nMyeCIDulrrid0M7Ln1WhW84QGp08a0EE3CYdFVpuAn9AkwABUFRb2 v/MXrChTkw+SbtFyv+st7rdfg1Kox/uM0ElVlp6e/2gnGFVl7AxelS2FiKZyz38W/HX1 9Oyw== X-Gm-Message-State: ALoCoQnOEof1/5mYQ7Y0G0bHgSrI8fYOzmjT7nOWqn8uihr5J3EhkLBGIY3O6OZCQj0YLcmz08WS MIME-Version: 1.0 X-Received: by 10.182.186.106 with SMTP id fj10mr24452073obc.54.1434391181080; Mon, 15 Jun 2015 10:59:41 -0700 (PDT) Received: by 10.202.196.75 with HTTP; Mon, 15 Jun 2015 10:59:41 -0700 (PDT) In-Reply-To: <20150615095928.18576.6993.idtracker@ietfa.amsl.com> References: <20150615095928.18576.6993.idtracker@ietfa.amsl.com> Date: Mon, 15 Jun 2015 13:59:41 -0400 Message-ID: From: Warren Kumari To: "opsawg@ietf.org" , "dns-privacy@ietf.org" , "" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [dane] Fwd: Third and FINAL call for volunteers, Nomcom 2015-2016 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 15 Jun 2015 17:59:56 -0000 Please consider volunteering for the NomCom -- it is a very important position, and helps ensure that we select an IAB and IESG who will help make the IETF successful... W ---------- Forwarded message ---------- From: NomCom Chair 2015 Date: Mon, Jun 15, 2015 at 5:59 AM Subject: Third and FINAL call for volunteers, Nomcom 2015-2016 To: IETF Announcement List Cc: ietf@ietf.org ***Reminder: Deadline for volunteering for Nomcom is in ONE WEEK.*** The IETF nomcom appoints folks to fill the open slots on the IAOC, the IAB, and the IESG. Ten voting members for the nomcom are selected in a verifiably random way from a pool of volunteers. The more volunteers, the better chance we have of choosing a random yet representative cross section of the IETF population. The details of the operation of the nomcom can be found in RFC 7437, and BCP10/RFC3797 details the selection algorithm. Volunteers must have attended 3 of the past 5 IETF meetings. As specified in RFC 7437, that means three out of the five past meetings up to the time this email announcement goes out to start the solicitation of volunteers. The five meetings out of which you must have attended *three* are: IETF 88 (Vancouver), \ 89 (London), \ 90 (Toronto), *** ANY THREE! 91 (Honolulu), / 92 (Dallas) / If you qualify, please volunteer. However, much as we want this, before you decide to volunteer, please be sure you are willing to forgo appointmen= t to any of the positions for which this nomcom is responsible. As of today, we have 151 confirmed volunteers. 72 of those who ticked the box on the registration form for Hawaii, Dallas and Prague have still not responded. If you believe you have volunteered, and your name is NOT below, please contact me as soon as possible. Thank you for volunteering! The list of people and posts whose terms end with the March 2016 IETF meeting, and thus the positions for which this nomcom is responsible, are IAOC: No terms expire at this time. IAB: Mary Barnes Joe Hildebrand Ted Hardie Erik Nordmark Brian Trammell Marc Blanchet IESG: Alissa Cooper (ART) Barry Leiba (ART) Brian Haberman (Internet) Benoit Claise (Operations and Management) Alia Atlas (Routing) Kathleen Moriarty (Security) Martin Stiemerling (Transport) The Applications and Real-Time (ART) area is the expected new area resulting from the merge of the APP and RAI areas. All appointments are for 2 years. The ART and Routing areas have 3 ADs and the General area has 1; all other areas have 2 ADs. Thus, all areas have at least one continuing AD. The primary activity for this nomcom will begin in July 2015 and should be completed in January 2016. The nomcom will have regularly scheduled conference calls to ensure progress. (We might dogfood WebRTC) There will be activities to collect requirements from the community, review candidate questionnaires, review feedback from community members about candidates, and talk to candidates. Thus, being a nomcom member does require some time commitment; but it is al= so a very rewarding experience. It is very important that you be able to attend IETF94 (Yokohama) to conduct interviews. Being at IETF93 (Prague) is useful for orientation. Being at IETF95 is not essential. Please volunteer by sending me an email before 11:59 pm CET (UTC +2 hours) June 22, 2015, as follows: To: nomcom-chair-2015@ietf.org Subject: Nomcom 2015-16 Volunteer Please include the following information in the email body: Your Full Name: __________ // as you write it on the IETF registration form Current Primary Affiliation: // Typically what goes in the Company field // in the IETF Registration Form Emails: _______________ // All email addresses used to register for the past 5 IETF meetings // Preferred email address first Telephone: _______________________ // For confirmation if selected You should expect an email response from me within 3 business days stating whether or not you are qualified. If you don't receive this response, please re-send your email with the tag "RESEND"" added to the subject line. If you are not yet sure if you would like to volunteer, please consider that nomcom members play a very important role in shaping the leadership of the IETF. Questions by email or voice are welcome. Volunteering for the nomcom is a great way to contribute to the IETF! You will find a detailed timeline on the nomcom web site at: https://datatracker.ietf.org/nomcom/2015/ Thank you! Harald Alvestrand hta+nomcom@alvestrand.no nomcom-chair-2015@ietf.org =3D=3D=3D=3D=3D qualified volunteers so far, in alphabetical order by firs= t name Adam Montville Adrian Farrel ANDREW Dolganow Andrew Newton Andy Bierman ANM Zaheduzzaman Sarker Anoop Ghanwani Anthony Nadalin Ari Keranen Benno Overeinder Bernard Aboba Bhumip KHASNABISH Bing Liu Borje Ohlman Carl Moberg Carlos Martinez Cengiz Alaettinoglu Charles Eckel Charles Perkins Chris Bowers Christer Holmberg Christian Huitema Christian O'Flaherty Cong Liu Corinna Schmitt Cullen Jennings Damien Saucez Daniele Ceccarelli Dapeng Liu David Conrad David Lamparter David Mandelberg David Sinicrope Dean Bogdanovic Derek Atkins Dhruv Dhody Dimitri Papadimitriou Donald Eastlake 3rd Edward Lemon Eliot Lear Emil Ivov Eric Gray Eric Vyncke Fangwei Hu Fernando Gont Fred Baker George Michaelson George Swallow Georgios Karagiannis Gonzalo Salgueiro Gregory Mirsky Hannes Gredler Hongyu Li Huaimo Chen Ignas Bagdonas Jason Weil Jean-Marc Valin Jean-Michel Combes Jesus Maria Martin Garcia Joel Halpern John Bradley John Brzozowski John Drake John Mattsson John Scudder Jon Hudson Jon Mitchell jouni korhonen Karen O'Donoghue Keith Moore Kenneth Gray Kent Watsen Kepeng Li Keyur Patel Laurent Ciavaglia Lee Howard Liang Xia Linda Dunbar Lingli Deng Lixia Zhang Lucy Lynch Luigi Iannone Mach CHEN Magnus Westerlund Mahalingam Mani Mark Townsley Matthew Bocci Matthew Lepinski Mehmet Ersue Michael Jones Michael StJohns Min Ye nalini elkins Nancy Cam-Winget Nathan Egge Niel Harper Ning Kong Ning Zong Ole Jacobsen Ole Tr=C3=B8an Pascal Thubert Patrick McManus Paul Wouters Peng Fan Peter Koch Peter Yee P=C3=A5l-Erik Martinsen QIN WU Rich Salz Richard Barnes Robby Simpson Ron Bonica Ross Callon Salvatore Loreto Sam K. Aldrin Sanjay Mishra Scott Mansfield Sheng Jiang SHUCHENG LIU Simon Perreault Sri Gundavelli Stephan Wenger Stephen Kent Steve Donovan Steve Olshansky Steven Wright Suhas Nandakumar Suresh Krishnan Susan Hares Thomas Nadeau Thomas Walsh Tim Wicinski Timothy Terriberry Tina (Ting) Tsou (Zou) TIRUMALESWAR REDDY KONDA Tobias Gondrom Toerless Eckert Tomohiro Fujisaki Tony Hansen Uma Chunduri Vic Liu Vijay Gurbani Warren Kumari Wassim Haddad Wijnands IJsbrand Xufeng Liu Yi Zhao Yihong Huang Yizhou Li Yuanlong Jiang Zhaohui Zhang --=20 I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Thu Jun 18 10:22: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 0B14F1B2A49 for ; Thu, 18 Jun 2015 10:22:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.261 X-Spam-Level: X-Spam-Status: No, score=-1.261 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_DE=0.35, 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 TtVzLE1OtZV5 for ; Thu, 18 Jun 2015 10:22:24 -0700 (PDT) Received: from mail.sys4.de (mail.sys4.de [194.126.158.139]) (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 2E3981B2A2F for ; Thu, 18 Jun 2015 10:22:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sys4.de; h= in-reply-to:content-disposition:content-type:content-type :mime-version:references:message-id:subject:subject:from:from :date:date; s=mail201310; t=1434648141; x=1436462542; bh=5qCPyS2 ic/eIbhwr0ymxDEdoDoS41XaBeDRtMtJPwXA=; b=Oy3ou+x2Z0+0U3Am4GfmJ9F 9AkZgZmbDVwGhYgWuq0khSB43xeCC5or612xguKIICYA6g4HWVp0/fOCx6LJ37gD AI6evSrf2evELBafFavbO4OrHmCb3ClDWpZYDhWt5GxCLP0CzwbfrX+5EXT7Bbl3 icgICPvTfdZaPDX6sNBsxbKlh035PNlV5cr1X2yj8rHFF15RIfi8VWHHPkooU8TY AzKnVvKiKv/X/hhkaBHy1z0LFZcD/Pyvgwpki2DWBEFR0f7qqFFF9+OQPXlWikP+ 23BXH9RgaQ5dfreI7+dv2SbXT7cNRUSX2QUDeTfkY5+o7dgmqsO0G2gTDaqmqLw= = X-Virus-Scanned: Debian amavisd-new at mail.sys4.de Received: from sys4.de (mail.sys4.de [194.126.158.139]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sys4.de (Postfix) with ESMTPSA id 3mC97K32Ztz82; Thu, 18 Jun 2015 19:22:21 +0200 (CEST) Date: Thu, 18 Jun 2015 19:22:20 +0200 From: Florian Kirstein To: dane@ietf.org Message-ID: <20150618172220.GA3750@sys4.de> References: <20150614160848.25376.qmail@ary.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20150614160848.25376.qmail@ary.lan> Archived-At: Subject: Re: [dane] AD review of draft-ietf-dane-openpgpkey-03 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 18 Jun 2015 17:22:30 -0000 Hi guys, I've been silently following this whole process basically from the beginning and I (hope I) read all arguments and understood them. It's a difficult topic and most things can't be simply declared "right" or "wrong", so I understand why there still are so many disputing opinions. But there are (mainly) two points, where I think the discussion has taken a wrong path, focussing too much on SMTP and too little on PGP. First is the CaSe topic: yes, the RFCs are clear, a SMTP server is not allowed to make assumptions about the interpretation of case on the receiving end. But: we are not describing a SMTP server here. We are describing a standard for PGP key LOOKUPS. I've been using PGP for 20 years (in 2 months my oldest used key reaches that age, it's 1248 Bit so I might have to revoke it some day though :) and I have never encountered a case sensitive lookup. GPG for example (and thus mutt's integration of it for lookup) ignores case completely when looking up a key. Also all key servers I use ignore case when you search for a email address. Both don't even offer an option for case sensitive lookup. And I really don't see and never have experienced a problem with it. As discussed, technically it is possible to have mail servers which route different cased addresses really to different people, but even though it is RFC compliant to do so, in the real world it should be avoided - setups where it happend were changed, as it is just too error prone. It's a theoretical corner case. On the other hand, people typing emails in "wrong" casing are more the default than the exception. If we build a lookup mechanism that ignores that, we make the same mistake again that has been made so many times in the history of email encryption: ignore the people supposed to use it. If we want more encryption to happen, the lookup has to work in real life cases (no pun intended ;). And it has to work BETTER than the existing key servers, not worse. So: a strong PRO lowercasing before lookup (as it's already in the current draft) from my side. If there still are security concerns: It would be possible to add a text telling domain operators, who know they route different cased addresses to different mailboxes, not to implement this standard for obvious reasons %) Won't affect real life deployments anyway. The second point is the often discussed "fuzzy matching". As John pointed out perfectly correct (that's why I chose to follow-up here): > When a mail server handles a locally addressed piece of mail, it maps > the local-part of the address into some sort of internal identifier. > The local identifier for FOO might be FOO or foo but it's as likely to > be user1234. But that's again the SMTP side! When we look at PGP and the OpenPGP standards, we find the term "email address" as part of the User ID. You create PGP Keys for your email addresses, not for your mail accounts! It is not totally uncommon for people to have user@ and user+private@ to be delivered into the same mailbox, but have different PGP keys for it. On the other hand, if I really want people to encrypt mails to my user+usenet199703@ address, I should also publish my key with that ID included. The same goes for username@gmail and user.name@gmail. If both are used in your email conversations, add both as User IDs to your key. It's the only way the sender can know the key is intended to be used for that address. It's also the reason, that in the web of trust you don't sign keys as many people think. You sign the individual user IDs with a key. Coming back to the real world: I hardly see people use encryption on such "modified" addresses, and if they do, then intentionally and with a key for it. That's a topic outside the scope of this draft, the important part is that we don't block such usage - and we don't. It's easy to publish the same key under many labels. So again: no objection to the current draft, we should not encourage implementors to do fuzzy matching stuff, but we also don't have to plan for it on the server side. It's the decission of a user which User IDs he adds to his PGP key and for those it will be used. I have some more thoughts on other topics of the current discussion, but that would be too much for this already too long to read post ;) Greetings, Florian -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstrasse 15, 81669 Muenchen Sitz der Gesellschaft: Muenchen, Amtsgericht Muenchen: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein From nobody Thu Jun 18 14:37: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 2C8551A6EE4 for ; Thu, 18 Jun 2015 14:37:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.349 X-Spam-Level: * X-Spam-Status: No, score=1.349 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_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 fy2sjx6fxsj8 for ; Thu, 18 Jun 2015 14:37:29 -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 980D01A6EE2 for ; Thu, 18 Jun 2015 14:37:29 -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 3mCGnf3rBHzGp19; Thu, 18 Jun 2015 23:37:26 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=roessner-network-solutions.com; s=swioBi3opho; t=1434663446; i=@roessner-network-solutions.com; bh=UV76L5CMYaGGIIhgXsmnPdXTSOyXvURsnVzO4qGn2LI=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=NjjhNd7TncwT6MrmO2SUkZvAM82JmKVlHDFbF85zC4nnRnTdIsjpSCeFFhVb53m2Q YK+duC1Hm7KapxmMUWFreRmDaNxgW/uJndFcnUuE2jttdTJehSUrYy8nwIxmA9Cwyf FKQsiLDVNkzznJc8dsAWD/w6sYNyB6pkJcPXp7GBuiYsSpnvS/jqIu0fK5So1UkNDn jKgAhSSCucVpHCWaEo5iFIlc8JXokfyPPMqwMejXZuYnGzIQPSkzaeCqvgehJrNhMr f93s++QPXHcyOBisCSn/ak8LKeXaZ6bmHZ+lFSKiB4o2qRKGcgFctSbP+eVcd7XBhK 45I80GMVGMmzw== 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 3mCGnd5x3czMlTK; Thu, 18 Jun 2015 23:37:25 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_C1C3FBDF-23A9-48D0-9E44-60E4182FF706"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: =?utf-8?Q?Christian_R=C3=B6=C3=9Fner?= In-Reply-To: <20150618172220.GA3750@sys4.de> Date: Thu, 18 Jun 2015 23:37:24 +0200 Message-Id: <640125B6-DC2C-45E5-96DF-D56590888AC8@roessner-network-solutions.com> References: <20150614160848.25376.qmail@ary.lan> <20150618172220.GA3750@sys4.de> To: Florian Kirstein X-Mailer: Apple Mail (2.2102) Outgoingd: 0.4.0_m1 Archived-At: Cc: dane@ietf.org Subject: Re: [dane] AD review of draft-ietf-dane-openpgpkey-03 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 18 Jun 2015 21:37:32 -0000 --Apple-Mail=_C1C3FBDF-23A9-48D0-9E44-60E4182FF706 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > I've been silently following this whole process basically from the > beginning and I (hope I) read all arguments and understood them. It's > a difficult topic and most things can't be simply declared "right" or > "wrong", so I understand why there still are so many disputing > opinions. >=20 > But there are (mainly) two points, where I think the discussion has > taken a wrong path, focussing too much on SMTP and too little on > PGP. >=20 > First is the CaSe topic: yes, the RFCs are clear, a SMTP server is not > allowed to make assumptions about the interpretation of case on the > receiving end. But: we are not describing a SMTP server here. We are > describing a standard for PGP key LOOKUPS. I've been using PGP for 20 > years (in 2 months my oldest used key reaches that age, it's 1248 > Bit so I might have to revoke it some day though :) and I have never > encountered a case sensitive lookup. GPG for example (and thus mutt's > integration of it for lookup) ignores case completely when looking up > a key. Also all key servers I use ignore case when you search > for a email address. Both don't even offer an option for case = sensitive > lookup. >=20 > And I really don't see and never have experienced a problem with it. > As discussed, technically it is possible to have mail servers which > route different cased addresses really to different people, but > even though it is RFC compliant to do so, in the real world it should > be avoided - setups where it happend were changed, as it is just too > error prone. It's a theoretical corner case. >=20 > On the other hand, people typing emails in "wrong" casing are more the > default than the exception. If we build a lookup mechanism that = ignores > that, we make the same mistake again that has been made so many times > in the history of email encryption: ignore the people supposed to use = it. > If we want more encryption to happen, the lookup has to work in real = life > cases (no pun intended ;). And it has to work BETTER than the existing > key servers, not worse. >=20 > So: a strong PRO lowercasing before lookup (as it's already in the = current > draft) from my side. If there still are security concerns: It would be = possible > to add a text telling domain operators, who know they route different = cased > addresses to different mailboxes, not to implement this standard for > obvious reasons %) Won't affect real life deployments anyway.=20 >=20 > The second point is the often discussed "fuzzy matching". As John = pointed > out perfectly correct (that's why I chose to follow-up here): >> When a mail server handles a locally addressed piece of mail, it maps >> the local-part of the address into some sort of internal identifier. >> The local identifier for FOO might be FOO or foo but it's as likely = to >> be user1234. >=20 > But that's again the SMTP side! When we look at PGP and the OpenPGP > standards, we find the term "email address" as part of the User ID. > You create PGP Keys for your email addresses, not for your mail = accounts! >=20 > It is not totally uncommon for people to have user@ and user+private@ > to be delivered into the same mailbox, but have different PGP keys > for it. On the other hand, if I really want people to encrypt mails > to my user+usenet199703@ address, I should also publish my key with = that > ID included. The same goes for username@gmail and user.name@gmail. If = both > are used in your email conversations, add both as User IDs to your = key. > It's the only way the sender can know the key is intended to be used = for > that address. It's also the reason, that in the web of trust you > don't sign keys as many people think. You sign the individual user > IDs with a key. >=20 > Coming back to the real world: I hardly see people use encryption on > such "modified" addresses, and if they do, then intentionally and with > a key for it. That's a topic outside the scope of this draft, the > important part is that we don't block such usage - and we don't. It's > easy to publish the same key under many labels. >=20 > So again: no objection to the current draft, we should not encourage > implementors to do fuzzy matching stuff, but we also don't have to = plan > for it on the server side. It's the decission of a user which User IDs > he adds to his PGP key and for those it will be used.=20 >=20 > I have some more thoughts on other topics of the current discussion, = but > that would be too much for this already too long to read post ;) I can fully agree with every word that you said. Please see =E2=80=9Ereal=E2=80=9C-world and make a difference between = SMTP and PGP (or for me interesting: SMIMEA). PRO: lowercase Concerning different things like user@ or user+foo@, CNAME is an option = that works. I have done some tests on the SMIMEA thing and I use several = CNAMES for different email addresses that point to the same address and = therefor to the same RR. Sincerely Christian= --Apple-Mail=_C1C3FBDF-23A9-48D0-9E44-60E4182FF706 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 9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDYxODIxMzcyNVowIwYJKoZIhvcNAQkEMRYEFM1IoCO/ GBr0OoPrRlc3Tl2zC5hzMIH2BgkrBgEEAYI3EAQxgegwgeUwgd4xCzAJBgNVBAYTAkRFMRIwEAYK CZImiZPyLGQBGRYCZGUxHDAaBgoJkiaJk/IsZAEZFgxyb2Vzc25lci1uZXQxDzANBgNVBAgMBkhl c3NlbjEQMA4GA1UEBwwHQWxzZmVsZDEPMA0GA1UECgwGUi5OLlMuMR4wHAYDVQQLDBVDZXJ0aWZp Y2F0ZSBBdXRob3JpdHkxGDAWBgNVBAMMD1Jvb3RDQSAoYykgMjAxNDEvMC0GCSqGSIb3DQEJARYg Y0Byb2Vzc25lci1uZXR3b3JrLXNvbHV0aW9ucy5jb20CAhAFMIH4BgsqhkiG9w0BCRACCzGB6KCB 5TCB3jELMAkGA1UEBhMCREUxEjAQBgoJkiaJk/IsZAEZFgJkZTEcMBoGCgmSJomT8ixkARkWDHJv ZXNzbmVyLW5ldDEPMA0GA1UECAwGSGVzc2VuMRAwDgYDVQQHDAdBbHNmZWxkMQ8wDQYDVQQKDAZS Lk4uUy4xHjAcBgNVBAsMFUNlcnRpZmljYXRlIEF1dGhvcml0eTEYMBYGA1UEAwwPUm9vdENBIChj KSAyMDE0MS8wLQYJKoZIhvcNAQkBFiBjQHJvZXNzbmVyLW5ldHdvcmstc29sdXRpb25zLmNvbQIC EAUwDQYJKoZIhvcNAQEBBQAEggEAkCRqJbl2AnGpojI9+NQIKuabPK4gDKABGg1AMSTO1MfnYWz0 2UHbRKNdXRXVZTZM0eUr2d1sn8XKn7+Kg4hcTNQ+BGcp+K2W9hse3fE+eY5+dN3jh98LjF7QXKpv aIPyKZhUV3fr8lYiKM1lAACjn9RyHTGysc13KLW17Tw3UJJYH25bWCbzXXf90ZaWFsVBnE4fmARj CoTa1NcMXqZ0ITqNz6WkUrGBRQphKd3XVUoHcpmbHQ80u/Ln/IS3cWcUJFOqQEDajyzhO9iiEzUE Wlk8bsuqUTgYEoTrjyOMa6G8vIs/FEbRnvGLnueAO6+p53lxn/ZXAT4M2aZ7n/mqoQAAAAAAAA== --Apple-Mail=_C1C3FBDF-23A9-48D0-9E44-60E4182FF706-- From nobody Thu Jun 18 17:01: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 A58F71B2D80 for ; Thu, 18 Jun 2015 17:01:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.663 X-Spam-Level: * X-Spam-Status: No, score=1.663 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 0OxvPl0EBlGe for ; Thu, 18 Jun 2015 17:01:21 -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 A794D1A88DE for ; Thu, 18 Jun 2015 16:56:56 -0700 (PDT) Received: (qmail 69897 invoked from network); 18 Jun 2015 23:57:05 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 18 Jun 2015 23:57:05 -0000 Date: 18 Jun 2015 23:56:33 -0000 Message-ID: <20150618235633.80533.qmail@ary.lan> From: "John Levine" To: dane@ietf.org In-Reply-To: <640125B6-DC2C-45E5-96DF-D56590888AC8@roessner-network-solutions.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dane] AD review of draft-ietf-dane-openpgpkey-03 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 19 Jun 2015 00:01:22 -0000 >Concerning different things like user@ or user+foo@, CNAME is an option that works. You can certainly use CNAMEs for aliases, and they will work in tiny examples. Given that there are over 500,000 ways to spell my single unexceptional gmail address, which doesn't even have anything like +foo extensions, I would think that the scaling issues would be obvious. R's, John From nobody Thu Jun 18 17:23: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 AE5711B2DFB for ; Thu, 18 Jun 2015 17:23:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.961 X-Spam-Level: X-Spam-Status: No, score=-3.961 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, 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 Ju18CJkVjC_O for ; Thu, 18 Jun 2015 17:23:38 -0700 (PDT) Received: from mail.sys4.de (mail.sys4.de [194.126.158.139]) (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 505171B2DFA for ; Thu, 18 Jun 2015 17:23:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sys4.de; h= in-reply-to:content-disposition:content-type:content-type :mime-version:references:message-id:subject:subject:from:from :date:date; s=mail201310; t=1434673416; x=1436487817; bh=kezZKS4 EyCOBIMcCndk4dUhPOXW3cZsr4lAogWBloao=; b=qSVBfJWDBR7qbFFTjho4qac jvyt2it9W0987fxbPvPO6sDNzaNQfU4gpcJyPn7Sopjze85xvY/3p5Dg3akVZdrt b3xVnUpmakxCd8got7zKjLeZblPGg+0DCnqllF9rw0mVi3JPNa37sSHS/JNPA+Cr wPJbFD4Si63dKJSS7m8/LSvMZ0nu5UCeb0aVlSMSUlfACgi00bfmJt/7lRuhveHC AKXE684dN8mbaYcqIUP/cQoTRxX0uYDMeZcbQ8YVJ2FhnO+sx4ViRAX/TyavFl6Q L2L93BZSmJMcyFGt6Y9xZy0hmIcIcRGU2+cFFDasnrcBKZm4D8YjVcw0TsvBaaA= = X-Virus-Scanned: Debian amavisd-new at mail.sys4.de Received: from sys4.de (mail.sys4.de [194.126.158.139]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sys4.de (Postfix) with ESMTPSA id 3mCLTM6rTNzNf; Fri, 19 Jun 2015 02:23:35 +0200 (CEST) Date: Fri, 19 Jun 2015 02:23:34 +0200 From: Florian Kirstein To: dane@ietf.org Message-ID: <20150619002334.GB3750@sys4.de> References: <640125B6-DC2C-45E5-96DF-D56590888AC8@roessner-network-solutions.com> <20150618235633.80533.qmail@ary.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20150618235633.80533.qmail@ary.lan> Archived-At: Subject: Re: [dane] AD review of draft-ietf-dane-openpgpkey-03 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 19 Jun 2015 00:23:42 -0000 Hi, > Given that there are over 500,000 ways to spell my single > unexceptional gmail address, which doesn't even have anything like > +foo extensions, I would think that the scaling issues would be > obvious. Indeed - at least if you want to use all those variants for encrypted mail. But usually people don't make up which variant of your gmail address to use. You decide that by publishing it or mailing from it. And that's also how PGP works, that is what I tried to explain in my possibly too long mail. You decide which of your addresses to add as User ID to your public key. And those are the addresses people should use to send you encrypted mail. Therefore I see no need for the openpgpkey specification to deal with address variations. That does not prevent anybody from inventing a webfinger standard to canonicalize email addresses, which could be an additional, usefull service. But from a PGP key lookup mechanism I expect to get keys which have the email I am searching for as User ID. So if you really want to use 500.000 variations of your address, it's PGP that has the scaling problem. Try to sign such a key ;) Greetings, Florian -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstrasse 15, 81669 Muenchen Sitz der Gesellschaft: Muenchen, Amtsgericht Muenchen: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein From nobody Thu Jun 18 17:58:07 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 CA06E1B2E3F for ; Thu, 18 Jun 2015 17:58:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.663 X-Spam-Level: * X-Spam-Status: No, score=1.663 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 wzbb8oFD_jjM for ; Thu, 18 Jun 2015 17:58:06 -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 252781B2E3D for ; Thu, 18 Jun 2015 17:58:05 -0700 (PDT) Received: (qmail 75949 invoked from network); 19 Jun 2015 00:58:15 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 19 Jun 2015 00:58:15 -0000 Date: 19 Jun 2015 00:57:42 -0000 Message-ID: <20150619005742.80717.qmail@ary.lan> From: "John Levine" To: dane@ietf.org In-Reply-To: <20150619002334.GB3750@sys4.de> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dane] AD review of draft-ietf-dane-openpgpkey-03 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 19 Jun 2015 00:58:06 -0000 >Therefore I see no need for the openpgpkey specification to deal with >address variations. That does not prevent anybody from inventing a >webfinger standard to canonicalize email addresses, which could be an >additional, usefull service. Well, of course, if people use a webfinger service, it'll return the PGP key directly. for reasons that should be obvious. R's, John From nobody Fri Jun 19 00:04: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 C4B971A6F39 for ; Fri, 19 Jun 2015 00:04:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.651 X-Spam-Level: X-Spam-Status: No, score=-0.651 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 jkcjVp-Qzu5l for ; Fri, 19 Jun 2015 00:04:25 -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 829891A6F10 for ; Fri, 19 Jun 2015 00:04:25 -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 3mCWMq3p43zGp19; Fri, 19 Jun 2015 09:04:23 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=roessner-network-solutions.com; s=swioBi3opho; t=1434697463; i=@roessner-network-solutions.com; bh=bdaebH7Lz9WXJgiWVrFwYD4TY17rEvhJCHHwaDD0hdQ=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=G8e72N8kyYICoQ0+0UefZPG3jYBnteiPSttaPOgFPxaY+p5VqjwKzJC+jTuHNFer7 u/LNaksy1feZbPMJfRtzFGa2KrugM7Vw+S3Xrb+dZA1JuVDj7/uIsTAt0zOGnbUHJE IXxDGuvlNRq0zYiSHzYCVZtRMoYHutEcCHd3Qpd0X2VVhQQipgDtbBjLJk8Tcg3fJv abt54UDvDfPoA94PwHi9xTE/NNLpBNebZYErJe+D3mL8SVss63l6mluZmqvXpRdW0y o/P0fdBcj4e5H3aSq5mulq3iOqNBENZB7zl8f7EcOvIE0+fR9vhR6UooMACNm5A4MU SiP5O5pZjhF+w== Received: from vpn-6.localdomain (business-135-104.deltasurf.de [193.239.104.135]) (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 3mCWMq052xzMlTK; Fri, 19 Jun 2015 09:04:22 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_C895F0F6-D906-4A5B-B217-CB01144C5E39"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: =?utf-8?Q?Christian_R=C3=B6=C3=9Fner?= In-Reply-To: <20150618235633.80533.qmail@ary.lan> Date: Fri, 19 Jun 2015 09:04:20 +0200 Message-Id: References: <20150618235633.80533.qmail@ary.lan> To: John Levine X-Mailer: Apple Mail (2.2102) Outgoingd: 0.4.0_m1 Archived-At: Cc: dane@ietf.org Subject: Re: [dane] AD review of draft-ietf-dane-openpgpkey-03 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 19 Jun 2015 07:04:27 -0000 --Apple-Mail=_C895F0F6-D906-4A5B-B217-CB01144C5E39 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > Am 19.06.2015 um 01:56 schrieb John Levine : >=20 >> Concerning different things like user@ or user+foo@, CNAME is an = option that works. >=20 > You can certainly use CNAMEs for aliases, and they will work in tiny > examples. >=20 > Given that there are over 500,000 ways to spell my single > unexceptional gmail address, which doesn't even have anything like > +foo extensions, I would think that the scaling issues would be > obvious. My argument was not for case-sensitive emails. It was for: - different emails - local parts with or without extension All treated lowercase. Like real world I do not understand this discussion. RFCs for SMTP. ok. That is one = point. Just think about paper mail. Would you expect that a letter = arrives at your home, if people write you name in different ways? Yes of = course! :-) So why this theoretical discussion about things that nobody = on earth does use.=20 If I answer your mail here and I write joHnL@tough.CoM, do you expect it = to arrive or do you say this is somebody else? I bet you expect the mail = has to arrive in your mailbox and nowhere else. No matter what the RFCs = say. You expect this mail to land at your mailbox. So this is the reason why I say, local part for PGP and SMIMEA MUST be = lowercase looked up. :-) Christian N.B. sorry for my english. May sound harsh. Isn=E2=80=99t meant so.= --Apple-Mail=_C895F0F6-D906-4A5B-B217-CB01144C5E39 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 9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDYxOTA3MDQyMVowIwYJKoZIhvcNAQkEMRYEFKdHTpt2 2Kp9ggzlM8qwPHqEpX4BMIH2BgkrBgEEAYI3EAQxgegwgeUwgd4xCzAJBgNVBAYTAkRFMRIwEAYK CZImiZPyLGQBGRYCZGUxHDAaBgoJkiaJk/IsZAEZFgxyb2Vzc25lci1uZXQxDzANBgNVBAgMBkhl c3NlbjEQMA4GA1UEBwwHQWxzZmVsZDEPMA0GA1UECgwGUi5OLlMuMR4wHAYDVQQLDBVDZXJ0aWZp Y2F0ZSBBdXRob3JpdHkxGDAWBgNVBAMMD1Jvb3RDQSAoYykgMjAxNDEvMC0GCSqGSIb3DQEJARYg Y0Byb2Vzc25lci1uZXR3b3JrLXNvbHV0aW9ucy5jb20CAhAFMIH4BgsqhkiG9w0BCRACCzGB6KCB 5TCB3jELMAkGA1UEBhMCREUxEjAQBgoJkiaJk/IsZAEZFgJkZTEcMBoGCgmSJomT8ixkARkWDHJv ZXNzbmVyLW5ldDEPMA0GA1UECAwGSGVzc2VuMRAwDgYDVQQHDAdBbHNmZWxkMQ8wDQYDVQQKDAZS Lk4uUy4xHjAcBgNVBAsMFUNlcnRpZmljYXRlIEF1dGhvcml0eTEYMBYGA1UEAwwPUm9vdENBIChj KSAyMDE0MS8wLQYJKoZIhvcNAQkBFiBjQHJvZXNzbmVyLW5ldHdvcmstc29sdXRpb25zLmNvbQIC EAUwDQYJKoZIhvcNAQEBBQAEggEATvlm3+brLA2uiIALRL7cJwrylh4zGP8SJIc+cswHLn9cIBNz 9X3Vobb1qv1VY7RUXV5NZEY+k80oU7UKXDk9gzyuB5Om+qrktKvdVaBxEbWvSaIC30H2YeKZTkwt xhHElx3CHoc6XvNCmvmJ2xdlLZWGUxlE75zmnUJr5Dr6PqaM6bwsyUfocfPRx7wDN2/1NINbW1tg KRVb9blKLp6UkZ4zQNtOR4mdbOcwJqQkTRg3NosdSNsIRYEOAteq/Hym41YsdD5cXuqHg7S8xsm/ u2xs7XTG6AMDKoO8/bvdFOTGIfybXe2KkF02Zxzuba56dEQdY4sJA4ZeFxK5vCc2uAAAAAAAAA== --Apple-Mail=_C895F0F6-D906-4A5B-B217-CB01144C5E39-- From nobody Fri Jun 19 06:39: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 9A8961A010D for ; Fri, 19 Jun 2015 06:39:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.911 X-Spam-Level: X-Spam-Status: No, score=-3.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, 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 ERUyYEbMqkKc for ; Fri, 19 Jun 2015 06:39:53 -0700 (PDT) Received: from mx2.cira.ca (mx2.cira.ca [192.228.22.117]) by ietfa.amsl.com (Postfix) with ESMTP id 7A80B1A0108 for ; Fri, 19 Jun 2015 06:39:53 -0700 (PDT) X-Virus-Scanned: by SpamTitan at corp.cira.ca Received: from EXCH-01.CORP.CIRA.CA ([fe80::2073:dbc0:bb14:ab50]) by EXCH-02.CORP.CIRA.CA ([fe80::3c25:d5f2:72b8:e35c%17]) with mapi id 14.03.0224.002; Fri, 19 Jun 2015 09:39:52 -0400 From: Jacques Latour To: "dane@ietf.org" Thread-Topic: [dane] AD review of draft-ietf-dane-openpgpkey-03 Thread-Index: AQHQnj2mLdi0GMh0QEaGlhkkUBWCkp2kUVMAgALGnYCAAFRggIAARZMAgAAWiYCAA6uhgIAA8pOAgAAG/oCAAAULAIAADLQAgAZd3wCAAEdEAIAAJuGAgAB3hQCAACTvwA== Date: Fri, 19 Jun 2015 13:39:52 +0000 Message-ID: References: <20150618235633.80533.qmail@ary.lan> In-Reply-To: Accept-Language: en-US, en-CA Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.228.22.11] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [dane] AD review of draft-ietf-dane-openpgpkey-03 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 19 Jun 2015 13:39:57 -0000 KzEgJiBGbG9yaWFuIGhpdCB0aGUgbWFpbCwgdWgsIHRoZSBuYWlsIG9uIHRoZSBoZWFkIHdpdGgg cmVhbCB3b3JsZCB1c2UsIHdlIHNob3VsZCBzdGFydCB3aXRoIGEgJ3NpbXBsZScgUEdQL0ROUy9T TVRQIHNvbHV0aW9uIGFuZCBnbyBmcm9tIHRoZXJlLiAgSSBleHBlY3QgZW1haWxzIHdpdGggYWxs IGNhc2UgdmFyaWFuY2Ugb2YgSmFDcXVlcy5MYXRvdXJAY2lyQS5jYSB0byBsYW5kIGluIG15IG1h aWxib3gsIGFuZCBsb29rZWQgdXAgaW4gb3BlbnBncGtleSB3aXRoIGphY3F1ZXMubGF0b3VyQGNp cmEuY2ENCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBkYW5lIFttYWls dG86ZGFuZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQ2hyaXN0aWFuIFLDtsOfbmVy DQo+IFNlbnQ6IEp1bmUtMTktMTUgMzowNCBBTQ0KPiBUbzogSm9obiBMZXZpbmUNCj4gQ2M6IGRh bmVAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtkYW5lXSBBRCByZXZpZXcgb2YgZHJhZnQtaWV0 Zi1kYW5lLW9wZW5wZ3BrZXktMDMNCj4gDQo+IA0KPiA+IEFtIDE5LjA2LjIwMTUgdW0gMDE6NTYg c2NocmllYiBKb2huIExldmluZSA8am9obmxAdGF1Z2guY29tPjoNCj4gPg0KPiA+PiBDb25jZXJu aW5nIGRpZmZlcmVudCB0aGluZ3MgbGlrZSB1c2VyQCBvciB1c2VyK2Zvb0AsIENOQU1FIGlzIGFu IG9wdGlvbg0KPiB0aGF0IHdvcmtzLg0KPiA+DQo+ID4gWW91IGNhbiBjZXJ0YWlubHkgdXNlIENO QU1FcyBmb3IgYWxpYXNlcywgYW5kIHRoZXkgd2lsbCB3b3JrIGluIHRpbnkNCj4gPiBleGFtcGxl cy4NCj4gPg0KPiA+IEdpdmVuIHRoYXQgdGhlcmUgYXJlIG92ZXIgNTAwLDAwMCB3YXlzIHRvIHNw ZWxsIG15IHNpbmdsZQ0KPiA+IHVuZXhjZXB0aW9uYWwgZ21haWwgYWRkcmVzcywgd2hpY2ggZG9l c24ndCBldmVuIGhhdmUgYW55dGhpbmcgbGlrZQ0KPiA+ICtmb28gZXh0ZW5zaW9ucywgSSB3b3Vs ZCB0aGluayB0aGF0IHRoZSBzY2FsaW5nIGlzc3VlcyB3b3VsZCBiZQ0KPiA+IG9idmlvdXMuDQo+ IA0KPiBNeSBhcmd1bWVudCB3YXMgbm90IGZvciBjYXNlLXNlbnNpdGl2ZSBlbWFpbHMuIEl0IHdh cyBmb3I6DQo+IA0KPiAtIGRpZmZlcmVudCBlbWFpbHMNCj4gLSBsb2NhbCBwYXJ0cyB3aXRoIG9y IHdpdGhvdXQgZXh0ZW5zaW9uDQo+IA0KPiBBbGwgdHJlYXRlZCBsb3dlcmNhc2UuIExpa2UgcmVh bCB3b3JsZA0KPiANCj4gSSBkbyBub3QgdW5kZXJzdGFuZCB0aGlzIGRpc2N1c3Npb24uIFJGQ3Mg Zm9yIFNNVFAuIG9rLiBUaGF0IGlzIG9uZSBwb2ludC4gSnVzdA0KPiB0aGluayBhYm91dCBwYXBl ciBtYWlsLiBXb3VsZCB5b3UgZXhwZWN0IHRoYXQgYSBsZXR0ZXIgYXJyaXZlcyBhdCB5b3VyIGhv bWUsIGlmDQo+IHBlb3BsZSB3cml0ZSB5b3UgbmFtZSBpbiBkaWZmZXJlbnQgd2F5cz8gWWVzIG9m IGNvdXJzZSEgOi0pIFNvIHdoeSB0aGlzDQo+IHRoZW9yZXRpY2FsIGRpc2N1c3Npb24gYWJvdXQg dGhpbmdzIHRoYXQgbm9ib2R5IG9uIGVhcnRoIGRvZXMgdXNlLg0KPiANCj4gSWYgSSBhbnN3ZXIg eW91ciBtYWlsIGhlcmUgYW5kIEkgd3JpdGUgam9IbkxAdG91Z2guQ29NLCBkbyB5b3UgZXhwZWN0 IGl0IHRvDQo+IGFycml2ZSBvciBkbyB5b3Ugc2F5IHRoaXMgaXMgc29tZWJvZHkgZWxzZT8gSSBi ZXQgeW91IGV4cGVjdCB0aGUgbWFpbCBoYXMgdG8NCj4gYXJyaXZlIGluIHlvdXIgbWFpbGJveCBh bmQgbm93aGVyZSBlbHNlLiBObyBtYXR0ZXIgd2hhdCB0aGUgUkZDcyBzYXkuIFlvdQ0KPiBleHBl Y3QgdGhpcyBtYWlsIHRvIGxhbmQgYXQgeW91ciBtYWlsYm94Lg0KPiANCj4gU28gdGhpcyBpcyB0 aGUgcmVhc29uIHdoeSBJIHNheSwgbG9jYWwgcGFydCBmb3IgUEdQIGFuZCBTTUlNRUEgTVVTVCBi ZQ0KPiBsb3dlcmNhc2UgbG9va2VkIHVwLg0KPiANCj4gOi0pDQo+IA0KPiBDaHJpc3RpYW4NCj4g DQo+IE4uQi4gc29ycnkgZm9yIG15IGVuZ2xpc2guIE1heSBzb3VuZCBoYXJzaC4gSXNu4oCZdCBt ZWFudCBzby4NCg== From nobody Fri Jun 19 15:56: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 4DA851A8780 for ; Fri, 19 Jun 2015 15:56:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5234slCr6ee7 for ; Fri, 19 Jun 2015 15:56:29 -0700 (PDT) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (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 917B71A7D83 for ; Fri, 19 Jun 2015 15:56:29 -0700 (PDT) Received: by qkeo142 with SMTP id o142so51130490qke.1 for ; Fri, 19 Jun 2015 15:56:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=I52kxIFPkM8IVg3mZndkSd+zCT2xA2gTUN0H/g7uNFg=; b=KoWgPIKxBXYiyco5Lco0a+lyGQOjU4w/6YHgn2TU3AiLTTWtnQoWhzaxHl3vzIREdg pdP31qW0/RfrSmpNV2UHy05IEAzvsrX69297/JWds4s3Bf2phn3jpExRt93mz380aW+L vC0enfsBl9KsAVpByb3J8MEHYRmnVBfx23HB1WQ7BzgpntqzoEzxy7On5IlIB4OX3vpW VzgHLpiG1lxZSpSthcmXRXBMuGoj0j0mrsylYkVApfSSnq+B/m57J/iQHCs0Eq58a6jL RuFNK8IKlwCZjHKeAt0H7AI+ubrACVyNbWj8m/JyzgLatDMIbFl0HfOnq81nx1or5vQY y5DQ== MIME-Version: 1.0 X-Received: by 10.140.46.75 with SMTP id j69mr24255081qga.17.1434754588854; Fri, 19 Jun 2015 15:56:28 -0700 (PDT) Received: by 10.140.80.208 with HTTP; Fri, 19 Jun 2015 15:56:28 -0700 (PDT) In-Reply-To: References: Date: Fri, 19 Jun 2015 18:56:28 -0400 Message-ID: From: Shumon Huque To: Olafur Gudmundsson Content-Type: multipart/alternative; boundary=001a113a68049bcea80518e6d53e Archived-At: Cc: dane WG list Subject: Re: [dane] dane-smtp and Dane future X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: shuque@gmail.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2015 22:56:31 -0000 --001a113a68049bcea80518e6d53e Content-Type: text/plain; charset=UTF-8 On Mon, Jun 1, 2015 at 9:54 PM, Olafur Gudmundsson wrote: > > We are reaching the point that the core DANE protocol work is complete. > At this point the WG has a choice as to what direction to take > a) Finish work on OPENPGP and S/MIME documents and close down > b) Start work on DANE-bis document(s) that combines the Protocol parts of > the 4 documents that define the DANE protocol. > c) Just work on promoting existing RFC along the standards track > d) Identify and adopt other documents that are needed for DANE > adoptions/operations/specifications > > Please provide guidance to chairs > Olafur & Warren > > I've written a draft to describe the use of DANE TLSA records for client certificate authentication. It needs a bit of fine tuning but I hope to put it out shortly. I know of several parties interested in using DANE with client certificates. If the working group is amenable, I would like to request time for discussion at IETF93. [Viktor Dukhovni mentioned previously that he was contemplating this also, and he and I have been subsequently discussing some of the subtle aspects of this topic.] Shumon Huque --001a113a68049bcea80518e6d53e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Jun 1, 2015 at 9:54 PM, Olafur Gudmundsson <ogud@ogud.com> w= rote:

We are reaching the point that the core DANE prot= ocol work is complete.=C2=A0
At this point the WG has a choice as= to what direction to take
a) Finish work on OPENPGP and S/MIME d= ocuments and close down
b) Start work on DANE-bis document(s) tha= t combines the Protocol parts of the 4 documents that define the DANE proto= col.=C2=A0
c) Just work on promoting existing RFC along the stand= ards track
d) Identify and adopt other documents that are needed = for DANE adoptions/operations/specifications=C2=A0

Please provide guidance to chairs=C2=A0
Olafur & Warren=C2= =A0


I'= ve written a draft to describe the use of DANE TLSA records for client cert= ificate authentication. It needs a bit of fine tuning but I hope to put it = out shortly. I know of several parties interested in using DANE with client= certificates. If the working group is amenable, I would like to request ti= me for discussion at IETF93.

[Viktor Dukhovni ment= ioned previously that he was contemplating this also, and he and I have bee= n subsequently discussing some of the subtle aspects of this topic.]
<= div>
Shumon Huque

--001a113a68049bcea80518e6d53e-- From nobody Sun Jun 21 13:36: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 C01F01B2B5C for ; Sun, 21 Jun 2015 13:36:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.248 X-Spam-Level: ** X-Spam-Status: No, score=2.248 tagged_above=-999 required=5 tests=[BAYES_80=2, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_DE=0.35, SPF_HELO_PASS=-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 uVgLYDdTP0u2 for ; Sun, 21 Jun 2015 13:36:01 -0700 (PDT) Received: from mail.somaf.de (mail.somaf.de [IPv6:2001:a60:f0b4:e503:2cdb:beff:feaa:880b]) (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 664BE1A916F for ; Sun, 21 Jun 2015 13:36:00 -0700 (PDT) Received: from andreasschulze.de (andreasschulze.de [IPv6:2001:a60:f0b4:e503:d86e:8dce:a73e:2fec]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: sca@andreasschulze.de) by mail.somaf.de (Postfix) with ESMTPSA id 3mF5HB4nylzDr2 for ; Sun, 21 Jun 2015 22:35:50 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=andreasschulze.de; s=J4bWGJQcBmxMQ; t=1434918951; bh=5EFUtcWY1GJ0zr6+eUJaNmlrivXdmt9MlCtkrdV7LXQ=; h=Date:From:To:Subject:References:In-Reply-To; b=fH6xY6vLhu9ContO/NBYAaci7EMiuxgvXqeqxza4CitHglr1AbhcSSM5PoNNjcmIW sRKrpi8pz6A0ZkTFLkstANU3EbFvebaPJA6BvwxctAuhJBHeDmGCL9w0KZoAn1YQ6z QmJiMFB7hGsHUpRSDuV1vbCuZypBN5WCkQlYVwHH47G815avcYRP8LXfdA16EIqNRR OOC6HrRVCs8A1u7GxfvQbdiNqkUfyBltp5G5Wannlgjs/Ep1IvAsNgeRLWX4mMEHo0 JoL6XtgjiavkBSnv1jokRfaqrU5KjrjxezkSYQfPbtm4iFLZ1Nj18jiYhTgQdyBTua PJZBP3RYx0sbfGZGHyZZNN+1V4EnTI0iBqR7Zr7zfDuU8tTcdBqPwY6s1NJb4uAvOj CV/PF5dCI1P/qzb+QjcgPr2FfZkuIMwiBDDgKnJC2AwPZ2pNJDsRohO3G1KjewTodZ eg8Lu9AE7R60Le0u/7HDyPmVBNIbg1d6hd7N4ZfaQDHQWfN6yGsIfDWHeHD3youqIE lMKa/LWw5Xlz6yhVR+8n8WyA2IAIahkhzuG1HpaVyVnKE9fJiWGAldhlg52ZQ3cGKl qkF5kQlnjhlTtq158YJIVNtPGFKHNlxH8ZisEs9TJLd+VHyJDbsRrCsPqSy+KTql5B kMy2/lljDmYSdDveMThLVENI= Received: from dimos.somaf.de (dimos.somaf.de [2001:a60:f0b4:e502::152]) by andreasschulze.de (Horde Framework) with HTTP; Sun, 21 Jun 2015 22:35:48 +0200 Date: Sun, 21 Jun 2015 22:35:48 +0200 Message-ID: <20150621223548.Horde.QMQrKms_nN6MLgI5jarhuSk@andreasschulze.de> From: "A. Schulze" To: dane@ietf.org References: <20150618235633.80533.qmail@ary.lan> In-Reply-To: User-Agent: Horde Application Framework 5 Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline Archived-At: Subject: Re: [dane] AD review of draft-ietf-dane-openpgpkey-03 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 21 Jun 2015 20:36:02 -0000 Jacques Latour: > I expect emails with all case variance of JaCques.Latour@cirA.ca to > land in my mailbox, > and looked up in openpgpkey with jacques.latour@cira.ca Jacques, That's the point: you EXPECT that. But John has the idea that this could fail. I don't know all the details about UTF8SMTP or EAI, but I could imagine we see the world in ASCII. Most of us have no daily expieriences with chinese or arabian. And at least I could not deny *THERE* Lee@chinese may be an other Mailbox then lEE@chinese because of some strange encoding that may exist. Andreas From nobody Mon Jun 22 06:41:25 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 400461A8FD5 for ; Mon, 22 Jun 2015 06:41:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.69 X-Spam-Level: X-Spam-Status: No, score=0.69 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 ZP-Le_Cq8pd9 for ; Mon, 22 Jun 2015 06:41:21 -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 9094F1A8F4C for ; Mon, 22 Jun 2015 06:41:17 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3mFX2M43W6z56D; Mon, 22 Jun 2015 15:41:15 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=DXopu67m 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 M3y3AztMHJZ2; Mon, 22 Jun 2015 15:41:14 +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, 22 Jun 2015 15:41:14 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 394C9800B6; Mon, 22 Jun 2015 09:41:13 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1434980473; bh=p9YJEWZQ2qas06gzTHlNmksQ9vFnuI7T6nlRuCq5giw=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=DXopu67mFX7akEgB/eqwqHi90fBKq5gvpttwedTcwiRv5QTAh5uCUPKrCDBKFXhrB ti4iEPWiwg60kuOFX+dZ4VAHfsLMuNYwE3QF6ldkFwa5vuoWM/Q7YXjTxZ3eN2nTBq JpQKe8ulTBFY2R2B2xAtO8CeqSmZOS+2xNagkguk= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.15.1/8.15.1/Submit) with ESMTP id t5MDfCV5023408; Mon, 22 Jun 2015 09:41:12 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Mon, 22 Jun 2015 09:41:12 -0400 (EDT) From: Paul Wouters To: "A. Schulze" In-Reply-To: <20150621223548.Horde.QMQrKms_nN6MLgI5jarhuSk@andreasschulze.de> Message-ID: References: <20150618235633.80533.qmail@ary.lan> <20150621223548.Horde.QMQrKms_nN6MLgI5jarhuSk@andreasschulze.de> User-Agent: Alpine 2.11 (LFD 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] AD review of draft-ietf-dane-openpgpkey-03 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 22 Jun 2015 13:41:23 -0000 On Sun, 21 Jun 2015, A. Schulze wrote: > That's the point: you EXPECT that. But John has the idea that this could > fail. > I don't know all the details about UTF8SMTP or EAI, but I could imagine we > see the world in ASCII. > Most of us have no daily expieriences with chinese or arabian. > And at least I could not deny *THERE* Lee@chinese may be an other Mailbox > then lEE@chinese > because of some strange encoding that may exist. John brought up three issues. 1) Lowwercase might fail for non-ascii 2) mailbox localpart guessing not allowed 3) mailbox/local part of different case might be different person His proposal of not doing a lowercase() completely ignores the problem of casing for ascii (and perhaps I have asked for confirmation that 3) exists and received no real life example. 1) could be further narrowed down to those languages where this is only a problem for. But there is not much point to address that if we cannot do 2) for dogmatic reasons. So again, I propose one of: 1) Do the lowercase() in the lookup and figure out non-ascii case 2) Don't do the lowercase() in the lookup and allow the client to do the request without lowercase() first, then try again with lowercase() if not found - if possible in the language/encoding used. If these are not accpetable, we're back at using a hash instead of base32 split and it won't solve the "guessing" issue which the clients will have to do. Paul From nobody Mon Jun 22 11:04: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 882BE1A00C8 for ; Mon, 22 Jun 2015 11:04:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.689 X-Spam-Level: X-Spam-Status: No, score=0.689 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 7JmaVKLOE0SU for ; Mon, 22 Jun 2015 11:04:50 -0700 (PDT) Received: from ore.jhcloos.com (ore.jhcloos.com [198.147.22.87]) (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 9080D1A00C7 for ; Mon, 22 Jun 2015 11:04:50 -0700 (PDT) Received: by ore.jhcloos.com (Postfix, from userid 10) id 38DF21E76D; Mon, 22 Jun 2015 18:04:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore14; t=1434996290; bh=ivajpninE3tTpOUlDFAy2fbdutI/oXwjCRGQvn8hDiA=; h=From:To:Subject:In-Reply-To:References:Date:From; b=GYNb5RLWX8BwHmNsHcUbTgLwNmQZXFU/uhk1RSbsAWvJ4avlfn5PcSsJmZt/nJISR Knhlv67FnOxJSbt4jFOzaf5Qy4NYhq3sMQGiLBPcnmqqWbxTGL6iXTdVr2ia1bCdHs 435sP9XLtFHcIG93yr3QhoxK2BJnt4xfYC0EThlI= Received: by carbon.jhcloos.org (Postfix, from userid 500) id 386ED106FD888; Mon, 22 Jun 2015 18:04:21 +0000 (UTC) From: James Cloos To: dane@ietf.org In-Reply-To: (Paul Wouters's message of "Mon, 22 Jun 2015 09:41:12 -0400 (EDT)") References: <20150618235633.80533.qmail@ary.lan> <20150621223548.Horde.QMQrKms_nN6MLgI5jarhuSk@andreasschulze.de> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) 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: Mon, 22 Jun 2015 14:04:21 -0400 Message-ID: Lines: 35 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Hashcash: 1:28:150622:dane@ietf.org::l9Bmj1BUBxW5/JBM:0009vQHU Archived-At: Subject: Re: [dane] AD review of draft-ietf-dane-openpgpkey-03 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 22 Jun 2015 18:04:56 -0000 >>>>> "PW" == Paul Wouters writes: PW> John brought up three issues. PW> 1) Lowwercase might fail for non-ascii 2) mailbox localpart guessing PW> not allowed PW> 3) mailbox/local part of different case might be different person But as was mentioned OpenPGP is relevant, not SMTP. And given that the most common OpenPGP and keyserver – and probably all – implementations are already caseless there is nothing wrong with following their lead. This isn't just about email. A large percentage of the sigs I verify are obtained though methods unrelated to smtp. Detatched sigs are quite common, and OpenPGP is or can be used when sending short messages, such as via xmpp, sip or even ss7. Using dnssec as an additional – or in many cases the only – trust path when verifying a sig can only improve things. It is not a perfect trust path of course, but it is better than nothing. Given all of that, taking (base32 (utf8 (lc (localpart address)))) and splitting it by – working with presentation format — putting a . every N chars from the right seems like the ideal plan. Unless reversibility is undesirable. I've written otherwise in the past, but only because I forgot that the OpenPGP world is caseless. And I did so because I only ever use and only remember seeing miniscule addresses when dealing with OpenPGP. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 From nobody Mon Jun 22 11:52: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 889321A1BF4; Mon, 22 Jun 2015 11:52:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 apZdMKA7pXru; Mon, 22 Jun 2015 11:52:41 -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 AFC8D1A1BE4; Mon, 22 Jun 2015 11:52:41 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 0F90D282FB9; Mon, 22 Jun 2015 18:52:40 +0000 (UTC) Date: Mon, 22 Jun 2015 18:52:40 +0000 From: Viktor Dukhovni To: Elwyn Davies Message-ID: <20150622185239.GU14121@mournblade.imrryr.org> References: <558851A5.20803@dial.pipex.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <558851A5.20803@dial.pipex.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: draft-ietf-dane-ops.all@tools.ietf.org, General area reviewing team , saag@ietf.org, dane@ietf.org Subject: Re: [dane] Gen-art LC review of draft-ietf-dane-ops-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: Mon, 22 Jun 2015 18:52:43 -0000 On Mon, Jun 22, 2015 at 07:19:17PM +0100, Elwyn Davies wrote: > Summary: Almost ready. There are a couple of minor issues, and I think > the authors need to reassess whether all the cases where RFC 2119 keyworrds > are actually protocol requirements as opposed to operation best practice > recommendations. Thanks, will double-check the SHOULDS/MUSTS/... > s3: I am not a security expert, but I suspect you may get some pushback on > not making TLS 1.2 mandatory. We'll see what happens. The most widely deployed use of DANE is with opportunistic TLS in SMTP, and requiring TLS 1.2 seems like an unnecessary restriction for an opportunistic protocol. However, non-support of TLS 1.2 is getting increasingly less common, so if push comes to shove, we can "require" TLS 1.2. Of course with no Internet Police to enforce this, the requirement will likely make little difference in practice. > > TLS clients and servers using DANE SHOULD support the > > "Server Name Indication" (SNI) extension of TLS. > > Under what circumstances would it be reasonable for a DANE/TLSA server not > to support SNI? Maybe I could see that a single domain server could do > without it. That's the primary use case, a server with a single certificate, and a "3 1 1" TLSA record has no need to support SNI. It can just respond with the same default certificate, regardless of the SNI extension value sent by the client. > I think this needs to be spelt out - earlier text seems to > indicate that SNI support was pretty much mandatory.... Ah! Later I see that > s5.1 gives a case where SNI is not mandatory - a forward pointer would help. Thanks, will try to make the text more consistent throughout. > s4.1: I am not clear that this section adds any value to the discussion in > s4. Why should the protocol designer be less inclined to use PKIX-xx rather > than DANE-xx when the protocol supports an OS mode as opposed to just fully > authenticated or fully authenticated plus cleartext modes? The basic principle is based on RFC7435. The issue is that PKIX is more brittle, the client and server must happen to agree on a mutually trusted CA, but with OS the client is just trying to protect the communication at the request of the server, and would otherwise be willing to use cleartext or unauthenticated TLS. Use of fragile mechanisms (like public CA authentication for some unspecified set of trusted CAs) is not sufficiently reliable. Since the OS client is basing the decision to employ DANE on the presence of TLSA RRs in DNS, no additional security is gained via the PKIX usages unless they are the only ones supported by the application protocol (the attacker who compromises DNS can just inject "3 1 1" records instead). So DANE-xx is more reliable at no security loss. Thus PKIX-xx is just a needless opportunity to fail that should be avoided. > Nits/editorial comments: > ===================== Will review those... thanks. > s17.2: I can't decide whether I would like RFC6781 to be normative. It would > of course be a downref. This is always going to be a problem since the > draft is combining operational considerations and protocol updates. The > one explicit reference indicates you have to know something about how to run > DNSSEC to run DANE - in practice I think you have to know a great deal about > how to run DNSSEC if you are going to run DANE so I would be inclined to > make this normative (and maybe refer to it in the introduction as well). Not sure what if anything to do about that. -- Viktor. From nobody Mon Jun 22 13:14: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 A02AC1ACF55 for ; Mon, 22 Jun 2015 13:14:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, MALFORMED_FREEMAIL=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 6vlBjAgBHX_Y for ; Mon, 22 Jun 2015 13:14:56 -0700 (PDT) Received: from mr11p24im-asmtp001.me.com (mr11p24im-asmtp001.me.com [17.110.78.41]) (using TLSv1.2 with cipher DHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B02CE1ACF1B for ; Mon, 22 Jun 2015 13:14:56 -0700 (PDT) Received: from [17.153.69.164] (unknown [17.153.69.164]) by mr11p24im-asmtp001.me.com (Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Mar 31 2015)) with ESMTPSA id <0NQD0037348SO150@mr11p24im-asmtp001.me.com> for dane@ietf.org; Mon, 22 Jun 2015 20:14:54 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151,1.0.33,0.0.0000 definitions=2015-06-22_04:2015-06-22,2015-06-22,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=1 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1412110000 definitions=main-1506220342 From: William Stouder-Studenmund Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable Message-id: <3A3B61AF-CA47-416E-A5D6-05118334B9D9@mac.com> Date: Mon, 22 Jun 2015 13:14:52 -0700 To: dane@ietf.org MIME-version: 1.0 (Mac OS X Mail 8.2 \(2100\)) X-Mailer: Apple Mail (2.2100) Archived-At: Subject: [dane] Remote DNS management automation? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 22 Jun 2015 20:14:57 -0000 I know I=E2=80=99m about to ask a question which is out of the WG scope, = but 1) I expect folks here will be able to point me to the right = answers, and 2) the question hits on an issue that I perceive is = hindering DANE deployment. What automation is out there for remotely managing DNS records when the = domain owner is using a registrar? I=E2=80=99m very excited by this = (DANE) group=E2=80=99s work, but if I=E2=80=99m using a registrar, TLSA = records only matter when they get to the registrar correctly. I know TSIG can update records. Are most registrars using it? Also, how = does one add or delete records? Thanks! Take care, Bill= From nobody Mon Jun 22 14:58:40 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 AF9201AD374 for ; Mon, 22 Jun 2015 14:58:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.663 X-Spam-Level: * X-Spam-Status: No, score=1.663 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 vO9Ws9Ga7dse for ; Mon, 22 Jun 2015 14:58:39 -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 100641AD35E for ; Mon, 22 Jun 2015 14:58:38 -0700 (PDT) Received: (qmail 78330 invoked from network); 22 Jun 2015 21:58:49 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 22 Jun 2015 21:58:49 -0000 Date: 22 Jun 2015 21:58:15 -0000 Message-ID: <20150622215815.88519.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] AD review of draft-ietf-dane-openpgpkey-03 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 22 Jun 2015 21:58:39 -0000 >John brought up three issues. > >1) Lowwercase might fail for non-ascii >2) mailbox localpart guessing not allowed >3) mailbox/local part of different case might be different person This sort of misrepresentation of what other people have said is extremely unhelpful. Anyone interested in understanding the issues and dealing with them can easily find out about them from the list archives. R's, John From nobody Mon Jun 22 15:02: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 1BD371AD481 for ; Mon, 22 Jun 2015 15:02:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.663 X-Spam-Level: * X-Spam-Status: No, score=1.663 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 TArNHlduz28P for ; Mon, 22 Jun 2015 15:02:37 -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 46B651AD2C0 for ; Mon, 22 Jun 2015 15:02:37 -0700 (PDT) Received: (qmail 78668 invoked from network); 22 Jun 2015 22:02:47 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 22 Jun 2015 22:02:47 -0000 Date: 22 Jun 2015 22:02:14 -0000 Message-ID: <20150622220214.88561.qmail@ary.lan> From: "John Levine" To: dane@ietf.org In-Reply-To: <3A3B61AF-CA47-416E-A5D6-05118334B9D9@mac.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dane] Remote DNS management automation? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 22 Jun 2015 22:02:38 -0000 >What automation is out there for remotely managing DNS records when the domain owner is >using a registrar? It completely depends on the registrar and the registry. Some provide DNS service, some don't. Some provide a complete API for managing services, some only provide a web site, some still need to do some updates (DS records notably) by manual support tickets. For the large fraction of domains that use a DNS service other than the one at the registrar, it also completely depends on who's providing the DNS. R's, John From nobody Mon Jun 22 22:52: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 67D001A877F for ; Mon, 22 Jun 2015 22:52:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.14 X-Spam-Level: * X-Spam-Status: No, score=1.14 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, 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 AiKsmivMIE3D for ; Mon, 22 Jun 2015 22:52:23 -0700 (PDT) Received: from smtp3.strotmann.de (smtp3.strotmann.de [46.38.233.133]) (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 450311A8759 for ; Mon, 22 Jun 2015 22:52:22 -0700 (PDT) Received: from debian01.home.strotmann.de (unknown [IPv6:2a01:198:2b6:1000:240:caff:fea0:83b3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp3.strotmann.de (Postfix) with ESMTPS id BEE877FD61 for ; Tue, 23 Jun 2015 07:52:19 +0200 (CEST) Received: from MacMini3.local (unknown [IPv6:2a01:198:2b6:0:a889:c5ae:cab2:ff6]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by debian01.home.strotmann.de (Postfix) with ESMTPSA id DDCFC20008D for ; Tue, 23 Jun 2015 07:52:18 +0200 (CEST) Message-ID: <5588F40D.3040809@strotmann.de> Date: Tue, 23 Jun 2015 07:52:13 +0200 From: Carsten Strotmann User-Agent: Postbox 4.0.1 (Macintosh/20150514) MIME-Version: 1.0 To: dane@ietf.org References: <20150615153024.30223.qmail@ary.lan> In-Reply-To: <20150615153024.30223.qmail@ary.lan> X-Enigmail-Version: 1.2.3 OpenPGP: id=F7465F6A; url=keys.gnupg.net Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030507040705060209030705" Archived-At: Subject: Re: [dane] AD review of draft-ietf-dane-openpgpkey-03 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 23 Jun 2015 05:52:25 -0000 This is a cryptographically signed message in MIME format. --------------ms030507040705060209030705 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, John Levine wrote: > It is painfully > evident that few people in this discussion have any experience with > mail systems other than their own, and none with large (millions of > mailboxes), and generalizing from limited experience is never a good > idea. I see interest in the email hosting market to implement the openpgpkey draft. I know of email service provider that already have deployed the openpgpkey draft, and others are prepared to go online once the draft is stable or published as an RFC. Adoption in the market is important, and for these providers with experience with a large number of mailboxes, the draft seems to be "good enough". The openpgpkey draft, as it is now, is a better way to retrieve PGP keys than we had before (keyserver, LDAP, http-server). It would be painful to see the adoption of openpgpkey to slow down or die because of the draft being stuck in discussion. I'm in favor of advancing the current draft to RFC status (experimental if needed), gain operational experience with deployments, and come back for improvements if required. Carsten Strotmann --------------ms030507040705060209030705 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGfzCC BnswggRjoAMCAQICAxBwIDANBgkqhkiG9w0BAQsFADB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xNTAz MjcxMDA2MDJaFw0xNTA5MjMxMDA2MDJaMD8xGDAWBgNVBAMTD0NBY2VydCBXb1QgVXNlcjEj MCEGCSqGSIb3DQEJARYUY2Fyc3RlbkBzdHJvdG1hbm4uZGUwggIiMA0GCSqGSIb3DQEBAQUA A4ICDwAwggIKAoICAQClk0pULQ8GSo1lOVvTDSMpw6yNdknHBZF9H//Ex2HBdldmy1OdY22r xIAYdz5KBzDg3r1v3bVuQvDDxowFvYugWgYav7yrJ0T/y8ftJlm7PnZHt7l/kLbLEmxxXdsl fkUzQkPFeUSKXQt6ZHpCFsIw7twvrD7It1SLccEOKinWD9hfnBO19mg3cTdAsQdIGT3Cq5yI tskXH75I+GxpMQxoGiwbfs5P1m1+ujgBjwlRSXgnDjDSYLkqkPI6nnjMfv/cpJpm4gqf1Gcj V3Gdd9aQED0w60DGZ1ZBD46jxtIRJl2ozVdd/CYfBNVDNwBo57Ag3oPzlqvGbpGlBiTiciLH gaw7cKMk72FdsGX3AnzFh9I16ZcmzD3a6cwsHYLDW+lKewTyu6LgyNceAUd7JiB8UA2wF8j7 HoupLfSxFu3toq+OdpR6eSanI05suMrZpNPQGDpALRpCpcSPK3rFVg/SXBj1uvOCepFNYBSu IRsG/6zrUXG0Jmcz05TMF9GCqtDuVmkICwbnMniri7OKB+rbuj0hrh8oo3WdY3sxYli21ch7 hbP8dQiYwAXysGN1AEUmZk7dDGuRn/RW99vecgCBd4hk3jXytAvUm2c+Ua3NYrfkPHx4RO+f k13gzfFRBNTSJg8CjVK3CXk+NgutYoZNZ3TWcHcqL+byLH1jIsgyzwIDAQABo4IBRDCCAUAw DAYDVR0TAQH/BAIwADBWBglghkgBhvhCAQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmlj YXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBodHRwOi8vd3d3LkNBY2VydC5vcmcwDgYDVR0P AQH/BAQDAgOoMEAGA1UdJQQ5MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYK KwYBBAGCNwoDAwYJYIZIAYb4QgQBMDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0 cDovL29jc3AuY2FjZXJ0Lm9yZzAxBgNVHR8EKjAoMCagJKAihiBodHRwOi8vY3JsLmNhY2Vy dC5vcmcvcmV2b2tlLmNybDAfBgNVHREEGDAWgRRjYXJzdGVuQHN0cm90bWFubi5kZTANBgkq hkiG9w0BAQsFAAOCAgEAVMv5QTFt4uaS0pBXnRseGLMvtCCzfQj1oFflMw+mw9sGeZyhN0bM UmU4u7x3x1Uw3pj3lVb3MCmFPY+JjBNfOJ5glmMUcpr7aYjpRJoSlxrN66+4cC1/Wi7gx26S LHb/cqhr/XDv32N4zeFo17NTechNHIix7RnMjcIh970jYT2gW9I0USB5l23Gh+kg0Dwn+J98 DcRH4uwKGh32HSmPvnlKV3LghXuYRCSLYonPIoeDbUNkv0sL1rI+qK0YLwijxyqG2i4Pgvhp /U10fHXFDD2UX+9TiJTSABWd5BeFBR2imuXbO8yMXBIG/D7fPNqOCTWozH9PvZpNZj42I3CR QWOnshVT4XIp/gveGu+Dedme3VaIYXwT4Vx3hzEyF2/DaLy1LU9bYIKa/8XRVG4CSQiD91Gq HwtthENlIMKdOHiTrp9K1dD+9PvwsxY//2XRkhJKaeC/31idtF51OBM9MNgQVMth8btxnlSI Zz1l8wCBgfdOiwLsCq42++/87hgb6/GPLGnV+PLFB/IVM+rX41DQAQZyAeBEsqXwR6ODhOEZ KhawJHZl1ajjrKkaoM5u5cA0D7b1/WwxoCe9oe9FL+M3eTSLOa4jH6AenxvygQNh+tMhiB59 oSSPLeWxQdKXCu2ngbCvX4KUcLbw5F3KQ8xm45g1uatSHov19pwzexMxggSUMIIEkAIBATCB gDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcx IjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1 cHBvcnRAY2FjZXJ0Lm9yZwIDEHAgMAkGBSsOAwIaBQCgggHoMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDYyMzA1NTIxM1owIwYJKoZIhvcNAQkEMRYE FMOaryu8hqC48wsn+5OyDDKYlyRxMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoG CCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggq hkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGDMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAc BgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5n IEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMQcCAwgZMG CyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6 Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEh MB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMQcCAwDQYJKoZIhvcNAQEBBQAE ggIAHBRWM0iqhfmFUEE6dnSlg0r0CAfOGL+U9okjRZaaXz0c/gvhwdGO6rRHDNqLf+0tSDZu eWV/AB+hlsagKwCGiJngHh5d9Nk4ohjA5/Z7gaB5+C2Rjnda4ncYAkQVScyRJ/toOibUDG8j 2WK+EFY1VZHVmpsl+VFZh5ivxbJy/JUt/vA02sqpBDyaq1fSaAWJV8ItDZ8sVCuiRC461t92 T9QsP5GNdzJk1QI2cyzAV93Z51L6GgZIH0EV9oWKlTuTBdXTMPyItgOffEyd++9cdKvWFQZU V+CpSMy8HFQgC30m4PslROReSBPi8yveIORqNtUYDNl9I0I3BJJth3UhWoOVQWIJwhg94FKh gsz6CyLodMluYOnVZBpKeD8eChhQhJxl3fbBa3FmKBq9a2tB1tiW3ELQJwNAO1JMpHnffA2N EuDGdk2GtXb6niqxMfAPShF7H5pLA0sGIbY/XWLkkuJ0JUUc5UsClQYa76BsKf3QwqtzxdQT e90drxgf/OSt9lDqo+Z7nwmlz5O7bNDYS4KamOqVka8+s/iR9iLhQt4vl0FiGDgd6gwKTDwC qExQ+CBrUpH4AnSTxKjDJ3ndM7ilN36NHQ5iE5VWh6uSCwSgAZ7uoHBlx2rKD5eglWbGUOY1 oirMwRtl/gZOCDOX39cUxCO0HEeO5riLFfRp6UQAAAAAAAA= --------------ms030507040705060209030705-- From nobody Tue Jun 23 05:41: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 6C3AF1A00B1; Tue, 23 Jun 2015 05:41:27 -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 cYJWuk5t-7yu; Tue, 23 Jun 2015 05:41:24 -0700 (PDT) Received: from b.painless.aa.net.uk (b.painless.aa.net.uk [IPv6:2001:8b0:0:30::51bb:1e34]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F7DB1A0039; Tue, 23 Jun 2015 05:41:24 -0700 (PDT) Received: from 4.6.9.9.c.3.f.6.1.7.6.6.5.a.4.d.1.0.0.0.f.b.0.0.0.b.8.0.1.0.0.2.ip6.arpa ([2001:8b0:bf:1:d4a5:6671:6f3c:9964]) by b.painless.aa.net.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1Z7NVt-0002vP-FP; Tue, 23 Jun 2015 13:41:17 +0100 Message-ID: <558953F3.5040503@dial.pipex.com> Date: Tue, 23 Jun 2015 13:41:23 +0100 From: Elwyn Davies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Viktor Dukhovni References: <558851A5.20803@dial.pipex.com> <20150622185239.GU14121@mournblade.imrryr.org> In-Reply-To: <20150622185239.GU14121@mournblade.imrryr.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-ietf-dane-ops.all@tools.ietf.org, General area reviewing team , saag@ietf.org, dane@ietf.org Subject: Re: [dane] Gen-art LC review of draft-ietf-dane-ops-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: Tue, 23 Jun 2015 12:41:27 -0000 Hi, Viktor. Thanks for the quick response. I'll wait for the revised draft to revisit the RFC 2118 stuff. I think the TLS1.2 point and the reference to RFC6781 probably need to be discussed with Stephen as your AD. I can't see that you can operate DANE without a good understanding of how to operate DNSSEC (particularly on the rekeying aspects) and you explicitly call out timeout issues discussed in RFC6781. Whether this needs to administrative hassle of the downref is another matter. There is a bit about the OS issue in line below. Cheers, Elwyn On 22/06/2015 19:52, Viktor Dukhovni wrote: > On Mon, Jun 22, 2015 at 07:19:17PM +0100, Elwyn Davies wrote: > >> Summary: Almost ready. There are a couple of minor issues, and I think >> the authors need to reassess whether all the cases where RFC 2119 keyworrds >> are actually protocol requirements as opposed to operation best practice >> recommendations. > Thanks, will double-check the SHOULDS/MUSTS/... > >> s3: I am not a security expert, but I suspect you may get some pushback on >> not making TLS 1.2 mandatory. > We'll see what happens. The most widely deployed use of DANE is > with opportunistic TLS in SMTP, and requiring TLS 1.2 seems like > an unnecessary restriction for an opportunistic protocol. However, > non-support of TLS 1.2 is getting increasingly less common, so if > push comes to shove, we can "require" TLS 1.2. Of course with no > Internet Police to enforce this, the requirement will likely make > little difference in practice. > >>> TLS clients and servers using DANE SHOULD support the >>> "Server Name Indication" (SNI) extension of TLS. >> Under what circumstances would it be reasonable for a DANE/TLSA server not >> to support SNI? Maybe I could see that a single domain server could do >> without it. > That's the primary use case, a server with a single certificate, > and a "3 1 1" TLSA record has no need to support SNI. It can just > respond with the same default certificate, regardless of the SNI > extension value sent by the client. > >> I think this needs to be spelt out - earlier text seems to >> indicate that SNI support was pretty much mandatory.... Ah! Later I see that >> s5.1 gives a case where SNI is not mandatory - a forward pointer would help. > Thanks, will try to make the text more consistent throughout. > >> s4.1: I am not clear that this section adds any value to the discussion in >> s4. Why should the protocol designer be less inclined to use PKIX-xx rather >> than DANE-xx when the protocol supports an OS mode as opposed to just fully >> authenticated or fully authenticated plus cleartext modes? > The basic principle is based on RFC7435. The issue is that PKIX > is more brittle, the client and server must happen to agree on a > mutually trusted CA, but with OS the client is just trying to > protect the communication at the request of the server, and would > otherwise be willing to use cleartext or unauthenticated TLS. Use > of fragile mechanisms (like public CA authentication for some > unspecified set of trusted CAs) is not sufficiently reliable. > > Since the OS client is basing the decision to employ DANE on the > presence of TLSA RRs in DNS, no additional security is gained via > the PKIX usages unless they are the only ones supported by the > application protocol (the attacker who compromises DNS can just > inject "3 1 1" records instead). So DANE-xx is more reliable > at no security loss. Thus PKIX-xx is just a needless opportunity > to fail that should be avoided. Maybe I have misunderstood how OS is intended to behave. I thought I understood that if the client was able to handle OS and it was not able to authenticate the server then it would potentially try for encryption only. Is the problem that there is a difference between there being no authentication available for a domain and an attempted authentication failing (aside from any explicit policy declared by server or client) when using OS? Otherwise I can't see that there is a difference between OS and the general case - in either case, using PKIX-xx is reckoned to be fragile and the process takes more resources without gaining anything. I can see the downside, but it appears to be general - is there an upside for OS in positively going for DANE-xx or is the downside further down in the case of OS? Otherwise there doesn't seem to be a lot of point in being more damning for the OS case (apart from it being a current topic of development :-) ). > >> Nits/editorial comments: >> ===================== > Will review those... thanks. > >> s17.2: I can't decide whether I would like RFC6781 to be normative. It would >> of course be a downref. This is always going to be a problem since the >> draft is combining operational considerations and protocol updates. The >> one explicit reference indicates you have to know something about how to run >> DNSSEC to run DANE - in practice I think you have to know a great deal about >> how to run DNSSEC if you are going to run DANE so I would be inclined to >> make this normative (and maybe refer to it in the introduction as well). > Not sure what if anything to do about that. > From nobody Tue Jun 23 06:42: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 A55C21B2C11; Tue, 23 Jun 2015 06:42: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, 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 K0vEbZOO0dAe; Tue, 23 Jun 2015 06:42:28 -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 B5DEF1B2C16; Tue, 23 Jun 2015 06:42:28 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id A07C6282FD0; Tue, 23 Jun 2015 13:42:27 +0000 (UTC) Date: Tue, 23 Jun 2015 13:42:27 +0000 From: Viktor Dukhovni To: dane@ietf.org, saag@ietf.org Message-ID: <20150623134227.GZ14121@mournblade.imrryr.org> References: <558851A5.20803@dial.pipex.com> <20150622185239.GU14121@mournblade.imrryr.org> <558953F3.5040503@dial.pipex.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <558953F3.5040503@dial.pipex.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dane] Gen-art LC review of draft-ietf-dane-ops-12 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: saag@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2015 13:42:30 -0000 On Tue, Jun 23, 2015 at 01:41:23PM +0100, Elwyn Davies wrote: > >Since the OS client is basing the decision to employ DANE on the > >presence of TLSA RRs in DNS, no additional security is gained via > >the PKIX usages unless they are the only ones supported by the > >application protocol (the attacker who compromises DNS can just > >inject "3 1 1" records instead). So DANE-xx is more reliable > >at no security loss. Thus PKIX-xx is just a needless opportunity > >to fail that should be avoided. > > Maybe I have misunderstood how OS is intended to behave. I thought I > understood that if the client was able to handle OS and it was not able to > authenticate the server then it would potentially try for encryption only. No, that is not the case. With opportunistic DANE TLS, when usable secure (i.e. DNSSEC validated) TLSA records are present, but authentication fails, there is typically no fallback to unauthenticated TLS (mitigate downgrade attacks), for example: https://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-19#section-3.2 > Is the problem that there is a difference between there being no > authentication available for a domain and an attempted authentication > failing (aside from any explicit policy declared by server or client) when > using OS? Yes, when no usable secure DANE TLSA records are absent, unauthenticated TLS is used if possible, and if not perhaps even cleartext. However, when TLSA records are published authentication must succeed. Thus PKIX-xx auth are to be avoided, because outside the browser space, there is no pre-ordained canon of trusted CAs, and in any case there is no value in using them when DANE-xx usages are also supported. For most application protocols there should be a clear statement of which of the two pairs apply (DANE-xx or PKIX-xx) and the other pair should not be used. -- Viktor. From nobody Tue Jun 23 07:58: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 176481B2CD3; Tue, 23 Jun 2015 07:58:36 -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 U6G8JT-BoFGh; Tue, 23 Jun 2015 07:58:33 -0700 (PDT) Received: from b.painless.aa.net.uk (b.painless.aa.net.uk [IPv6:2001:8b0:0:30::51bb:1e34]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5B271B2C75; Tue, 23 Jun 2015 07:58:33 -0700 (PDT) Received: from 4.6.9.9.c.3.f.6.1.7.6.6.5.a.4.d.1.0.0.0.f.b.0.0.0.b.8.0.1.0.0.2.ip6.arpa ([2001:8b0:bf:1:d4a5:6671:6f3c:9964]) by b.painless.aa.net.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1Z7Peh-0001gw-FR; Tue, 23 Jun 2015 15:58:31 +0100 Message-ID: <5589741C.3020105@dial.pipex.com> Date: Tue, 23 Jun 2015 15:58:36 +0100 From: Elwyn Davies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: saag@ietf.org, dane@ietf.org References: <558851A5.20803@dial.pipex.com> <20150622185239.GU14121@mournblade.imrryr.org> <558953F3.5040503@dial.pipex.com> <20150623134227.GZ14121@mournblade.imrryr.org> In-Reply-To: <20150623134227.GZ14121@mournblade.imrryr.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dane] Gen-art LC review of draft-ietf-dane-ops-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: Tue, 23 Jun 2015 14:58:36 -0000 Hi, Viktor. Thanks for clearing up my misunderstanding. I think it would be worth a sentence or two along the lines of what you have written below to clarify why OS is potentially more badly affected by fragile PKIX-xx behaviour. Cheers, Elwyn On 23/06/2015 14:42, Viktor Dukhovni wrote: > On Tue, Jun 23, 2015 at 01:41:23PM +0100, Elwyn Davies wrote: > >>> Since the OS client is basing the decision to employ DANE on the >>> presence of TLSA RRs in DNS, no additional security is gained via >>> the PKIX usages unless they are the only ones supported by the >>> application protocol (the attacker who compromises DNS can just >>> inject "3 1 1" records instead). So DANE-xx is more reliable >>> at no security loss. Thus PKIX-xx is just a needless opportunity >>> to fail that should be avoided. >> Maybe I have misunderstood how OS is intended to behave. I thought I >> understood that if the client was able to handle OS and it was not able to >> authenticate the server then it would potentially try for encryption only. > No, that is not the case. With opportunistic DANE TLS, when usable > secure (i.e. DNSSEC validated) TLSA records are present, but > authentication fails, there is typically no fallback to unauthenticated > TLS (mitigate downgrade attacks), for example: > > https://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-19#section-3.2 > >> Is the problem that there is a difference between there being no >> authentication available for a domain and an attempted authentication >> failing (aside from any explicit policy declared by server or client) when >> using OS? > Yes, when no usable secure DANE TLSA records are absent, unauthenticated > TLS is used if possible, and if not perhaps even cleartext. However, > when TLSA records are published authentication must succeed. Thus > PKIX-xx auth are to be avoided, because outside the browser space, > there is no pre-ordained canon of trusted CAs, and in any case > there is no value in using them when DANE-xx usages are also > supported. For most application protocols there should be a clear > statement of which of the two pairs apply (DANE-xx or PKIX-xx) and > the other pair should not be used. > From nobody Tue Jun 23 08:05: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 D60881B2CEA for ; Tue, 23 Jun 2015 08:05:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.663 X-Spam-Level: * X-Spam-Status: No, score=1.663 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 tC6cv48T0Awz for ; Tue, 23 Jun 2015 08:05:46 -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 926781B2CE1 for ; Tue, 23 Jun 2015 08:05:46 -0700 (PDT) Received: (qmail 22760 invoked from network); 23 Jun 2015 15:05:56 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 23 Jun 2015 15:05:56 -0000 Date: 23 Jun 2015 15:05:23 -0000 Message-ID: <20150623150523.89259.qmail@ary.lan> From: "John Levine" To: dane@ietf.org In-Reply-To: <5588F40D.3040809@strotmann.de> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dane] AD review of draft-ietf-dane-openpgpkey-03 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 23 Jun 2015 15:05:48 -0000 >I see interest in the email hosting market to implement the openpgpkey >draft. I know of email service provider that already have deployed the >openpgpkey draft, and others are prepared to go online once the draft is >stable or published as an RFC. That's quite surprising. I've talked to the large providers, all of whom were extremely unenthusiastic. R's, John From nobody Tue Jun 23 08:57: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 4552E1A923A for ; Tue, 23 Jun 2015 08:57:54 -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, 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 IGgxUJzcJvNg for ; Tue, 23 Jun 2015 08:57:52 -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 40CB41A8F4F for ; Tue, 23 Jun 2015 08:57:46 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 28075282FD0; Tue, 23 Jun 2015 15:57:45 +0000 (UTC) Date: Tue, 23 Jun 2015 15:57:45 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150623155744.GC14121@mournblade.imrryr.org> References: <5588F40D.3040809@strotmann.de> <20150623150523.89259.qmail@ary.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20150623150523.89259.qmail@ary.lan> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dane] AD review of draft-ietf-dane-openpgpkey-03 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2015 15:57:54 -0000 On Tue, Jun 23, 2015 at 03:05:23PM -0000, John Levine wrote: > >I see interest in the email hosting market to implement the openpgpkey > >draft. I know of email service provider that already have deployed the > >openpgpkey draft, and others are prepared to go online once the draft is > >stable or published as an RFC. > > That's quite surprising. I've talked to the large providers, all of > whom were extremely unenthusiastic. I think this reflects a difference in attitudes between Germany and the USA. In Germany, there's been a noticeable interest in and uptake of DANE for SMTP, and now some interest in DANE for end-to-end email security. In the USA, the large providers have been first and foremost rather reluctant to implement DNSSEC, which then precludes all manner of DANE technologies, including PGP. As and when that changes, it might become more clear whether they were dragging their feet on DNSSEC in general, or had specific reservations about the localpart encoding for keys in DNS, or did not want to vend user keys via DNS at all. Can you be more specific about the concerns of the providers you surveyed? Are they planning to move forward with DNSSEC? What fraction of users do they expect to adopt E2E encrypted email? Are any of them planning to publish a draft with a concrete proposal for vending user end-to-end keys? I would conjecture that at the scale of the USA, large scale changes tend to be viewed as "turning the Titanic" challenges, and that the providers are often loathe to tackle DNSSEC adoption. Questions of whether to then use DNSSEC in some manner for user keys are rather downstream from that. Note, I am still on the fence about whether user E2E keys should be vended via DNS, or some service over TLS, with keys for that vended via TLSA RRs. As for hash vs. base32, if more providers are likely to support base32, so be it. The sticking point is lower-case lookup, not whether the result is hashed or base32 encoded. Yes, lower-case is a minefield for EAI. And yet Firefox and Chrome routinely downcase all the Cyrillic domains I've tried before querying DNS. Try: ГоДжи-чИа.Рф I don't know what they do with other scripts. -- Viktor. From nobody Tue Jun 23 09:43: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 C791D1B2DD7 for ; Tue, 23 Jun 2015 09:43:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.69 X-Spam-Level: X-Spam-Status: No, score=0.69 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 MMba5oki2guB for ; Tue, 23 Jun 2015 09:43:20 -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 2B1FF1B2DD5 for ; Tue, 23 Jun 2015 09:43:20 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3mGD1y5x6jz4D4 for ; Tue, 23 Jun 2015 18:43:18 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=dbLLS2hw 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 NDH0ZEHe-E8f for ; Tue, 23 Jun 2015 18:43:16 +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 ; Tue, 23 Jun 2015 18:43:16 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 86A8A800B6 for ; Tue, 23 Jun 2015 12:43:15 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1435077795; bh=6uDEAfcUTuXnx6xlpGA8D0Cyk52dumU6ywi0Uk6Y0U0=; h=Date:From:To:Subject:In-Reply-To:References; b=dbLLS2hwynty6FrrgBm2ybUQR7ZJGLJ+gzI6b8btBas0Z0+3GnIiXoz0pTIzc9gpK dVo6+XT22r9eLbrkFCq4foEo5YBYKexqlgOs3lG4/WZNcCYTE9AruEGAubMapC8Sa1 f3bl8qctE0iuQoiC5ZNW3H0n7qcVx0lbJdNY3V60= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.15.1/8.15.1/Submit) with ESMTP id t5NGhF4Z009618 for ; Tue, 23 Jun 2015 12:43:15 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Tue, 23 Jun 2015 12:43:15 -0400 (EDT) From: Paul Wouters To: dane WG list In-Reply-To: <20150623150523.89259.qmail@ary.lan> Message-ID: References: <20150623150523.89259.qmail@ary.lan> User-Agent: Alpine 2.11 (LFD 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dane] AD review of draft-ietf-dane-openpgpkey-03 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 23 Jun 2015 16:43:21 -0000 On Tue, 23 Jun 2015, John Levine wrote: >> I see interest in the email hosting market to implement the openpgpkey >> draft. I know of email service provider that already have deployed the >> openpgpkey draft, and others are prepared to go online once the draft is >> stable or published as an RFC. > > That's quite surprising. I've talked to the large providers, all of > whom were extremely unenthusiastic. For all the obvious reasons. Did you ask them if their reluctance was based on business rather than technical implementation reasons? Obviously most of the large email providers provide "free" email for a reason, and if that email is all unreadable to them, their ad business is affected negatively. Another obvious unsolved problem is webmail and how you trust cryptographic keys to a browser. Obviously the big players do not want to stop their ad driven webbased mail service. These are the same reasons why the "big messenger providers" (which happen to be the same as the big email providers) also actively block or do not support the use of OTR encrypted messaging. It has however, not stood in the way of OTR being deployed widely. large providers being unenthusiastic about end-to-end encryption is exactly the reason others want to deploy this document - to keep their privacy. Paul From nobody Tue Jun 23 10:17: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 C32F11B2E5F for ; Tue, 23 Jun 2015 10:17:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.039 X-Spam-Level: * X-Spam-Status: No, score=1.039 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_DE=0.35, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uHU3QUoxCXkC for ; Tue, 23 Jun 2015 10:16:58 -0700 (PDT) Received: from mail.sys4.de (mail.sys4.de [IPv6:2001:1578:400:111::7]) (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 347481B2E5A for ; Tue, 23 Jun 2015 10:16:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sys4.de; h= in-reply-to:content-disposition:content-type:content-type :mime-version:references:message-id:subject:subject:from:from :date:date; s=mail201310; t=1435079815; x=1436894216; bh=1J3eXYi zonDn5KfexxpE8+cRcQM5hDPEMoSzOTyMX6k=; b=qjhARPvIIuvSnMxkifwnpAd AxBchy3dN0LQQJNM7zG0xySFJTpJaqF8+61mrQRCuJvNjgHffDMyq5zDz5dBMlhF amShYYHh1QFtWa3uDzshK1/Z5fS0rXusMpRqI26ObBAlsDKpoFNrbmUsYJCxIsyL XUdw3y45PF272K5PNbOws6g7fBb7urKoZTSJK+4Je5hg8hYZ0id9bJGh6GktBnJN 3p4Oi6r0v6uBAos895aM5/CC0ztWxHJNxgKIIgJ/666IF7HH+AKIAqghwtiDOgv4 a7biH44MRlSgD6AXuTmLPrvmI4p38doQU2u0aKHoXUa/P+E8TqkdtaxWtlV3cjQ= = X-Virus-Scanned: Debian amavisd-new at mail.sys4.de Received: from sys4.de (mail.sys4.de [194.126.158.139]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sys4.de (Postfix) with ESMTPSA id 3mGDml4MKFzg for ; Tue, 23 Jun 2015 19:16:55 +0200 (CEST) Date: Tue, 23 Jun 2015 19:16:54 +0200 From: Florian Kirstein To: dane@ietf.org Message-ID: <20150623171653.GC3750@sys4.de> References: <20150618235633.80533.qmail@ary.lan> <20150621223548.Horde.QMQrKms_nN6MLgI5jarhuSk@andreasschulze.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20150621223548.Horde.QMQrKms_nN6MLgI5jarhuSk@andreasschulze.de> Archived-At: Subject: Re: [dane] AD review of draft-ietf-dane-openpgpkey-03 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 23 Jun 2015 17:17:00 -0000 Hi, > That's the point: you EXPECT that. But John has the idea that this > could fail. As I already wrote, I think the important part is that we implement a new form of PGP key lookup, not a mail server. All current mechanisms are case-insensitive, key servers as well as the gpg implementation. I have to admit I would not see a real reason why we could not allow or better require a lookup to be done in original AND lowercased form, as long as it is defined that the published record should or even must be the lowercase variation. But if we want a clearly defined version, lowercase still is in my opinion the best way. For ASCII localparts. Regarding UTF8: > I don't know all the details about UTF8SMTP or EAI, but I could > imagine we see the world in ASCII. You don't have to go to China, also Europe has many non-ASCII characters. But indeed, international email using UTF8 chars is really really uncommon here. The same goes for Japan, they simply use ASCII. I can't tell much about China, but they don't have upper and lower case characters anyway. I have NEVER seen a PGP key with UTF8 characters in the Cmail address, but I admit, the standard as I understand it allows it. I am pretty sure case insensitive comparision will fail there with the usual locale problems in the usual tools, and people using such addresses are or will have to get used to it and work accordingly. > And at least I could not deny *THERE* Lee@chinese may be an other > Mailbox then lEE@chinese As I said, the chinese don't have lower case characters. But of course european countries like france or germany have, outside ASCII. And UTF8 has other problems - there are multiple different binary representations for basically the same string. Thats why RFC6530 recommends that mail servers expect localparts could be normalized and people are advised to generate their addresses in normalized form in the first place. It's not a MUST though, which means people can do stupid things if they want to. I think very few people have acutal experience with utf8 email, but I would expect in that world, binary equivalence will be the main matching system. So do we want to care for UTF8 in the current form of the draft? If yes, my suggestion would be to clarify that the lowercasing is only to be applied for ASCII addresses. utf8 addresses should be looked up in the original form, and if that original form is not equivalent to the normalized form that SHOULD be looked up additionally. On the domain owners side I would RECOMMEND (as the international mail RFC already does) to use normalized utf8 for the address and thus for the record - if that differs from the form used in correspondence it might be advised to also add a record for that form. Generally people using such addresses should know (as people using other variations like +something) which forms of their address might be used by others, an not only add matching OPENPGPKEY records for those, but also add those forms as User IDs to their keys! I REALLY would advise not to make this a show stopper to advance the DRAFT in its current form, possibly adding some clearifications like those above for handling non-ASCII addresses. UTF8 emails are very uncommon today and it is hard to guess how they will be used, especially how PGP will be used with them. Everything beyond binary match in unified form (and in original form as backup) would be wild guessing - and I really assume, IF utf8 emails will be in broader use somewhere (asia most probably I would guess) people won't enter them manually anyway, so nothing beyond normalization should happen to it. Greetings, Florian -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstrasse 15, 81669 Muenchen Sitz der Gesellschaft: Muenchen, Amtsgericht Muenchen: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein From nobody Tue Jun 23 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 72F1B1B2E8A for ; Tue, 23 Jun 2015 10:24:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.663 X-Spam-Level: * X-Spam-Status: No, score=1.663 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 o_-0eaYnj6X4 for ; Tue, 23 Jun 2015 10:24:34 -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 403681B2E89 for ; Tue, 23 Jun 2015 10:24:34 -0700 (PDT) Received: (qmail 45274 invoked from network); 23 Jun 2015 17:24:43 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 23 Jun 2015 17:24:43 -0000 Date: 23 Jun 2015 15:44:32 -0000 Message-ID: <20150623154432.89553.qmail@ary.lan> From: "John Levine" To: dane@ietf.org In-Reply-To: <20150623155744.GC14121@mournblade.imrryr.org> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dane] adoption chances, was AD review of draft-ietf-dane-openpgpkey-03 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 23 Jun 2015 17:24:35 -0000 >Can you be more specific about the concerns of the providers you >surveyed? Are they planning to move forward with DNSSEC? They're planning to do DNSSEC. Giant zones of hashed names that don't have local-part semantics, not so much. At least one of them said it'd make more sense to do it with webfinger. >I would conjecture that at the scale of the USA, large scale changes >tend to be viewed as "turning the Titanic" challenges, and that >the providers are often loathe to tackle DNSSEC adoption. You would be mistaken. To point out the obvious, the operator of the largest mail system also runs the 8.8.8.8 public DNS resolver, and it does DNSSEC just fine. They are also the registry for a bunch of new TLDs which are required by contract to support DNSSEC from day 1. R's, John From nobody Tue Jun 23 10:52: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 2B7F81ACE9F for ; Tue, 23 Jun 2015 10:52:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.961 X-Spam-Level: X-Spam-Status: No, score=-3.961 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, 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 RgggJRW7pzjr for ; Tue, 23 Jun 2015 10:52:25 -0700 (PDT) Received: from mail.sys4.de (mail.sys4.de [194.126.158.139]) (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 41EAE1A87AB for ; Tue, 23 Jun 2015 10:52:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sys4.de; h= in-reply-to:content-disposition:content-type:content-type :mime-version:references:message-id:subject:subject:from:from :date:date; s=mail201310; t=1435081942; x=1436896343; bh=0TPlG5W HBlTSUJ1PGZ1isY4WMqSzugbSkBo8rs7w0VE=; b=M6Nu6C1dyG5zV6iQuk/YaLl FLlhJxblGiYTXNAnXRbo9erzLBurGGji9eGfMCCRg46CI2Ei3kRMOUbYo80OyVNw OWBzDTxyWBK3g9o+hohCjpB17sjerwlBZyjxXUOi8oyyh9hsvYszAizOaKL23PS7 aWQ3INBis2ns4XD27go5+nbV8PZjO1IqIGs+EZeOpSoiAYbE9nlNdqDCqQ6OmPcz u1PUwm86HdDPLcemEx+BI/aZWdzqUQqRB0xs+DWDjkHYVKKJG519nVekkWntLmKu MrG4fxSVbZJSdedtheUrDWrvU91JXjtp9/e4UHvg4kgi+0864/Vkee5uaD/QaVA= = X-Virus-Scanned: Debian amavisd-new at mail.sys4.de Received: from sys4.de (mail.sys4.de [194.126.158.139]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sys4.de (Postfix) with ESMTPSA id 3mGFYf1k4kzFv for ; Tue, 23 Jun 2015 19:52:22 +0200 (CEST) Date: Tue, 23 Jun 2015 19:52:21 +0200 From: Florian Kirstein To: dane@ietf.org Message-ID: <20150623175221.GD3750@sys4.de> References: <5588F40D.3040809@strotmann.de> <20150623150523.89259.qmail@ary.lan> <20150623155744.GC14121@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20150623155744.GC14121@mournblade.imrryr.org> Archived-At: Subject: Re: [dane] AD review of draft-ietf-dane-openpgpkey-03 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 23 Jun 2015 17:52:27 -0000 Hi, > As for hash vs. base32, if more providers are likely to support > base32, so be it. The sticking point is lower-case lookup, not > whether the result is hashed or base32 encoded. Full ack! I must admit I personally would prefer hashing for its simplicity, chopped sha256 really is easy to implement in basically all languages including shell scripts. The need to split some localparts in two records adds complexity and I don't see the benefits. But I don't have real objections against base32, as long as the tolower() part remains. To have the full benefits base32 might have over hashing, I think the additional lookup of the original form would have to be a MUST then, so people really wanting to implement some clever lookup server side (which I currently dont really expect to happen, it simply doesn't make sense as a PGP key has a fixed set of user IDs and those should be the lookup targets, simple as that) can do so. Regarding adding dots every few bytes: if people really fear big Zonefiles that would be an option I also would not object. But again I don't really see the problem it wants to solve, really big providers will most probably do live signing on request... Greetings, Florian -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstrasse 15, 81669 Muenchen Sitz der Gesellschaft: Muenchen, Amtsgericht Muenchen: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein From nobody Wed Jun 24 19:22: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 7E8E91A886F for ; Wed, 24 Jun 2015 19:22:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.663 X-Spam-Level: * X-Spam-Status: No, score=1.663 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 RKb1X7nUAevM for ; Wed, 24 Jun 2015 19:22:12 -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 4C1401A886E for ; Wed, 24 Jun 2015 19:22:12 -0700 (PDT) Received: (qmail 13658 invoked from network); 25 Jun 2015 02:22:21 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 25 Jun 2015 02:22:21 -0000 Date: 25 Jun 2015 02:21:47 -0000 Message-ID: <20150625022147.91282.qmail@ary.lan> From: "John Levine" To: dane@ietf.org In-Reply-To: <20150623175221.GD3750@sys4.de> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dane] AD review of draft-ietf-dane-openpgpkey-03 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 25 Jun 2015 02:22:13 -0000 >Regarding adding dots every few bytes: if people really fear big >Zonefiles that would be an option I also would not object. But again I >don't really see the problem it wants to solve, really big providers will >most probably do live signing on request... In base32, live signing is pretty much a given since the data will all be live from the mail server, In hashes, you might want to do some back of the envelope calcuations about how many CNAMEs you'd need to cover even a modest number of dots and case variations. Speaking of case folding, I note that nobody here seems to understand UTF-8 and EAI. Really, it matters. If you think it doesn't, please add a sentence saying "This specification MUST NOT be implemented in any country where languages other than English and Hawaiian are in use" since those are the only ones that can be written in ASCII. R's, John From nobody Wed Jun 24 20:46:35 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 21B281ACEED for ; Wed, 24 Jun 2015 20:46:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 Srk7V75tom2O for ; Wed, 24 Jun 2015 20:46:31 -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 888761ACEEB for ; Wed, 24 Jun 2015 20:46:31 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 1011A284AD6; Thu, 25 Jun 2015 03:46:30 +0000 (UTC) Date: Thu, 25 Jun 2015 03:46:30 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150625034629.GQ14121@mournblade.imrryr.org> References: <20150623175221.GD3750@sys4.de> <20150625022147.91282.qmail@ary.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20150625022147.91282.qmail@ary.lan> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dane] AD review of draft-ietf-dane-openpgpkey-03 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, 25 Jun 2015 03:46:33 -0000 On Thu, Jun 25, 2015 at 02:21:47AM -0000, John Levine wrote: > Speaking of case folding, I note that nobody here seems to understand > UTF-8 and EAI. That's a unnecessary over-generalization. Some of us have read enough of the 2003 and 2008 IDNA standards to have been grounded in the various issues. I've been involved in multiple discussions on EAI implementation in a popular MTA. My comment about Cyrillic was an observation of current practice in major browsers with at least one non-Latin (though still European) script, there are clearly some pragmatic choices being made at the user-interface layer that would not be appropriate in most other contexts. Thus while MTAs, DNS servers, ... must not case-fold UTF-8, user-facing software (such as a mobile phone or similar), where users enter email addresses, might well have enough information to do something sensible with mixed case input, and may allow users to correct unwanted normalization (damn you auto-correct). Of course the story is much simpler for IDNA domain names than it is for EAI localpart addresses. IDNA (2008) domains use a restricted character set that does not allow for the existence of two distinct valid domain names that differ only in case. The corresponding isssue for local parts is much more difficult, because email addresses are not expected to satisfy this constraint. I might hypothetically have an email address of: Виктор.Духовный@духовный.рф In which, when entered by a user into an EAI-enabled MUA, the domain might be casually mapped to lower-case Cyrillic, but the wisdom of a similar localpart mapping is much more questionable, and might require user confirmation. What this might mean for the draft under discussion, is that any case-conversion might need to be user visible and not implicit, and be a feature of the address input UI, and not the underlying PGP key lookup mechanism, once the user settles on an input address. We can sensibly discuss other approaches, without asserting that everyone else present is clueless. If I and/or others have the wrong end of the stick, a more constructive suggestion would work better. This could be, lower-case lookup for ASCII only, or could be lower-case lookup only with user confirmation, (feature of MUA user-interface, not key lookup library), etc. -- Viktor. From nobody Thu Jun 25 06: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 6BFF51A88FD for ; Thu, 25 Jun 2015 06:53:11 -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 9RmzOuLBrZBl for ; Thu, 25 Jun 2015 06:53:08 -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 A1D0B1A88F6 for ; Thu, 25 Jun 2015 06:53:08 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3mHN8f5RDXz7LY; Thu, 25 Jun 2015 15:53:06 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=dlJisd3M 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 AdvLb_GoQ46X; Thu, 25 Jun 2015 15:53:03 +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, 25 Jun 2015 15:53:02 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id BEF4F80058; Thu, 25 Jun 2015 09:53:01 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1435240381; bh=8FwsSFfVAcr67kc2jgc5cr4ThKWZ9ejOzX280hbgkPo=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=dlJisd3M9uiTD4TBR+LrSkDMPe3yQl22nuT4IrtQp2LhJjksVc+Pt8xi9huKlPXJj NE52J300LLsoogE7kidcPSWmmPeSd6Fyl1LUXy153mbf22s6goBmq2RpFKg9Mcrts9 1hjY4czFWBF+RIiIC4EFU8YAaIysDae3yA7WhILU= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.15.1/8.15.1/Submit) with ESMTP id t5PDr1w3021733; Thu, 25 Jun 2015 09:53:01 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Thu, 25 Jun 2015 09:53:01 -0400 (EDT) From: Paul Wouters To: dane WG list In-Reply-To: <20150625022147.91282.qmail@ary.lan> Message-ID: References: <20150625022147.91282.qmail@ary.lan> User-Agent: Alpine 2.11 (LFD 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dane] AD review of draft-ietf-dane-openpgpkey-03 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 25 Jun 2015 13:53:11 -0000 On Wed, 25 Jun 2015, John Levine wrote: > In hashes, you might want to do some back of the envelope calcuations > about how many CNAMEs you'd need to cover even a modest number of dots > and case variations. > > Speaking of case folding, I note that nobody here seems to understand > UTF-8 and EAI. "This sort of misrepresentation of what other people [have said] is extremely unhelpful." > Really, it matters. If you think it doesn't, please > add a sentence saying "This specification MUST NOT be implemented in > any country where languages other than English and Hawaiian are in > use" since those are the only ones that can be written in ASCII. I'm at ICANN53 and talked to some of the people that are well versed in EAI, such as Asmus Freytag, Hirofumi Hotta and Wil Tan. There is apparently only one language where lowercasing can change the meaning of a letter and that is Turkish (with the letter I) Their recommendation was to only lowercase for ascii and to normalize everything else, then hash (or base32/split) Normalization seems to be a proper way of doing things. Some references: https://tools.ietf.org/html/draft-dainow-eai-email-clients-00#section-5 https://tools.ietf.org/html/draft-ietf-eai-rfc5335bis-08#section-2.2 https://tools.ietf.org/html/draft-klensin-net-utf8-09 So my suggestion is to recommend normalization and refer to draft-dainow-eai-email-clients and draft-klensin-net-utf8 I still feel that using this ruleset, using a hash seems fine, but if people really feel that live signing DNSSEC servers talking to live mail servers is a thing that must be supported instead of that use case being handed of to a separate webfinger document, I could go with base32/split as well. I'll try to run into Warren again here at ICAN and see how and when he would like me to update the document. Paul From nobody Thu Jun 25 07:29: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 9795F1A8984 for ; Thu, 25 Jun 2015 07:29:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.011 X-Spam-Level: X-Spam-Status: No, score=-4.011 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, 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 cDiEgOjUmsvn for ; Thu, 25 Jun 2015 07:29:00 -0700 (PDT) Received: from statler.isode.com (statler.isode.com [217.34.220.151]) by ietfa.amsl.com (Postfix) with ESMTP id 472B01A895D for ; Thu, 25 Jun 2015 07:28:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1435242536; d=isode.com; s=selector; i=@isode.com; bh=D6jMnbcsGpengE8FEmPgRBjz3e78jypkDt1dvYJ3jp0=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=iueaEB9T/CQsNP8m7XmZme1qL5HJPaSoov1pUGrEVqiimDubquZsxZdKbjP+atCANkJRGF 7yq8NQocZP49fSnWlcCVUF8vW51v8FK7wG8rWP+/CZh4KTrJzbxUQ69OXXxByKYy2mNe+9 IdKGLZB9wqa3qjVPhzv3xuXs70Gu2Hw=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Thu, 25 Jun 2015 15:28:55 +0100 Message-ID: <558C1016.7030109@isode.com> Date: Thu, 25 Jun 2015 15:28:38 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 To: Paul Wouters , dane WG list References: <20150625022147.91282.qmail@ary.lan> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dane] AD review of draft-ietf-dane-openpgpkey-03 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 25 Jun 2015 14:29:01 -0000 Hi Paul, On 25/06/2015 14:53, Paul Wouters wrote: > On Wed, 25 Jun 2015, John Levine wrote: >> In hashes, you might want to do some back of the envelope calcuations >> about how many CNAMEs you'd need to cover even a modest number of dots >> and case variations. >> >> Speaking of case folding, I note that nobody here seems to understand >> UTF-8 and EAI. > > "This sort of misrepresentation of what other people [have said] is > extremely unhelpful." > >> Really, it matters. If you think it doesn't, please >> add a sentence saying "This specification MUST NOT be implemented in >> any country where languages other than English and Hawaiian are in >> use" since those are the only ones that can be written in ASCII. > > I'm at ICANN53 and talked to some of the people that are well versed > in EAI, such as Asmus Freytag, Hirofumi Hotta and Wil Tan. > > There is apparently only one language where lowercasing can change the > meaning of a letter and that is Turkish (with the letter I) > > Their recommendation was to only lowercase for ascii and to normalize > everything else, then hash (or base32/split) > > Normalization seems to be a proper way of doing things. Some references: > > https://tools.ietf.org/html/draft-dainow-eai-email-clients-00#section-5 > https://tools.ietf.org/html/draft-ietf-eai-rfc5335bis-08#section-2.2 > https://tools.ietf.org/html/draft-klensin-net-utf8-09 > > So my suggestion is to recommend normalization and refer to > draft-dainow-eai-email-clients This draft has expired in 2008... I don't think it will ever be completed. So make the reference informative ("as specified in ...") and copy the text from it. > and draft-klensin-net-utf8 > > I still feel that using this ruleset, using a hash seems fine, but if > people really feel that live signing DNSSEC servers talking to live mail > servers is a thing that must be supported instead of that use case being > handed of to a separate webfinger document, I could go with base32/split > as well. > > I'll try to run into Warren again here at ICAN and see how and when he > would like me to update the document. From nobody Thu Jun 25 15:51: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 BB7791B2BEA for ; Thu, 25 Jun 2015 15:51:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.039 X-Spam-Level: * X-Spam-Status: No, score=1.039 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_DE=0.35, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GyeWQXKHLcrW for ; Thu, 25 Jun 2015 15:50:59 -0700 (PDT) Received: from mail.sys4.de (mail.sys4.de [IPv6:2001:1578:400:111::7]) (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 E5DE61B2BE9 for ; Thu, 25 Jun 2015 15:50:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sys4.de; h= content-disposition:content-type:content-type:mime-version :message-id:subject:subject:from:from:date:date; s=mail201310; t=1435272655; x=1437087056; bh=CEzPkGWUYFaZJuL5Sg1rdLeCj/18f4hV PI2MtkewsYI=; b=qe5vuBxFz8WeB2ZWgPEKueus275UtcZXcTUO8blR8veyJlRG Opo6DaYnq6NumEj6m/ACk+Iyhcywq/4yZt+bhEoa1gIEqSmDhFgakD+bllbQkKEF UQW47NwhP0zlmktjOPOtyBe9OxVNlPBo59owxVWXitFNItqUVJBVZ2eUqfiZThd8 BC6XSXvPToa54jzHLFjiJssROd+Di8XBxV/jouc4kOObLThf+IhVIjH7BbyZo0sI VQ7+t5kz0pv9btgJs2LnqGxHKCv8O99lGhCGnrPHuo7M5B4JcuqyuVdUrrPbxdNq UhnFzpeHArhj8M0CMW1rUFR5U+PcBWdV5DhLsQ== X-Virus-Scanned: Debian amavisd-new at mail.sys4.de Received: from sys4.de (ipb21b2720.dynamic.kabel-deutschland.de [178.27.39.32]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sys4.de (Postfix) with ESMTPSA id 3mHc5C3tcSzNf for ; Fri, 26 Jun 2015 00:50:55 +0200 (CEST) Date: Fri, 26 Jun 2015 00:50:54 +0200 From: Patrick Ben Koetter To: dane@ietf.org Message-ID: <20150625225054.GB4011@sys4.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="r5Pyd7+fXNt84Ff3" Content-Disposition: inline Archived-At: Subject: [dane] DANE - Tales and Lessons Learned X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 25 Jun 2015 22:51:01 -0000 --r5Pyd7+fXNt84Ff3 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Greetings, I gave a presentation called "One year of DANE - Tales and Lessons Learned"= at the 34th M=C2=B3AA3WG General Meeting in Dublin a few weeks ago. Barry (Lei= ba) asked me in an offlist mail to share the slides with you on this list and a= lso write about the experience we've made during the last 1,5 years. # Slides Here's a quick rundown to give an idea what my presentation was about: The first part is technical. It starts off naming the issues traditional opportunistic TLS faces today. Then they show an approach/plan to solve the named issues only to present DANE as a solution next. The slides then show = and discuss current use cases for DANE (with a strong focus on email) - HTTPS, SMTP, OPENPGPKEYS, SMIMEA. The second part deals with adoption, possible markets and reasons why the o= ne or the other TLD has a better starting position to adopt DANE. It also lists things we have learned during the last 1,5 years working with DANE or get to hear often when we talk with people interested to DANE-enable their infrastructure. Download the slides at https://sys4.de/download/dane-maawg.pdf. # Experience Barry also suggested I summarize our experience with DANE. Here's a list of things we've learned or I believe to have understood (sudden moments of cla= rity are a great thing [tm]): DANE is server and client DANE may be used by clients and offered to others. This is obvious once you've become aware of that, but people seem to focus at the "offering DANE part" above average. And they seem to fade out the client side. =20 When they realize the server side isn't low hanging fruit they seem to = get stuck. Shifting their focus to the client side helps. That's the low hanging fruit (assuming you have DANE capable clients at hand). Using DANE in a client is easy You need a DNSSEC-capable resolver and DANE capable client software. It= 's simple, compared to offering DANE, because these componets are simplier= to control and problems stay your own. Failures have comparatively limited effect. Postmasters change settings within their well-known application. They don't need to deal with a DNS server, which they might not know as well or need to talk a hostmaster to do something for them (they don't feel comfortable with). =20 DNSSEC-enabling your infrastructure requires careful thinking DNSSEC is about security. The right way [tm] to do DNSSEC on a host is = to equip it with a local DNSSEC-capable resolver. If you want to add fallback resolvers (resolv.conf) *all* of them need to be DNSSEC-capable or you might end up with a (bad,insecure,...) DNS reply that would have been suppressed by a DNSSEC aware resolver. Careful if your run your own, internal TLD Local TLDs are not DNSSEC signed by default. DNSSEC-aware resolvers will suppress answers unless you DNSSEC-enable the internal ZONE or configure the resolvers to ignore the DNSSEC chain of trust for that particular domain. Test before or you will risc needless service outage. Check your firewalls TLSA, SMIMEA and OPENPGPKEYS queries to DNS servers end up in TCP answe= rs. Your firewall must permit TCP on 53. (Most people will probably have th= at=20 in place if they also serve DKIM. If not this might be the answer to th= ese strange DNS problems... ;) Check also that your firewall doesn't filter RRs. It might drop requests for TLSA and all the other new RRs. It works from inside, but fails for outside requests. Offering DANE RRs is all about DNSSEC Offering DANE requires a DNSSEC-enabled DNS server. Everything after DNSSEC-enabling the DNS server is comparatively easy. DNSSEC-enabling is the hardest part People are scared to DNSSEC-enable their domain(s). They have to upgrade their applications. They have to clean up/refactor/get a better understanding of their service. (You're up and running in a few minutes and once that works you don't spend time with DNS anymore - unless you'= re a large player or do DNS for business). =20 Registrars don't invest in DNSSEC Offering DNSSEC means to invest in security. It requires to invest in a race to the bottom market where cheaper seems to be more important than more secure. The market interest for DNSSEC isn't great enough at the moment to invest into DNSSEC. (In .nl the goverment subsidizes DNSSEC-enabled domains. Surveys indicate 50% of .nl is DNSSEC-enabled!) DNSSEC-capable registrars are hard to find At least in .de its hard to find a registrar offering DNSSEC. One of the question we get to hear all the time is if we could recommend a list of DNSSEC registrars in Germany. To me this seems directly related to the little invest we see in DNSSEC on the registrars side - a chicken egg dilemma. Monitor your DNSSEC domain Keep an eye on your zones signature TTL. If it expires DNSSEC-capable resolvers will suppress replies. They will ignore your domain until you= 've renewed the signature. Monitor your DNSSEC domain. Monitor TTLs and TLSA pinned certificate enddates (see next lesson). RR rollover requires more careful handling If you need to roll in a new TLSA (or any other DANE related record) ma= ke you do it in advance. Leave the old one and add the new one. Wait two T= TL cycles. Give clients out there time to revisit and learn the new RR. On= ly then remove the old one. If you forget to add the new RR you risk receiving no mail from DANE enabled clients. They check the RR and if you publish an old TLSA, but = use a new cert they will not send. That's just how DANE should work. ;) Automate the rollover and make sure the rollover works reliably *before* you upload your zones signing key to your registrar and publicly DNSSEC-able your domain. DNSSEC obstructs DANE People who critice DANE usually criticise it because of DNSSEC. They say DNSSEC hasn't been worked on for too long time. The standard should be updated. They say it doesn't provide the level of security it could and should for something as important as DANE to build upon. From their poi= nt of view DANE security is directly linked to the level of security DNSSEC provides. I'm no DNS expert to tell how much substance there is in their criticism. If there is updating DNSSEC standards might help to break the ice. There's no market for DANE at the moment Everybody seems to wait for everybody else to start using/offering DNSSEC/DANE. Those who DANE enable their clients find only few DANE enabled servers to communicate with. Those who could DNSSEC-enable their domains and could start serving DANE-related RRs don't see the benefit = to go through all the required work. We - heise.de (Germany's most popular IT magazine and portal), BSI (Federal Office for Information Security), DENIC (Germanys .de TLD registry) and sys4 - spent about half a year to prepare a DNSSEC-Day. DNSSEC-Day will take place next week Tuesday (June, 30th) between 2 p.m and 6 p.m. (CEST). It will be a (German language only) video livestream (see: http://www.heise.de/netze/dnssec-day) where all four parties will discuss topics related to DNSSEC and DANE. Articles and screencasts complement the broadcast. DANE is for machine to machine communication As it is there's almost no support for DANE functionality in end user applications. If there is, the code is not part of the core, but an add-on. It should reside in the core for security reasons. The/some reasons why there's no core support in end user clients at the moment h= ave been discussed on this list. For the time being DANE remains limited to machine to machine communication. That's it for the moment. I hope this summary is useful and we will see wide adoption of DANE soon. p@rick --=20 [*] sys4 AG =20 https://sys4.de, +49 (89) 30 90 46 64 Franziskanerstra=C3=9Fe 15, 81669 M=C3=BCnchen =20 Sitz der Gesellschaft: M=C3=BCnchen, Amtsgericht M=C3=BCnchen: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein =20 --r5Pyd7+fXNt84Ff3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJVjIXOAAoJEFZ3ImvNH9cE7FwP/1ZwiWs+lolXBsj+CnesRPVO 7Q9CXMfm7KMM8qxihOVV1wNmAX5QAdG/cT1E+cyKcgKJIXTayoC/Iv1tfvmUTHgZ xW4nEd/E9Ci/2MNZYYV92JvLoykUI9qs+kCDUpEIcpTiluIe37f8d5pKU1Xj2k01 8DQ3ygUtoeq2tKasjrksznOLNB36v+ZOy8aoSEEEjmCEego2oeQHFXBKcEjoOW5S rIMjLw0T68Ck/Ngd8qqWwZT6h2fGLIRT7qiapossSPoylZrAVT3p1Pj7NT58vEGq anbF9dh3Om4Y0XOjFRK/nd6KHla85+ZWtonm1jYTNQxJrGHA+TRuVXIabRIGqKpF OkfiSU2AtZpUDgSWx67uPYm66WZiUAje3AHLbVZ0999MblpQUV3t7UbRQrm0AHfC vM8RR7Nfnq2Ai1a1ReMLik+1+B/14xNoPxPI0pJfbgDJWqy8g+R7uHS1RAKvKY4k gNkGy6MKpE/UCXA+X70zA3DkkNAMfgji8gfFdkgFACMdY2v95YtgMHop+rHIaDcQ 8OFltISRGt5QCa5SefMtWFgoVZbmg3fnQ/azX/0cZB+eyx45ZkjpNUecmgAIFNqZ 3onnN4ayG+NAOVUX0aZnPPgoqs45i8mzk1UDhq0g563q7JYzNYXPRLB+q8bhN9Ji q7yPd7HXmxtPFOBjY+SW =9RYd -----END PGP SIGNATURE----- --r5Pyd7+fXNt84Ff3-- From nobody Thu Jun 25 22:53: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 8A6CF1B3375 for ; Thu, 25 Jun 2015 22:53:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 oCTOFB_mPj2u for ; Thu, 25 Jun 2015 22:53: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 404841B2F19 for ; Thu, 25 Jun 2015 22:53:15 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 210CD284B64; Fri, 26 Jun 2015 05:53:13 +0000 (UTC) Date: Fri, 26 Jun 2015 05:53:13 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150626055312.GF14121@mournblade.imrryr.org> References: <20150625225054.GB4011@sys4.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150625225054.GB4011@sys4.de> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dane] DANE - Tales and Lessons Learned 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, 26 Jun 2015 05:53:17 -0000 On Fri, Jun 26, 2015 at 12:50:54AM +0200, Patrick Ben Koetter wrote: > # Experience > > Barry also suggested I summarize our experience with DANE. Here's a list > of things we've learned or I believe to have understood (sudden moments > of clarity are a great thing [tm]): Thanks. My experience behind is based primarily on tracking the implementations and deployments of others, rather than doing my own. The main take-away for me has been: Individuals deploying DANE in small scale personal domains to make a statement of support for on-line privacy, often do so as a point-in-time exercise. A year or more later, when the decide to replace their certificate and/or private key, they often neglect to update their TLSA RRset, and end-up with TLSA records that don't match reality, until my monitoring catches up with them and they fix the problem. We need to find ways to embed reminders to do key rotation right into configuration files, README files in directories with keys and certificates, perhaps even the certificates themselves. Also into any monitoring tools that report "imminent" certificate "expiration", which need to remind users about any associated TLSA RRs if any also exist. This needs to be emphasized in product documentation, we must shout it from the rooftops! Server operators really need to take to heart the content of section 8 of the "dane-ops" draft. Substantially fewer early adopters had outright DNSSEC zone signature problems, than failures to update TLSA records. I think this is in part due to the fact that zone re-signing is easily automated, and failures are immediately felt, so are remediated quickly. So while DNSSEC is difficult to deploy, most domains continue to work reliably after initial deployment. There are some domains that have *only* deployed DNSSEC (e.g. much of the ".gov" TLD), and have not yet done anything with DANE, but which have broken firewalls that block requests for "unexpected" DNS query RRtypes. https://tools.ietf.org/html/draft-andrews-dns-no-response-issue-07 This causes some grief for DANE early adopters, but fortunately the domains with working DANE already substantially (more than 10:1) outnumber the domains with broken nameservers. Just a handful of sites fixing nameservers or firewalls would lower this number by another factor of 10. This is IMHO not a long-term concern. Finally, some domains publish TLSA RRs, but install software that selectively enables TLS support only for clients that pass some sort of "good behaviour" test (e.g. SMTP grey-listing). This creates a catch-22, in which DANE clients can never pass the test because the server never offers TLS, and so always fails authentication. This is rather rare, and should not be a significant problem in for most domains. I am hoping that once one or more of the largest domains enables DANE for SMTP, there will be much greater visibility of problems for any administrator who misconfigures his system, resulting in immediately noticeable mail delay. This should act to substantially reduce the number of sites having problems (for any length of time), and I hope administrators will learn to avoid the above and similar problems. On the software implementation side, I continue to see flawed attempts at DANE verification code. Generally, usage DANE-EE(3) is implemented correctly, while the verification logic for usage DANE-TA(2), PKIX-TA(0) and PKIX-EE(1) is often rather insufficient to the task. Implementors often don't take the time to understand that the "heap" of wire certificates from the remote peer don't necessarily form any sort of "chain", or even if a chain can be formed from the leaf to some ultimate issuer, that chain may well not include any of the certificates in the peer's "heap" that matched the TLSA RRset. Finding some certificate on the wire that matches the TLSA RRset is far from sufficient unless that is the leaf certificate, and the usage is DANE-EE(3). Then we have the usual failures to perform hostname checks (all usages other than DANE-EE(3)), or to support the additional reference identifiers required in the SMTP and SRV drafts. Bottom line, without a major investment of time, and great care, even reasonably experienced programmers are only able to write correct validation for DANE-EE(3) and no other usages. Had the DANE WG in crafting RFC 6698 given much more weight to programmer fallibility, we might have had just usage DANE-EE(3) to contend with (and it likely would have been good enough for everyone, despite the fact that DANE-TA(2) has some operational advantages for large deployments). Reaching rough consensus on such a "radically" minimal model was likely not possible, but we're likely to deal with security advisories for DANE-enabled products that are due to the complexity of the other options. As of today, I am tracking 1450 domains with DANE TLSA records published for at least one of the best preference MX hosts, Most have all MX hosts covered by TLSA RRs. -- Viktor. From nobody Thu Jun 25 23:26: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 741E71B2FC0 for ; Thu, 25 Jun 2015 23:26:14 -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 jA0QOnAFoF4o for ; Thu, 25 Jun 2015 23:26:13 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBAF21B2D95 for ; Thu, 25 Jun 2015 23:26:12 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx.ams1.isc.org (Postfix) with ESMTPS id 0EE0E1FCCCB for ; Fri, 26 Jun 2015 06:26:09 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id AA43C160042 for ; Fri, 26 Jun 2015 06:26:49 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 93EAE16006D for ; Fri, 26 Jun 2015 06:26:49 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id aUO159Fej69X for ; Fri, 26 Jun 2015 06:26:49 +0000 (UTC) Received: from rock.dv.isc.org (c122-106-161-187.carlnfd1.nsw.optusnet.com.au [122.106.161.187]) by zmx1.isc.org (Postfix) with ESMTPSA id 28203160042 for ; Fri, 26 Jun 2015 06:26:49 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 39E813161F42 for ; Fri, 26 Jun 2015 16:26:04 +1000 (EST) To: dane@ietf.org From: Mark Andrews References: <20150625225054.GB4011@sys4.de> <20150626055312.GF14121@mournblade.imrryr.org> In-reply-to: Your message of "Fri, 26 Jun 2015 05:53:13 +0000." <20150626055312.GF14121@mournblade.imrryr.org> Date: Fri, 26 Jun 2015 16:26:04 +1000 Message-Id: <20150626062604.39E813161F42@rock.dv.isc.org> Archived-At: Subject: Re: [dane] DANE - Tales and Lessons Learned X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 26 Jun 2015 06:26:14 -0000 In message <20150626055312.GF14121@mournblade.imrryr.org>, Viktor Dukhovni writes: > There are some domains that have *only* deployed DNSSEC (e.g. much > of the ".gov" TLD), and have not yet done anything with DANE, but > which have broken firewalls that block requests for "unexpected" DNS > query RRtypes. > > https://tools.ietf.org/html/draft-andrews-dns-no-response-issue-07 There are TLD operators that break lookups based on the query type. See: http://ednscomp.isc.org/compliance/tld-typereport.txt The "CDS=refused" are, we believe, due to a bug in BIND 9.8.8/9.9.6/9.10.1 which is fixed in BIND 9.9.7/9.10.2. BIND 9.8.8/9.9.6/9.10.1 add master file support for CDS. 4049. [bug] CDS and CDNSKEY had the wrong attributes. [RT #38491] Firewalls are a pain in the backside for DNS. Do anything sightly different but still with well defined server behaviour specified and you will see a firewall drop it. http://ednscomp.isc.org/compliance/summary.html Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Fri Jun 26 00:23: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 2FEB21B34AF for ; Fri, 26 Jun 2015 00:23:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.251 X-Spam-Level: X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 wiqsez7VNgeG for ; Fri, 26 Jun 2015 00:23:45 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id CF9B31B34AD for ; Fri, 26 Jun 2015 00:23:44 -0700 (PDT) Received: from [192.168.40.15] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 558B693C1AF; Fri, 26 Jun 2015 07:22:41 +0000 (UTC) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_CC84127D-71F2-4066-AE38-692254F6DB98"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Pgp-Agent: GPGMail 2.5b6 From: "Olle E. Johansson" In-Reply-To: <20150625225054.GB4011@sys4.de> Date: Fri, 26 Jun 2015 09:23:39 +0200 Message-Id: <90289F96-640F-4271-98EA-529FD0A0F111@edvina.net> References: <20150625225054.GB4011@sys4.de> To: Patrick Ben Koetter X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: dane@ietf.org Subject: Re: [dane] DANE - Tales and Lessons Learned X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 26 Jun 2015 07:23:49 -0000 --Apple-Mail=_CC84127D-71F2-4066-AE38-692254F6DB98 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Thank you! Great summary, I learned a lot. /Olle On 26 Jun 2015, at 00:50, Patrick Ben Koetter wrote: > Greetings, >=20 > I gave a presentation called "One year of DANE - Tales and Lessons = Learned" at > the 34th M=B3AA3WG General Meeting in Dublin a few weeks ago. Barry = (Leiba) > asked me in an offlist mail to share the slides with you on this list = and also > write about the experience we've made during the last 1,5 years. >=20 > # Slides > Here's a quick rundown to give an idea what my presentation was about: >=20 > The first part is technical. It starts off naming the issues = traditional > opportunistic TLS faces today. Then they show an approach/plan to = solve the > named issues only to present DANE as a solution next. The slides then = show and > discuss current use cases for DANE (with a strong focus on email) - = HTTPS, > SMTP, OPENPGPKEYS, SMIMEA. >=20 > The second part deals with adoption, possible markets and reasons why = the one > or the other TLD has a better starting position to adopt DANE. It also = lists > things we have learned during the last 1,5 years working with DANE or = get to > hear often when we talk with people interested to DANE-enable their > infrastructure. >=20 > Download the slides at https://sys4.de/download/dane-maawg.pdf. >=20 >=20 > # Experience > Barry also suggested I summarize our experience with DANE. Here's a = list of > things we've learned or I believe to have understood (sudden moments = of clarity > are a great thing [tm]): >=20 > DANE is server and client > DANE may be used by clients and offered to others. This is obvious = once > you've become aware of that, but people seem to focus at the = "offering > DANE part" above average. And they seem to fade out the client = side. >=20 > When they realize the server side isn't low hanging fruit they seem = to get > stuck. Shifting their focus to the client side helps. That's the = low > hanging fruit (assuming you have DANE capable clients at hand). >=20 > Using DANE in a client is easy > You need a DNSSEC-capable resolver and DANE capable client = software. It's > simple, compared to offering DANE, because these componets are = simplier to > control and problems stay your own. Failures have comparatively = limited > effect. Postmasters change settings within their well-known = application. > They don't need to deal with a DNS server, which they might not = know as > well or need to talk a hostmaster to do something for them (they = don't > feel comfortable with). >=20 > DNSSEC-enabling your infrastructure requires careful thinking > DNSSEC is about security. The right way [tm] to do DNSSEC on a host = is to > equip it with a local DNSSEC-capable resolver. If you want to add > fallback resolvers (resolv.conf) *all* of them need to be = DNSSEC-capable > or you might end up with a (bad,insecure,...) DNS reply that would = have > been suppressed by a DNSSEC aware resolver. >=20 > Careful if your run your own, internal TLD > Local TLDs are not DNSSEC signed by default. DNSSEC-aware resolvers = will > suppress answers unless you DNSSEC-enable the internal ZONE or = configure > the resolvers to ignore the DNSSEC chain of trust for that = particular > domain. Test before or you will risc needless service outage. >=20 > Check your firewalls > TLSA, SMIMEA and OPENPGPKEYS queries to DNS servers end up in TCP = answers. > Your firewall must permit TCP on 53. (Most people will probably = have that > in place if they also serve DKIM. If not this might be the answer = to these > strange DNS problems... ;) > Check also that your firewall doesn't filter RRs. It might drop = requests > for TLSA and all the other new RRs. It works from inside, but fails = for > outside requests. >=20 > Offering DANE RRs is all about DNSSEC > Offering DANE requires a DNSSEC-enabled DNS server. Everything = after > DNSSEC-enabling the DNS server is comparatively easy. >=20 > DNSSEC-enabling is the hardest part > People are scared to DNSSEC-enable their domain(s). They have to = upgrade > their applications. They have to clean up/refactor/get a better > understanding of their service. (You're up and running in a few = minutes > and once that works you don't spend time with DNS anymore - unless = you're > a large player or do DNS for business). >=20 > Registrars don't invest in DNSSEC > Offering DNSSEC means to invest in security. It requires to invest = in a > race to the bottom market where cheaper seems to be more important = than > more secure. The market interest for DNSSEC isn't great enough at = the > moment to invest into DNSSEC. (In .nl the goverment subsidizes > DNSSEC-enabled domains. Surveys indicate 50% of .nl is = DNSSEC-enabled!) >=20 > DNSSEC-capable registrars are hard to find > At least in .de its hard to find a registrar offering DNSSEC. One = of the > question we get to hear all the time is if we could recommend a = list of > DNSSEC registrars in Germany. To me this seems directly related to = the > little invest we see in DNSSEC on the registrars side - a chicken = egg > dilemma. >=20 > Monitor your DNSSEC domain > Keep an eye on your zones signature TTL. If it expires = DNSSEC-capable > resolvers will suppress replies. They will ignore your domain until = you've > renewed the signature. Monitor your DNSSEC domain. Monitor TTLs and = TLSA > pinned certificate enddates (see next lesson). >=20 > RR rollover requires more careful handling > If you need to roll in a new TLSA (or any other DANE related = record) make > you do it in advance. Leave the old one and add the new one. Wait = two TTL > cycles. Give clients out there time to revisit and learn the new = RR. Only > then remove the old one. >=20 > If you forget to add the new RR you risk receiving no mail from = DANE > enabled clients. They check the RR and if you publish an old TLSA, = but use > a new cert they will not send. That's just how DANE should work. ;) >=20 > Automate the rollover and make sure the rollover works reliably = *before* > you upload your zones signing key to your registrar and publicly > DNSSEC-able your domain. >=20 > DNSSEC obstructs DANE > People who critice DANE usually criticise it because of DNSSEC. = They say > DNSSEC hasn't been worked on for too long time. The standard should = be > updated. They say it doesn't provide the level of security it could = and > should for something as important as DANE to build upon. =46rom = their point > of view DANE security is directly linked to the level of security = DNSSEC > provides. I'm no DNS expert to tell how much substance there is in = their > criticism. If there is updating DNSSEC standards might help to = break the > ice. >=20 > There's no market for DANE at the moment > Everybody seems to wait for everybody else to start using/offering > DNSSEC/DANE. Those who DANE enable their clients find only few DANE > enabled servers to communicate with. Those who could DNSSEC-enable = their > domains and could start serving DANE-related RRs don't see the = benefit to > go through all the required work. >=20 > We - heise.de (Germany's most popular IT magazine and portal), BSI > (Federal Office for Information Security), DENIC (Germanys .de TLD > registry) and sys4 - spent about half a year to prepare a = DNSSEC-Day. >=20 > DNSSEC-Day will take place next week Tuesday (June, 30th) between 2 = p.m > and 6 p.m. (CEST). It will be a (German language only) video = livestream > (see: http://www.heise.de/netze/dnssec-day) where all four parties = will > discuss topics related to DNSSEC and DANE. Articles and screencasts > complement the broadcast. >=20 > DANE is for machine to machine communication > As it is there's almost no support for DANE functionality in end = user > applications. If there is, the code is not part of the core, but an > add-on. It should reside in the core for security reasons. The/some > reasons why there's no core support in end user clients at the = moment have > been discussed on this list. > For the time being DANE remains limited to machine to machine > communication. >=20 >=20 > That's it for the moment. I hope this summary is useful and we will = see wide > adoption of DANE soon. >=20 > p@rick >=20 > -- > [*] sys4 AG >=20 > https://sys4.de, +49 (89) 30 90 46 64 > Franziskanerstra=DFe 15, 81669 M=FCnchen >=20 > Sitz der Gesellschaft: M=FCnchen, Amtsgericht M=FCnchen: HRB 199263 > Vorstand: Patrick Ben Koetter, Marc Schiffbauer > Aufsichtsratsvorsitzender: Florian Kirstein >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane --Apple-Mail=_CC84127D-71F2-4066-AE38-692254F6DB98 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: http://edvina.net iQGcBAEBCAAGBQJVjP37AAoJEDCi1qX1P5VG29IMAKRmONWyBEO5vd2vY3aaI+72 nAEBMCBIPktx7WvDiuRVs3wB2Pjc52ogDnSTn+3sEs2wIwIWYgmHRDmed4Nu5XNu x50eGMIDJnTcjCRFi3Ei9Y0BgFOCQtRz1MRs4FufMVTQpXLoXkt72kalI7vxw8/B CqNZp6WGDiQDvdBDhDWsHRTolhw7cqaEv+cUkJoAfTR7piZzrVIHSgK9cWBYiYSz Roaqmcr+foTaNBjU2LrxYYJGe4xdd6SAV0dCZH9Teev8HfC8FoDRfoNTAwnQAzdS dNXHN9/VY2mNzJ3Om2F7isDfDOoxIJSi4l18e+KjH4xArNOcVXmwJmUfHVw5xe3d TyIBFJdw5rZoc9Y7/sYvPrEDYQmy9CzbWOWazGXf9bhm/C3HLSKh3V62dU8n20Rw 1YBeeCqOlhTsIv2siAaVKuGBVPbCP5jxrMLpqTqN8kBLReuRhQF/SMT0t8p3d82l BfrrYovtg58Le/AAPnbvIxUcfJUYt6KuSEHQ9NBQ+w== =vPQD -----END PGP SIGNATURE----- --Apple-Mail=_CC84127D-71F2-4066-AE38-692254F6DB98-- From nobody Mon Jun 29 11:41: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 64D701A903C for ; Mon, 29 Jun 2015 11:41:08 -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 8WRkPWLxKlxh for ; Mon, 29 Jun 2015 11:41:07 -0700 (PDT) Received: from smtp100.iad3a.emailsrvr.com (smtp100.iad3a.emailsrvr.com [173.203.187.100]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53D331A9023 for ; Mon, 29 Jun 2015 11:41:07 -0700 (PDT) Received: from smtp29.relay.iad3a.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp29.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 7C31238010E for ; Mon, 29 Jun 2015 14:41:06 -0400 (EDT) Received: by smtp29.relay.iad3a.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id 5AD7C3800BC for ; Mon, 29 Jun 2015 14:41:06 -0400 (EDT) X-Sender-Id: ogud@ogud.com Received: from [10.0.0.26] (c-73-159-10-46.hsd1.ma.comcast.net [73.159.10.46]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:587 (trex/5.4.2); Mon, 29 Jun 2015 18:41:06 GMT From: Olafur Gudmundsson Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: Date: Mon, 29 Jun 2015 14:41:05 -0400 To: dane Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) X-Mailer: Apple Mail (2.2098) Archived-At: Subject: [dane] Deferral of SMIME draft X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2015 18:41:08 -0000 Dear Colleagues =20 The editors of draft-ietf-dane-smime have requested that draft be put on = hold for at least a year to see how the OPENPGP =E2=80=9Cexperiment=E2=80=9D= works out. The chairs have agreed with this request.=20 Olafur & Warren=20 From nobody Mon Jun 29 11: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 09E6A1A902E for ; Mon, 29 Jun 2015 11:42: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 uX_JhwY6S5DQ for ; Mon, 29 Jun 2015 11:42:07 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B02001A9040 for ; Mon, 29 Jun 2015 11:42:06 -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.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150629184206.23743.52790.idtracker@ietfa.amsl.com> Date: Mon, 29 Jun 2015 11:42:06 -0700 From: IETF Secretariat Archived-At: Subject: [dane] Milestones changed for dane WG 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, 29 Jun 2015 18:42:08 -0000 Changed milestone "Advance DANE SMIME document to IESG", set due date to August 2015 from August 2014. URL: https://datatracker.ietf.org/wg/dane/charter/ From nobody Mon Jun 29 13:27: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 90D641A1A8C for ; Mon, 29 Jun 2015 13:27:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.195 X-Spam-Level: X-Spam-Status: No, score=0.195 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] 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 QxuCTW65TFCC for ; Mon, 29 Jun 2015 13:27:23 -0700 (PDT) Received: from shannon.7bits.nl (shannon.7bits.nl [IPv6:2a01:1b0:202:40::1]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE28F1A1A8B for ; Mon, 29 Jun 2015 13:27:23 -0700 (PDT) Received: from [192.168.0.13] (e163253.upc-e.chello.nl [213.93.163.253]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: peter) by shannon.7bits.nl (Postfix) with ESMTPSA id 02583C1B55; Mon, 29 Jun 2015 22:27:19 +0200 (CEST) From: "Peter van Dijk" To: dane@ietf.org Date: Mon, 29 Jun 2015 22:27:19 +0200 Message-ID: In-Reply-To: <20150629184206.23743.52790.idtracker@ietfa.amsl.com> References: <20150629184206.23743.52790.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.1r5084) Archived-At: Subject: Re: [dane] Milestones changed for dane WG X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2015 20:27:25 -0000 Hello, On 29 Jun 2015, at 20:42, IETF Secretariat wrote: > Changed milestone "Advance DANE SMIME document to IESG", set due date > to August 2015 from August 2014. > > URL: https://datatracker.ietf.org/wg/dane/charter/ If they want to watch the OPENPGPKEY experiment for a year, shouldn’t this at least be August 2016? Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ From nobody Mon Jun 29 17:02: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 912F31B3645 for ; Mon, 29 Jun 2015 17:02:00 -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 HmSTp0saYVPc for ; Mon, 29 Jun 2015 17:01: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 89C5C1B3643 for ; Mon, 29 Jun 2015 17:01:57 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3mL5TG6GB9z9bv; Tue, 30 Jun 2015 02:01:54 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=IXcIKarE 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 RxH3m8mnuBrj; Tue, 30 Jun 2015 02:01:52 +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; Tue, 30 Jun 2015 02:01:52 +0200 (CEST) Received: from [192.168.101.152] (unknown [181.93.14.4]) by bofh.nohats.ca (Postfix) with ESMTPSA id 59B0080042; Mon, 29 Jun 2015 20:01:50 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1435622510; bh=prTu0Hg8AwJIfmYwN1AzgUxgSHP4sWkrtwhOiBQs9gI=; h=References:In-Reply-To:Cc:From:Subject:Date:To; b=IXcIKarEUBP9y+9py4kwm6zyaFvjOnUy1KF5H7OL5CzX4T4JzEWUCITPtf03/iW51 CFUTMSQC1vB8H0D2nK5n3hyU+/iFk8iSUdgWANyKKFM+csXQhaIC+ibFkmGOJsOz4m hax6Pa5n5jQyVc0l5MhRSQkQyhGUuEORVB8cyEqU= References: Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <02F05872-7915-4D3F-8F07-1758E683B18F@nohats.ca> X-Mailer: iPhone Mail (12B466) From: Paul Wouters Date: Mon, 29 Jun 2015 21:01:35 -0300 To: Olafur Gudmundsson Archived-At: Cc: dane Subject: Re: [dane] Deferral of SMIME draft X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2015 00:02:00 -0000 That's a little unfortunate because we're merging two prototypes millers int= o one. But we'll adapt the smime one based on the same prefix as openpgpkey Sent from my iPhone > On Jun 29, 2015, at 15:41, Olafur Gudmundsson wrote: >=20 >=20 > Dear Colleagues =20 > The editors of draft-ietf-dane-smime have requested that draft be put on h= old for at least a year to see how the OPENPGP =E2=80=9Cexperiment=E2=80=9D w= orks out. The chairs have agreed with this request.=20 >=20 > Olafur & Warren=20 >=20 >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From nobody Mon Jun 29 18:43: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 9DE661A88F1 for ; Mon, 29 Jun 2015 18:43: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 DAVKJO2s68BD for ; Mon, 29 Jun 2015 18:43:15 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C5AD51A88F2 for ; Mon, 29 Jun 2015 18:43:11 -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.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150630014311.4362.34976.idtracker@ietfa.amsl.com> Date: Mon, 29 Jun 2015 18:43:11 -0700 From: IETF Secretariat Archived-At: Subject: [dane] Milestones changed for dane WG X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2015 01:43:17 -0000 Changed milestone "Advance DANE reverse binding (server to client) document to IESG", set due date to December 2015 from June 2015. Changed milestone "Advance DANE security model document to IESG", set due date to December 2015 from January 2015. Changed milestone "Advance DANE IPSEC document to IESG", set due date to December 2015 from May 2015. Changed milestone "Advance DANE RFC6698 and DANE SRV RFC to Internet Standard", set due date to January 2016 from September 2015. Changed milestone "Advance DANE SMIME document to IESG", set due date to August 2016 from August 2015. Changed milestone "Recharter or close down", set due date to August 2016 from November 2015. Changed milestone "Advance DANE operational guidance/errata document to IESG", set due date to August 2016 from September 2014. URL: https://datatracker.ietf.org/wg/dane/charter/ From nobody Mon Jun 29 18:44: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 AE64B1A88F2 for ; Mon, 29 Jun 2015 18:44:09 -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 hcVWvGwwVOXB for ; Mon, 29 Jun 2015 18:44:07 -0700 (PDT) Received: from smtp108.iad3a.emailsrvr.com (smtp108.iad3a.emailsrvr.com [173.203.187.108]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7934F1A88F1 for ; Mon, 29 Jun 2015 18:44:07 -0700 (PDT) Received: from smtp22.relay.iad3a.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp22.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 87D4938018F; Mon, 29 Jun 2015 21:44:06 -0400 (EDT) Received: by smtp22.relay.iad3a.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id 638A438012B; Mon, 29 Jun 2015 21:44:04 -0400 (EDT) X-Sender-Id: ogud@ogud.com Received: from [10.0.0.26] (c-73-159-10-46.hsd1.ma.comcast.net [73.159.10.46]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:587 (trex/5.4.2); Tue, 30 Jun 2015 01:44:06 GMT Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Olafur Gudmundsson In-Reply-To: Date: Mon, 29 Jun 2015 21:44:04 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <39C5BBCD-2FCE-4E60-9056-360996579478@ogud.com> References: <20150629184206.23743.52790.idtracker@ietfa.amsl.com> To: Peter van Dijk X-Mailer: Apple Mail (2.2098) Archived-At: Cc: dane@ietf.org Subject: Re: [dane] Milestones changed for dane WG X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2015 01:44:09 -0000 > On Jun 29, 2015, at 4:27 PM, Peter van Dijk = wrote: >=20 > Hello, >=20 > On 29 Jun 2015, at 20:42, IETF Secretariat wrote: >=20 >> Changed milestone "Advance DANE SMIME document to IESG", set due date >> to August 2015 from August 2014. >>=20 >> URL: https://datatracker.ietf.org/wg/dane/charter/ >=20 > If they want to watch the OPENPGPKEY experiment for a year, = shouldn=E2=80=99t this at least be August 2016? >=20 Remind me not to change milestones with a glass of red wine in my hand = :-) fixed=20 Olafur > Kind regards, > --=20 > Peter van Dijk > PowerDNS.COM BV - https://www.powerdns.com/ >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From nobody Mon Jun 29 23:25:25 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 CD9AF1AC3DF; Mon, 29 Jun 2015 23:25:23 -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, 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 7j9PVihA7FCL; Mon, 29 Jun 2015 23:25: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 DF7D61ABB19; Mon, 29 Jun 2015 23:25:20 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id A2861282FB9; Tue, 30 Jun 2015 06:25:18 +0000 (UTC) Date: Tue, 30 Jun 2015 06:25:18 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20150630062518.GC14121@mournblade.imrryr.org> References: <55922571.8080605@nomountain.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55922571.8080605@nomountain.net> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: dane@ietf.org Subject: Re: [dane] [TLS] draft-shore-tls-dnssec-chain-extension-00 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tls@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2015 06:25:24 -0000 On Mon, Jun 29, 2015 at 09:13:21PM -0800, Melinda Shore wrote: > Please have a look at it and get comments or suggestions > to us. We're planning on getting one more revision out > prior to the Prague meeting, and on having a test > implementation available in Prague. > The draft is available at: > https://tools.ietf.org/html/draft-shore-tls-dnssec-chain-extension-00 1. There's a more compelling reason than stated why the extension is not well suited to MTA to MTA SMTP. With MTA to MTA SMTP DANE is opportunistic, (START)TLS is optional unless a requirement for authenticated signalled via TLSA records. Such signalled cannot be postponed to the TLS handshake, because that handshake may not even take place unless the SMTP client MTA knows that TLS is required. Even if TLS were to be used, authentication is generally not required in MTA to MTA traffic, so the extension would be vulnerable to MITM attacks. Similar considerations apply to server-to-server XMPP traffic. Thus the extension in question is only relevant with protocols where TLS (with authenticaiton) is mandatory, and DANE is a potentially attractive alternative PKI. With opportunistic DANE TLS, the extension is inevitably too late. 2. That said, the extension is a potentially good fit for MUA to MSA submission, and XMPP user-agent (client) to first-hop XMPP server, where the user agent statically enforces TLS, and generally connects to a single fixed server it can reasonably authenticate. 3. I'm not sure what purpose the last paragraph of section 3 is intended to serve: Obviously, an authentication chain will be most compact and easiest to verify if each RRset has a single record, i.e., if there is a single DNSKEY RR and a single DS RR at each step. In addition, as suggested above, keeping zone cuts to a minimum also reduces the length of the authentication chain. The TLS server has no choice but to return the complete RRset for each owner name class and RRtype, since RRSIGs cover RRsets, not individual RRs. So "compacting" is possible. The server returns the RRsets exactly as published by the relevant DNS(SEC) servers. Speaking of RRsets, are the RRs in each RRset returned by the server required to be sorted in canonical order? 4. I think the Section 4 SNI interaction would be a lot cleaner, if SNI is mandatory for clients that use the proposed extension. In which case the server can only respond with a leaf TLSA RRset (and chain of RRSIG/DNSKEY/DS/... records) whose "base domain" ( see section 3 of RFC6698 and soon definition of TLSA base domain in draft-ietf-dane-ops-13 (later this week)). Using some random name for the server's IP address is not a good idea IMHO. PTR records are too often poorly correlated with the client's notion of the target server name. 5. In Section 5, the server MUST not violate DNS TTLs. The last senetence: Alternatively, it could be configured to rebuild the chain at some predefined periodic intervals. is I fear too much rope. Sure the server can periodically flush its cache (using shorter than possible TTLs), but this does not free it of the obligation to not extend TTLs by relying exclusively on a cache lifetime of its own choosing. 6. Note that the soon up for IESG review draft-ietf-dane-ops considerably revises the DANE verification logic for TLSA certificate usage DANE-EE(3). Section 6 should refer to draft-ietf-dane-ops-12 (soon -13 which responds to AD and GEN-ART comments) as well as RFC6698. 7. The draft often says "TLSA record" when it needs to say "TLSA RRset". It will be quite common for multiple TLSA RRs to be present in the RRset, as this is required to correctly effect key rotation. Therefore, in Section 6 (and elsewhere), text such as the below: If the record is correctly authenticated, the client then performs DANE authentication according to the DANE TLS protocol [RFC6698]. is sub-optimal, it should refer to a TLSA RRset, which MUST contain at least one TLSA record that matches the server's certificate chain, but will often contain additional records that do not. 8. Great care must be taken (with Certificate usages other than DANE-EE(3)) to ensure that the TLSA record matches a certificate that is actually part of the server's chain and not just some random unrelated certificate that happens to be present in the server certificate message. Many implementors fail to check this. 9. This draft should reiterate the requirement that with certificate usage DANE-TA(2), the server MUST include the trust-anchor certificate in its certificate message even if that trust-anchor is self-signed (root CAs are NOT optional with DANE-TA(2)). 10. Validation of RRSIGs is a subtle art, the client will definitely need to check not only the signatures but also the validity intervals of all RRSIGs (the client must trust its own clock or have access to a trusted time source). Since the server forwards wire-format RRsets, these include TTLs, and clients might plausibly cache these, provided the TTLs are consistent with the RRSIG validity intervals. The draft might provide guidance on any client-side caching (clients might e.g. not even send the extension when they have unexpired cached TLSA data from a previous interaction with the server). 11. Finally, Shumon Huque (mostly) and I (helping out) are writing a draft to specify DANE TLSA for client authentication. If and when that progresses (WG adoption, ...), there may need to be a similar extension, allowing a client to forward its DNSSEC-validated TLSA RRset. This is not an immediate priority and can be re-evaluated later. -- Viktor. From nobody Tue Jun 30 02:20: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 D78781A1EF3 for ; Tue, 30 Jun 2015 02:20:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.548 X-Spam-Level: X-Spam-Status: No, score=0.548 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 Ah5pXQKKsEK4 for ; Tue, 30 Jun 2015 02:20:16 -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 555051A1B83 for ; Tue, 30 Jun 2015 02:20:16 -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 3mLKqb21BLzGnxj; Tue, 30 Jun 2015 11:18:35 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=roessner-network-solutions.com; s=swioBi3opho; t=1435655915; i=@roessner-network-solutions.com; bh=SVJC7ZdPTIHGz24PfOMyTGNoDWPLTU//5HqrGnw7rIg=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=ROmoUKTx7G/yeJWBsmcbI+460c9x8dVi6salJMP23aO31zw4Lg2Eq6mvZrof6jlET N2tm/OP1CXXVOyibkt+wzrhCgAzWMgB3qe2ZkrfbRk7gqSKIlJaySJhjxmHc6ETSYM EAdflaZlSnzfmmt3kYgIFSA2G0+yklfJmptiDEbwC6btbTc6rt6seN7NHmwwQBC0qu BbN0CzHellRsdagKtyLG42vrM1HejqOFAlFdtB9L+1FVVK3gbmO/zO7kWeD3eh6TEs WWysafReKD0kqjgvFzmKVUOT++uDQsrO/13A5mltZ613uxf1sowpok9hl341Yyooly /DOYBywQpWycg== 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 3mLKqZ5LYpzMl0m; Tue, 30 Jun 2015 11:18:34 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: =?utf-8?Q?Christian_R=C3=B6=C3=9Fner?= In-Reply-To: <02F05872-7915-4D3F-8F07-1758E683B18F@nohats.ca> Date: Tue, 30 Jun 2015 11:20:13 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8E9AC093-084B-48D0-A13E-FB2335DACF4F@roessner-network-solutions.com> References: <02F05872-7915-4D3F-8F07-1758E683B18F@nohats.ca> To: Paul Wouters X-Mailer: Apple Mail (2.2102) Outgoingd-Filter: Outgoingd Filter v0.4.0_m1 mail.roessner-net.de 3mLKqZ5LYpzMl0m Anomaly-Results: mail.roessner-net.de; rate=0% Archived-At: Cc: dane Subject: Re: [dane] Deferral of SMIME draft X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2015 09:20:18 -0000 > Am 30.06.2015 um 02:01 schrieb Paul Wouters : >=20 > That's a little unfortunate because we're merging two prototypes = millers into one. But we'll adapt the smime one based on the same prefix = as openpgpkey I fully agree. I have spent many hours on developing a prototype for = SMIMEA. This code should be merged with Paul=E2=80=99s code :-( N.B.: I use this prototype already in production stage for testing and = it works perfectly. So I really can not understand this decision. Christian >=20 > Sent from my iPhone >=20 >> On Jun 29, 2015, at 15:41, Olafur Gudmundsson wrote: >>=20 >>=20 >> Dear Colleagues =20 >> The editors of draft-ietf-dane-smime have requested that draft be put = on hold for at least a year to see how the OPENPGP =E2=80=9Cexperiment=E2=80= =9D works out. The chairs have agreed with this request.=20 >>=20 >> Olafur & Warren=20 >>=20 >>=20 >> _______________________________________________ >> dane mailing list >> dane@ietf.org >> https://www.ietf.org/mailman/listinfo/dane >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From nobody Tue Jun 30 06:59: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 D6E9B1A0235 for ; Tue, 30 Jun 2015 06:59:54 -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 0Gmg-5ARGcDC for ; Tue, 30 Jun 2015 06:59:53 -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 DE6BA1A1A34 for ; Tue, 30 Jun 2015 06:59:52 -0700 (PDT) Received: by qgdz60 with SMTP id z60so477800qgd.0 for ; Tue, 30 Jun 2015 06:59:52 -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 :user-agent:content-type:content-id:content-transfer-encoding :mime-version; bh=wU/6jf/mhEZl2CO/g3ZLCz2mKZ+dM7ucyHtr2N2xN/s=; b=fO4S2mnYcHs5O5aPcF+rateJnm30OeAkkmA4lVqUc1/a8smRBJi0rlQH146hh43Dow zd4Oju2N2fBwWeI4rnf3c5Dh/E9yBK4c1nnRKgQk/WgG2SuMJgmk00Tw4J/FkZ+i+tgI O5Upfq0h2gLOnRhblrsiL8Z6wZu5YoG+cOT8KZ1UCh26d9sQ9XLiaDx0M0pS496vosOD lrbt++JRiJqGVYfsIEtbgnuI4x+vNyM+aFJWgea6w/b4D0v/7ttjOx1lfz7MJav3TwM7 qza5i2wi0Ib+fG8BpTADvI8KVt23O5GxlbptL3t/y7/p3/8N+4K6uem9H6dpvRis+TwB YMJA== X-Gm-Message-State: ALoCoQl9TFysEbkrTfA2qC/oTIWnFCYOFmHcZdrIcfjSKwPZWU9C2hp7xL5bq4cQlIApIN+UidH8hMVz+rJY4aW96HV75WHFFQ== X-Received: by 10.140.96.230 with SMTP id k93mr21304882qge.7.1435672792140; Tue, 30 Jun 2015 06:59:52 -0700 (PDT) Received: from brn1lxmailout02.verisign.com (brn1lxmailout02.verisign.com. [72.13.63.42]) by mx.google.com with ESMTPS id b15sm651484qkh.2.2015.06.30.06.59.51 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 30 Jun 2015 06:59:52 -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 t5UDxn9i030010 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 30 Jun 2015 09:59:51 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Tue, 30 Jun 2015 09:59:37 -0400 From: "Wiley, Glen" To: Olafur Gudmundsson , dane Thread-Topic: [dane] Deferral of SMIME draft Thread-Index: AQHQspsq+hwuYwzV6EqI+OdyRokHqJ3FFNWA Date: Tue, 30 Jun 2015 13:59:37 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.9.150325 x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <2F7E9A4DCFF8194FAB6922FE04B406A7@verisign.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [dane] Deferral of SMIME draft X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2015 13:59:55 -0000 I am a big fan of PGP, however considering the current use of SMIME in existing mail implementations I don=B9t understand the rationale for the deferral. Since some of the more popular MUAs are able to digest SMIME already doesn=B9t it make sense to include SMIMEA in the DANE toolbox to leverage that operational footprint? --=20 Glen Wiley Principal Engineer Verisign, Inc. (571) 230-7917 http://vbsdcon.com A5E5 E373 3C75 5B3E 2E24 6A0F DC65 2354 9946 C63A On 6/29/15, 2:41 PM, "Olafur Gudmundsson" wrote: > >Dear Colleagues =20 >The editors of draft-ietf-dane-smime have requested that draft be put on >hold for at least a year to see how the OPENPGP =B3experiment=B2 works out= . >The chairs have agreed with this request. > >Olafur & Warren=20 > > >_______________________________________________ >dane mailing list >dane@ietf.org >https://www.ietf.org/mailman/listinfo/dane From nobody Tue Jun 30 10:12: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 15D121AD374 for ; Tue, 30 Jun 2015 10:12:11 -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 k_0wahWV4Ory for ; Tue, 30 Jun 2015 10:12:08 -0700 (PDT) Received: from mail-oi0-f100.google.com (mail-oi0-f100.google.com [209.85.218.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 CD7F51AD1A6 for ; Tue, 30 Jun 2015 10:12:06 -0700 (PDT) Received: by oiav1 with SMTP id v1so519079oia.0 for ; Tue, 30 Jun 2015 10:12:06 -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 :user-agent:content-type:content-id:content-transfer-encoding :mime-version; bh=KoYAlKORI001RCra4RtnrBW0HzLoRVv285srHlKTYAw=; b=b7MK4SURiyTupTLEGIkA7rTphM/t+htsxZtRFa8dXjW9Hy+wwXyTpDyjtKQGFnwRVE RcKdUimCPyOlAmy8U5BMrJBMxM5kUtPyd+5K49lP8RT6c18BgZ/Ku6QgVfKj5r5WB5MQ 13pXYDas80QBp7AFTN9b9JfcZfdsQ3QP3nlVbT8YUZFdrTAsKwzs5z6P4kjwaHg/qhGO oGpf8b9ccGQVFmVo8fNTbb5lb/54KTa109lmEQXqvpQWMxDUYQQSAqTHRpwCXcxvvbqB u5+EtxiI/NLWRKMmwsKGqEdd9xiOb4VG1QTjum+ZNLxeP9Cbk7iqb7SgfeWYIFkCmSZH 2kNw== X-Gm-Message-State: ALoCoQlZgxnFK6HhiQGwNUkgqexmwlaoiIIUbupuKjBnop35vqj51cTW+c560EdsowNwcEBhrrexl8iGCwj2hvzlFOlMQR9b2g== X-Received: by 10.140.218.5 with SMTP id o5mr29157760qhb.13.1435684325990; Tue, 30 Jun 2015 10:12:05 -0700 (PDT) Received: from brn1lxmailout02.verisign.com (brn1lxmailout02.verisign.com. [72.13.63.42]) by mx.google.com with ESMTPS id f66sm807508qkf.1.2015.06.30.10.12.05 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 30 Jun 2015 10:12:05 -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 t5UHC4gO020931 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 30 Jun 2015 13:12:05 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Tue, 30 Jun 2015 13:11:53 -0400 From: "Wiley, Glen" To: Patrick Ben Koetter , "dane@ietf.org" Thread-Topic: [dane] DANE - Tales and Lessons Learned Thread-Index: AQHQr5lvEzm8BnTr2U6Bl1h+FiUVSp3FUJIA Date: Tue, 30 Jun 2015 17:11:53 +0000 Message-ID: References: <20150625225054.GB4011@sys4.de> In-Reply-To: <20150625225054.GB4011@sys4.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.9.150325 x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="windows-1254" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [dane] DANE - Tales and Lessons Learned X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2015 17:12:11 -0000 I was there and felt that was an excellent presentation. Thanks for taking the time to bring that to us. --=20 Glen Wiley Principal Engineer Verisign, Inc. (571) 230-7917 http://vbsdcon.com A5E5 E373 3C75 5B3E 2E24 6A0F DC65 2354 9946 C63A On 6/25/15, 6:50 PM, "Patrick Ben Koetter" wrote: >Greetings, > >I gave a presentation called "One year of DANE - Tales and Lessons >Learned" at >the 34th M=B3AA3WG General Meeting in Dublin a few weeks ago. Barry (Leiba= ) >asked me in an offlist mail to share the slides with you on this list and >also >write about the experience we've made during the last 1,5 years. > ># Slides >Here's a quick rundown to give an idea what my presentation was about: > >The first part is technical. It starts off naming the issues traditional >opportunistic TLS faces today. Then they show an approach/plan to solve >the >named issues only to present DANE as a solution next. The slides then >show and >discuss current use cases for DANE (with a strong focus on email) - HTTPS, >SMTP, OPENPGPKEYS, SMIMEA. > >The second part deals with adoption, possible markets and reasons why the >one >or the other TLD has a better starting position to adopt DANE. It also >lists >things we have learned during the last 1,5 years working with DANE or get >to >hear often when we talk with people interested to DANE-enable their >infrastructure. > >Download the slides at https://sys4.de/download/dane-maawg.pdf. > > ># Experience >Barry also suggested I summarize our experience with DANE. Here's a list >of >things we've learned or I believe to have understood (sudden moments of >clarity >are a great thing [tm]): > >DANE is server and client > DANE may be used by clients and offered to others. This is obvious >once > you've become aware of that, but people seem to focus at the "offering > DANE part" above average. And they seem to fade out the client side. > =20 > When they realize the server side isn't low hanging fruit they seem >to get > stuck. Shifting their focus to the client side helps. That's the low > hanging fruit (assuming you have DANE capable clients at hand). > >Using DANE in a client is easy > You need a DNSSEC-capable resolver and DANE capable client software. >It's > simple, compared to offering DANE, because these componets are >simplier to > control and problems stay your own. Failures have comparatively >limited > effect. Postmasters change settings within their well-known >application. > They don't need to deal with a DNS server, which they might not know >as > well or need to talk a hostmaster to do something for them (they don't > feel comfortable with). > =20 >DNSSEC-enabling your infrastructure requires careful thinking > DNSSEC is about security. The right way [tm] to do DNSSEC on a host >is to > equip it with a local DNSSEC-capable resolver. If you want to add > fallback resolvers (resolv.conf) *all* of them need to be >DNSSEC-capable > or you might end up with a (bad,insecure,...) DNS reply that would >have > been suppressed by a DNSSEC aware resolver. > >Careful if your run your own, internal TLD > Local TLDs are not DNSSEC signed by default. DNSSEC-aware resolvers >will > suppress answers unless you DNSSEC-enable the internal ZONE or >configure > the resolvers to ignore the DNSSEC chain of trust for that particular > domain. Test before or you will risc needless service outage. > >Check your firewalls > TLSA, SMIMEA and OPENPGPKEYS queries to DNS servers end up in TCP >answers. > Your firewall must permit TCP on 53. (Most people will probably have >that=20 > in place if they also serve DKIM. If not this might be the answer to >these > strange DNS problems... ;) > Check also that your firewall doesn't filter RRs. It might drop >requests > for TLSA and all the other new RRs. It works from inside, but fails >for > outside requests. > >Offering DANE RRs is all about DNSSEC > Offering DANE requires a DNSSEC-enabled DNS server. Everything after > DNSSEC-enabling the DNS server is comparatively easy. > >DNSSEC-enabling is the hardest part > People are scared to DNSSEC-enable their domain(s). They have to >upgrade > their applications. They have to clean up/refactor/get a better > understanding of their service. (You're up and running in a few >minutes > and once that works you don't spend time with DNS anymore - unless >you're > a large player or do DNS for business). > =20 >Registrars don't invest in DNSSEC > Offering DNSSEC means to invest in security. It requires to invest in >a > race to the bottom market where cheaper seems to be more important >than > more secure. The market interest for DNSSEC isn't great enough at the > moment to invest into DNSSEC. (In .nl the goverment subsidizes > DNSSEC-enabled domains. Surveys indicate 50% of .nl is >DNSSEC-enabled!) > >DNSSEC-capable registrars are hard to find > At least in .de its hard to find a registrar offering DNSSEC. One of >the > question we get to hear all the time is if we could recommend a list >of > DNSSEC registrars in Germany. To me this seems directly related to the > little invest we see in DNSSEC on the registrars side - a chicken egg > dilemma. > >Monitor your DNSSEC domain > Keep an eye on your zones signature TTL. If it expires DNSSEC-capable > resolvers will suppress replies. They will ignore your domain until >you've > renewed the signature. Monitor your DNSSEC domain. Monitor TTLs and >TLSA > pinned certificate enddates (see next lesson). > >RR rollover requires more careful handling > If you need to roll in a new TLSA (or any other DANE related record) >make > you do it in advance. Leave the old one and add the new one. Wait two >TTL > cycles. Give clients out there time to revisit and learn the new RR. >Only > then remove the old one. > > If you forget to add the new RR you risk receiving no mail from DANE > enabled clients. They check the RR and if you publish an old TLSA, >but use > a new cert they will not send. That's just how DANE should work. ;) > > Automate the rollover and make sure the rollover works reliably >*before* > you upload your zones signing key to your registrar and publicly > DNSSEC-able your domain. > >DNSSEC obstructs DANE > People who critice DANE usually criticise it because of DNSSEC. They >say > DNSSEC hasn't been worked on for too long time. The standard should be > updated. They say it doesn't provide the level of security it could >and > should for something as important as DANE to build upon. From their >point > of view DANE security is directly linked to the level of security >DNSSEC > provides. I'm no DNS expert to tell how much substance there is in >their > criticism. If there is updating DNSSEC standards might help to break >the > ice. > >There's no market for DANE at the moment > Everybody seems to wait for everybody else to start using/offering > DNSSEC/DANE. Those who DANE enable their clients find only few DANE > enabled servers to communicate with. Those who could DNSSEC-enable >their > domains and could start serving DANE-related RRs don't see the >benefit to > go through all the required work. > > We - heise.de (Germany's most popular IT magazine and portal), BSI > (Federal Office for Information Security), DENIC (Germanys .de TLD > registry) and sys4 - spent about half a year to prepare a DNSSEC-Day. > > DNSSEC-Day will take place next week Tuesday (June, 30th) between 2 >p.m > and 6 p.m. (CEST). It will be a (German language only) video >livestream > (see: http://www.heise.de/netze/dnssec-day) where all four parties >will > discuss topics related to DNSSEC and DANE. Articles and screencasts > complement the broadcast. > >DANE is for machine to machine communication > As it is there's almost no support for DANE functionality in end user > applications. If there is, the code is not part of the core, but an > add-on. It should reside in the core for security reasons. The/some > reasons why there's no core support in end user clients at the moment >have > been discussed on this list. > For the time being DANE remains limited to machine to machine > communication. > > >That's it for the moment. I hope this summary is useful and we will see >wide >adoption of DANE soon. > >p@rick > >--=20 >[*] sys4 AG >=20 >https://sys4.de, +49 (89) 30 90 46 64 >Franziskanerstra=DFe 15, 81669 M=FCnchen >=20 >Sitz der Gesellschaft: M=FCnchen, Amtsgericht M=FCnchen: HRB 199263 >Vorstand: Patrick Ben Koetter, Marc Schiffbauer >Aufsichtsratsvorsitzender: Florian Kirstein >=20 From nobody Tue Jun 30 14:10: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 6FEC51B29BB; Tue, 30 Jun 2015 14:10:27 -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 pzy5k1cSjE2M; Tue, 30 Jun 2015 14:10:25 -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 123C71B29A8; Tue, 30 Jun 2015 14:10:25 -0700 (PDT) Received: from homiemail-a103.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a103.g.dreamhost.com (Postfix) with ESMTP id AB6622005E627; Tue, 30 Jun 2015 14:10:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=nomountain.net; h= message-id:date:from:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; s= nomountain.net; bh=xWV3aOnylSofTe3X1pgWWO+gw9c=; b=ZePoNx2pi+qud qQToVVzv/gfwhE6SzCV/vBXLAAO1u58c3Vg5GoT95zCevBTGLGnHkwgRcAyea+UT Nu3/vZurhaLg/+C5Joz7nHvYr3TQuvVN8GewcPfiu6maJD0TZSTgxVxsLI50gwib aXJwo4cV4MFJpfFMj4zEN/9HQkXXNU= Received: from spandex.local (216-67-117-38-rb3.fai.dsl.dynamic.acsalaska.net [216.67.117.38]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: melinda.shore@nomountain.net) by homiemail-a103.g.dreamhost.com (Postfix) with ESMTPSA id 0EAE22005E628; Tue, 30 Jun 2015 14:10:23 -0700 (PDT) Message-ID: <559305BD.9050502@nomountain.net> Date: Tue, 30 Jun 2015 13:10:21 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: tls@ietf.org References: <55922571.8080605@nomountain.net> <20150630062518.GC14121@mournblade.imrryr.org> In-Reply-To: <20150630062518.GC14121@mournblade.imrryr.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: dane@ietf.org Subject: Re: [dane] [TLS] draft-shore-tls-dnssec-chain-extension-00 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2015 21:10:27 -0000 Thanks for the detailed review, Viktor. Some of the issues you've raised are still things we're hashing through, and we're grateful for your clarifications. We'll be getting a new draft out before document submission closes and it will incorporate some of your suggestions. On 6/29/15 10:25 PM, Viktor Dukhovni wrote: > Similar considerations apply to server-to-server XMPP traffic. > Thus the extension in question is only relevant with protocols > where TLS (with authenticaiton) is mandatory, and DANE is a > potentially attractive alternative PKI. With opportunistic DANE > TLS, the extension is inevitably too late. Right now our main use case is https, as browser vendors are extremely sensitive to increased latency in connection establishment, and anything we can do to help that can make it easier to argue for implementation. We have, though, been talking about other application protocols, including XMPP, but haven't worked through the details. In particular we haven't looked at opportunistic DANE usage. We'll add some text clarifying that this extension would be inapplicable in those cases. > Speaking of RRsets, are the RRs in each RRset returned by the server > required to be sorted in canonical order? That's one of the things we've been discussing. One of the things that's been driving our decisions so far has been implementation considerations, and in particular how to deliver the data needed for validation to a validator that's part of a DNS API. > 4. I think the Section 4 SNI interaction would be a lot cleaner, > if SNI is mandatory for clients that use the proposed extension. > In which case the server can only respond with a leaf TLSA RRset > (and chain of RRSIG/DNSKEY/DS/... records) whose "base domain" ( > see section 3 of RFC6698 and soon definition of TLSA base domain > in draft-ietf-dane-ops-13 (later this week)). Using some random > name for the server's IP address is not a good idea IMHO. PTR > records are too often poorly correlated with the client's notion > of the target server name. Right, and we actually changed that back and forth a few times. It's not clear to us that SNI is being used across all applications using TLS. I think that generally we're going to need guidelines for application developers. > 6. Note that the soon up for IESG review draft-ietf-dane-ops > considerably revises the DANE verification logic for TLSA certificate > usage DANE-EE(3). Section 6 should refer to draft-ietf-dane-ops-12 > (soon -13 which responds to AD and GEN-ART comments) as well as > RFC6698. Okay, thanks. > is sub-optimal, it should refer to a TLSA RRset, which MUST contain > at least one TLSA record that matches the server's certificate > chain, but will often contain additional records that do not. That's another issue we're currently working through. We'll have some more thoughtful text in the next revision. > 8. Great care must be taken (with Certificate usages other than > DANE-EE(3)) to ensure that the TLSA record matches a certificate > that is actually part of the server's chain and not just some random > unrelated certificate that happens to be present in the server > certificate message. Many implementors fail to check this. Good point, thanks. > 9. This draft should reiterate the requirement that with certificate > usage DANE-TA(2), the server MUST include the trust-anchor certificate > in its certificate message even if that trust-anchor is self-signed > (root CAs are NOT optional with DANE-TA(2)). Ditto. > 10. Validation of RRSIGs is a subtle art, the client will definitely > need to check not only the signatures but also the validity intervals > of all RRSIGs (the client must trust its own clock or have access > to a trusted time source). Since the server forwards wire-format > RRsets, these include TTLs, and clients might plausibly cache these, > provided the TTLs are consistent with the RRSIG validity intervals. > The draft might provide guidance on any client-side caching (clients > might e.g. not even send the extension when they have unexpired > cached TLSA data from a previous interaction with the server). Will do, but I'm not sure this will make it into the next revision in much detail, given time constraints. But yes, I agree it should go into the document in greater detail in the future. Thanks again, Melind -- Melinda Shore No Mountain Software melinda.shore@nomountain.net "Software longa, hardware brevis." From nobody Tue Jun 30 16: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 5EADF1B2A82 for ; Tue, 30 Jun 2015 16:50:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SI-obchTfdCd for ; Tue, 30 Jun 2015 16:50:26 -0700 (PDT) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::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 9FAB51B2A6C for ; Tue, 30 Jun 2015 16:50:26 -0700 (PDT) Received: by qkeo142 with SMTP id o142so18539454qke.1 for ; Tue, 30 Jun 2015 16:50:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; bh=OmqOLwUS2jLfqt80c7NpG/F3DF1T/+rRAArzYdqMhXI=; b=Y6JLYA+jY/tqhbILWOs1NXHwB+e8eDMhuKpE/4GD4IObWsFJGHixUZvb3oXz2asgrk cVGxJYKBE+NlGad8jWBbZrxFMAcXnfSDj/jfX2Z/ouXHIva7ZR3nyqnHmHQ2d6r+rS/N XO+X5ut4uQR02zcACIH/L3rFv1zIONMmy/fHkpViu81Uss3nLmH5wAXP5UjwaeywTd0u IXHI5s9TzXivdJgXo+YXv8sIPc/j4InOHyc8OB8tWsVv1wQkYZaSxWLie28Zeu0Qb/uo DpMyRD0D2w92BMm1QOBvRZhQzresJ5ZFf2Flj/qkzTw3CRoU8YwDLCeYrC3P4rtY8Wq0 DZkQ== MIME-Version: 1.0 X-Received: by 10.140.148.67 with SMTP id 64mr31502097qhu.74.1435708225347; Tue, 30 Jun 2015 16:50:25 -0700 (PDT) Received: by 10.140.80.208 with HTTP; Tue, 30 Jun 2015 16:50:25 -0700 (PDT) Date: Tue, 30 Jun 2015 19:50:25 -0400 Message-ID: From: Shumon Huque To: "" Content-Type: multipart/alternative; boundary=001a1135636ac5e8520519c4ded2 Archived-At: Subject: [dane] draft: Client Certificates in TLSA records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: shuque@gmail.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2015 23:50:28 -0000 --001a1135636ac5e8520519c4ded2 Content-Type: text/plain; charset=UTF-8 A new draft on DANE/TLSA Client Certificates is available: https://tools.ietf.org/html/draft-huque-dane-client-cert-00 The authors are hoping to have some discussion on list, and in person at IETF93 on this topic. There are 2 owner name formats proposed in the draft, but we might be advocating another simpler one (_service.[client-domain-name]) in the next revision (along with a few more tweaks). I'm working on a separate draft describing a TLS extension to signal DANE client identity (see Section 5 for the rationale for this). That draft won't be ready by the IETF93 draft cutoff, so you should see it shortly after Prague. Thanks, Shumon. --001a1135636ac5e8520519c4ded2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
A new draft on DANE/TLSA Client Certificates is avail= able:

=C2=A0 =C2=A0 https://tools.ietf.org/html/draft-huqu= e-dane-client-cert-00

The authors are hoping to = have some discussion on list, and in person at IETF93 on this topic.
<= div>
There are 2 owner name formats proposed in the draft, bu= t we might be advocating another simpler one (_service.[client-domain-name]= ) in the next revision (along with a few more tweaks).

=
I'm working on a separate draft describing a TLS extension to sign= al DANE client identity (see Section 5 for the rationale for this). That dr= aft won't be ready by the IETF93 draft cutoff, so you should see it sho= rtly after Prague.

Thanks,
Shumon.
=


--001a1135636ac5e8520519c4ded2-- From nobody Tue Jun 30 18:42: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 176251A03D5 for ; Tue, 30 Jun 2015 18:42:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.911 X-Spam-Level: X-Spam-Status: No, score=-101.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 86Rv46WL82IL for ; Tue, 30 Jun 2015 18:42:53 -0700 (PDT) Received: from mail.tcb.net (mail.tcb.net [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id EA9051A0404 for ; Tue, 30 Jun 2015 18:42:52 -0700 (PDT) Received: from dspam (unknown [127.0.0.1]) by mail.tcb.net (Postfix) with SMTP id 75BB6301180 for ; Wed, 1 Jul 2015 01:42:52 +0000 (UTC) Received: from mail2.tcb.net (localhost [127.0.0.1]) by mail.tcb.net (Postfix) with ESMTP id 4815C300FD9 for ; Tue, 30 Jun 2015 19:42:52 -0600 (MDT) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Tue, 30 Jun 2015 19:42:52 -0600 From: Danny McPherson To: In-Reply-To: References: Message-ID: X-Sender: danny@tcb.net User-Agent: Roundcube Webmail/0.8.2 X-DSPAM-Result: Innocent X-DSPAM-Processed: Tue Jun 30 19:42:52 2015 X-DSPAM-Confidence: 1.0000 X-DSPAM-Improbability: 1 in 98689409 chance of being spam X-DSPAM-Probability: 0.0023 X-DSPAM-Signature: 5593459c8678801586966 X-DSPAM-Factors: 27, see+#+action, 0.40000, August+#+from, 0.40000, suspect+a, 0.40000, to+#+#+#+date, 0.40000, been+#+actual, 0.40000, the+mailing, 0.40000, Furthermore+#+see, 0.40000, action+#+#+#+to, 0.40000, effectuated+and, 0.40000, this+#+in, 0.40000, same+#+#+was, 0.40000, 12+41, 0.40000, to+August, 0.40000, normally+#+#+the, 0.40000, or+#+new, 0.40000, well+#+#+#+one, 0.40000, surprised+#+#+this, 0.40000, due+#+to, 0.40000, would+#+blocking, 0.40000, action+#+the, 0.40000, and+#+contributors, 0.40000, the+#+#+#+at, 0.40000, mailing+#+2015, 0.40000, there+#+#+actual, 0.40000, to+#+2016, 0.40000, of+#+MIME, 0.40000, to+#+this, 0.40000 Archived-At: Subject: Re: [dane] Deferral of SMIME draft X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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 Jul 2015 01:42:54 -0000 On 2015-06-29 12:41, Olafur Gudmundsson wrote: > Dear Colleagues > The editors of draft-ietf-dane-smime have requested that draft be put > on hold for at least a year to see how the OPENPGP “experiment” works > out. The chairs have agreed with this request. Given the proliferation of S/MIME use in corporate environments this seems quite short-sighted to me as well (having responsibility for one such environment). I was even more surprised to see this action in the WG milestones datatracker at effectively the same time this was posted to the mailing list: 2015-06-29 Ólafur Guðmundsson Changed milestone "Advance DANE operational guidance/errata document to IESG", set due date to August 2016 from September 2014 I'd have thought changes such as these were normally discussed among the WG before being effectuated and new contributors solicited when appropriate. Furthermore, I see no defensible reason why an "OPENPGP "experiment"" would be blocking on this work - quite the contrary, actually. Had there been an actual discussion on this already-a-year-overdue-WG-milestone I suspect a responsible action would have been to find some new editors. As such, I hereby respectively request that the chairs reconsider this matter or present new facts in support of their decision. Thanks in advance, -danny From nobody Tue Jun 30 19:12: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 7500B1A21AF for ; Tue, 30 Jun 2015 19:12:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ALjje6PN1wZC for ; Tue, 30 Jun 2015 19:12:26 -0700 (PDT) Received: from mail-ie0-f171.google.com (mail-ie0-f171.google.com [209.85.223.171]) (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 D345E1A1BD4 for ; Tue, 30 Jun 2015 19:12:25 -0700 (PDT) Received: by ieqy10 with SMTP id y10so25363528ieq.0 for ; Tue, 30 Jun 2015 19:12:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=xSePhGbOano6CaTzLX+Fyko6itzVGj4jbBCm/YgxOH4=; b=l8jM3vtOm75YNYQJeSLo9Xq7NC+qMpBd3r1xZFcVu1sHeezfrvLmBt4saPhl8X+NXi Aio9EctI75E2Z8+GhoUholviJ82sncl9g8WbjB9Gbfi2koxdXWjEesKjOSns+7lIBZk+ DOyOMKpKTreR/GWZJuFzTvnYfDSnBGeLduOniwCWfdY578i5Malz8U8/Ik9qit0Hoe6D XLBNZNXNr0577Zv2oZuG1YYMnuHAvN0sE8LW3l4Vigc5KfluFDxxFmAlUmaJ8cg6u5gU SBwXit+KvPtX/ZOP+iOW4lcdpV7bcOxODT6RkNqB3uxn5WVA6aW6KvbCcWyKI39WwnuN vwkA== X-Gm-Message-State: ALoCoQnJvVHMJTOwbaG9etHmzpjRRo4ATb5R7X0q1R8eyf/WxY0Nk/vLdWedslH6ytf4PEd8/0Ok X-Received: by 10.107.164.89 with SMTP id n86mr32467941ioe.73.1435716745635; Tue, 30 Jun 2015 19:12:25 -0700 (PDT) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by smtp.googlemail.com with ESMTPSA id h2sm879360igv.2.2015.06.30.19.12.23 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 30 Jun 2015 19:12:24 -0700 (PDT) Message-ID: <55934C85.2060609@andyet.net> Date: Tue, 30 Jun 2015 20:12:21 -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.7.0 MIME-Version: 1.0 To: Danny McPherson , dane@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dane] Deferral of SMIME draft X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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 Jul 2015 02:12:27 -0000 On 6/30/15 7:42 PM, Danny McPherson wrote: > On 2015-06-29 12:41, Olafur Gudmundsson wrote: >> Dear Colleagues >> The editors of draft-ietf-dane-smime have requested that draft be put >> on hold for at least a year to see how the OPENPGP “experiment” works >> out. The chairs have agreed with this request. > > Given the proliferation of S/MIME use in corporate environments this > seems quite short-sighted to me as well (having responsibility for one > such environment). > > I was even more surprised to see this action in the WG milestones > datatracker at effectively the same time this was posted to the mailing > list: > > 2015-06-29 Ólafur Guðmundsson Changed milestone "Advance DANE > operational guidance/errata document to IESG", set due date to August > 2016 from September 2014 > > I'd have thought changes such as these were normally discussed among the > WG before being effectuated and new contributors solicited when > appropriate. > > Furthermore, I see no defensible reason why an "OPENPGP "experiment"" > would be blocking on this work - quite the contrary, actually. Had > there been an actual discussion on this > already-a-year-overdue-WG-milestone I suspect a responsible action would > have been to find some new editors. > > As such, I hereby respectively request that the chairs reconsider this > matter or present new facts in support of their decision. Another approach would be to progress the SMIME document now and update or obsolete it once the results of the OpenPGP experiment are known. Peter -- Peter Saint-Andre https://andyet.com/ From nobody Tue Jun 30 19:51: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 8E9191A896B for ; Tue, 30 Jun 2015 19:51:41 -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 dzKj8HYibBet for ; Tue, 30 Jun 2015 19:51:40 -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 C558B1A896A for ; Tue, 30 Jun 2015 19:51:39 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3mLnBd1J2NzCJd; Wed, 1 Jul 2015 04:51:37 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=Fywe2HYV 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 4c5RRg3-VsRa; Wed, 1 Jul 2015 04:51: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; Wed, 1 Jul 2015 04:51:35 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 47151800B3; Tue, 30 Jun 2015 22:51:34 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1435719094; bh=4AhIwC8qkp99Fx1H/VuoKqy+Mvm45wU3k6tzRoAYsEw=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=Fywe2HYVQadejtN7xovwZEXjJAOO6+RbWWbebjjmQCOdnpR65j2SVFPGPaiCqtsT4 0MZGbx+wBYrvTrkiHcXqbd8YXIiF9StoR2UeBpL1AYRyXENemKLT5mFt3TAOgB0WMq IooJ3iwnwkG+Yu5wJmyNoaT3A/EWeHu0dpNHnmM4= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.15.1/8.15.1/Submit) with ESMTP id t612pXgD029102; Tue, 30 Jun 2015 22:51:33 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Tue, 30 Jun 2015 22:51:33 -0400 (EDT) From: Paul Wouters To: Danny McPherson In-Reply-To: Message-ID: References: User-Agent: Alpine 2.11 (LFD 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] Deferral of SMIME draft X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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 Jul 2015 02:51:41 -0000 On Tue, 30 Jun 2015, Danny McPherson wrote: > Furthermore, I see no defensible reason why an "OPENPGP "experiment"" would > be blocking on this work - quite the contrary, actually. Had there been an > actual discussion on this already-a-year-overdue-WG-milestone I suspect a > responsible action would have been to find some new editors. I actually also do not really understand the decision, other than the authors seeing a hot potato. I still believe it would be in the interest of both the OPENPGPKEY and the SMIMEA drafts that they continue to discuss and attempt to use the same lookup mechanism. iI suspect many software implementors that will implement one, will also implement the other. Since it is mostly a different format for the same idea, attempt to encrypt emails when a public key is advertised. Paul From nobody Tue Jun 30 20:16:08 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 227D41A1A3B for ; Tue, 30 Jun 2015 20:16:07 -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 ZYkPpni2j-Nu for ; Tue, 30 Jun 2015 20:16:05 -0700 (PDT) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) (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 BD0C41A1A36 for ; Tue, 30 Jun 2015 20:16:05 -0700 (PDT) Received: by pabvl15 with SMTP id vl15so15402362pab.1 for ; Tue, 30 Jun 2015 20:16:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=5Xri7a4BeJ5MMfdz01/yjlQjWSyo+vk1jy/3cGKysOo=; b=KG4GG1cMxBApOhZqhomvYkAl5lo9gH/FnNb2g/4zN3R4tG8lOcvHc5ca+hJQ7BAgAt bFNb18yMzWHDGaLq1WxCNq0ivExeb3sF0D5frnIgFzPJ5LxEDvX7VqenDZICvzbbyNjl WF3Nt8mEk5RpRc6k7bkTF0FWtvewKn856GXiqsRirn6WW9eYwKVu2Y37DSiXHqgmYk9Z KQSCJnTb/MG+L5gORhj8y9xcD4bwvoFpjJvv39SYCPWI3VXp3G9qvzvL62B98gd3CpJy ztr8sHBZqBNnmyT0ckY129SCAhM5aDT5ZdB8dZj0Y+7FO+zmBIN4vjKMw6zYXfQwbFEE A49A== X-Received: by 10.67.30.17 with SMTP id ka17mr49624368pad.24.1435720565848; Tue, 30 Jun 2015 20:16:05 -0700 (PDT) Received: from spandex.local (216-67-117-38-rb3.fai.dsl.dynamic.acsalaska.net. [216.67.117.38]) by mx.google.com with ESMTPSA id fa15sm363471pac.25.2015.06.30.20.16.04 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 30 Jun 2015 20:16:05 -0700 (PDT) Message-ID: <55935B73.2080602@gmail.com> Date: Tue, 30 Jun 2015 19:16:03 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Paul Wouters , Danny McPherson References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: dane@ietf.org Subject: Re: [dane] Deferral of SMIME draft X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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 Jul 2015 03:16:07 -0000 On 6/30/15 6:51 PM, Paul Wouters wrote: > I actually also do not really understand the decision, other than the > authors seeing a hot potato. I still believe it would be in the interest > of both the OPENPGPKEY and the SMIMEA drafts that they continue to > discuss and attempt to use the same lookup mechanism. > iI suspect many software implementors that will implement one, will > also implement the other. Since it is mostly a different format for the > same idea, attempt to encrypt emails when a public key is advertised. Yes, to all of this. I really don't understand the reasoning behind this decision, mostly because the only explanation given has been pretty perfunctory. Surely a better option right now would be to find additional editors. Melinda From nobody Tue Jun 30 20:23: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 DFD8E1A1A51 for ; Tue, 30 Jun 2015 20:23:14 -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 OI2WcRw0YoIu for ; Tue, 30 Jun 2015 20:23:14 -0700 (PDT) Received: from hoffman.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 2EB7C1A1A4E for ; Tue, 30 Jun 2015 20:23:14 -0700 (PDT) Received: from [10.20.30.101] (142-254-17-100.dsl.dynamic.fusionbroadband.com [142.254.17.100]) (authenticated bits=0) by hoffman.proper.com (8.15.1/8.14.9) with ESMTPSA id t613NAx1075129 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Jun 2015 20:23:11 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 142-254-17-100.dsl.dynamic.fusionbroadband.com [142.254.17.100] claimed to be [10.20.30.101] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Paul Hoffman In-Reply-To: <55935B73.2080602@gmail.com> Date: Tue, 30 Jun 2015 20:23:10 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <961A61DD-758A-4AD6-84EB-9061C5984347@vpnc.org> References: <55935B73.2080602@gmail.com> To: Melinda Shore X-Mailer: Apple Mail (2.2098) Archived-At: Cc: dane WG list Subject: Re: [dane] Deferral of SMIME draft X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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 Jul 2015 03:23:15 -0000 On Jun 30, 2015, at 8:16 PM, Melinda Shore = wrote: > On 6/30/15 6:51 PM, Paul Wouters wrote: >> I actually also do not really understand the decision, other than the >> authors seeing a hot potato. I still believe it would be in the = interest >> of both the OPENPGPKEY and the SMIMEA drafts that they continue to >> discuss and attempt to use the same lookup mechanism. >> iI suspect many software implementors that will implement one, will >> also implement the other. Since it is mostly a different format for = the >> same idea, attempt to encrypt emails when a public key is advertised. >=20 > Yes, to all of this. I really don't understand the reasoning > behind this decision, mostly because the only explanation given > has been pretty perfunctory. Surely a better option right now > would be to find additional editors. We have plenty of willing editors: what we need is WG interest in = reviewing (not just in asking for us to finish regardless of the open = issues). The open issue in draft-ietf-dane-smime heavily overlap with = those in draft-ietf-dane-openpgpkey, but only a very small number of = people have chimed in on the recent threads. Without sufficient review, there is a good chance that the protocol will = be heavily flawed. Note that the current issues are not the only ones for = draft-ietf-dane-smime. Eric Osterweil brought up many proposals earlier = that died because no one even commented on them. WG consensus by silence = is a good sign that not enough people care about getting the protocol = right. --Paul Hoffman= From nobody Tue Jun 30 20:27: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 554681A1A70; Tue, 30 Jun 2015 20:27:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ebWgKlwoW6OL; Tue, 30 Jun 2015 20:27:15 -0700 (PDT) Received: from mail-qg0-x22d.google.com (mail-qg0-x22d.google.com [IPv6:2607:f8b0:400d: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 9C9A01A1A66; Tue, 30 Jun 2015 20:27:15 -0700 (PDT) Received: by qgem68 with SMTP id m68so13350955qge.0; Tue, 30 Jun 2015 20:27:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=uLwayf64nkEoAjlF+A58u/8TULlEAwQr3Lmq5+nDzGs=; b=oyjod6zZwnwu3Dz9GD5/5qeUKTxRqML+cDzX8vJRPV5mKqwq3n4UbK8pQegrRPemTx OW/oQoqDrzgmzX8UqwgQlXDangFW/qtz2xf+lihCe6O4F+22EWssfUl6v9mYxm2CWj7P DU0mC9qM2xRm3ZGWO35VuzY2oTgxOj4WkC3uxVqBI72W9pdvrdgcYozRFJStLm8uclRW N0O1yOHpGjTY2jUb9/0xGHyQMQhiWq4iE3duopkvFbbv/jbXKEaDKsu63+FHnAEfSYJf o1tB9/GtvSzHJ+hVUxrEQ2f2S7msEEicOAx2BW6IKualEAl1b+XcZ9hlRVemRRf0SC29 tZHA== MIME-Version: 1.0 X-Received: by 10.55.23.17 with SMTP id i17mr50071868qkh.39.1435721235260; Tue, 30 Jun 2015 20:27:15 -0700 (PDT) Received: by 10.140.80.208 with HTTP; Tue, 30 Jun 2015 20:27:15 -0700 (PDT) In-Reply-To: <20150630062518.GC14121@mournblade.imrryr.org> References: <55922571.8080605@nomountain.net> <20150630062518.GC14121@mournblade.imrryr.org> Date: Tue, 30 Jun 2015 23:27:15 -0400 Message-ID: From: Shumon Huque To: tls@ietf.org Content-Type: multipart/alternative; boundary=001a1146fabe3986e30519c7e6ac Archived-At: Cc: "" Subject: Re: [dane] [TLS] draft-shore-tls-dnssec-chain-extension-00 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: shuque@gmail.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2015 03:27:18 -0000 --001a1146fabe3986e30519c7e6ac Content-Type: text/plain; charset=UTF-8 On Tue, Jun 30, 2015 at 2:25 AM, Viktor Dukhovni wrote: Thanks Victor. I'll add a few to Melinda's earlier comments .. On Mon, Jun 29, 2015 at 09:13:21PM -0800, Melinda Shore wrote: > > > Please have a look at it and get comments or suggestions > > to us. We're planning on getting one more revision out > > prior to the Prague meeting, and on having a test > > implementation available in Prague. > > The draft is available at: > > https://tools.ietf.org/html/draft-shore-tls-dnssec-chain-extension-00 > > > 3. I'm not sure what purpose the last paragraph of section 3 is > intended to serve: > > Obviously, an authentication chain will be most compact and easiest > to verify if each RRset has a single record, i.e., if there is a > single DNSKEY RR and a single DS RR at each step. In addition, as > suggested above, keeping zone cuts to a minimum also reduces the > length of the authentication chain. > > The TLS server has no choice but to return the complete RRset for > each owner name class and RRtype, since RRSIGs cover RRsets, not > individual RRs. So "compacting" is possible. The server returns > the RRsets exactly as published by the relevant DNS(SEC) servers. > Yeah, section 3 needs a bit of work. Also, the order of record (sets) in the given example doesn't match the dnssec_chain structure definition - that should be fixed in the next rev. The structure will likely undergo some additional changes too, e.g. names that involve CNAME/DNAMEs might need an authentication tree rather than a single authentication chain, or a sequence of authentication chains. > Speaking of RRsets, are the RRs in each RRset returned by the server > required to be sorted in canonical order? > It would be nice to do so, but not essential - as long as the validator sorts them canonically before signature verification. > 4. I think the Section 4 SNI interaction would be a lot cleaner, > if SNI is mandatory for clients that use the proposed extension. > In which case the server can only respond with a leaf TLSA RRset > (and chain of RRSIG/DNSKEY/DS/... records) whose "base domain" ( > see section 3 of RFC6698 and soon definition of TLSA base domain > in draft-ietf-dane-ops-13 (later this week)). Using some random > name for the server's IP address is not a good idea IMHO. PTR > records are too often poorly correlated with the client's notion > of the target server name. > I agree with this. > 5. In Section 5, the server MUST not violate DNS TTLs. The last > senetence: > > Alternatively, it could be configured to rebuild the chain at some > predefined periodic intervals. > > is I fear too much rope. Sure the server can periodically flush > its cache (using shorter than possible TTLs), but this does not > free it of the obligation to not extend TTLs by relying exclusively > on a cache lifetime of its own choosing. > I agree that is a bit of rope. The first part of the section does tell the validator to do the right thing. The alternative (which would be simpler to implement) was provided for cases where the server operator might know the TTLs and signature validity periods of the chain above it (assuming they are stable), and be able to select a suitable regeneration interval below them. But yes, it provides more opportunity for doing the wrong thing by selecting the wrong interval. Note that the original draft suggested something similar (regenerating the stapled chain into an X.509 cert at some predefined interval). > 11. Finally, Shumon Huque (mostly) and I (helping out) are writing > a draft to specify DANE TLSA for client authentication. If and > when that progresses (WG adoption, ...), there may need to be a > similar extension, allowing a client to forward its DNSSEC-validated > TLSA RRset. This is not an immediate priority and can be re-evaluated > later. > I posted a link to the draft separately on the dane list. But for TLS folks: https://tools.ietf.org/html/draft-huque-dane-client-cert-00 -- Shumon Huque --001a1146fabe3986e30519c7e6ac Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Jun 30, 2015 at 2:25 AM, Viktor Dukhovni <ietf-dane@dukhovni.org= > wrote:

Thanks Victor. I'll add a few to Melinda's earlier= comments ..

On Mon, Jun 29, 2015 at 09:13:21PM -0800, Melinda Shore wrote:

> Please have a look at it and get comments or suggestions
> to us.=C2=A0 We're planning on getting one more revision out
> prior to the Prague meeting, and on having a test
> implementation available in Prague.
> The draft is available at:
> https://tools.ietf.org/htm= l/draft-shore-tls-dnssec-chain-extension-00

=C2=A0
3.=C2=A0 I'm not sure what purpose the last paragraph of section 3 is intended to serve:

=C2=A0 =C2=A0Obviously, an authentication chain will be most compact and ea= siest
=C2=A0 =C2=A0to verify if each RRset has a single record, i.e., if there is= a
=C2=A0 =C2=A0single DNSKEY RR and a single DS RR at each step.=C2=A0 In add= ition, as
=C2=A0 =C2=A0suggested above, keeping zone cuts to a minimum also reduces t= he
=C2=A0 =C2=A0length of the authentication chain.

The TLS server has no choice but to return the complete RRset for
each owner name class and RRtype, since RRSIGs cover RRsets, not
individual RRs.=C2=A0 So "compacting" is possible.=C2=A0 The serv= er returns
the RRsets exactly as published by the relevant DNS(SEC) servers.

Yeah, section 3 needs a bit of work. Also, the o= rder of record (sets) in the given example doesn't match the dnssec_cha= in structure definition - that should be fixed in the next rev. The structu= re will likely undergo some additional changes too, e.g. names that involve= CNAME/DNAMEs might need an authentication tree rather than a single authen= tication chain, or a sequence of authentication chains.


Speaking of RRsets, are the RRs in each RRset returned by the server
required to be sorted in canonical order?

It would be nice to do so, but not essential - as long as the validator = sorts them canonically before signature verification.
=C2=A0
4.=C2=A0 I think the Section 4 SNI interaction would be a lot cleaner,
if SNI is mandatory for clients that use the proposed extension.
In which case the server can only respond with a leaf TLSA RRset
(and chain of RRSIG/DNSKEY/DS/... records) whose "base domain" (<= br> see section 3 of RFC6698 and soon definition of TLSA base domain
in draft-ietf-dane-ops-13 (later this week)).=C2=A0 Using some random
name for the server's IP address is not a good idea IMHO.=C2=A0 PTR
records are too often poorly correlated with the client's notion
of the target server name.

I agree with= this.
=C2=A0
5.=C2=A0 In Section 5, the server MUST not violate DNS TTLs.=C2=A0 The last=
senetence:

=C2=A0 =C2=A0 Alternatively, it could be configured to rebuild the chain at= some
=C2=A0 =C2=A0 predefined periodic intervals.

is I fear too much rope.=C2=A0 Sure the server can periodically flush
its cache (using shorter than possible TTLs), but this does not
free it of the obligation to not extend TTLs by relying exclusively
on a cache lifetime of its own choosing.

I agree that is a bit of rope. The first part of the section does tell th= e validator to do the right thing. The alternative (which would be simpler = to implement) was provided for cases where the server operator might know t= he TTLs and signature validity periods of the chain above it (assuming they= are stable), and be able to select a suitable regeneration interval below = them. But yes, it provides more opportunity for doing the wrong thing by se= lecting the wrong interval. Note that the original draft suggested somethin= g similar (regenerating the stapled chain into an X.509 cert at some predef= ined interval).
=C2=A0
11.=C2=A0 Finally, Shumon Huque (mostly) and I (helping out) are writing a draft to specify DANE TLSA for client authentication.=C2=A0 If and
when that progresses (WG adoption, ...), there may need to be a
similar extension, allowing a client to forward its DNSSEC-validated
TLSA RRset.=C2=A0 This is not an immediate priority and can be re-evaluated=
later.

I posted a link to the draft sep= arately on the dane list. But for TLS folks:


--=C2=A0
Shumon Huque

--001a1146fabe3986e30519c7e6ac--